具有ETag的客户端始终执行条件GET

Question

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

这是ETag应该如何与GET一起使用？

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

修改

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

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

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

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

修改

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

如果启用了ETag并且Max-Age将来很远，那么User Agents是否应该使用条件GET而不是使用先前缓存的新响应？

Answer 1

如何在浏览器中加载页面可能与此相关：

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

Answer 2

  

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

答案在RFC中：

  

10.3.5 304 Not Modified

     

如果客户端执行了条件GET请求并且访问权限是      允许，但文件尚未修改，服务器应该      回复此状态代码。

所以，是的。

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

  

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

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