1

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

这是 ETags 应该如何与 GET 一起工作的吗？

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

编辑

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

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

所以我猜在启用 ETags 的情况下，除非有充分的理由使用缓存版本，例如没有网络，否则客户端将始终有条件地获取。

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

编辑

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

当 ETags 被启用并且 Max-Age 在遥远的未来时，用户代理是否应该总是使用条件 GET 而不是使用以前缓存的新响应？

4

2 回答 2

1

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

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

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

答案在 RFC 中：

10.3.5 304 未修改

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

所以，是的。

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

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

如果您不打算使用条件请求（If-Match等等），您可能确实会省略 ETag 计算和处理。

于 2013-07-08T11:10:19.250 回答