为什么ETag不足以使浏览器缓存无效？

Question

我已经阅读了很多关于这个问题的相关文章，还有关于HTTP缓存的非常好的文章： https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en#invalidating-and-updating-cached-responses 但我现在还不清楚：

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

Answer 1

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

• https://jakearchibald.com/2016/caching-best-practices/
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag

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

  

如果用户再次访问给定的URL（设置了ETag），并且陈旧，这太旧而不能被视为可用，则客户端将发送其ETag的值在If-None-Match标题字段中......

客户将使用ETag在资源变为“陈旧”时重新验证资源。但是什么构成＆＃34;陈旧＆＃34;？

这是Cache-Control标头派上用场的地方。可以通过响应发送Cache-Control标头，让客户端知道客户端可以缓存项目多长时间，直到它被认为是陈旧的。例如，Cache-Control: no-cache表示该资源应立即被视为过时。有关可用的缓存控制值的详细信息，请参阅MDN Cache-Control page。

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

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

其他资源：

• Difference between no-cache and must-revalidate
• What's default value of cache-control?

直接回答您的问题：

• 为什么不发送ETag标头足以使特定资源的浏览器缓存无效？ - 因为在缓存条目被认为是陈旧的情况下，ETag标头未经过验证，例如通过Cache-Control响应标头中设置的到期日期。
• 为什么每个人都建议实际更改资源的URL /文件名以强制浏览器重新下载文件？ - 更改URL /文件名或添加查询字符串将强制客户端避免使用缓存。这很简单，几乎可以保证缓存破坏。这并不意味着它是必要的，但它在浏览器行为不一致的情况下往往是安全的。
• 如果浏览器已经使用特定的ETag缓存了文件并且在服务器上修改了ETag，那还不够吗？ - 从技术上讲，只要适当的话，它就足够了包含Cache-Control标头（包括Pragma和Expires标头）。有关详细信息，请参阅How to control web page caching, across all browsers?。