Re: does no-store request invalidate?

On Wed, 2005-07-27 at 12:56 -0700, Mark Nottingham wrote:
> 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. 

That is my reading as well, but I wonder whether that was the intent. It
seems odd that the protocol talks at length about validating cached
entries using fresh 304 and HEAD responses but does not mention similar
validation using no-store responses.

> Otherwise, a malicious client could  
> effectively invalidate any cache entry it chose to.

... which it can often do without no-store (using a DELETE method, for
example):

   "If the [DELETE] request passes through a cache and the Request-URI
identifies one or more currently cached entities, those entries SHOULD
be treated as stale."

Alex.

> 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 20:16:02 UTC