我被告知要防止用户信息泄露，仅响应“无缓存”是不够的。 “no-store”也是必须的。
Cache-Control: no-cache, no-store
阅读此规范http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 后，我仍然不太清楚为什么。
我目前的理解是它仅适用于中间缓存服务器。即使响应“无缓存”，中间缓存服务器仍然可以将内容保存到非易失性存储中。中间缓存服务器将决定是否将保存的内容用于后续请求。但是，如果响应中包含“no-store”，则中间缓存服务器不应该存储内容。所以，它更安全。
我们需要“no-cache”和“no-store”还有什么其他原因吗？
【问题讨论】：
no-cache 并不代表你认为的那样。实际上，它的意思是“请重新验证”。
我必须澄清no-cache 并不意味着不缓存。实际上，这意味着在每次请求中使用您可能拥有的任何缓存响应之前“与服务器重新验证”。
另一方面，must-revalidate 只需要在资源被认为陈旧时重新验证。
如果服务器说资源仍然有效，那么缓存可以用它的表示来响应，从而减轻服务器重新发送整个资源的需要。
no-store 实际上是完整的 do not cache 指令，旨在防止以任何形式的缓存存储表示。
我随便说，但请在 RFC 2616 HTTP 规范中注意这一点：
历史缓冲区可以存储此类响应作为其正常操作的一部分
但这在较新的 RFC 7234 HTTP 规范中被省略，可能是为了使no-store 更强大，请参阅：
【讨论】：
Cache-Control: no-store 还不够吗？
no-store，而是将 no-cache 描述为好像根本没有缓存一样......我很困惑！
在某些情况下，即使Cache-Control: no-cache 在响应头中，IE6 仍会缓存文件。
如果 no-cache 指令没有 指定一个字段名，然后是一个缓存 不得使用响应来满足 后续请求没有成功 与源服务器重新验证。
在我的应用程序中，如果您访问了带有 no-cache 标头的页面，然后注销然后在浏览器中回击，IE6 仍会从缓存中获取该页面（无需向服务器发送新/验证请求） .添加 no-store 标头阻止了它这样做。但如果你相信 W3C 的话，实际上没有办法控制这种行为：
历史缓冲区可以存储此类响应，作为其正常操作的一部分。
浏览器历史记录和普通 HTTP 缓存之间的一般差异在in a specific sub-section of the spec 中进行了描述。
【讨论】：
no-store。否则 Chrome 会在使用返回按钮时显示缓存/缓冲数据。
no-cache 标头的响应是不正确的。下面的 W3C 引用清楚地表明情况并非如此。相反，no-cache 标头只是意味着必须重新验证响应，然后才能重用于后续请求。
无商店：
no-store 指令的目的是防止无意中释放或保留敏感信息（例如，在备份磁带上）。 no-store 指令适用于整个消息，并且可以在响应或请求中发送。如果在请求中发送，缓存不得存储此请求的任何部分或对它的任何响应。如果在响应中发送，缓存不得存储此响应或引发它的请求的任何部分。该指令适用于非共享和共享缓存。在这种情况下，“不得存储”意味着缓存不得有意将信息存储在非易失性存储中，并且必须尽最大努力在转发信息后尽快从易失性存储中删除信息。 即使此指令与响应相关联，用户也可能会在缓存系统之外显式存储此类响应（例如，使用“另存为”对话框）。历史缓冲区可以存储这些响应作为其正常操作的一部分。 该指令的目的是满足某些用户和服务作者的既定要求，他们担心通过对缓存数据结构的意外访问而意外释放信息。虽然在某些情况下使用该指令可能会改善隐私，但我们警告说，它绝不是确保隐私的可靠或充分的机制。特别是，恶意或受损的缓存可能无法识别或遵守此指令，并且通信网络可能容易受到窃听。
【讨论】：
no-cache 和 max-age=0 说该项目被认为是陈旧的。这意味着它必须在送达之前重新验证。这意味着缓存可以存储文件，然后执行服务器可以回复304 NOT MODIFIED 的条件请求。这显然是一个巨大的优势，因为不需要生成和发送响应的主体。因此，为了利用这么多（大多数？）缓存将存储no-cache响应。
no-store 在正常情况下不应该是必需的，并且会损害速度和可用性。它适用于 HTTP 响应包含如此敏感的信息，因此根本不应该将其写入磁盘缓存的情况，无论对用户造成的负面影响如何。
它是如何工作的：
通常，即使浏览器等用户代理确定不应缓存响应，由于用户代理内部的原因，它仍可能将其存储到磁盘缓存中。此版本可用于“查看源代码”、“返回”、“页面信息”等功能，其中用户不一定再次请求该页面，但浏览器不会将其视为新页面视图并且提供用户当前正在查看的相同版本是有意义的。
使用no-store 将阻止该响应被存储，但这可能会影响浏览器提供“查看源代码”、“返回”、“页面信息”等的能力，而无需对服务器，这是不可取的。换句话说，用户可能会尝试查看源代码，如果浏览器没有将其保存在内存中，他们要么会被告知这是不可能的，要么会导致对服务器的新请求。因此，no-store 仅应在这些功能无法正常或快速运行的受阻用户体验被确保内容不存储在缓存中的重要性所抵消时使用。
我目前的理解是它仅适用于中间缓存服务器。即使响应为“no-cache”，中间缓存服务器仍然可以将内容保存到非易失性存储中。
这是不正确的。与 HTTP 1.1 兼容的中间缓存服务器将遵循 no-cache 和 must-revalidate 指令，确保内容不被缓存。使用这些指令将确保响应不会被任何中间缓存缓存，并且所有后续请求都将发送回源服务器。
如果中间缓存服务器不支持 HTTP 1.1，那么您将需要使用 Pragma: no-cache 并希望最好。请注意，如果它不支持 HTTP 1.1，那么 no-store 无论如何都无关紧要。
【讨论】：
no-cache 在不牺牲缓存的所有好处的情况下保持严格的新鲜度，这意味着如果服务器以 304 Not Modified 响应，缓存将被存储并再次使用。
no-store 的疑问
如果您想阻止所有缓存（例如，在使用后退按钮时强制重新加载），您需要：
IE 无缓存
Firefox 无商店
这里有我的相关信息：
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
【讨论】：
如果缓存系统正确实现了无存储，那么您就不需要无缓存。但并非所有人都这样做。此外，一些浏览器实现了 no-cache ，就像它是 no-store 一样。因此，虽然没有严格要求，但将两者都包括在内可能是最安全的。
【讨论】：
对于 chrome，no-cache 用于在重新访问时重新加载页面，但如果您返回历史记录（后退按钮），它仍然会缓存它。要重新加载页面以返回历史记录，请使用 no-store。 IE 需要重新验证才能在所有情况下工作。
所以只是为了确保避免我经常使用的所有错误和误解
Cache-Control: no-store, no-cache, must-revalidate
如果我想确保它重新加载。
【讨论】：
请注意，从版本 5 到 8 的 Internet Explorer 在尝试下载通过 https 提供的文件并且服务器发送 Cache-Control: no-cache 或 Pragma: no-cache 标头时会引发错误。
见http://support.microsoft.com/kb/812935/en-us
Cache-Control: no-store 和 Pragma: private 的使用似乎是最接近仍然有效的方法。
【讨论】：
Cache-Control: no-store, no-cache, must-revalidate 以使其正常工作。但是，这在我们的场景中不起作用，但@bassim 上面建议的内容确实如此。谢谢！
最初我们在多年前使用 no-cache，但在某些浏览器上确实遇到了一些陈旧内容的问题......不幸的是，不记得具体细节了。
从那以后，我们决定只使用无商店。从那以后，任何浏览器或中介都没有回头看或遇到过任何过时内容的问题。
这个空间肯定是由实现的现实与碰巧在各种 RFC 中编写的内容所主导。尤其是许多代理人倾向于认为通过用自己的政策替换他们应该遵循的政策，他们在“提高绩效”方面做得更好。
【讨论】：
no-store。
更糟糕的是，在某些情况下，no-cache 不能使用，但 no-store 可以：
http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/
【讨论】：
OWASP 对此进行了讨论：
缓存控制指令：no-cache 和 no-store 有什么区别？
响应中的 no-cache 指令表示该响应不得用于服务后续请求，即缓存不得显示在标头中设置了此指令的响应，但必须让服务器为请求提供服务。 no-cache 指令可以包含一些字段名；在这种情况下，可以从缓存中显示响应，但指定的字段名称应从服务器提供。 no-store 指令适用于整个消息，并指示缓存不得存储响应的任何部分或请求它的任何请求。
我对这些指令完全安全吗？
没有。但通常，除了 Expires: 0 （或充分回溯的 GMT 日期，例如 UNIX 纪元）之外，还同时使用 Cache-Control: no-cache, no-store 和 Pragma: no-cache。即使设置了上述缓存控制指令，非 html 内容类型（如 pdf、word 文档、excel 电子表格等）也经常被缓存（尽管这因版本和额外使用 must-revalidate、pre-check=0、post-check 而异=0、max-age=0 和 s-maxage=0 在实践中有时至少会导致在某些情况下由于浏览器怪癖和 HTTP 实现而在浏览器关闭时删除文件）。此外，“自动完成”功能允许浏览器缓存用户在表单的输入字段中键入的任何内容。要检查这一点，表单标签或单独的输入标签应包含 'Autocomplete="Off" ' 属性。不过需要注意的是，这个属性是非标准的（虽然主流浏览器都支持），所以它会破坏 XHTML 验证。
来源here。
【讨论】：
no-cache 说如果没有服务器的 validating 就不能使用它。如果您的缓存副本仍然很好，服务器将回复 304，然后您使用缓存副本。为您节省潜在的大型网络下载。另一方面，no-store 表示您根本不允许缓存数据。