Re: Call for compatibility testers

   [Roy:]
>>>There is a difference between being compatible with older versions
>>>of HTTP and being compatible with old browsers that do not implement
>>>any version of HTTP correctly.
>> 
   [Koen:]
>> HTTP/1.0 is an informational standard.  As far as I know, this means
>> that the IETF does not have an opinion on whether lynx implements
>> HTTP/1.0 correctly.

[Roy:]
>I need to correct this misunderstanding. As far as the IETF (and W3C)
>is concerned, RFC 1945 is the only definition of HTTP/1.0 -- there simply
>is no other reference for that protocol.

You misunderstand.  I was not claiming that there were other
definitions of 1.0.  I was claiming that the IETF *has no opinion* on
how necessary it is to comply to every detail in the 1.0 definition.
Quoting from rfc1602:

           2.4.3  Informational

              An "Informational" specification is published for the
              general information of the Internet community, and does
              not represent an Internet community consensus or
              recommendation.

If you want to discuss how valid lynx is as an implementation of 1.0,
this WG is not the place to do it.

The conneg draft claims to be downwards compatible with 1.0, and as
far as I am concerned we need *running code* to prove this point, not
any discussion which leads to WG rough consensus about well-known
1.0 browsers being invalid 1.0 implementations.

I am not very interested in keeping mechanisms which cause non-running
code with well-known 1.0 browsers, even if you can work around it
using Vary: user-agent.  I was too optimistic about the degree in
which well-known 1.0 browsers implement features in the 1.0
informational spec, and I hope to correct for this in the next draft.
This is my current proposal for correcting it:

 We just forget about sending cached list responses to non-negotiating
 clients altogether.  This allows us to keep using the 300 code as
 originally intended.  The List_OS result of the network negotiation
 algorithm disappears, and so does the `forward' directive in the
 alternates header, because `forward' is now the only action possible.
 We allow origin servers to generate whatever response they want
 (including a 200 response with a list) when contacted by a
 non-negotiating user agent.

What do you think?

By the way, I did some experiments with the Arena browser, made by the
w3c, and the sun4 binary I tried does *nothing* when getting a 4xx
class response, it just keeps the current page on screen.

[...]
>adding hacks to the protocol means that correctly implemented applications
>will suffer forever.

My proposal above (and also my earlier `use 416 instead of 300'
proposal) do not add hacks to the protocol.  I'm just as much against
adding hacks as you are.  By proposal above *cuts* a feature from the
draft, because it is now known that this feature is a premature
optimization.

[...]
>> The current draft does not allow you to use Vary to optimize here:
>> proxies ignore the Vary header in cached list responses when using the
>> network negotiation algorithm.  The spec could be extended with more
>> vary rules, but I don't think this is the way to go.
>
>I'll have to check your spec, but you need to be careful in considering
>the overlapping purposes of Vary and Alternates --

I was a careful as I could be.  You will have to check my work to see
if I got everything right.

> Alternates does not
>act as a replacement for Vary.

I'm painfully aware of that.  If Alternates: <something> would have
implied Vary: {accept-headers} for all 1.1 clients, as in my original
design, the conneg draft would have been about 5 pages shorter.

[...]
>Alternates details alternative
>representations of the response for 2xx, 4xx (except 406), and 5xx
>responses, and alternative representations of the requested resource
>for 1xx, 3xx and 406 responses

No it does not, at least not in my draft.  I have no intention of
making my head explode by trying to define transparent content
negotiation for error responses.  You don't have conditional GETs and
range retrieval on error responses, and you won't have transparent
negotiation on them for the same reason: these mechanisms can change
the status code of the response, so they are always applied *before*
the status code is chosen.

[...]
>Therefore, there is no reason for proxies to ignore Vary on 1xx, 3xx and 406
>responses (nor can they do so if they wish to be compliant with
>HTTP/1.1).

Proxies *have to* ignore Vary if transparent content negotiation is to
be more efficient than plain vary-based negotiation.  And proxies can
do so while being 1.1 compliant.  From the 1.1 spec:

 This specification does not define any mechanism for transparent
 negotiation, though it also does not prevent any such mechanism from
 being developed as an extension and used within HTTP/1.1.
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^ 

The rules on not ignoring Vary in the 1.1 spec apply to 1.1 proxies
acting as a 1.1 caching proxy, not to 1.1 proxies which do transparent
negotiation on behalf of the origin server.

> ...Roy T. Fielding

Koen.

Received on Monday, 19 August 1996 05:15:16 UTC