带有 ETag 的客户端总是执行条件 GET

Question

我正在开发一个新的 API。启用 ETags 后，Chrome 总是有条件地 GET 一个具有较长缓存生命周期的资源，也就是说，Chrome 在没有先确认 ETag 的情况下不再使用缓存版本。

ETag 应该这样与 GET 一起工作吗？

如果是这样，并且考虑到我不需要它们来进行更新竞争检查，我将删除 ETag 并减轻我的服务器正在做的额外工作。

编辑

我本以为 Chrome 会根据 max-age 使用缓存项，直到它过期，然后使用条件 GET 来更新其缓存项。

在我写这篇文章时，我现在想到它无法“更新其缓存项”，因为 304 不包含用于延长到期时间的 max-age。

所以我猜想启用 ETags 后，客户端将始终有条件地 GET，除非有充分的理由使用缓存版本，例如没有网络。

因此，当不需要并发控制时，ETag 似乎会损害服务器性能。

编辑

我想我已经猜到了答案（上图），但简而言之就是这个问题：

当启用 ETag 并且 Max-Age 远在未来时，用户代理是否应该始终使用条件 GET 而不是使用先前缓存的新响应？

Answer 1

您在浏览器中加载页面的方式可能与此处相关：

• 如果您按 Ctrl 并使用刷新按钮重新加载页面，这将导致您的资源无条件重新加载并返回 200s。
• 如果您只是使用刷新按钮（或 F5 等等效键）重新加载，则会发送条件请求，并为静态资源返回 304。
• 如果您在地址框中按 Enter 键，将页面添加到书签并从那里加载，或者从超链接访问页面，缓存 max-age 应该会按预期工作。

Answer 2

启用 ETags 后，Chrome 总是有条件地获取具有较长缓存生命周期的资源，[...] ETags 应该如何与 GET 一起工作？

答案在 RFC 中：

10.3.5 304 Not Modified

如果客户端已经执行了一个有条件的 GET 请求并且访问是 允许，但文档没有被修改，服务器应该 使用此状态码进行响应。

所以，是的。

如果这不是您期望的答案，您可能希望在问题中包含一些实际流量，以显示您期望和实际获得的请求-响应对的顺序。

考虑到我不需要它们来进行更新竞赛检查

如果你不打算使用条件请求（If-Match之类的），你确实可以省略ETag计算和处理。