Github API 条件请求、ETag 或 Last-Modified 哪个更可靠？答案

【问题标题】：Which is more reliable for Github API Conditional Requests, ETag or Last-Modified?Github API 条件请求、ETag 或 Last-Modified 哪个更可靠？
【发布时间】：2015-03-19 13:16:39
【问题描述】：

Github API 指定了两个可以在条件请求中使用的标头，Last-Modified 和 ETag。查询 API 时哪个更可靠？

对于上下文：当在大型 repo 的每个子目录上使用 api 端点 GET /repos/:owner/:repo/git/trees/:sha 时，每个响应都包含相同的 last-modified 值（即使 github 上的 repo 显示不同的创作日期），而 etag 值每个都是不同的。我想知道ETag 是否是回购内容状态变化的更精细表示（用于缓存目的）。

【问题讨论】：

标签： github-api etag last-modified

【解决方案1】：

不幸的是，至少在 2019 年 8 月 1 日的状态下，GitHub API 和 /releases/latest 端点，ETag 没有给出一致的值。

大多数情况下它会为您提供一致不变的ETag 值，但随机（有时经常）ETag 会有所不同。请参阅我的示例，我运行了几次 API 调用：

curl -IsL -H "Accept-Encoding: gzip" https://api.github.com/repos/mautic/mautic/releases/latest | grep -P '^(HTTP/|ETag:|X-RateLimit-Remaining|Last-Mod)'

第一个结果：

HTTP/1.1 200 OK
X-RateLimit-Remaining: 56
ETag: W/"b86f015c353e7c1d773f1f781d4cf822"
Last-Modified: Mon, 25 Mar 2019 23:14:15 GMT

一段时间后：

HTTP/1.1 200 OK
X-RateLimit-Remaining: 59
ETag: W/"9f670edf97e04c5c23cce74457be61a3"
Last-Modified: Mon, 25 Mar 2019 23:14:15 GMT

请注意Last-Modified 是如何保持不变的，因此与ETag 相比，仅使用该标头执行条件GET 将导致更好的API 缓存能力。

【讨论】：

【解决方案2】：

阅读“ETags: a pretty sweet feature of HTTP 1.1”，它说：

“ETags allow dynamic content to be cached using an app-specific "opaque token"”

ETag 或实体标签是一个不透明的令牌，用于标识特定 URL 所服务的组件的版本。令牌可以是引号中的任何内容；通常是内容的 md5 哈希，或内容的 VCS 版本号。

如果答案内容相同，则ETag每次都应该相同。

我刚刚用https://api.github.com/repos/VonC/gopanic/git/trees/master对其进行了测试，实际上它的ETag即使在重复调用时仍然是W/"34a03ea1d4dc0b5d533ecf8d36492879"。

但是如果我获取每个子文件夹的树，那么 ETag 会有所不同，因为它代表不同响应内容的签名。

ETag 的优点是它不依赖于日期（其时钟可能因各种原因而变化），而是依赖于答案的内容：如果未更改，则表示发送的内容与发送的内容相同之前发过。

【讨论】：

谢谢 - 似乎ETag 标头显示了正确的状态更改，而Last-Modified 标头与整个存储库相关（使用 github api 时）。
我认为有一个错误，因为每次获取引用时我都会得到 304，即使有新的提交也是如此。更新以使用 etag 而不是 last-modified 修复了问题
如果ETag 与Authorization 标头一起使用发送令牌，则每次使用一个令牌发出请求都会响应304，以防文档没有更改，但如果您发送相同的 ETag 但使用不同的令牌，端点将以 200 响应，无论文档是否更改。那么有没有办法知道文档是否发生了变化，但没有中继发送的令牌？考虑到所有 github api 端点的 Last-Modified 标头都不可用（响应标头中缺少）。
@p1nox 我不知道，但这本身应该是一个好问题。