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

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 
DELETE etc)
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.

e.g.

whether something is storable for the purpose of satisfying subsequent 
requests
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 
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p6-cache/)

Adrien


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