- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Tue, 20 Feb 1996 07:47:57 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>
So, I've been digging through my mail backlog of things I wanted to respond to (was 98 messages regarding HTTP and 105 generic messages) but would never have the time to do so (judging from the amount of new mail that is generated by each response) before they were hopelessly forgotten threads of no usefulness anyway. That's when I found this one, which I thought I had already responded to, but a check of the hypermail archive indicates otherwise. Jeff said: > > You wrote in an earlier message: > A sensible design would have the server send the "new version" it > has in its cache and then the client can compare the Date on its > stored version to the Date on the "new version" -- if the "new > version" is not newer according to the Date comparison, then the > client can invalidate both and send a "no-cache" request as a > follow-up. > > How about if I paraphrase this as: > > If a client does a [conditional?] request for a resource that it > already has in its cache, and the response it receives > contains a Date: value that appears to be older than the > one it already has in its cache, then the client SHOULD repeat the > request unconditionally, and include > Cache-control: [ no-cache | reload ] > to force any intermediate caches to obtain a new copy > from the origin server. This prevents certain paradoxes > arising from the use of multiple caches. I'd say: If a client performs a GET request for a resource that it already has in its cache, and the response it receives contains a Date header field value that indicates an entity older than the one it already has in its cache, then the client should repeat the request unconditionally and include Cache-control: no-cache to force any intermediate caches to obtain a new copy from the origin server. This prevents certain paradoxes arising from the use of multiple caches. > We can argue at some other time about the specific Cache-control: > syntax, OK? And this might be a case where "Cache-control: revalidate" > is useful, since it's quite possible that the client's current > copy is actually valid (since it has the newer Date:). I think we would have been better off arguing about the syntax first, since the primary problem I have had so far is explaining to people how the existing syntax already does everything they need from caching, with the exception of some error conditions which will be made somewhat less likely with the Age header. Sure, the descriptions need some elaboration, but that is what the subgroup is supposed to do. The revalidate directive is not useful because it adds no semantic value to the request and would lead to a contradiction if revalidate were sent without the corresponding header fields which *do* indicate revalidation (IMS, If-Valifd, whatever). ...Roy T. Fielding Department of Information & Computer Science (fielding@ics.uci.edu) University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056 http://www.ics.uci.edu/~fielding/
Received on Tuesday, 20 February 1996 16:27:44 UTC