Etag:弱示例与强示例

Question

我一直在读关于Etags的文章，我知道产生Etag的方法有两种，弱的和强的。弱的Etags在计算上比强的更容易生成。我还了解到，对于大多数用例来说，弱的Etags实际上已经足够了。

来自MDN

弱的验证器很容易生成，但对比较却没有多大用处。强验证器是比较理想的，但很难高效地生成。

另一个片段：

相同资源的两个表示形式的弱Etag值可能在语义上是等价的，但不是字节对字节相同的。

我发现很难理解资源在语义上是相似的，但不是字节相同的，这意味着什么？很高兴看到一些例子。

编辑:找到一个示例这里，但我不明白：

弱验证:这两种资源表示在语义上是等价的，例如，从业务逻辑的角度来看，一些内容差异并不重要，例如显示在页面上的当前日期对于更新页面的整个资源可能不重要。

是否就像在生成Etag时，您可以决定内容的更改对功能不重要(例如，对于字体大小的css属性更改)，并以304响应？如果是，那么什么时候在浏览器上更新资源，我猜只要Etag是相同的，浏览器就不会得到最新的版本。在这种情况下，这可能意味着当发生重大更改并创建新的Etag时，css属性更改将与主要更改一起发送到浏览器。

Answer 1

我的建议是看一下规范，RFC 7232，第2.1节。它只有几页长，可以回答你所有的问题。

您询问了一些示例，下面是规范中的一些示例：

• 例如，基于动态测量，每秒钟变化一次的天气报告的表示可以与同一弱验证器组合成一组等效的表示(从源服务器的角度来看)，以允许缓存的表示在合理的时间内有效。
• 一个表示法的修改时间，如果仅用一秒的分辨率定义，可能是一个弱验证器，如果表示可以在一秒内被修改两次，并在这些修改之间检索到。
• 如果源服务器为应用gzip内容编码的表示发送相同的验证器，则该验证器是弱的。

最后一种可能是弱ETags最常见的用法:服务器在压缩内容时将强ETags转换为弱的。例如，是Nginx干的。

规范还解释了何时更改弱ETag：

源服务器应该更改弱实体标记，只要它认为以前的表示形式是不可接受的，作为当前表示的替代。

换句话说，由您来决定一个资源的两个表示是否是可接受的替代。如果是的话，您可以通过给它们提供相同的弱ETag来提高缓存性能。