Re: Call for compatibility testers

> 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.  Any browser that does nothing upon receipt
of a valid status response (valid being defined as anything that fits
within the syntax of HTTP, not just the standard response codes) is not
fit for use.  The only correct way to deal with such browsers is to
exclude them on the basis of their User Agent field, or just let them
puke and die.  The protocol itself will not be changed every time
some programmer screws up.

> Under the current spec, an origin server can specify conditions under
> which a proxy can send a cached list response to a 1.0 user agent.
> This seems to be important for efficiency and scalability, but it
> depends on cached list responses having a format which all 1.0 user
> agents can handle.  That is why I'm seeking an alternative for using
> the 300 code.

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.  User agents that are known to
be broken could receive a 200 response instead of the 300.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Tuesday, 13 August 1996 20:57:23 UTC