#285: Strength of requirements on Accept re: 406

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/285>

The definition of the 406 status code allows servers to override the clients' preferences:

"""
Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the header fields of an incoming response to determine if it is acceptable.
"""

(editorial nit: I think that should be "according to the Accept and Accept-* header fields...")

However, this isn't really reflected in the Accept-* header requirements; e.g., for Accept:

"""
If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (Not Acceptable) response.
"""

For Accept-Charset, we currently have:

"""
If no "*" is present in an Accept-Charset field, then all character encodings not explicitly mentioned get a quality value of 0.
"""

.... which implies that they're unacceptable.

Accept-Encoding has:

"""
If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.

If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header field, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.

If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding.  In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.
"""

Finally, for Accept-Language, we currently defer to RFC4647, but 2616 said:

"""
If no language-range in the field matches the tag, the language quality factor assigned is 0. [...] If an Accept-Language header is present, then all languages which are assigned a quality factor greater than 0 are acceptable.
"""


My understanding has always been that it's always permissible to send a response in a format that isn't explicitly called out in the Accept header, UNLESS Accept explicitly contains */*;q=0 -- and even then, the client needs to be able to handle an unexpected response format. This is because you can't require servers (especially HTTP/1.0 servers, for which there aren't hard requirements) to understand the Accept-* headers. 

If that's the case, I think we should soften these requirements in the Accept-* headers and also align them. Straw-man text for Accept:

"""
If an Accept header field is present, but the server cannot send a response which is acceptable according to its field value, the server can either send a response in another format, or a 406 (Not Acceptable) response. However, the server SHOULD NOT send a format that matches a media-range with a qvalue of "0".
"""

Thoughts? It's pretty clear that the smallest impact change would be to just change the definition of 406 to align with the text in the Accept-* headers, but I don't think that reflects reality.

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 22 June 2011 00:21:42 UTC