2

我目前正在开发一个客户端向源服务器发出 HTTP 1.1 请求的系统。我同时控制客户端和服务器软件，因此可以自由支配 HTTP 标头集。客户端之间是多个分层的 Web 代理/缓存设备（想想、Squid 或类似设备）。

源提供的数据通常是高度可缓存的，我打算设置 HTTP 响应标头来表明这一点。具体来说，我打算使用Cache-Control: public, max-age=<value>. 我知道这意味着中间代理会将响应缓存到指定max-age的 ，此时它们将根据源重新验证（可能带有Last-Modified标头，寻找304响应）。

我遇到的问题是客户端可能会意识到缓存持有的数据现在可能无效。在这种情况下，我需要客户端发出一个请求，指示缓存获取或重新验证其对源的响应。如果源响应现在不同，缓存应该存储这个新响应。在我看来，这将涉及客户端发出请求，并且链中的每个缓存都应该重新验证其与下一个上游设备的响应，一直返回到源点。然后可以从最近的实际拥有它的缓存中提供新的响应。

为了实现这一点，需要在客户端请求上设置哪些正确的 HTTP 标头？起初我认为Cache-control: no-cache在 HTTP请求中设置会发生这种情况，但阅读 RFC，似乎这将指示中间缓存既回到原点（期望），又不缓存新响应（不期望） . 然后我看到一篇文章，其中的 HTTP 请求标头Cache-control: max-age=0可能会这样做，但我不确定。

会max-age=0在这里做我需要的，还是我需要其他一些 HTTP 标头组合？

4

1 回答 1

1

我在这里问了一个类似的问题：How to make proxy revalidate resource from origin。从那以后，我了解到在撰写本文时 nginx 不支持代理重新验证。它计划在1.5 版本中发布。

如果来自源的原始响应包含正确的缓存控制标头，则从客户端发送 max-age=0 应该会在代理中触发此重新验证机制。

但是您的上游服务器是否会尊重这些标头并使用它们的来源重新验证显然不是您可以假设的。如果您可以控制上游服务器，我认为它可以工作。

由于标题 afaik，etag 也优于修改。

我发现这些是关于该主题的有用文章：

缓存教程

缓存控制指令

http 验证规范

本规范的第 14.9.4 节

[更新] Nginx 1.5.8 版本已经发布，我可以确认这个机制现在正在工作！

于 2013-12-13T11:37:46.310 回答