18

据我了解规范，在 RFC 2616 (HTTP/1.1) 中引入的 ETag 是 Last-Modified-Header 的继承者（某种意义上），它旨在让软件架构师对缓存重新验证过程。

如果缓存验证标头（If-None-Match 和 If-Modified-Since）都存在，根据 RFC 2616，客户端（即浏览器）在检查资源是否已更改时应使用 ETag。根据 RFC 2616 的第 14.26 节，如果 If-None-Match-Header 中出现的 ETag 已更改，服务器不得以 304 Not Modified 响应，并且服务器必须忽略额外的 If-Modified-Since-Header ，如果存在。如果呈现的 ETag 匹配，他不得执行请求，除非 Last-Modified-Header 中的日期如此说明。（如果呈现的 ETag 匹配，则服务器应在 GET 或 HEAD 请求的情况下以 304 Not Modified 响应...）

本节为一些猜测留下了空间：

  • 一个强大的 ETag 应该“每次”都改变，资源会改变。因此，必须以 304 Not Modified 之类的其他内容响应具有未更改的 ETag 和 If-Modified-Since-Header，不匹配的请求有点矛盾，因为强 ETag 说，资源是未修改。（不过，这并不是那么致命，因为服务器可以再次发送相同的未更改资源。）
  • ...

...好的，当我写这篇文章时，问题正在归结为这个答案：

上述（小）矛盾是由于弱 ETags 造成的。标有 Weak ETag 的资源可能已更改，尽管 ETag 没有。因此，如果是弱 ETag，当 ETag 未更改但 If-Modified-Since 中显示的日期不匹配时，以 304 Not Modified 回答是错误的，对吧？

4

1 回答 1

19

常规（强）ETag 和弱 ETag 之间的区别在于，匹配的强 ETag 保证文件是逐字节相同的，而匹配的弱 ETag 表明内容在语义上是相同的。因此，如果文件内容发生变化，弱 ETag 也应该发生变化。

在您呈现的场景中，服务器上的文件可能比客户端中的缓存副本更新 - 但由于 ETag 匹配，它在语义上等同于缓存副本，因此返回 304 响应是可以接受的。

于 2010-06-16T04:41:57.653 回答