Re: weak validators (resend)

   [Roy:]
>>>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).
>> 
   [Koen:]
>> 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.

 [Roy:]
>So what?  We already know 1.0 is not reliable in the face of caching.

The 1.0 _spec_ specifies a reliable mechanism.  That 1.0 user agent caches
do not use it is another matter entirely.

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

I don't buy this line of reasoning.  1.1 can never declare itself
compatible with 1.0 because all maintainers of incompatible 1.0 servers
will upgrade anyway.  I'm talking about the internal consistency of the 1.1
spec, and this consistency is orthogonal to how many 1.0 servers will be
upgraded.

>This has nothing to do with protocol compatibility.

Let's agree that we disagree on this.

I have run out of technical arguments. I propose that an issue is added to
the list:

 RANGELASTMODIFIED May proxy and user agent caches merge ranges with the
    same Last-Modified date, if the Last-Modified headers were produced by
    a 1.0 server?

and that some issue owner prepared to take this calls for votes.  We have
already spent far too much time discussing this issue.

Koen.

Received on Sunday, 14 April 1996 17:28:50 UTC