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

Re: does no-store request invalidate?

From: Robert Olofsson <robo@khelekore.org>
Date: Tue, 26 Jul 2005 20:52:05 +0200
Message-ID: <42E68655.9060503@khelekore.org>
To: Alex Rousskov <rousskov@measurement-factory.com>
CC: ietf-http-wg@w3.org

Alex Rousskov wrote:

>  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)? 
I would say that it violates the rfc:
"If sent in a request, a cache MUST NOT store any part of either this
 request or any response to it"

Every request passing through a proxy have a few different possible
1) No response at all (proxy crashes), hopefully this does not happen.
2) Use a cached response.
3) Get response from real server/chained proxy.

Depending on Cache-Control headers responses from 2 might
be filtered (returning 304) and/or not used (when no-cache).

My interpretation of a no-store header is that I have to remove
alternative 2. Remove meaning delete the response from the
cache in this case.

Of course my interpretation of "any" might be wrong.
Especially if one consider the case of a server generated no-store:
"If sent in a response, a cache MUST NOT store any part of either this
 response or the request that elicited it."

Which seems to say that it is ok for a cache to keep any old response...

Test case:

1: Client requests an entity A 
2: Proxy caches response and serves it
3: Client request the same entity A with "Cache-control: no-cache"
4: Server responds with "Cache-Control: no-store"
5: Client requests the same entity A again
6: Proxy serves the old cache entity from step #2.  

Hmm, interesting. I would sure like to hear from someone that knows
how it ought to be.

Received on Tuesday, 26 July 2005 18:52:28 UTC

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