- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 27 Jul 2005 12:56:02 -0700
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: ietf-http-wg@w3.org
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 UTC