Re: Ordered 'opqque' validators

> 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

    Pragma: no-cache

in an HTTP/1.0 request, or

    Cache-control: no-cache

in an HTTP/1.1 request.

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

n.a.

> 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?

Because the multiple levels in a request chain receive new entities
at times independent of any individual user agent (i.e., the higher
level cache may have the newer entity that the user is looking for).

As I have said before, the protocol is designed for this configuration:

     UA  ----->  Org. Proxy  ----->  Regional Proxy  ---->  Origin

I am, after all, half New Zealander and am well aware of how the national
network is set up to minimize cross-Pacific (and even cross-Tasman) traffic.

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

Well, it is moot, but for a different reason.  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/

Received on Tuesday, 6 February 1996 19:23:32 UTC