Re: Ordered 'opqque' validators

Jeffrey Mogul writes:
 > 
 > 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.
	...

 > 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.
	...
 > 
 > 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!

I believe (or believed, depending on the answer to questions below)
that to use Date as a sequencer, the Date in the response headers
would be used, and passed back (somehow) in subsequent requests.  But
I think there is a deeper confusion here.

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?  If so, conditional GETs will often be more expensive than
unconditional GETs that can be answered by a cache.  If so (as an
aside), I think we should not call them "conditional GETs", since that
seems to imply that the overhead is <= the overhead of a normal GET.
Maybe we should call them "validating GETs" instead.

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?


If validating GETs always must be forwarded all the way to the origin
server, the question is simply which validator should a cache use when
attempting to validate a resource.  It only makes sense for a cache to
send a validator for an object it contains a copy of, so if it has to
make a choice, the response's Date could be used as the criterion as
discussed.

What follows is moot if all validating requests (those containing
validators) must be forwarded all the way to the origin server:

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.  This is why I said that in order to make use of Date as
a sequencer, it would be necessary for clients to pass back the
Date and Validator corresponding to the objects they wanted
to validate.  Then the cache could know if the date (corresponding to
the object referenced by the validator) in the request
headers was after or before the date in its cached entry.  If before,
the cache could respond with its fresh entry.  If after, the request
must be forwarded.  And it was following this that I made the other
suggestions about heuristics to avoid it.  But it's all moot if
validating requests must all be forwarded all the way.

--Shel

Received on Monday, 5 February 1996 22:49:21 UTC