为什么在HTTP响应中应该使用no-cache和no-store？
我被告知要防止用户信息泄漏，只有响应中的“no-cache”是不够的。 “无店”也是必要的。
Cache-Control: no-cache, no-store 在阅读了这个规范http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html之后 ，我还不太清楚为什么。
我目前的理解是，它只是用于中间caching服务器。 即使“no-cache”正在响应，中间caching服务器仍然可以将内容保存到非易失性存储器中。 中间caching服务器将决定是否将保存的内容用于以下请求。 但是，如果响应中存在“无存储”，则中间caching服务器不应该存储该内容。 所以更安全
有没有其他的原因，我们需要“无caching”和“无存储”？
我必须澄清， no-cache并不意味着不caching 。 实际上，在每次请求使用caching的响应之前，这意味着“使用服务器重新validation”。
must-revalidate ，另一方面，只有当资源被视为陈旧时才需要重新validation。
如果服务器说资源仍然有效，那么caching可以用它的表示做出响应，从而减轻了服务器重新发送整个资源的需要。
no-store实际上是完全不caching指令，并且旨在防止以任何forms的caching存储该表示。
我说什么，但请注意在RFC 2616 HTTP规范：
历史缓冲区可以将这些响应作为其正常操作的一部分进行存储
但是这是从较新的RFC 7234 HTTP规范中省略的，可能试图使no-store更强大，请参阅：
在某些情况下，即使Cache-Control: no-cache在响应头中，IE6仍然会caching文件。
W3C的no-cache ：
如果no-cache指令没有指定一个字段名，那么caching不能使用响应来满足后续的请求，而不需要对源服务器进行成功的重新validation。
在我的应用程序中，如果你访问了一个no-cache头的页面，然后退出然后在你的浏览器中，IE6仍然会从caching中抓取页面（没有向服务器发送新的/有效的请求）。 在no-store头中添加停止了这样做。 但是如果你用W3C的话说，实际上没有办法来控制这个行为：
历史缓冲区可以将这些响应作为其正常操作的一部分进行存储。
浏览器历史logging和常规HTTPcaching之间的一般差异在规范的特定子部分中描述。
从HTTP 1.1规范 ：
无店铺 ：
无存储指令的目的是防止无意中释放或保留敏感信息（例如在备份磁带上）。 no-store指令适用于整个消息，可以通过响应或请求发送。 如果在请求中发送，caching不得存储这个请求的任何部分或者对它的任何响应。 如果在响应中发送，caching不得存储这个响应或引发它的请求的任何部分。 该指令适用于非共享和共享高速caching。 在这种情况下，“不得存储”意味着caching不能有意将信息存储在非易失性存储器中，并且必须尽可能尽快地尝试在转发之后尽快从易失性存储器中移除信息。 即使此指令与响应关联，用户也可以在高速caching系统之外明确存储这样的响应（例如，使用“另存为”对话框）。 历史缓冲区可以将这些响应作为其正常操作的一部分进行存储。 该指令的目的是满足某些用户和服务作者的陈述要求，他们担心通过意外访问caching数据结构而意外释放信息。 虽然在某些情况下使用此指令可能会提高隐私，但我们提醒您，这绝不是确保隐私的可靠或充分的机制。 特别是，恶意或者被破坏的caching可能不会识别或遵守这个指令，通信networking可能容易被窃听。
如果你想防止所有的caching（例如，使用后退button时强制重新加载），你需要：
-
没有caching的IE浏览器
-
没有存储的Firefox
这里有我的信息：
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
在正常情况下不需要存储 ，如果浏览器实际上遵循规范，则会妨碍可用性。 它旨在用于HTTP响应包含敏感信息的情况下，即使这会影响浏览器的速度和function，永远不会写入磁盘caching。
怎么运行的：
-
通常，即使用户代理（如浏览器）确定响应是不可caching的，但由于用户代理内部的原因，它仍可能将其存储在磁盘caching中。 它仍然可以用于“查看源代码”，“返回”，“页面信息”等function，用户不一定再次请求页面，但浏览器不认为它是一个新的页面视图。
-
使用无存储function可以防止这种情况的发生，但是可能会影响浏览器给出“查看源”，“返回”，“页面信息”等function，而不会对服务器提出新的请求，这是不可取的。 换句话说，用户可能会尝试查看源代码，如果浏览器没有将其保存在内存中，则可能会被告知这是不可能的，否则会向服务器发出新的请求。 因此，只有当这些function的用户体验不能正常工作或不能正常工作时，才能使用“无存储”function，因为确保内容未被存储在caching中是非常重要的。
我目前的理解是，它只是用于中间caching服务器。 即使“no-cache”正在响应，中间caching服务器仍然可以将内容保存到非易失性存储器中。
这是不正确的。 遵循HTTP 1.1规范的中级caching服务器将遵循no-cache和must-revalidate（或proxy-revalidate）指令，确保内容不被caching。 使用这两个指令将确保响应不会被任何中间cachingcaching，并且所有后续请求都会被发送回原始服务器
如果中间caching服务器不支持HTTP 1.1，那么您将需要使用Pragma：no-cache并希望获得最佳效果。 请注意，如果它不支持HTTP 1.1，那么无存储是无关紧要的。
请注意，从第5版到第8版的Internet Explorer在尝试下载通过https提供的文件以及发送Cache-Control: no-cache的服务器Cache-Control: no-cache或Pragma: no-cache标头时将引发错误。
请参阅http://support.microsoft.com/kb/812935/en-us
Cache-Control: no-store的使用Cache-Control: no-store和Pragma: private似乎是仍然有效的最接近的东西。
对于chrome，no-cache用于在重新访问时重新加载页面，但是如果您返回历史logging（后退button），仍然会caching该页面。 要重新载入历史logging页面，请使用no-store。 IE需要重新validation才能在所有场合工作。
所以只是为了避免我总是使用的所有错误和误解
Cache-Control: no-store, no-cache, must-revalidate
如果我想确保它重新加载。
如果一个caching系统正确地实现了无存储，那么你就不需要no-cache。 但不是全部。 另外，一些浏览器像no-store一样实现no-cache。 因此，虽然没有严格要求，但包括两者可能是最安全的。
阅读更多： http : //palisade.plynt.com/issues/2008Jul/cache-control-attributes/
最初我们在很多年前就使用了no-cache，并且遇到了某些浏览器内容过于陈旧的问题…不幸的是，不记得具体的细节。
我们之后就决定只使用无存储。 从来没有回头，或从任何浏览器或中介机构陈旧的内容单一问题。
这个空间当然是由实现的现实所支配的，而不是在各种RFC中写的。 许多代理人特别倾向于认为，通过取代他们应该遵循的政策来改善绩效。
只是为了让事情变得更糟，在某些情况下，no-cache不能被使用，但是no-store可以：
http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/
