Re: Call for compatibility testers

Roy T. Fielding:
>
   [Koen Holtman:]
>> OK, you don't like 416.  But I'd rather be compatible without
>> user-agent tricks, because user-agent tricks increase the cost of
>> minimal implementations and make caching *much* more difficult.
>
>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.

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.

You obviously have strong opinions about lynx not being a HTTP/1.0
application, but these are not universally held.  If the conneg draft
would continue to use the 300 code (without providing an adequate
escape hatch) now that the lynx interoperability problems are known,
this would effectively encode your strong opinions in the spec.  I
don't think that would be appropriate.

[...]
>  The only correct way to deal with such browsers is to
>exclude them on the basis of their User Agent field, 

Using this compatibility hack would be very expensive; you would have
to disallow proxies from ever sending a cached list (300) response to
a non-negotiating user agent, which means that you will have to handle
all these requests yourself.  

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.

[...]
>Sounds to me like you are making transparent negotiation incredibly
>difficult to implement just to make a minor (and almost never effective)
>improvement over including
>
>    Vary: User-Agent
>
>in the 300 response for those sites that care whether or not such
>a broken browser would puke and die.

Huh? Sending list responses 416 instead of 300 would hardly make
transparent negotiation incredibly difficult to implement.  It is the
compatibility hacks you need if we keep using the 300 response without
a good escape which are difficult to implement.

>  User agents that are known to
>be broken could receive a 200 response instead of the 300.

Yes, but having a proxy downgrade a 300 into a 200 would be incredibly
yucky.

Newsflash: I just got a report that Arena 0.97h for Linux prints an
error message on stdout when getting a 416 response, without changing
the page on screen.  That seems to rule out using 416.

OK, how about this proposal: 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.

> ...Roy T. Fielding

Koen.

Received on Wednesday, 14 August 1996 09:12:19 UTC