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

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

From: Adrien de Croy <adrien@qbik.com>
Date: Mon, 18 Oct 2010 14:28:15 +1300
Message-ID: <4CBBA2AF.8040803@qbik.com>
To: "Eric J. Bowman" <eric@bisonsystems.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>, David Morris <dwm@xpasc.com>

surely only server responses can invalidate a cache entry.  whether that 
server response is

a) a successful response to a request which should invalidate (such as 
b) a successful response to GET or HEAD which indicates a stored 
representation is no longer valid
c) a 404 to something that's in cache
d) doubtless something else I can't put my finger on

to allow a request to invalidate a cache entry is an open door to DOS.

As for no-store meaning no-cache.  I think people misunderstand 
no-cache.  The word "cache" and derivatives are used in several 
different contexts.


whether something is storable for the purpose of satisfying subsequent 
whether something is usable without revalidating with an O-S
whether something is usable after revalidation

no-cache to my reading implies revalidation is required, not that under 
no circumstances may a stored response be used.
no-store simply means the result cannot be stored in non-volatile 
storage (as per 


On 18/10/2010 2:12 p.m., Eric J. Bowman wrote:
> David Morris wrote:
>> But if the application author went to the trouble of making
>> such a request, then we should err on the side of privacy and
>> preclude any use of storage for the request or response.
> Why are you assuming it's the application author making the request?
>> I'd argue that to not be true. NO-STORE is a privacy oriented
>> directive and I don't think we have the ability to discern all the
>> small leaks that might occur given the clever black hats that abound.
>> The safe path is no use of storage.
> But in this case, the sender intent explicitly allows caching.  If the
> application author wants to change a representation to never be stored,
> then the server configuration needs changed, which isn't the intent of
> no-store in a request.  In fact, I think the clever black-hats might
> find it useful to know that a DDoS can get around cached responses by
> just invalidating them in the initial requests.
> -Eric
Received on Monday, 18 October 2010 01:28:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC