Re: [i81] Content Negotiation for media types

Yes; I've hit this a few times. I think it revolves around the  
interpretation of "acceptable". Consider:

1) Accept: text/html
2) Accept: text/html;q=1, */*;q=0.1
3) Accept: text/html;q=1, */*;q=0

Many people read the spec as saying that #1 and #3 are equivalent. It  
sounds like we're saying #1 and #2 are closer to the mark -- i.e.,  
that the server can choose to send anything back, even if it's not  
listed, as long as the client didn't explicitly say they didn't want  
that to happen. This seems to be in the spirit of server-driven  
negotiation;

> Server-driven negotiation is advantageous when the algorithm for
>    selecting from among the available representations is difficult to
>    describe to the user agent, or when the server desires to send its
>    "best guess" to the client along with the first response (hoping to
>    avoid the round-trip delay of a subsequent request if the "best
>    guess" is good enough for the user).

So, I could see making changes to the requirement level around 406,  
as well as some clarifications generally around the concept of  
"acceptable."

Cheers,

P.S. In looking into this, I did notice how much jumping around the  
spec was necessary. Just food for thought WRT partitioning...



On 05/11/2007, at 1:00 AM, Julian Reschke wrote:

>
> Larry Masinter wrote:
>> ...
>> The point about changing the 406 requirement so that it matches  
>> reality
>> should also be added to the issue.
>> ...
>
> Looking at "Accept"...:
>
> "If no Accept header field is present, then it is assumed that the  
> client accepts all media types. 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." -- <http:// 
> greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.1.p.8>
>
> and "406"...:
>
> "Note: 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 to sending a 406  
> response. User agents are encouraged to inspect the headers of an  
> incoming response to determine if it is acceptable." -- <http:// 
> greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.4.7.p.2>
>
> ...it seems that the spec needs to be clarified anyway: the  
> description of "Accept" says "SHOULD send 406", but the description  
> of 406 makes it sound like something OPTIONAL.
>
> I think the latter is closer to reality...
>
> BR, Julian
>


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

Received on Monday, 12 November 2007 06:15:09 UTC