Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I had this same question, and found some info in my searches (your question came up as one of the results). Here's what I determined...</p> <p>There are two sides to the <code>Cache-Control</code> header. One side is where it can be sent by the web server (aka. "origin server"). The other side is where it can be sent by the browser (aka. "user agent").</p> <hr> <h2>When sent by the origin server</h2> <p>I believe <code>max-age=0</code> simply tells caches (and user agents) the response is stale from the get-go and so they <strong>SHOULD</strong> revalidate the response (eg. with the <code>If-Not-Modified</code> header) before using a cached copy, whereas, <code>no-cache</code> tells them they <strong>MUST</strong> revalidate before using a cached copy. From <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1" rel="noreferrer">14.9.1 What is Cacheable</a>:</p> <blockquote> <p><strong>no-cache</strong></p> <p>...a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.</p> </blockquote> <p>In other words, caches may sometimes choose to use a stale response (although I believe they have to then add a <code>Warning</code> header), but <code>no-cache</code> says they're not allowed to use a stale response no matter what. Maybe you'd want the <strong>SHOULD</strong>-revalidate behavior when baseball stats are generated in a page, but you'd want the <strong>MUST</strong>-revalidate behavior when you've generated the response to an e-commerce purchase.</p> <p>Although you're correct in your comment when you say <code>no-cache</code> is not supposed to prevent storage, it might actually be another difference when using <code>no-cache</code>. I came across a page, <a href="https://web.archive.org/web/20140811162719/http://palizine.plynt.com/issues/2008Jul/cache-control-attributes/" rel="noreferrer">Cache Control Directives Demystified</a>, that says (I can't vouch for its correctness):</p> <blockquote> <p>In practice, IE and Firefox have started treating the no-cache directive as if it instructs the browser not to even cache the page. We started observing this behavior about a year ago. We suspect that this change was prompted by the widespread (and incorrect) use of this directive to prevent caching.</p> <p>...</p> <p>Notice that of late, "cache-control: no-cache" has also started behaving like the "no-store" directive.</p> </blockquote> <p>As an aside, it appears to me that <code>Cache-Control: max-age=0, must-revalidate</code> should basically mean the same thing as <code>Cache-Control: no-cache</code>. So maybe that's a way to get the <strong>MUST</strong>-revalidate behavior of <code>no-cache</code>, while avoiding the apparent migration of <code>no-cache</code> to doing the same thing as <code>no-store</code> (ie. no caching whatsoever)?</p> <hr> <h2>When sent by the user agent</h2> <p>I believe <a href="https://stackoverflow.com/a/1046987">shahkalpesh's answer</a> applies to the user agent side. You can also look at <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.6" rel="noreferrer">13.2.6 Disambiguating Multiple Responses</a>.</p> <p>If a user agent sends a request with <code>Cache-Control: max-age=0</code> (aka. "end-to-end revalidation"), then each cache along the way will revalidate its cache entry (eg. with the <code>If-Not-Modified</code> header) all the way to the origin server. If the reply is then 304 (Not Modified), the cached entity can be used.</p> <p>On the other hand, sending a request with <code>Cache-Control: no-cache</code> (aka. "end-to-end reload") doesn't revalidate and the server <strong>MUST NOT</strong> use a cached copy when responding.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload