Re: Confusion over caching (was Re: Logic Bag concerns)

> Roy writes:
>    What is the actual difference in development and run-time expense
>    between implementing a general mechanism for preconditions such as
>        IF: {eq {Content-MD5 "89787jhlkr8r87y98437=="}}
>    or
>        IF: {eq {Last-Modified "Fri, 01 Dec 1995 14:13:06 GMT"}}
>    over implementing a special-purpose mechanism for cache validation
>        Content-Validator: "89787jhlkr8r87y98437=="
>    and
>        If-Validator: "89787jhlkr8r87y98437=="
> 
> This entirely misses the point I've been trying to make over and
> over and over again.  If you accept the principle that
> cache validation ought to be done using an opaque validator,

Should, yes, but I cannot accept that condition as a MUST.
I simply cannot do that given the presence of existing resources on existing
servers for which no Cache-Validator header field is present.

> and that the design of caching is *central* to the operation of
> HTTP, then this is hardly a "special-purpose mechanism for cache
> validation."  (This is why I wrote in another message today
> that agreeing on principles should be done before fighting about
> syntax.)

Sorry, but if the only thing it can be used for is cache validation,
then it is a special-purpose mechanism for cache validation.  There
is no point in arguing that it isn't.

> Remember that (in the opaque-validator model) the server *could* use
> an MD5 hash or a modification date as the cache-validator.  And
> this means that the decision about how to define cache validity
> rests with the origin-server, which knows the semantics of the
> data, rather than with the client.

Yes, which is why I used that exact example above.

>    keeping in mind that no existing server currently provides a
>    Content-Validator header field and that the field, whatever it
>    contains, must be duplicating some other entity-header.
> 
> I think you are confused.  It *may* duplicate some other entity-header,
> but it might not.  For example, the server may choose to encode
> the file modification date in (seconds.fractional_seconds) as
> a string of 9 or 10 hex digits, which is both shorter than the
> 29 bytes of an HTTP date, and also more precise.  Or the server
> may use a proprietary hashing function (i.e., not MD5) which might
> be more efficient for the purpose.  Or the server might use some
> combination of its internal index for an item in a database,
> plus a database update-version number, if it isn't storing
> modification timestamps for each database entry.

All of which are duplicating an entity header field -- the server may
not be sending that information in a header field now, but there is
no reason why it can't do so.

> My point is that we should not restrict the cache-validator
> to something that can be expressed using just the other
> standard header fields, both because these fields may not
> include the requisite information, and because doing so
> would require the *client* to decide how to determine if
> a cached object is valid, when this is most certainly the
> role of the origin-server.

If the server is capable of generating an opaque validation string,
then it is capable of sending that string as the value of Content-Version,
in which case the client is capable of using Content-Version within
the request precondition to serve as the opaque validator.

It is reasonable to require that the client use Content-Version in
preference to other comparators.  It is not reasonable to require
all resources to use the same comparator.


 ...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 Friday, 8 December 1995 15:17:00 UTC