已经有人问过各种各样的问题，但我还没有看到真正的答案。
我们有一个单独的图像服务，我们的网络应用程序使用它来获取它的一些图像。图像服务已经过良好测试并且运行正常。具体来说，我们的应用程序由 domain.com 提供。 img 元素的 src 元素是 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 属性可以解决问题，但这是一种我们宁愿不必做的 hack。
值得注意的是，Firefox 最初也在做同样的事情。最初响应中没有 Cache Control header 。我们向响应 header 添加了一个 Cache Control: no-cache header (并尝试了 no-store)，这修复了 Firefox 中的行为，但 Chrome 和 Safari 仍然在不调用图像的 src 的情况下提供过时的缓存图像。
这似乎是 Chromium 中的一个长期存在的错误 (https://code.google.com/p/chromium/issues/detail?id=103458)，据称已在大约 6 周前修复，但我们使用的是最新版本的 Chrome。
我们查看了答案 here和 here但他们实际上并没有回答这个问题。
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
除非我们遗漏了什么或做错了什么，否则 Chrome(和 Safari)似乎不符合 302 的 no-cache header 的 RFC 行为重定向？任何人以前都经历过这种情况或有任何见解？
最佳答案
缓存控制:无存储
我遇到了与您描述的相同的令人抓狂的问题(略有不同，因为它是缺少 cookie 重定向回登录页面)，但 Safari 除外。
无奈之下，偶遇this open WebKit bug并看到了致命的评论(终于看到了一线希望):
CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.
将 no-store 添加到我的 cache-control header 中，不再有问题。
关于html - Chrome 和 Safari 缓存 302 重定向，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22495231/