避免缓存 http 响应答案

【问题标题】：Avoid caching of the http responses避免缓存 http 响应
【发布时间】：2012-04-10 16:30:24
【问题描述】：

避免任何类型的 http 数据缓存的最终解决方案是什么？我们可以修改客户端和服务器 - 所以我认为我们可以在客户端和服务器之间拆分任务。

客户端可以为每个请求附加一个随机参数http://URL/path?rand=6372637263 - 我的感觉是仅使用这种方式它不能 100% 工作 - 可能有一些智能代理可以检测到… 另一方面，我认为如果 URL 与前一个不同，代理不能简单地决定发回一些缓存的响应。

在服务器上可以控制一堆HTTP头：

Expires: Tue, 03 Jul 2001 06:00:00 GMT
Last-Modified: {now} GMT
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache

对此有什么建议，最好的方法是什么？

【问题讨论】：

标签： http caching http-headers client-server browser-cache

【解决方案1】：

添加标题

Cache-control: private

保证，网关缓存不会缓存此类请求。

我想向您推荐 Fabien Potencier 关于缓存的讲座：http://www.slideshare.net/fabpot/caching-on-the-edge

【讨论】：

很酷的演示文稿。谢谢你。
这并不完全正确。根据我的经验，Akamai CDN 倾向于（倾向于？）忽略这一点，并且仍然很乐意为您缓存您的私人数据。

【解决方案2】：

服务器端缓存控制标头应如下所示：

Expires: Tue, 03 Jul 2001 06:00:00 GMT
Last-Modified: {now} GMT
Cache-Control: max-age=0, no-cache, must-revalidate, proxy-revalidate

避免在客户端重写 URL，因为它会污染缓存，并导致其他奇怪的语义问题。此外：

使用一个Cache-Control 标头（请参阅rfc 2616），因为具有多个条目的行为未定义。此外，第二个缓存控制中的 MSIE 特定条目是 at best redundant。
no-store 是关于数据安全的。（这只意味着不要将其写入磁盘 - 仍然允许缓存将响应存储在内存中）。
Pragma: no-cache 在服务器响应中毫无意义 - 它是一个请求标头，这意味着任何接收请求的缓存都必须将其转发到源。
同时使用 Expires (http/1.0) 和 cache-control (http/1.1) 并不是多余的，因为存在仅使用 http/1.0 或将降级协议的代理。
从技术上讲，根据no-cache，最后修改的标头是多余的，但最好将其保留在那里。
某些浏览器在遇到无法识别的指令后会忽略缓存控制标头中的后续指令 - 所以将重要的内容放在首位。

【讨论】：

我注意到人们仍在关注这个答案。就像互联网上的所有东西一样，它有点过时了——pushstate 确实允许客户端修改 URL——但要格外小心！也请看一下 mod_pagespeed。这会在服务器上处理大量 URL 重写和内容合并。除此之外，我回答中的其余内容仍然有效。
你能解释一下Expires: Tue, 03 Jul 2001 06:00:00 GMT - 这应该是Expires: Thu, 01 Jan 1970 00:00:00 GMT 吗？
@If215：过去的任何时间应该阻止缓存。但是，当您开始与大量计算机交谈时，您会发现人们的时钟电池电量不足、时区配置错误和其他奇怪现象。
注意：虽然这是一件好事，但 GET 仍然可以被代理使用自己的规则缓存。意思是，他们不尊重您的标题。永远。
根据规范，代理继承了与浏览器缓存相关的相同义务。此外，还有一些专门针对中间缓存行为的指令（因为规范中描述了缓存代理）。同意并非所有设备都符合规则，但您的陈述不准确且具有误导性

【解决方案3】：

要禁用缓存，您应该使用

Expires: 0

或者

Cache-Control: no-store

如果你使用一个，那么不应该使用另一个。

【讨论】：