Why both no-cache and no-store should be used in H

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"?

Answer 1

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/

Answer 2

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 affects the speed and functionality of the browser.

How it works:

• 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. It may still be utilised for features like "view source", "back", "page info", and so on, where the user hasn't necessarily requested the page again, but the browser doesn't consider it a new page view.

• 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 3

If a caching system correctly implements no-store, then you wouldn't need no-cache. But not all do. Additionally, some browsers implement no-cache like it was no-store. Thus, while not strictly required, it's probably safest to include both.

Answer 4

Originally 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.