我目前正在开发一个客户端发出源服务器的HTTP 1.1请求的系统。我控制客户端和服务器软件，因此可以自由设置HTTP标头。客户端之间是Web代理/缓存设备的多个分层层（想想，Squid或类似的）。
原点提供的数据通常是高度可缓存的，我打算设置HTTP响应头来表明这一点。具体来说，我打算使用Cache-Control: public, max-age=<value>。我理解这意味着中间代理会将响应缓存到指定的max-age，此时它们将针对原点重新验证（可能使用Last-Modified标头，寻找304响应）。
我遇到的问题是客户端可能会意识到缓存保存的数据现在可能无效。在这种情况下，我需要客户端发出请求，指示缓存获取或重新验证其对源的响应。如果原始响应现在不同，则缓存应存储此新响应。在我看来，这将涉及客户端发出请求，并且链中的每个缓存应该重新验证其对下一个上游设备的响应，一直回到原点。然后可以从实际拥有它的最近的缓存中提供新的响应。
为实现此目的，需要在客户端请求上设置正确的HTTP标头是什么？起初我认为在HTTP 请求中设置Cache-control: no-cache会使这种情况发生，但是阅读RFC，似乎这将指示中间缓存返回原点（需要）但也不缓存新的响应（不需要）。然后我看到一篇文章，其中Cache-control: max-age=0的HTTP请求标题可能会这样做，但我不确定。
max-age=0会在此处执行我需要的操作，还是需要其他一些HTTP标头组合？
答案 0 :(得分：1)
我在这里问了一个类似的问题：How to make proxy revalidate resource from origin。我知道在撰写本文时nginx不支持代理重新验证。它安排在1.5 release。
如果来自原点的原始响应包含正确的缓存控制标头，则从客户端发送max-age = 0应该在代理中触发此重新验证机制。
但是，您的上游服务器是否会尊重这些标头并重新验证它们的来源显然不是您可以假设的。如果您可以控制上游服务器，我认为它可以正常工作。
此外，etag优于自标题后修改。
我发现这些是关于这个主题的有用文章：
[UPDATE] Nginx 1.5.8版本已经发布，我可以确认这个机制现在正在运行！