Why both no-cache and no-store should be used in HTTP response?

Question

I'm told to prevent user-info leaking, only "no-cache" in response is not enough. "no-store" is also necessary.

Cache-Control: no-cache, no-store

After reading this spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, I'm still not quite sure why.

My current understanding is that it is just for intermediate cache server. Even if "no-cache" is in response, intermediate cache server can still save the content to non-volatile storage. The intermediate cache server will decide whether using the saved content for following request. However, if "no-store" is in the response, the intermediate cache sever is not supposed to store the content. So, it is safer.

Is there any other reason we need both "no-cache" and "no-store"?

Thanks.

Answer 1

I'm not sure of the specifics of the scenario that the bug manifests itself, but under certain circumstances, IE6 will still cache files even when Cache-Control: no-cache is in the response headers. Adding in no-store seems to fix the problem.

So to answer your question directly, you need it not because it makes any sense, but because IE6 has bugs.

EDIT: Not sure why I'm getting voted down, I realise the technical differences between no-store & no-cache, but that doesn't stop there being a bug in IE6 that means it doesn't conform to these specifications. The W3C states of no-cache:

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server.

However IE6 doesn't always conform to this - I was dealing with exactly this issue a week or so ago. In my application, if you visited a page with the no-cache header, then logged out and then hit back in your browser, IE6 would still grab the page from the cache (without a new/validating request to the server). This is clearly a violation of the W3C specifications and therefore a bug in IE6 (the problem didn't manifest in other browsers). Adding in the no-store header fixes this issue in IE6.

Answer 2

From the www.w3.org http 1.1 definition

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3

no-store:

The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non- shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers MAY store such responses as part of their normal operation. The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive might improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.

Answer 3

Origionally we used no-cache many years ago and did run into some problems with stale content with certain browsers... Don't remember the specifics unfortunately.

We had since settled on JUST the use of no-store. Have never looked back or had a single issue with stale content by any browser or intermediaries since.

This space is certainly dominated by reality of implementations vs what happens to have been written in various RFCs. Many proxies in particular tend to think they do a better job of "improving performance" by replacing the policy they are supposed to be following with their own.

Answer 4

no-store should not be necessary in normal situations, and can impede usability if browsers actually follow the spec as written. It is intended for use where the HTTP response contains information so sensitive it should never be written to a disk cache at all, even if this breaks things like "view source" or the back button. no-cache and must-revalidate are the two instructions you probably want to use.

• Normally, even if a user agent such as a browser determines that a response is uncacheable, it may still store it to the disk cache for reasons internal to the user agent. This version on disk will never be used to satisfy a subsequent request for that resource, but it may still be utilised for features like "view source", "back", "page info", and so on, where the user has not requested a re-request for the resource.

• Using no-store will prevent that happening, but it may impact upon the browser's ability to give "view source", "back", "page info" and so on without making a new request for the server, which is undesirable. In other words, the user may try viewing the source and if the browser didn't keep it in memory, they'll either be told this isn't possible, or it will cause a new request to the server. Therefore, no-store should only be used when the impeded user experience of these features not working properly or quickly is outweighed by the importance of ensuring content is not stored in the cache.

My current understanding is that it is just for intermediate cache server. Even if "no-cache" is in response, intermediate cache server can still save the content to non-volatile storage.

This is incorrect. Intermediate cache servers which follow the HTTP 1.1 specification will obey the no-cache and must-revalidate (or proxy-revalidate) instruction, ensuring that content is not cached. Using these two instructions will ensure that the response is not cached by any intermediate cache, and that all subsequent requests are sent back to the origin server

If the intermediate cache server does not support HTTP 1.1, then you will need to use Pragma: no-cache and hope for the best. Note that if it doesn't support HTTP 1.1 then no-store is irrelevant anyway.

Answer 5

If you want to prevent all caching (e.g. force a reload when using the back button) you need:

• no-cache for IE

• no-store for Firefox

There's my information about this here:

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

Answer 6

Just to make things even worse, in some situations, no-cache can't be used, but no-store can:

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/