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

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.

   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.

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.

-Jeff

Received on Thursday, 7 December 1995 14:30:23 UTC