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

Roy T. Fielding writes:
 > > 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.

And less:  the content-validator header should NOT specify
"lastmodified", "md5", or any other specific algorithm.  If it did, it
would hardly be opaque, would it?

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

I think it would be helpful if you would explain these claims rather
than just claiming them.  Yes, the header would need to be present for
any cachable resource (except for backwards compatibility with 1.0).
But why do you say it is only usable for metadata comparison?  If a
part of a server is configured to use algorithm X to determine its own
stated content-validator, then that part of the server must be able to
respond to requests that use content-validators as generated by
algorithm X, no?  And isn't it only the origin server that has to
worry about generating these headers?  


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

The point of the opaque validator is to remove the smarts from the
client side.  It really seems like there are multiple issues being
discussed at once, which should be being discussed separately:

1. What are the foreseeable "high-level" reasons for doing conditional
requests, and how should those conditional requests be encoded in the
protocol?  We have yet to see a plausible scenario that demonstrates
this need.  Without stated requirements this seems like an exercise in
futility.

2. Is there a requirement or benefit of having a general case solution
to this that outweighs its complexity and the difficulty of specifying
the semantics exactly?  General case solutions are nice, where there
is a general case problem to be solved, but the added hair of having
to put an expression parser in at this level seems quite questionable
without a definite need.
	
3. Should we mix the high level mechanism with the low-level
cache-integrity mechanisms?  What are the benefits/costs of that?
It seems to me that cache-integrity concerns are a low level and
encapsulatable piece of the puzzle, and that trying to mix it with
a condition about, say, the price of some product seems like 
mixing levels in a most unfortunate way.   (Don't cross the beams!)
The cache integrity problem is, or at least should be, well defined,
and should not require an interpreter to solve.

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

Doesn't backwards compatiblity already imply that this is required?


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


--Shel Kaphan

Received on Sunday, 10 December 1995 16:20:49 UTC