（弱）ETags和Last-Modified

Question

据我所知，规范中，RFC 2616（HTTP / 1.1）中引入的ETag是Last-Modified-Header的后续版本，它可以为软件架构师提供更多功能。控制缓存重新验证过程。

如果存在Cache-Validation-Headers（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中的Date表示如此。 （如果呈现的ETag匹配，服务器应该在GET或HEAD请求的情况下响应304 Not Modified ...）

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

• 强大的ETag应该每次都改变''，资源会发生变化。所以，不得不用其他东西作为304 Not Modified来回应一个没有改变的ETag和一个If-Modified-Since-Header的请求，这是一个矛盾，因为强大的ETag说，资源是没有修改。 （虽然这不是致命的，因为服务器可以再次发送相同的未更改资源。）
• ...

... o.k. 当我写这篇文章的时候，问题就是这个答案：

上面提到的（小）矛盾是因为弱ETag。标有弱ETag的资源可能已经改变，尽管ETag没有。所以，在弱ETag的情况下，回答304 Not Modified，当ETag没有改变，但是If-Modified-Since中出现的日期不匹配时，对吗？

Answer 1

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

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