Chrome 和 Safari 缓存 302 重定向

Question

已经问过各种各样的问题，但我还没有看到真正的答案。

我们有一个单独的图像服务，我们的网络应用使用它来获取它的一些图像。图像服务经过良好测试并且运行正常。具体来说，我们的应用程序来自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 决定根本不访问imgsrc，而只是返回图像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。

我们查看了here 和here 的答案，但他们实际上并没有回答问题。

每个部分14.9.1 of RFC 2616：

如果 no-cache 指令未指定字段名称，则缓存不得使用响应来满足后续请求，而无需与源服务器成功重新验证。这允许源服务器阻止缓存，即使缓存已配置为向客户端请求返回陈旧响应。

除非我们遗漏了什么或做错了什么，否则 Chrome（和 Safari）似乎不符合 302 重定向的 no-cache 标头的 RFC 行为？有没有人经历过这种情况或有任何见解？

Answer 1

cache-control: no-store

我遇到了与您描述的相同的令人抓狂的问题（略有不同，因为它缺少 cookie 重定向回登录页面），但在 Safari 之外的任何地方都可以使用。

在绝望中，我偶然发现了this open WebKit bug，并看到了致命的评论（终于看到了一线希望）：

CachedRawResource 现在保留重定向链，并有一些用于检查正确性的简单逻辑，但还远未完成（仅检查 cacheControlContainsNoStore()）。当然，其他资源类型没有任何东西。

将no-store 添加到我的cache-control 标头中，不再有问题。

Answer 2

请阅读此内容.. https://www.hochmanconsultants.com/articles/301-versus-302.shtml

Chrome 有相当激进的缓存。

当您使用临时重定向时，您基本上是在说实际 URL 暂时不可用，因此请改用这个其他 URL。 Chrome 会正确缓存旧 URL，因为它仍然有效。请尝试使用 301。那么 Chrome 应该知道原来的 URL 不再有效。