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

Question

我已经阅读了很多与此相关的文章，也阅读了有关HTTP缓存的很好的文章：https : //developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl = en＃无效并更新缓存的响应， 但我仍然不清楚：

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

Answer 1

我发现以下页面有帮助：

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

MDN的ETag页面中的这一行共享关键点（添加了重点）：

如果用户再次访问给定的URL（已设置ETag），并且该URL是过时的，那么就太旧了以至于无法使用，客户端将在If-None-Match标头字段中发送其ETag的值。 ..

一旦资源变为“陈旧”，客户端将使用ETag重新验证资源。但是什么构成“陈旧”？

这是Cache-Control标头派上用场的地方。可以将Cache-Control标头与响应一起发送，以使客户端知道客户端可以将项目缓存多长时间，直到应将其视为过时为止。例如，Cache-Control: no-cache将指示应立即将资源视为过时的资源。有关可用的缓存控制值的更多信息，请参见MDN缓存控制页面。

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

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

其他资源：

• 无缓存和必须重新验证之间的区别
• 缓存控制的默认值是什么？

要直接回答您的问题：

• 为什么发送ETag标头不足以使特定资源的浏览器缓存无效？-因为直到缓存条目被认为是过时的，ETag标头才被验证，例如通过在Cache-Control响应标头中设置的到期日期。
• 为什么每个人都建议实际更改资源的URL /文件名以强制浏览器重新下载文件？-更改URL /文件名或添加查询字符串将迫使客户端避免使用缓存。这很简单，实际上是保证清除缓存的方法。这并不意味着它是必需的，但在浏览器行为不一致的领域中它通常是安全的。
• 如果浏览器已经使用特定的ETag缓存了文件，并且在服务器上修改了ETag，那还不够吗？-从技术上讲，只要包含适当的Cache-Control标题（包括Pragma和Expires标题）就足够了。请参阅如何在所有浏览器中控制网页缓存？更多细节。