- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 06 Feb 96 16:44:52 PST
- To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
- Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>
Yep, though what I'd really like is the words to put in the spec so
that we can transfer our group's accumulated understanding about
all these niggling details into something an implementor can work from.
I've been trying to collect some of these little pearls of wisdom
as we seem to reach consensus on them. For now, I'm sticking
them into my "cachemodel.txt" draft, but ultimately the important
ones will have to migrate into the HTTP/1.1 spec.
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.
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:).
-Jeff
Received on Wednesday, 7 February 1996 00:56:23 UTC