ETag 相对于更新 URL 的优点
ETag 允许浏览器执行条件 GET。仅当相关资源被更改时，才必须重新下载该资源。但是，浏览器仍然需要等待服务器响应其请求。
ETag 的替代方法是在指向资源的 URL 中引入令牌：
http://example.com/css/styles.css?token=134124134
或
http://example .com/css/134124134/styles.css
这两种方法都避免了重新下载未更改的资源。
但是，使用带有令牌的 URL 允许服务器在资源上设置远期到期标头。这节省了条件 GET 所占用的往返时间 - 如果资源未更改，则指向它的 URL 将不会更改。
使用 ETag 与使用令牌的 URL 相比有什么优势吗？
ETags allow browsers to perform conditional GETs. Only if the resource in question has been altered will the resource have to be re-downloaded. However, the browser still has to wait for the server to respond to its request.
An alternative to ETags is to introduce a token into the URL pointing to the resource:
http://example.com/css/styles.css?token=134124134
or
http://example.com/css/134124134/styles.css
Both approaches avoid having to re-download an unchanged resource.
However, using URLs with tokens allows the server to set a far-future expiry header on the resource. This saves the round trip taken up by a conditional GET - if the resource is unchanged then the URL pointing to it will be unchanged.
Are there any advantages to using ETags over URLs with tokens?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为只读资源的主要缺点是，如果我们对所有静态资源都采用这种方法，那么客户端缓存将开始填充各种过时的资源。
另外，请考虑所有将开始保存大量无用文件的中间缓存。
您正在用这种方法对抗网络，如果它变得流行，那么某些东西就必须改变，因为它不是一个可扩展的解决方案。
是否存在某种混合方法，您使用一组有限的令牌并将过期时间设置得足够小，以便旧的缓存资源在重新使用令牌之前会过期？
Etag 还用于读写资源，在这种情况下，我怀疑令牌解决方案不起作用。
The major downside for read-only resources that I see is that if we all took this approach for all static resources then client caches would start to fill with all sorts of out-dated resources.
Also, think of all the intermediary caches that would start holding loads of useless files.
You are fighting against the web with this approach and if it became popular then something would have to change because it is not a scalable solution.
Could there be some kind of hybrid approach where you use a limited set of tokens and set the expiry small enough that an old cached resource would expire before the token was reused?
Etags are also used for read-write resources and in this case the I suspect the token solution just does not work.
我认为最大的区别/潜在优势是配置； URL 设置必须在应用程序内部配置/设置（例如，HTML 实际上必须包含该值）。 ETag 是为整个 Web 服务器配置的，无需修改 HTML 即可利用它们。
此外，当文件指向的文件发生变化时，ETag 也会发生变化（假设它们配置正确）；向 URL 添加令牌将需要一些额外的“东西”来告诉它进行更改（编辑 HTML 的人或某些配置设置等）。
I think the biggest difference/potential advantage would be configuration; The URL setting must be configured/setup inside the application (eg, the HTML actually must include the value). ETags are configured for the entire web server, and the HTML doesn't have to be modified to take advantage of them.
Also, the ETags will (assuming they are configured correctly) change when the file pointed at changes; Adding a token to the URL will require some additional "thing" that tells it to change (either a person editing the HTML or some configuration setting, etc).
有固定的 URI 吗？
Have a constant URI?