谷歌浏览器不重新ETAG对前/后(Google Chrome does not revalidate

尽管我发送“缓存控制：必须-重新验证”谷歌浏览器使用在浏览器中来回按钮时使用本地缓存的页面。

原来这是响应的一部分：

HTTP/1.1 200 OK
cache-control: private, must-revalidate
etag: "c9239b5d4b98949f8469a05062e05bb999d7512e"
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

如果我刷新页面，我收到了“HTTP / 1.1 304未修改”响应，但是当我使用后退按钮，我得到如下回应：

Request URL:example.com
Request Method:GET
Status Code:200 OK (from cache)

我在寻找的响应是304或200 OK，是有可能实现这一目标？

Answer 1:

当使用后退和前进按钮，键Cache-Control指令，以防止浏览器返回的页面的缓存副本是no-store 。

闲来无事会有所帮助，并没有别的需要。 你Cache-Control头可以简单地：

Cache-Control: no-store

有两个例外，虽然。

1. Opera和Safari不会不管你设置什么样的头文件（至少版本我测试过）重新验证。 如果你在新标签打开网页，该副本将是新鲜的，但原来的标签将继续浏览时来回，直到您刷新或重新输入该网址，显示陈旧版本。
2. 火狐似乎有一个错误在打开的第一个页面的缓存（即当没有后退按钮）。 页面的所有后续实例将刷新为您导航来回，但一旦你备份一路最上面的页面，它往往还呈现出其初始陈旧的副本。

最后，我要指出，在使用该指令是不是一般的建议，因为它显然对带宽使用显著的影响。 浏览器甚至不能利用Etags获得304 Not Modified的反应，因为它不会有任何副本存储在一个事件使用304收到响应。

Answer 2:

“必须重新验证”指令仅适用后的反应是陈旧的（ RFC2616，仲14.9.4 ）。 由于响应包含既不是“过期”头也不是“最大年龄”的指令时，浏览器可能会处理响应，仍记忆犹新，因此返回的缓存副本。 为了防止这种情况，你应该包括“最大年龄：0”的Cache-Control头（和可能的含过期在过去的日期标头），使缓存立即响应变得陈旧。 另外，以防止缓存，使用“无缓存”指令，而不是“必须重新验证”。

Answer 3:

在no-store缓存指令可以用来指示浏览器不写页面到磁盘缓存。 联合no-cache这应该确保所有的浏览器将从上游，而不是从磁盘获取资源。

Cache-Control: private, no-cache, no-store

文章来源: Google Chrome does not revalidate etag on back/forth