Re: (ACCEPT*) Consensus

Roy T. Fielding:
>
>> |  [##Note: the new 416 is similar to the 406 response code in the old
>>    draft.  406 cannot be used for content negotiation compatibility
>>    reasons##]
>
>I am not aware of any such reasons.  Please explain.

First some background:

The old 1.1-01 draft required 406 responses to contain `a list of
resource characteristics and locations from which the user or user
agent can choose the one most appropriate.'  Such a thing is not
required in the 416 response I defined, so I thought it best to assign
a new code, rather than rewrite the 406 text.

According to my current draft texts, we will have:

  416 Not Acceptable

  The resource identified by the Request-URI and Host request header
  (present if the request-URI is not an absoluteURI) is only capable of
  generating response entities which have content characteristics not
  acceptable according to the accept headers sent in the request.

  HTTP/1.1 servers are allowed to return responses which are not
  acceptable according to the accept headers sent in the request. In
  some cases, this may even be preferable over sending a 416
  response. User agents are encouraged to inspect the headers of an
  incoming response to determine if it is acceptable. If the response is
  not acceptable, user agents should interrupt the receipt of the
  response if doing so would save network resources.  If it IS unknown
  whether an incoming response would be acceptable, a user agent should
  temporarily stop receipt of more data and query the user for a
  decision on further actions.

and

406 None Acceptable

   This status code is reserved for future use by a planned content
   negotiation mechanism.  HTTP/1.1 user agents receiving a 406
   response which includes a Location header can treat this response
   as they would treat a 303 (See Other) response.  If no Location
   header is included, the appropriate action is to display the entity
   enclosed in the response to the user.

Now the compatibility reasons:

User agents may want to take an automatic action when getting a 416
(Not Acceptable) response.a An example would be popping up a dialog box
with a standard error message (in the user's native language), while
leaving the original page containing the link followed on screen.
Such automatic action would have the advantage that the user can still
see the original link followed.

This is why 406 and 416 cannot be merged into one status code.  Doing
the 416 automatic action for a 406 response would be wholly
inappropriate: you absolutely want the entity included in the 406
response to be displayed on screen, because this entity will likely be
a list of links to the various alternate resources that are available.

Of course, I know of no existing user agent that does automatic
actions on 4xx error responses.  But we have to account for future
agents doing it: that is why we have these 3-digit response codes in
the first place.

We could swap 406 and 416 around if you think this better reflects
historical use.  I don't think it would.

> ...Roy T. Fielding

Koen.

Received on Sunday, 14 April 1996 02:25:42 UTC