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

> I think the issue between opaque validators vs. header-based
> validators is one of where you expect the additional implementation
> work to be if a different value is chosen as validator.
> 
> IF: {eq {Content-MD5 "blah"}}
> 
> or
> 
> content-validator: md5:blah
> 
> ====
> 
> IF: {eq {Last-Modified "Fri, 01 Dec 1995 14:13:06 gMT"}}
> 
> or
> 
> content-validator: lastmodified:19951201141306
> 
> These are logically equivalent in terms of protocol, but using IF the
> cache has to decide which field is relevant for determining cache
> validity, while in the latter case, the server decides which field is
> valid.

There is more to it than that.  A separate validator field would have
to be generated by all servers for all cachable resources, consisting
of an opaque value which is only usable for metadata comparison (i.e.,
it does nothing to ensure that the entity received is the same as that
sent by the origin server).  It requires that the server be capable and
willing to generate this opaque validator even when the entity is
not directly controlled by the server.

In contrast, IF does not make any assumptions or special requirements
on the information being compared.  If an opaque value is available,
then it can be compared.  If an MD5 is available, then it can be
used as both an MD5 checksum and for cache validation.  If any
useful metainformation (as judged by the client) is available, then
it can be used within a comparison.

Most importantly, we don't have to specify the interaction between
N types of preconditions if we only use one precondition field.

BTW, the logic bag syntax was designed to be tokenized within a
binary HTTP.


 ...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 Sunday, 10 December 1995 15:36:33 UTC