使用 curl 观察 ETag 和 304 —— 手动验证 HTTP 缓存

关于本文
本文使用生成式 AI 的自动化流程创建。我们查阅了 HTTP 条件请求规范和 curl 官方文档，整理了观察 ETag 和 If-None-Match 的方法。

验证状态：📘 已确认 HTTP/curl 官方规范，未进行实际通信

ETag 并不是“浏览器缓存用的神秘字符串”，而是用于向服务器查询当前表现形式是否与之前相同验证器（validator），可以通过实践来观察。

首先尝试

使用会返回 ETag 的公开 URL 执行以下命令。

curl -I https://example.com/

根据目标网站的不同，可能没有 ETag。这种情况下，请不要擅自对其他网站进行大量访问，而应在自己的测试环境或会返回 ETag 的 API 中进行确认。

假设 ETag 是 "abc"，则形式如下。

curl -i -H 'If-None-Match: "abc"' https://example.com/

如果条件成立，可能会返回 304 Not Modified。

观察此处

查看 200 和 304 的区别。在 304 情况下，“可以复用之前拥有的表现形式”，这正是避免重复发送相同正文的机制。

sequenceDiagram
Client->>Server: GET
Server-->>Client: 200 + ETag
Client->>Server: If-None-Match
Server-->>Client: 304 Not Modified

修改一处

故意将 ETag 改为不存在的值。通过观察可以发现，当条件不匹配时，会返回正常的表现形式。

如果在工作中遇到

如果是网页运营人员，有助于理解“更新了却看到旧页面”的现象；如果是 API 负责人，有助于理解“每次都获取大型 JSON”的问题；如果是行政自动化负责人，则有助于理解“每次都处理未变更数据”等场景。

但是，请不要想当然地认为 ETag 就是文件的密码学哈希。其生成方法取决于服务器的实现。

总结

ETag 是亲身体验缓存机制的入口。通过查看响应标头、添加一次 If-None-Match 并观察 200/304 的区别，HTTP 条件请求便会变得十分具体。

官方信息与第一手资料

• RFC 9110 HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110

• curl manual: https://curl.se/docs/manpage.html