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

Edibles

no-cache does not mean what you think it does. Actually, it means "please revalidate". – Ophthalmia

@ErwanLegrand great name for it then – Goy

Answer 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

Gisellegish

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? – Freitas

Are there differences between browsers? Because this article from Microsoft learn.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! – Emissary

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! – Gisellegish

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. – Cogitable

@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: learn.microsoft.com/en-us/troubleshoot/developer/browsers/… – Goeselt

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

Inexplicit

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

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. – Assizes

-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. – Adversary

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. – Tumbledown

Answer 3

no-store should not be necessary in normal situations, and in some cases can harm speed and usability.

It was intended as a privacy measure: it tells browsers and caches that the response contains sensitive information that should never be written to a disk-based cache (or other non-volatile storage).

How it works:

• Normally, even if a response is marked as no-cache by the server, a user agent such as a browser may store the response. If the user agent needs to request the same resource again later, it may make a conditional request whereby the server can decide to either send an updated response or allow the user agent to re-use the stored response.

  If the server does not positively affirm that the stored response can still be used, or if the server can't be reached, the user agent (eg the browser) can't use the stored response.

• Using no-store will prevent that response being stored to disk or any non-volatile storage, and prevents the response being used in a later conditional request.

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 same no-cache and must-revalidate instructions as browser caches will.

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 also not going to have the desired effect.

Upwards

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. – Furiya

-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) – Janayjanaya

Just explained my doubts about when we need no-store – Pad

Re-reading my answer over a decade later, a fair bit of it wasn't correct. I've edited it to remove incorrect information. – Upwards

Answer 4

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.

Germann

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

@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. – Hydrograph

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/

Arabist

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

Which IE version are you talking about? – Furiya

@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. – Franky

Answer 6

For chrome, no-cache is used to reload the page on a re-visit, but it still caches it if you go back in history (back button). To reload the page for history-back as well, use no-store. IE needs must-revalidate to work in all occasions.

So just to be sure to avoid all bugs and misinterpretations I always use

Cache-Control: no-store, no-cache, must-revalidate

if I want to make sure it reloads.

Magog

Answer 7

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.

Janayjanaya

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

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

Answer 8

Note that Internet Explorer from version 5 up to 8 will throw an error when trying to download a file served via https and the server sending Cache-Control: no-cache or Pragma: no-cache headers.

See http://support.microsoft.com/kb/812935/en-us

The use of Cache-Control: no-store and Pragma: private seems to be the closest thing which still works.

Amalamalbena

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 @Amalamalbena suggested above did. Thanks! – Endosteum

Answer 9

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.

Birdhouse

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

Answer 10

To answer the question, there are two players here, the client (request) and the server (response).

Client:

The client can only request with ONE cache method. There are different methods and if not specified, will use default.

• default: Inspect browser cache:
  1. If cached and "fresh": Return from cache.
  2. If cached, stale, but still "valid": Return from cache, and schedule a fetch to update cache (for next use).
  3. If cached and stale: Fetch with conditions, cache, and return.
  4. If not cached: Fetch, cache, and return.
• no-store: Fetch and return.
• reload: Fetch, cache, and return. (default-4)
• no-cache: Inspect browser cache:
  1. If cached: Fetch with conditions, cache, and return. (default-3)
  2. If not cached: Fetch, cache, and return. (default-4)
• force-cache: Inspect browser cache:
  1. If cached: Return it regardless if stale.
  2. If not cache: Fetch, cache, and return. (default-4)
• only-if-cached: Inspect browser cache:
  1. If cached: Return it regardless if stale.
  2. If not cached: Throw network error.

Notes:

• Still "valid" means the current age is within the stale-while-revalidate lifetime. It needs "revalidation", but is still acceptable to return.
• "Fetch" here, for simplicity, is short for "non-conditional network fetch".
• "Fetch with conditions" means fetch using headers like If-Modified-Since, or ETag so the server can respond with 304: (Not Modified).

https://fetch.spec.whatwg.org/#concept-request-cache-mode

Server::

Now that we understand what the client can do, the server responses make more sense. Looking at the Cache-Control header, if the server returns:

