- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 05 Feb 96 19:38:03 PST
- To: Shel Kaphan <sjk@amazon.com>
- Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>
What is at issue is the semantics of conditional GET. Do
conditional GETs always have to be forwarded all the way to the
origin server in all cases, even if a cache contains a fresh
response with a matching validator?
No. If the cache is sure that its own copy is fresh, then it can
return it to the requesting client.
I suppose it doesn't make sense for validating GETs to be
answerable by a cache, since the requestor must already have a copy
of the object (else why would it have the validator?), and so, if
it believes the document to be fresh, why would it be validating it
unless it really wanted to check with the origin server?
You've somehow gotten extremely confused. "Fresh" values do not need
to be validated; the server (by attaching an Expires: date in the future)
has indicated that the response is usable without validation for the
indicated period.
Conditional GETs are done by a client or cache that has a copy
of the resource, and a validator (either an opaque one or a last-modified
date) for the resource, and if the client or cache believes that
its copy is stale.
My draft proposal includes
Cache-control: reload
and
Cache-control: revalidate
to allow a client to force a cache to reload or revalidate a
resource that it (the cache) would otherwise return without
checking. But this should only be necessary when something has
gone wrong (such as an incorrectly assigned Expires: date or
a corrupted date).
You are talking above about a different scenario than what we were
considering. We were talking about a situation in which a cache
contains a single "best" response so far, and is presented by a
client with a validator that does not correspond to the entry
already in the cache. In this case, although the entry in the
cache may still be fresh and may in fact be the "current version",
without additional state the cache cannot respond to a conditional
request using the fresh entry.
Nonsense. If the cache believes its own copy is fresh, then it
can return it to the client. If the client's validator is the
same as the cache's validator, it should return "304 Not Modified"
but otherwise it must return the entire entity.
The only difficult case arises when a client (or cache) is getting
copies of the same resource from two different paths to the origin
server. E.g., suppose that my browser is somehow able to use both
of these proxies:
proxy1.pa.dec.com
proxyB.pa.dec.com
Suppose that I round-robin between the proxies, and I keep
retrieving http://www.digital.com. So I do this sequence:
GET http://www.digital.com
from proxy1
proxy1 GETs from www.digital.com
Validator = XX1
[at this point, someone at the server modifies the file]
conditional GET http://www.digital.com
from proxyB
If-Valid: XX1
proxyB GETs from www.digital.com
Validator = XX2
conditional GET http://www.digital.com
from proxy1
If-Valid: XX2
What should proxy1 do? Well, it depends on whether the copy it
has is still fresh. If the server assigned an over-optimistic
Expires: date, then it is still technically fresh and proxy1 can
hand it back to the client, even though this would appear somewhat
paradoxical at the client (hence the need to set honest Expires:
values!)
One could argue that this problem would go away if we simply used
If-Modified-Since: or some other totally ordered validator, but I
believe that the scenario here depends upon inconsistent treatment of
Expires: dates (why would the client have done the second GET unless it
thought the value it got from proxy1 was already stale? in which case
proxy1 would only return it in response to the third GET if there is a
serious clock-skew problem). So if we keep the clock skews under
relatively good control (i.e., by using NTP and the Age: header), I
don't think this case is likely to happen.
-Jeff
Received on Tuesday, 6 February 1996 03:47:11 UTC