Re: Ordered 'opqque' validators

Roy T. Fielding writes:
 > > 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.  The conditional GET applies to the next server on the request chain
 > which has an entity for that resource.  It is possible to force
 > the IMS to be applied against the origin server by including
 > 

I agree with this, since in both your (Roy's) version, and Jeff's
version, there are explicit ways to force a validation request to go all the
way to the origin server.

	...

   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.  Given that this would be a
 > one-in-quadrillion possibility, the performance penalty of a second
 > request is not significant.
 > 
 > 
 >  ...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/

That seems like a reasonable way to do it, which only costs anything
in the presumably unusual cases where it can be a problem.  (Question
for everyone: we do believe these cases are going to be unusual, don't
we?)

Note that neither your solution nor my proposed heuristics require any
protocol elements (though they may require language describing this use
of the Date header), and that either solution could be implemented and
be consistent with the protocol -- in other words, all we have to
convince ourselves of is that no new protocol is required, and leave
specific optimizations for others to worry about.

--Shel

Received on Tuesday, 6 February 1996 22:56:14 UTC