Luke Puplett Luke Puplett - 1 year ago 212
HTTP Question

Difference between no-cache and must-revalidate

From the RFC 2616


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. This allows an origin
server to prevent caching even by caches that have been configured to
return stale responses to client requests.

So it directs agents to revalidate all responses.

Compared this to


When the must-revalidate directive is present in a response received
by a cache, that cache MUST NOT use the entry after it becomes stale
to respond to a subsequent request without first revalidating it with
the origin server

So it directs agents to revalidate stale responses.

Particularly with regard to
, is this how user agents actually, empirically treat this directive?

What's the point of
if there's

See this comment:


Though this directive sounds like it is instructing the browser not to
cache the page, there’s a subtle difference. The “no-cache” directive,
according to the RFC, tells the browser that it should revalidate with
the server before serving the page from the cache. Revalidation is a
neat technique that lets the application conserve band-width. If the
page the browser has cached has not changed, the server just signals
that to the browser and the page is displayed from the cache. Hence,
the browser (in theory, at least), stores the page in its cache, but
displays it only after revalidating with the server. 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.

Has anyone got anything more official on this?


The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could result in incorrect operation, such as a silently unexecuted financial transaction.

That's something I've never taken to heart until now. The RFC is saying not to use must-revalidate lightly. The thing is, with web services, you have to take a negative view and assume the worst for your unknown client apps. Any stale resource has the potential to cause a problem.

And something else I've just considered, without Last-Modified or ETags, the browser can only fetch the whole resource again. However with ETags, I've observed that Chrome at least seems to revalidate on every request. Which makes both these directives moot or at least poorly named since they can't properly revalidate unless the request also includes other headers that then cause 'always revalidate' anyway.

I just want to make that last point clearer. By just setting
but not including either an ETag or Last-Modified, the agent can only get the content again since it has nothing to send to the server to compare.

However, my empirical testing has shown that when ETag or modified header data is included in responses, the agents always revalidate anyway, regardless of the presence of the

So the point of
is to force a 'bypass cache' when it goes stale, which can only happen when you have set a lifetime/age, thus if
is set on a response with no age or other headers, it effectively becomes equivalent to
since the response will be considered immediately stale.

-- So I'm going to finally mark Gili's answer!

Answer Source

I believe that must-revalidate means "once the cache expires, refuse to return stale responses to the user even if they say that they are acceptable". Whereas no-cache implies must-revalidate plus the fact the response becomes stale right away.

If a response is cacheable for 10 seconds, then must-revalidate kicks in after 10 seconds, whereas no-cache implies must-revalidate after 0 seconds.

At least, that's my interpretation.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download