Re: Ordered 'opqque' validators

On Sat, 3 Feb 1996, Shel Kaphan wrote:

> To use Date: in this way, wouldn't it also be necessary for it to be
> passed somehow as part of every conditional request?  I.e. a
> conditional GET would also need to pass the date associated with the
> validator in order for an intermediate proxy to be able to do an order
> comparison if there was a mismatch.  This seems to be a bit
> cumbersome -- we've reinvented if-modified-since!

I think you've caught the stumbling block ... if the doesn't have a record
of the validator it doesn't have the date either to associate with it.


> Another approach I tried (somewhat unsuccessfully) to put forward at
> the meeting is to leave this optimization (and that's all that it is)
> entirely up to a cache implementation.  I believe I have described how
> to do this before.  A cache can get pretty good coverage if it keeps a
> sequence of validators associated with a changing resource.  If a
> validator in a conditional request ever matches a no-longer-used
> validator for a resource, and the cache contains a "fresh" version of
> the resource, it can return that fresh version.  This only misses when
> the cache has never seen the request's validator before -- but notice,
> it only misses the first time!  The benefit is that no additional
> protocol is needed, and a cache implementation is free not to do this
> optimization at all.

Attempting to paraphrase the objection someone besides me raised 
initially, this unknown case was exactly the point of optimization they
were concerned about.  Where the client was using more than one cache
(perhaps several) and the client already had the most recent copy. 

Hmm. In the simple validator scenario, I think there is an assumption
of only one proxy serving the user? Otherwise, anytime the client 
provides an unknown validator, the proxy must always ask the origin
if the copy the client has is more current than what the proxy has.

But this is a 3 state situation.  CLIENT NEW, PROXY NEW, NEITHER NEW.
The PROXY must issue an IF-FRESH request using the VALIDATOR the PROXY
holds, not the validator the CLIENT holds since the the PROXY needs to
be updated even if the CLIENT is correct.

> To enable this reliably, one constraint this would require us to put
> on validators is that a given validator must never occur twice for two
> different versions of the same object.  Is this a reasonable
> constraint?

Reasonable constraint, needed I believe in any case for reliable operation
(there can be no assumption about how long a client might wait to ask
about a given validator). BUT for the sake of avoiding a simple ordering
property on the otherwise opaque validator we will have an exposure to 
quite a few additional retrievals.  I think, even as I describe above in
the simple single proxy case there is a problem with a cache being able
to use validators to determine if the copy it holds is more recent than
the copy the client holds.

Dave Morris

Received on Monday, 5 February 1996 00:27:55 UTC