据我了解规范，在 RFC 2616 (HTTP/1.1) 中引入的 ETag 是 Last-Modified-Header 的后继者(某种程度上)，建议为软件架构师提供更多信息控制缓存重新验证过程。
如果同时存在缓存验证 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 应该“每次”都会更改，资源会更改。因此，对于具有未更改的 ETag 和 If-Modified-Since-Header 的请求，必须用其他东西作为 304 Not Modified 来响应，这有点矛盾，因为强 ETag 说，资源是未修改。 (不过，这并不是那么致命，因为服务器可以再次发送相同的未更改资源。)
- ...
...好吧。 当我写这篇文章时，问题归结为这个答案:
上述(小的)矛盾是由于弱 ETag 造成的。标记有弱 ETag 的资源可能已经更改，尽管 ETag 没有。因此，在弱 ETag 的情况下，当 ETag 未更改但 If-Modified-Since 中显示的日期不匹配时，用 304 Not Modified 回答是错误的，对吗？
最佳答案
常规(强)ETag 和弱 ETag 之间的区别在于，匹配的强 ETag 保证文件逐字节相同，而匹配的弱 ETag 表示内容在语义上相同。因此，如果文件内容发生变化，那么弱 ETag 也应该发生变化。
在您呈现的场景中，服务器上的文件可能比客户端缓存的副本更新——但由于 ETag 匹配，它在语义上等同于缓存的副本，因此返回 304 响应是可以接受的.
关于http - (弱)ETags 和 Last-Modified，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3043729/