- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 05 Feb 96 13:05:51 PST
- To: "David W. Morris" <dwm@shell.portal.com>
- Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>, mogul@pa.dec.com
In prior discussions of opaque validators, someone suggested that
opaque validators should have an order property for the case where
a client is utilizing multiple caches which may not be
synchronized.
This was already discussed on the http-caching mailing list, in
a similar context (caches autonomously pooling entries with each
other).
Hence via proxy-A the client may receive the resource with
validator BCX and later check if still BCX is still OK to server
but ask proxy-B. Proxy-B may have an out of date validator but
have no way of knowing.
Validators are never "out of date". A validator is always useful;
one uses it to find out from the origin server if the associated
cached value is still valid. This is true whether one is using
opaque validators or If-modified-since.
What clients receive are responses of the form
R = (validator, expires, Date:, body, other headers)
although in some cases the first two fields might be NULL.
Say a client (or another cache) has two such responses R1 and R2
for the same resource, and so must decide which of them to use
(if any) without doing a conditional GET (i.e., without checking
the validator), or to decide which is the optimal validator
to use in a conditional GET. It first checks the Expires:
value, of course; if one response is expired and the other isn't,
the choice is clear.
Otherwise, it has to decide which of the two responses is more
"believable." That is, if they are both still fresh, but have
different bodies, then the server must have been too optimistic when
assigning the Expires: value to one of them. [It might be the case
that in this case the server intends no semantic difference, but
it might also be the case that the server screwed up.] If they
are both stale, but they have different validators, then it's
possible that one validator will result in a "304 Not modified"
response while the other will result in a complete reload, so
it would be nice to use the right one in a conditional GET.
So the problem is to assign an ordering to the *responses*, not
the validators, that allows the client/cache to choose the "best"
one.
After discussion in todays subgroup meeting, Jeff Mogul suggested
that the Date: header value could be used in conjunction with the
validator to establish the order.
Exactly. Although I actually first proposed this on the list several
weeks ago. Note that the Date: is in the *response* headers that
came from the origin server, NOT (as Shel seems to have believed)
in the requests!
There is a potential for sub-optimal (but not incorrect!) behavior
if a proxy ends up deciding that (say) of R1 and R2, R2 is the best
value to cache, but in fact they are semantically identical, and
later on a client sends to the proxy a request for the resource
using the validator from R1. In this case, there might be an
extra interaction with the origin server, but I think it's unavoidable
(and relatively unlikely). This would be true for any ordering
mechanism, not just for Date:.
On the surface, other than the possiblity that the Date: would not
have sufficient granularity and hence cause an unproductive
IF-VALID RTT, this seems OK. Does this seem reasonable?
The granularity problem should arise rarely (only when two different
responses are generated within the same second). In order to entirely
avoid the possibility of returning the "wrong" response, if a cache
is trying to decide between two responses with different validators
but identical Date: values, it would have to treat both of them as
suspect, since it cannot tell which is newer.
If so, then the working notes draft proposal needs to be updated to
describe the use of date: to establish order.
It's been there since at least January 22 (section 2.9.1).
-Jeff
Received on Monday, 5 February 1996 21:24:07 UTC