- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Thu, 08 Aug 1996 17:48:24 -0700
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> 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