W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2005

Re: does no-store request invalidate?

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 27 Jul 2005 12:56:02 -0700
Message-Id: <304BD1A2-681B-45E4-A0DF-27E88D8856F2@mnot.net>
Cc: ietf-http-wg@w3.org
To: Alex Rousskov <rousskov@measurement-factory.com>

My reading is that a no-store request header applies to that request  
only; i.e., it's control information specific to that client, at the  
time it made that request. Otherwise, a malicious client could  
effectively invalidate any cache entry it chose to.

Cheers,

On 26/07/2005, at 9:53 AM, Alex Rousskov wrote:

>
> Hello,
>
>     Responses to HTTP requests with "Cache-control: no-store" are not
> cachable. Recently, we came across a cache that does not cache  
> responses
> to no-store requests but also does not invalidate an older cached  
> entity
> with the same URL. When future requests stop using no-store, the old
> cached entity is served.
>
> For example, the following happens in our test case:
>
>   1. Client requests an entity A without using no-store.
>   2. Cache proxies the transaction and caches the response (entity A).
>
>   3. Client requests the same entity A using "Cache-control: no- 
> store".
>   4. Cache proxies the transaction and does NOT cache the response.
>
>   5. Client requests the same entity A again, without using no-store.
>   6. Cache serves the "old" entity A cached in step #2 above.
>
> Does the cache violate the intent of RFC 2616 in step #6? If yes,  
> should
> that intent be made explicit (I cannot find any explicit rules
> prohibiting the above behavior)?
>
> If no, should the cache check that response in step #4 does not  
> indicate
> that cached entity A is stale? I cannot find explicit rules requiring
> that, but we do have similar rules about 304 and HEAD responses
> invalidating older cached entities.
>
> Thank you,
>
> Alex.
>
>
>
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 27 July 2005 19:56:16 GMT

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