W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

#285: Strength of requirements on Accept re: 406

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 22 Jun 2011 10:21:15 +1000
Message-Id: <4C6A8E78-4CF9-4E9E-9595-D2DA95AD761D@mnot.net>
To: httpbis Group <ietf-http-wg@w3.org>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC