rpm*_*rtz 6 html safari caching google-chrome http
已经提出过各种各样的风味,但我还没有看到真正的答案.
我们有一个单独的图像服务,我们的网络应用程序用它来获取它的一些图像.图像服务经过了充分测试,运行正常.为了使它具体化,我们的应用程序来自domain.com.所述src的元件img的元件是images.domain.com/{imageId}.图像服务检索图像的URL并发回图像的HTTP 302重定向.
该应用程序允许用户更改图像.因此,假设用户5将图像A作为个人资料图像,并决定通过上传图像来更改图像B.当用户上载映像时,应用程序缓存将正确无效并更新数据库.应用程序执行标准重定向后POST,用户在更改其图像后重定向到的页面中的一个元素如下所示:
<img src="example.domain.com/5">
问题是Chrome example.domain.com/5在初始重定向或定期重新加载页面时从不调用来检索图像,它只是提供A来自浏览器缓存的图像. 单独调用以example.domain.com/5正确返回图像B,以及硬刷新或清除Chrome的缓存会强制Chrome请求图像src,从而正确返回图像B.请注意,我不是在谈论在收到304 Not Modified回复后从缓存中提供任何一个图像,我说的是Chrome决定不访问该文件img src而只返回图像A.此外,附加了一些独特的查询字符串到img的src属性可以解决问题,但就是这样,我们宁愿没有做一个黑客.
值得注意的是Firefox最初也在做同样的事情.Cache Control最初的响应中没有标题.我们在响应头中添加了一个Cache Control: no-cache标题(并尝试no-store过),这修复了Firefox中的行为,但Chrome和Safari仍然提供过时的缓存图像而不调用图像src.
看起来这是Chromium中长期存在的错误(https://code.google.com/p/chromium/issues/detail?id=103458),据称大约在6周前修复了,但我们使用的最多Chrome的更新版本.
我们已经在这里和这里查看了答案,但他们实际上并没有回答这个问题.
如果no-cache指令没有指定字段名,那么缓存绝不能使用响应来满足后续请求,而不能成功地与源服务器重新验证.这允许源服务器甚至通过已配置为返回对客户端请求的陈旧响应的缓存来防止缓存.
除非我们遗漏某些内容或做错了什么,否则Chrome(和Safari)似乎不遵守重定向no-cache标头的RFC行为302？任何人以前都有这种经历或有任何见解？
请阅读此内容.. https://www.hochmanconsultants.com/articles/301-versus-302.shtml
Chrome 具有相当激进的缓存。
当您使用临时重定向时，您基本上是在说实际 URL 暂时不可用，因此请改用其他 URL。Chrome 正确地缓存了旧 URL，因为它仍然有效。请尝试改用 301。那么 Chrome 应该知道原始 URL 不再有效。