• no-store: Tells client to not use cache at all
• no-cache: Tells client it should do conditional requests and ignore freshness
• max-age: Tells client how long a cache is "fresh"
• stale-while-revalidate: Tells client how long cache is "valid"
• immutable: Cache forever

---

Now we can put it all together. That means the only possibilities are:

• Non-conditional network fetch
• Conditional network fetch
• Return stale cache
• Return stale but valid cache
• Return fresh cache
• Return any cache

Any combination of client, or server can dictate what method, or set of methods, to use. If the server returns no-store, it's not going to hit the cache, no matter what the client request type. If the client request was no-store, it doesn't matter what the server returns, it won't cache. If the client doesn't specify a request type, the server will dictate it with Cache-Control.

It makes no sense for a server to return both no-cache and no-store since no-store overrides everything. Yes, you've probably seen both together, and it's useless outside of broken browser implementations. Still, no-store has been part of spec since 1999: https://datatracker.ietf.org/doc/html/rfc2616#section-14.9.2

In real life usage, if your server supports 304: Not Modified, and you want to use client cache as a way to improve speed, but still want to force a network fetch, use no-cache. If don't support 304, and want to force a network fetch, use no-store. If you're okay with cache sometimes, use freshness and revalidation headers.

In reality, if you're mixing up no-cache and no-store on the client, very little would change. Then, just a couple of headers get sent and there will different internal responses handled by the browser. An issue can occur if you use no-cache and then forget to use it later. no-cache tells it to store the response in the cache, and a later request without it might trigger internal cache.

There are times when you may want to mix methods even on the same resource based on context. For example, you may want to use reload on a service worker and background sync, but use default for the web page itself. This is where you can manipulate the user agent (browser) cache to your liking. Just remember that the server generally has the final say as to how the cache should work.

---

To clarify some possible future confusion. The client can use the Cache-Control header on the request, to tell the server to not use its own cache system when responding. This is unrelated to the browser/server dynamic, and more about the server/database dynamic.

Also no-store technically means must not store to any non-volatile storage (disk) and release it from volatile storage (memory) ASAP. In practice, it means don't use a cache at all. The command actually goes both ways. A client request with no-store shouldn't write to disk or database and is meant to transient.

---

TL;DR: no-store overrides no-cache. Setting both is useless, unless we are talking out-of-spec or HTTP/1.0 browsers that don't support no-store (Maybe IE11?). Use no-cache for 304 support.

Cogitable

Answer 11

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/

Atypical

Answer 12

A pretty old topic but I'll share some recent ideas:

no-store: Must not attempt to store anything, and must also take action to delete any copy it might have.

no-cache: Never use a local copy without first validating with the origin server. It prevents all possibility of a cache hit, even with fresh resources.

So, answering the question, using only one of them is enough. Also, some (not very) recent works prove that browsers are more Cache-Control compatible nowadays.

Eastsoutheast

Answer 13

OWASP discusses this:

What's the difference between the cache-control directives: no-cache, and no-store?

The no-cache directive in a response indicates that the response must not be used to serve a subsequent request i.e. the cache must not display a response that has this directive set in the header but must let the server serve the request. The no-cache directive can include some field names; in which case the response can be shown from the cache except for the field names specified which should be served from the server. The no-store directive applies to the entire message and indicates that the cache must not store any part of the response or any request that asked for it.

Am I totally safe with these directives?

No. But generally, use both Cache-Control: no-cache, no-store and Pragma: no-cache, in addition to Expires: 0 (or a sufficiently backdated GMT date such as the UNIX epoch). Non-html content types like pdf, word documents, excel spreadsheets, etc often get cached even when the above cache control directives are set (although this varies by version and additional use of must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0 in practice can sometimes result at least in file deletion upon browser closure in some cases due to browser quirks and HTTP implementations). Also, 'Autocomplete' feature allows a browser to cache whatever the user types in an input field of a form. To check this, the form tag or the individual input tags should include 'Autocomplete="Off" ' attribute. However, it should be noted that this attribute is non-standard (although it is supported by the major browsers) so it will break XHTML validation.

Source here.

Blessed

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. – Jassy