W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

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

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Sun, 17 Oct 2010 18:31:31 -0600
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <20101017183131.beb39948.eric@bisonsystems.net>
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...

-Eric
Received on Monday, 18 October 2010 00:32:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:29 GMT