为什么仅使用ETag无法使浏览器缓存失效？

Question

为什么仅使用ETag无法使浏览器缓存失效？

17

我已经阅读了许多相关文章，还有这里介绍的非常好的关于HTTP缓存的文章：https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en#invalidating-and-updating-cached-responses但是对我来说仍然不清楚：

为什么发送ETag头不能足以使浏览器缓存失效？为什么每个人都建议实际更改资源的URL /文件名以强制浏览器重新下载文件？如果浏览器已经使用特定的ETag缓存了文件，并且在服务器上修改了ETag，那么这是否足够？

- AsGoodAsItGets

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Mike Hill · Accepted Answer

我发现以下页面很有帮助：

这行来自MDN的ETag页面，分享了关键点（已加重强调）：

如果用户再次访问已设置ETag的给定URL，并且它已经过期而不可用，客户端将在If-None-Match标头字段中发送其ETag的值...

客户端将使用ETag在资源变得“陈旧”后重新验证资源。但是什么构成“陈旧”？

这就是Cache-Control标头派上用场的地方。可以通过响应发送Cache-Control标头以告知客户端可以缓存项目的时间，直到应将其视为过时。例如，Cache-Control：no-cache表示应立即将资源视为过时。有关可用Cache-Control值的更多信息，请参见MDN Cache-Control页面。

当浏览器尝试处理被视为过时的缓存资源的请求时，它将首先使用资源的最后一个ETag值通过If-None-Match请求标头向服务器发送重新验证请求，如MDN的ETag页面所述。它还可以使用Last-Modified响应标头作为If-Modified-Since请求标头的辅助选项。

如果服务器确定客户端的ETag值（在If-None-Match请求头中）是当前的，则它将用一个304（未修改）HTTP状态代码和一个空的正文来响应，表示客户端可以使用缓存条目。否则，服务器将用一个200 HTTP状态代码和新的响应正文来响应。

其他资源：

直接回答您的问题：

为什么只发送 ETag 标头不足以使特定资源的浏览器缓存失效？ -- 因为 ETag 标头在缓存条目被视为过期（例如通过在 Cache-Control 响应标头中设置的到期日期）之前不会得到验证。
为什么每个人都建议实际更改资源的 URL/文件名以强制浏览器重新下载文件？ -- 更改 URL/文件名或添加查询字符串将强制客户端避免使用缓存。这很简单，几乎可以保证缓存破坏。这并不意味着必须这样做，但在不一致的浏览器行为领域中，它往往是安全的。
如果浏览器已经使用特定 ETag 缓存了文件，并且服务器上修改了 ETag，那么这是否足够？ -- 从技术上讲，只要包括适当的 Cache-Control 标头（包括 Pragma 和 Expires 标头），就应该足够。有关更多详细信息，请参见如何控制所有浏览器上的网页缓存？。