Re: Ordered 'opqque' validators

So, I've been digging through my mail backlog of things I wanted to
respond to (was 98 messages regarding HTTP and 105 generic messages)
but would never have the time to do so (judging from the amount of new
mail that is generated by each response) before they were hopelessly
forgotten threads of no usefulness anyway.  That's when I found this
one, which I thought I had already responded to, but a check of the
hypermail archive indicates otherwise.

Jeff said:
> 
> You wrote in an earlier message:
>     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.
> 
> How about if I paraphrase this as:
> 
>     If a client does a [conditional?] request for a resource that it
>     already has in its cache, and the response it receives
>     contains a Date: value that appears to be older than the
>     one it already has in its cache, then the client SHOULD repeat the
>     request unconditionally, and include
> 	Cache-control: [ no-cache | reload ]
>     to force any intermediate caches to obtain a new copy
>     from the origin server.  This prevents certain paradoxes
>     arising from the use of multiple caches.

I'd say:

      If a client performs a GET request for a resource that it already
      has in its cache, and the response it receives contains a Date
      header field value that indicates an entity older than the one
      it already has in its cache, then the client should repeat the
      request unconditionally and include
         Cache-control: no-cache 
      to force any intermediate caches to obtain a new copy
      from the origin server.  This prevents certain paradoxes
      arising from the use of multiple caches.

> We can argue at some other time about the specific Cache-control:
> syntax, OK?  And this might be a case where "Cache-control: revalidate"
> is useful, since it's quite possible that the client's current
> copy is actually valid (since it has the newer Date:).

I think we would have been better off arguing about the syntax first,
since the primary problem I have had so far is explaining to people how
the existing syntax already does everything they need from caching,
with the exception of some error conditions which will be made
somewhat less likely with the Age header.  Sure, the descriptions need
some elaboration, but that is what the subgroup is supposed to do.

The revalidate directive is not useful because it adds no semantic
value to the request and would lead to a contradiction if revalidate
were sent without the corresponding header fields which *do* indicate
revalidation (IMS, If-Valifd, whatever).


 ...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, 20 February 1996 16:27:44 UTC