在阅读了有关缓存标头的两天后，我仍然不确定什么是最佳组合，以确保始终从服务器重新获取具有动态内容的PHP页面。
我认为Cache-Control: no-cache标头似乎已足够，并且可能是一个Expires标头，其中包含过去的值以确保与HTTP 1.0代理缓存的兼容性。
Pragma未指定为响应标头：
注意：因为实际上没有指定“Pragma：no-cache作为响应头字段”的含义，它不能为响应中的“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 / { {1}}），使任何缓存都无法使用响应。因此，它似乎完全是多余的。ETag似乎是多余的。proxy-revalidate / public似乎也是多余的，因为任何缓存机制都无法使用响应。private是特定于IE的值，我认为这也是不必要的。我没有使用SSL / HTTPS，因此据说与pre-check=0, post-check=0一起出现的IE8错误不适用于此问题。在按后退/前进按钮时，我也不关心浏览器是使用存储的副本还是重新获取资源。
我的所有假设都是正确的吗？我忽略了什么？或者任何可能的改进？
答案 0 :(得分：1)
我相信你的假设是正确的。我做了很多涉及动态数据的项目，我们从不需要Cache-Control: no-cache（HTTP / 1.1标头）。过去设置Expires:日期也是覆盖HTTP / 1.0用户代理的好习惯。
也就是说，如果您想特别通知请求代理该页面明显不同于先前的访问权限，则可能值得发送基于时间的Etag:标头。这样，任何以前提取的副本将具有不同的Etag，并且代理将知道现在发送的副本是新的。这将略微增加请求标头大小，因为请求将包含先前的Etag（如果有）。