Chrome和Safari缓存302重定向 [英] Chrome and Safari caching 302 redirect

问题描述

我们已经提出了各种各样的风格，但我还没有看到真正的答案。

我们有一个单独的图像服务，即我们的web应用程序用来获取它的一些图像。图像服务已经过良好测试并且运行正常。为了使其具体，我们的应用程序从 domain.com 提供。 img 元素的 src 元素为 images.domain.com/ {imageId} 。图像服务检索图像的URL并为图像发回一个 HTTP 302 重定向。

该应用程序允许用户更改图像。因此，假设用户 5 具有图片 A 作为个人资料图片，并决定通过上传图片 B 。当用户上传图像时，应用程序缓存将被正确无效并且数据库被更新。该应用程序在 POST 之后执行标准重定向，并且用户在更改图像后重定向到的页面中的一个元素如下所示：

 < img src =example.domain.com/5> 
  

问题在于Chrome从不会调用示例。 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的最新版本。 p>

我们已经看过答案这里和这里，但他们并没有真正回答这个问题。

每节 RFC 2616的第14.9.1部分：

如果no-cache指令没有指定一个字段名称，那么缓存绝不能使用该响应来满足后续请求，而不会对源服务器进行成功的重新验证。这使原始服务器可以防止缓存，即使是被配置为对客户端请求返回陈旧响应的缓存。

除非我们错过了某些东西或做错了事情，看起来Chrome（和Safari）不符合 no-cache 头文件对 302 重定向？任何人都可以在此之前体验过，或有任何见解？ c $ c
$ b我有和你描述的一样疯狂的问题（略有不同，因为它是一个缺失的cookie重定向回登录页面） 。





无奈之下，我遇到了这个开放的WebKit错误，并看到了命运的评论（最后还有一丝希望）：

CachedRawResource现在保持重定向链，并且有一些微不足道的逻辑来检查正确性，但是它远不是完整的（只检查cacheControlContainsNoStore（））。当然，其他资源类型也没有。

新增 no-store 我的缓存控制标题，没有更多的问题。

Various flavors of this have been asked already, but I've yet to see a real answer for this.

We have a separate image service that our web app uses to get some of its images. The image service is well tested and is functioning properly. To make it concrete, our app is served from domain.com. The src element of img elements is images.domain.com/{imageId}. The image service retrieves the URL for the image and sends back a HTTP 302 redirect for the image.

The application allows users to change images. So say a user 5 has image A as a profile image, and decides to change it by uploading image B. When the user uploads the image, the application cache is properly invalidated and the database is updated. The application does a standard redirect after POST and one of the elements in the page that the user is redirected to after changing her image is something like:

 <img src="example.domain.com/5">

The problem is that Chrome never makes the call to example.domain.com/5 to retrieve the image upon the initial redirect or a regular reload of the page, it simply serves image A from the browser cache. A standalone call to example.domain.com/5 correctly returns image B, and a hard refresh or clearing Chrome's cache forces Chrome to request the image's src, which correctly returns image B. Note that I'm not talking about serving either image from the cache after getting a 304 Not Modified response, I'm talking about Chrome deciding not to visit the img src at all and just returning image A. Also, appending some unique query string to the img's src attribute fixes the problem, but that's a hack that we'd rather not have to do.

It's worth noting that Firefox was doing the same thing initially. There were no Cache Control headers in the response initially. We added a Cache Control: no-cache header (and tried no-store as well) to the response header and this fixed the behavior in Firefox, but Chrome and Safari still serve the outdated, cached image without making a call to the image's src.

It looks like this was a longstanding bug in Chromium (https://code.google.com/p/chromium/issues/detail?id=103458) that's allegedly fixed as of about 6 weeks ago, but we're using the most updated version of Chrome.

We've looked at the answers here and here but they don't actually answer the question.

Per section 14.9.1 of RFC 2616:

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.

Unless we're missing something or doing something wrong, it would seem that Chrome (and Safari) are not complying the RFC behavior for no-cache headers for 302 redirects? Anyone experience this before or have any insight?

解决方案

cache-control: no-store

I had the same maddening problem that you described (slightly different in that it was a missing cookie redirect back to the login page) that worked everywhere but Safari.

In desperation, I came across this open WebKit bug and saw the fateful comment (and finally a glimmer of hope):

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.

Added no-store to my cache-control header and no more problem.

这篇关于Chrome和Safari缓存302重定向的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！