正确的缓存标头以确保始终重新获取 PHP 页面答案

【问题标题】：Proper cache headers to ensure PHP pages are always re-fetched正确的缓存标头以确保始终重新获取 PHP 页面
【发布时间】：2014-02-27 23:37:20
【问题描述】：

花了 2 天时间阅读有关缓存标头的内容后，我仍然不确定什么是确保始终从服务器重新获取具有动态内容的 PHP 页面的最佳组合。

我相信Cache-Control: no-cache 标头似乎就足够了，并且可能带有过去值的Expires 标头以确保与HTTP 1.0 代理缓存的兼容性。

编译指示

Pragma 未指定为响应头：

注意：因为“Pragma: no-cache as a response header field”的含义实际上并没有指定，所以它不能为响应中的“Cache-Control: no-cache”提供可靠的替换

响应中Pragma 标头的行为是特定于实现的，我相信当标头已经包含时它不会增加太多：

Cache-Control: no-cache 
Expires: Sat, 01 Jan 2000 00:00:00 GMT

Pragma: no-cache 是非标准的，似乎完全没有必要。

Cache-Control 标头接受许多值，所以这里是我必须的细分：

no-cache 表示将资源视为陈旧并在后续请求中重新验证（通过If-Modified-Since/If-None-Match）。它暗示max-age=0, must-revalidate，所以我不需要那些标题。最近的一些浏览器甚至将no-cache 视为no-store。
no-store 主要与安全有关，以防止将包含敏感数据的响应存储在计算机中。不仅我通常不需要它，而且它似乎也是完全多余的，因为响应带有 Cache-Control: no-cache 标头（必须重新验证）并且没有验证方式（没有 Last-Modified/ETag），使任何缓存都无法使用响应。因此，它似乎完全是多余的。
由于与上述相同的原因，proxy-revalidate 似乎是多余的。
public/private 似乎也是多余的，因为任何缓存机制都无法使用响应。
pre-check=0, post-check=0 是特定于 IE 的值，我认为这也是不必要的。

我没有使用 SSL/HTTPS，所以据说出现在 Cache-Control: no-cache 中的 IE8 错误不适用于这个问题。我也不关心浏览器在按下后退/前进按钮时是使用存储的副本还是重新获取资源。

以上所有假设都正确吗？有什么我忽略的吗？或者有什么可能的改进？

【问题讨论】：

【解决方案1】：

我相信你的假设是正确的。我做过很多涉及动态数据的项目，我们只需要Cache-Control: no-cache（一个HTTP/1.1 标头）。在过去设置一个 Expires: 日期也是涵盖 HTTP/1.0 用户代理的好习惯。

也就是说，如果您想明确告知请求代理该页面与之前的访问完全不同，则可能值得发送一个基于时间的 Etag: 标头。这样，任何之前获取的副本都会有不同的Etag，并且代理会知道现在发送的副本是新的。这将略微增加请求标头的大小，因为请求将包含先前的 Etag（如果有）。

【讨论】：

有没有 HTTP/1.0 用户代理之类的东西？我四处寻找清单，但找不到任何东西。我假设 IE Cache-Control: no-cache 应该足够了，我也会将问题留得更久。
见this 帖子。截至 2010 年，wget 仍然使用 HTTP/1.0。