Re: Call for compatibility testers

> The transparent content negotiation draft
> (http://gewis.win.tue.nl/~koen/conneg/) currently specifies the 300
> response code for list responses.  
> 
> It turns out that this is not compatible with several existing
> browsers: lynx and some versions of Mosaic fail to display anything if
> they get back a 3xx class response without a Location header.  As lynx
> in particular will be important for some people who want to offer
> negotiated material, this rules out use of the 300 response code in
> transparent content negotiation.

Read the description of 300 in the HTTP/1.1 spec:

    10.3.1 300 Multiple Choices
 
    The requested resource corresponds to any one of a set of
    representations, each with its own specific location, and agent-driven
    negotiation information (section 12) is being provided so that the user
    (or user agent) can select a preferred representation and redirect its
    request to that location.
 
    Unless it was a HEAD request, the response SHOULD include an entity
    containing a list of resource characteristics and location(s) from which
    the user or user agent can choose the one most appropriate. The entity
    format is specified by the media type given in the Content-Type header
    field. Depending upon the format and the capabilities of the user agent,
    selection of the most appropriate choice may be performed automatically.
    However, this specification does not define any standard for such
    automatic selection.
 
    If the server has a preferred choice of representation, it SHOULD
    include the specific URL for that representation in the Location field;
    user agents MAY use the Location field value for automatic redirection.
    This response is cachable unless indicated otherwise.

So, please explain why you are sending a 3xx class response without a
Location header.

> I have done some checking, and it seems that the creation of a new
> response code:
> 
>   416 List Response
> 
> is the best way to get downwards compatibility.

And is out of the question.  Bugwards compatibility is achieved by
looking at the User-Agent value, and sending 406 (or just 200 with
an appropriate Vary and Alternates) is better than generating a
success message masked as a client error.


 ...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 Thursday, 8 August 1996 18:07:05 UTC