gau*_*430 8 etag caching http browser-cache http-headers
我一直在阅读有关 Etag 的内容,并且我知道有两种生成 Etag 的方法,弱的和强的。弱 Etag 在计算上比强 Etag 更容易生成。我还了解到,弱 Etag 对于大多数用例来说实际上已经足够了。
来自MDN
弱验证器很容易生成,但对于比较来说用处不大。强大的验证器非常适合比较,但很难有效生成。
另一个片段:
相同资源的两种表示形式的弱 Etag 值可能在语义上等效,但逐字节不同。
我发现很难理解资源在语义上相似但不是逐字节相同意味着什么?很高兴看到一些例子。
编辑:在这里找到了一个例子,但我不明白:
弱验证:两种资源表示在语义上是等效的,例如,从业务逻辑的角度来看,某些内容差异并不重要,例如,页面上显示的当前日期对于更新整个资源来说可能并不重要。
是否就像在生成 Etag 时,您可以决定内容的更改对于功能来说并不重要(例如,字体大小的 css 属性更改)并以 304 响应?如果是,那么浏览器上的资源什么时候更新,我猜只要Etag相同,浏览器就不会获取最新版本。在这种情况下,这可能意味着当发生重大更改并创建新的 Etag 时,CSS 属性更改只会与主要更改一起发送到浏览器。
我的建议是查看规范RFC 7232,第 2.1 节。它只有几页长,可以回答您所有的问题。
您要求提供示例,以下是规范中的一些示例:
例如,基于动态测量,内容每秒发生变化的天气报告的表示可能会被分组为具有相同弱验证器的等效表示集(从源服务器的角度来看),以便允许缓存的表示有效在合理的时间内。
如果仅以一秒分辨率定义表示的修改时间,并且表示可能在一秒内被修改两次并在这些修改之间检索,则可能是一个弱验证器。
如果源服务器为应用了 gzip 内容编码的表示发送与为没有内容编码的表示相同的验证器,则该验证器很弱。
最后一个代表了弱 ETag 的最常见用途:服务器在 gzip 内容时将强 ETag 转换为弱 ETag。例如,Nginx 就是这样做的。
该规范还解释了何时更改弱 ETag:
每当源服务器认为先前的表示无法替代当前的表示时,它就应该更改弱实体标签。
换句话说,由您决定资源的两种表示形式是否可以接受替换。如果是,您可以通过为它们提供相同的弱 ETag 来提高缓存性能。
| 归档时间: |
|
| 查看次数: |
6608 次 |
| 最近记录: |