Re: weak validators (resend)

> [...]
>>If there is no other available information, Last-Modified is sufficient
>>and can be assumed to BE sufficient for all caching purposes.  If it
>>isn't sufficient, the provider of that information MUST supply something
>>more reliable than Last-Modified (which itself is reliable 99.9999% of
>>the time).
> 
> My point against allowing Last-Modified values (generated by 1.0 servers)
> to combine ranges is not so much that it is unreliable in 0.0001% of the
> cases, but that there is nothing in the 1.0 spec that _disallows_ a 1.0
> server to provide resources for which combining ranges using Last-Modified
> is 99.9% unreliable.  You can require the above MUST for 1.1 servers, but
> not for 1.0 servers.

So what?  We already know 1.0 is not reliable in the face of caching.
Content providers that want reliable caching must upgrade to HTTP/1.1.
What must not happen is for service to degrade for HTTP/1.1 users when
talking to HTTP/1.0 servers.  We can safely assume that HTTP/1.0 is a
land of optimism because anyone with a worry should upgrade -- if they
don't, then they will suffer the consequences.

This has nothing to do with protocol compatibility.

>>I am not using double-quotes around the change-token (what was being
>>called the validator) because it is generally better to avoid quoted
>>values when they can be avoided (due to problems of charsets and the
>>possibility of embedded quotes and the problems of whitespace lossage
>>by gateways to non-HTTP environments).  In any case, I see no advantage
>>in giving people extra rope to hang themselves when the thing must be
>>a computed function anyway in order to be reliable.
> 
> Side remark: I think the chance of CGI authors hanging themselves writing
> functions that make tokens are is greater than the chance of CGI authors
> hanging themselves writing functions that make quoted strings.  When making
> tokens, you have to know all about which characters cannot be in tokens
> because they are in `tspecials'.  I certainly don't know all tspecials by
> heart.  How many CGI authors will not bother to look it up?

I disagree.  I have seen more people, in practice, hang themselves with
a quoted string than with a more restricted syntax.  We could make an
exception syntax like

    <"> <any CHAR except CTLs, <">, and SP> <">

but that is just as likely to be screwed up as token.

>>   If the Request-URI corresponds to two or more variant representations,
>>   then a variant-id MUST be included in the entity-id to distinguish
>>   between those representations.
> 
> I disagree to this MUST: the alternates in transparent content negotiation
> do not have variant-ids in draft-holtman, they have alternate URIs.  The
> above MUST does not allow transparent content negotiation according to
> draft-holtman on top of 1.1, and we have consensus that this must be
> allowed.

That simply is not true.  You can add variant-ids (or ignore them) to
the Alternates stuff with no impact to transparent negotiation.  Deriving
a variant-id when you already have a location is trivial -- it is just
the difference between the specific URI and the common URI (with a mapping
to a suitable syntax).  There is absolutely no justification for making
the choice between negotiation mechanisms exclusive, nor is it a good
idea to force providers to choose one in exclusion of the other.  A single
resource can and should support both EID and Alternates.

> I strongly object to a requirement that varying resources which use the
> Alternates header to indicate variance MUST include variant-ids.  Such a
> requirement would be easy to satisfy for preemptive negotiation, but very
> painful for reactive negotiation, where a second request is done on the
> actual URI of the alternate resource (which may even live on a different
> server).  ...

This has no impact on the second response in reactive negotiation
because the second response is a different Request-URI, and your
argument simply does not apply.  Nor do any of the suggested changes.

>>   The change-indicator is used to indicate changes to the content of
>>   the resource uniquely identified by the Request-URI and variant-id.
>>   The change-indicator value SHOULD change when the content of an entity
>>   changes and SHOULD NOT change when the content remains the same.
>>   When the value changes, it MUST change to a value not already used for
>>   that entity within a timeframe for which there may still exist
>>   legitimately cached entities with the same change-indicator value.
> 
> As Jeff has pointed out in his more theoretical caching models, one can
> legitimately store in cache memory a stale response forever.  So your
> requirement above is better expressed as:
> 
>     When the value changes, it MUST change to a value not already used.

No, the wording is correct as it stands -- the origin server can and
will decide the scope of the timeframe.  In most cases, it will be "forever",
but that is not necessary in the protocol.

>>As far as I can tell, there is no reason that a private cache should
>>be prevented from using a weak validator comparison, even for byte range
>>insertion.
> 
> As far as I can tell, the privacy requirements of a response are orthogonal
> to the server's ability to supply a strong validator.  So a private cache
> should also be prevented from using a weak validator comparison for
> combining ranges.

No, there is no way for the private cache to have a stored entity which
is different from that of the client, and therefore it is always safe
for a private cache to handle partial GET requests.

> I do not agree to removing validators if we can't settle all issues
> connected to them in 24 hours.  Removing validators would make accessing
> varying resources way to expensive.  We have consensus that the 1.1 Vary
> header should be good enough to support multi-lingual servers.  Removing
> If-Invalid would make use of Vary so expensive that it is hardly usable.

Then it will be hardly usable.

.....Roy

Received on Sunday, 14 April 1996 04:03:13 UTC