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

Solution 1

I must clarify that no-cache does not mean do not cache. In fact, it means "revalidate with server" before using any cached response you may have, on every request.

must-revalidate, on the other hand, only needs to revalidate when the resource is considered stale.

If the server says that the resource is still valid then the cache can respond with its representation, thus alleviating the need for the server to resend the entire resource.

no-store is effectively the full do not cache directive and is intended to prevent storage of the representation in any form of cache whatsoever.

I say whatsoever, but note this in the RFC 2616 HTTP spec:

History buffers MAY store such responses as part of their normal operation

But this is omitted from the newer RFC 7234 HTTP spec in potentially an attempt to make no-store stronger, see:

https://www.rfc-editor.org/rfc/rfc7234#section-5.2.1.5

Solution 2

Under certain circumstances, IE6 will still cache files even when Cache-Control: no-cache is in the response headers.

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.

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). Adding in the no-store header stopped it doing so. But if you take the W3C at their word, there's actually no way to control this behavior:

History buffers MAY store such responses as part of their normal operation.

General differences between browser history and the normal HTTP caching are described in a specific sub-section of the spec.

Solution 3

From the HTTP 1.1 specification:

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.

Solution 4

no-store should not be necessary in normal situations, and can harm both speed and usability. It is intended for use where the HTTP response contains information so sensitive it should never be written to a disk cache at all, regardless of the negative effects that creates for the user.

How it works:

• Normally, even if a user agent such as a browser determines that a response shouldn't be cached, it may still store it to the disk cache for reasons internal to the user agent. This version may 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 and it would make sense to serve the same version the user is currently viewing.

• Using no-store will prevent that response being stored, but this may impact the browser's ability to give "view source", "back", "page info" and so on without making a new, separate 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 compatible with HTTP 1.1 will obey the no-cache and must-revalidate instructions, ensuring that content is not cached. Using these 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.

Solution 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/

View more solutions

Comments

[Lèse majesté]

If you're already not caching the request, then wouldn't that already prevent the storage of the response in non-volatile media?

[Pacerier]

when you hit back in your browser, IE6 doesn't grab the page from the cache. It grabs the page from the history buffer.

[Pacerier]

Am I misunderstanding something because mnot.net/cache_docs/#CACHE-CONTROL is contradicting you. It says that no-cache maintains rigid freshness without sacrificing all the benefits of caching, which means the cache is stored and used again if the server respond with 304 Not Modified.

[james.garriss]

-1: no-cache does not mean that the content cannot be cached. In 14.9.1 What Is Cachable the spec says, "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." (w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.) As Chris Shiflett explains, it "does not prevent a caching system from keeping a cached copy. It simply requires that the caching system revalidate its cache prior to sending it back to the client." (HTTP Developer's Handbook, p 91)

[Simon Lieschke]

Why wouldn't no-store be sufficient for Internet Explorer? Your blog post doesn't explain.

[Pacerier]

Which IE version are you talking about?

[Eirik H]

As suggested in a related SO answer you can set Cache-Control: no-store, no-cache, must-revalidate in that exact order to make it work. However, that did not work in our scenario, but what @bassim suggested above did. Thanks!

[Kevin Cox]

@Lèsemajesté Most often not. no-cache and max-age=0 say the the item is to be considered stale. This means the it must be revalidated before being served. This means that a cache could store the file and then perform a conditional request to which the server could reply 304 NOT MODIFIED. This is obviously a huge advantage as the body of the response need not be generated and sent. So to take advantage of this many (most?) caches will store no-cache responses.

[caw]

In Chrome 34 (2014), it is still necessary to set no-store as well. Otherwise Chrome will show cached/buffered data when using the back button.

[trysis]

@Pacerier, Probably whatever IE version was the newest at the time he/she wrote the comment. According to Wikipedia this was IE7. For FF it looks like 3. Not many people still use either.

[thomasrutter]

I don't think what I wrote in this answer contracts either of those two comments - I simply did not speak about how browsers revalidate (eg using If-Modified-Since / If-None-Match) because I didn't see it as relevant. I didn't even attempt to cover what no-cache is for, so I'm having difficulty understanding how the comment by @james.garriss relates to my answer.

[bvdb]

I believe it's Firefox who used to prefer the no-store.

[Mark Amery]

-1 because the first sentence wrongly implies that it is incorrect for a browser to cache a response that has a no-cache header. The W3C quote immediately below makes clear that this is not the case; rather, the no-cache header just means that the response must be revalidated before being reused to serve subsequent requests.

[Franklin Yu]

“But not all do.” We need a concrete example to convince my colleague.

[Franklin Yu]

Still not answer the question: why both no-cache and no-store should be used in HTTP response? Isn’t Cache-Control: no-store enough?

[james.garriss]

That comment was made 6 years ago. You'll need to survey the current behavior of caching servers to see what they're doing.

[Roel]

Are there differences between browsers? Because this article from Microsoft docs.microsoft.com/en-us/iis/configuration/system.webServer/‌​… does not even mention no-store and describes no-cache as if it does no caching at all.... I'm confused!

[Luke Puplett]

Alconja's answer is the answer to the question, specifically. When I answered I did so only to clarify a very common miconception. Please vote the other answer up!

[Arcin B]

Wording of the spec has been improved from RFC1616, to the current version of the spec (tools.ietf.org/html/rfc7230 family of RFCs). a family because it is 6 RFCs. They obsolete 2616.

[Gargoyle]

This is incorrect. no-cache says you can't use it without validating with the server. If your cached copy is still good, the server will reply with a 304 and you then use your cached copy. Saves you a potentially large network download. no-store on the other hand says you're not allowed to cache the data at all.

[John Xiao]

Just explained my doubts about when we need no-store

[ShortFuse]

The Microsoft documentation's explanation is wrong, but the implementation seems sound. IIS will send no-cache and ETag. If it's not using cache, ETag is useless. IIS does indeed send 304.

[didxga]

@FranklinYu the answer you want: IE before version 10 uses only no-cache for Cache-Control header, so we need both no-cache and no-store for it working on both old IE and other browsers. See: docs.microsoft.com/en-us/troubleshoot/developer/browsers/…