Re: Does no-store in request imply no-cache?

Mark Nottingham wrote:
> Right, but that's largely orthogonal to the question below; whether
> no-store in a request implies that a previously stored response needs
> to be invalidated.

Whoops, I made the same mistake in my response.

> >>> If Squid does not purge, the next regular request will get the
> >>> same cached response as the no-store request got, kind of
> >>> violating the "MUST NOT store any response to it" no-store
> >>> requirement.

I don't think it violates anything -- no-store says nothing about not
caching *previous* responses, only the current response.  The important
thing is that no other caches between the user-agent and the responding
cache, or the user-agent cache, stores the current response.  If I want
a response from the origin server, not a cache, I'd combine no-store
with max-age=0.  If I want to invalidate, I'd combine no-store with
must-revalidate, basically erasing previously-cached responses.

> My inclination is to clarify "any response to it" so that a cache can
> use the same cached response to serve multiple requests with no-store
> in them (or not). 

So I give this an on-second-thought +1, rather sheepishly...


Received on Monday, 18 October 2010 00:32:07 UTC