HTTP 标头：Cache-Control 是否足够，还是我还需要 Expires？
HTTP 1.1 引入了一类新的标头，即 Cache-Control 响应标头，以使 Web 发布者能够更好地控制其内容，并解决 Expires 的限制。
由于其局限性，过期是一种痛苦。首先，因为涉及到绝对日期，所以Web服务器和客户端缓存上的时钟必须同步；如果他们对时间有不同的想法，则无法实现预期结果，并且缓存可能会错误地将陈旧内容视为新鲜内容。
过期的另一个问题是很容易忘记您已将某些内容设置为在特定时间过期。如果您不在过期时间过去之前更新它，则每个请求都将返回到您的 Web 服务器，从而增加负载和延迟。
那么，我们是否需要再使用 Expires，或者 Cache-Control（具体来说，max-age 设置为某个遥远的未来秒数）对于我的静态内容来说足够了吗？我想避免使用 Expires，但我应该同时设置两者吗？
HTTP 1.1 introduced a new class of headers, Cache-Control response headers, to give Web publishers more control over their content, and to address the limitations of Expires.
Expires is kind of a pain due to its limitations. First, because there’s an absolute date involved, the clocks on the Web server and the client's cache must be synchronized; if they have a different idea of the time, the intended results won’t be achieved, and caches might wrongly consider stale content as fresh.
Another problem with Expires is that it’s easy to forget that you’ve set some content to expire at a particular time. If you don’t update an Expires time before it passes, each and every request will go back to your Web server, increasing load and latency.
So, do we need to use Expires anymore, or is Cache-Control (specifically, max-age set to some far future number of seconds) enough for my static content? I'd like to avoid using Expires, but should I set both?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，同时使用两者被认为是最佳实践，因为即使 HTTP/1.0 代理和客户端也可以理解 Expires（尽管可能很少见）。
几乎所有服务器平台都会为您动态计算 Expires 标头。
Generally speaking, it's considered a best-practice to use both, as Expires will be understood by even HTTP/1.0 proxies and clients (rare though they may be).
Almost all server platforms will dynamically calculate the Expires header for you.