Re: #285: Strength of requirements on Accept re: 406

Back to the original issue here.

I think it can be broken down like this:

1) Accept's definition needs to be aligned with the definition of 406 to allow the server to send something other than what's in Accept. See proposal at the bottom of this e-mail.

2) Accept-Charset explicitly says that if it's present, anything not mentioned gets a quality value of '0'. Accept-Language implies that (depending on how you read it). In both cases, if servers are disallowed from sending anything not acceptable, this implies that these headers are mandatory. I'd argue that the requirements should be relaxed in a manner similar to the proposal for Accept, to match reality.

3) Either way, more needs to be said about this in p3 5.1 Server-Driven negotiation.

I'm happy to write a proposal along these lines; anyone with concerns about going in this direction?

Cheers,


On 22/06/2011, at 10:21 AM, Mark Nottingham wrote:

> <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/
> 
> 
> 
> 

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

Received on Tuesday, 28 June 2011 05:41:29 UTC