Subject: order of Accept-* and Server-Driven negotiation

From: olivier Thereaux <[email-masked]>
Date: Wed, 13 Feb 2008 13:21:18 +0900

Hello,

In one of our current projects, dealing with some language- 
negotiation, we ran into some cases on which the HTTP specs appears  
underspecified.

Apologies if I've missed the relevant part of the spec - a pointer  
would be appreciated -, and if not, please consider this a request to  
add the clarifications in the upcoming HTTPbis spec.

1) order of acceptable values: significant or not?

Consider a request with the header
Accept-Language: en, fr; q=0.5, de, ja; q=0.8

According to RFC2616 (Sec 14) this computes to
en	= 1
de	= 1
ja	= 0.8
fr	= 0.5

The spec's section on server-driven negotiation, be it in 2616 or  
draft-ietf-httpbis-p3-payload, does not specify how to treat choices  
with equivalent quality factors, like "en" and "de" in this case.  
Supposing both variants are available for the resource, is it up to  
the server?

The only doc I could find about it says:
[[
this header is Accept_Languageand will typically be the list of  
language keywords the user specifies (in descending order of preference)
]] -- http://www.ibm.com/developerworks/library/wa-apac.html

... but I am unsure whether the quote paragraph is a description of  
the apache implementation, of a part of the spec I've missed, or just  
an assumption by the author.

2) multiple instances of an accept value

Is this Accept-Language OK:
Accept-Language: da, da

How about this one?
Accept-Language: da;q=0.8, de, fr, da, es

If the latter is OK, what's the precedence? How is it (supposed to be)  
parsed?

Thanks!
olivier

-- 
olivier Thereaux - W3C - http://www.w3.org/People/olivier/
W3C Open Source Software: http://www.w3.org/Status

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 Feb 2008 21:09:11 -0800

My .02;

On 12/02/2008, at 8:21 PM, olivier Thereaux wrote:
> the apache implementation, of a part of the spec I've missed, or  
> just an assumption by the author.

It isn't spelled out, but the overall tone of the applicable sections  
clearly communicates, IMO, that Accept and friends indicate a client  
*preference*, which the server takes into account when responding.  
Thus, if two values have an equivalent qval, the client doesn't have a  
stated preference between them, and they are equally acceptable; the  
server is free to choose between them.

> If the latter is OK, what's the precedence? How is it (supposed to  
> be) parsed?

Again IMO: I don't think this is specified, and I don't know it should  
be (see the duplicate header issue #93).

Cheers,

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

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 13 Feb 2008 03:30:54 -0200

olivier Thereaux wrote,

olivier Thereaux <>

> According to RFC2616 (Sec 14) this computes to

Yes.

> draft-ietf-httpbis-p3-payload, does not specify how to treat choices  with 
> equivalent quality factors, like "en" and "de" in this case.  Supposing 
> both variants are available for the resource, is it up to  the server?

I think so. Furthermore, the server is not required to honor your accept-* 
headers at all. It may return a Chinese variant instead of 406 (Not 
Acceptable) and stills conform the spec. It is up to the client verify that 
the response actually matches the requested values.

Note: according to draft-ietf-httpbis-p3-payload-01, 406 (Not Acceptable) 
SHOULD be returned, however it is not an practice because
severs usually ignore the Accept header.  Modifying this requirement was 
included in issue #81 "Content Negotiation for media types" ("This may also 
affect the text that describes the circumstances when a 406 may/must be 
sent") This proposal was last discused around 
http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/0119.html.

> this header is Accept_Languageand will typically be the list of  language 
> keywords the user specifies (in descending order of preference)
> ... but I am unsure whether the quote paragraph is a description of  the 
> apache implementation, of a part of the spec I've missed, or just  an 
> assumption by the author.

"Quality factors allow the user
   or user agent to indicate the relative degree of preference for that
   media-range, using the qvalue scale from 0 to 1"

"order of preference" refers to the "q" parameter, not the order in that tag 
occurs. See examples in Section 5.1 of draft-ietf-httpbis-p3-payload-01 
(also, Section 14.1 of RFC 2616).
The ordering of each tag is not significant.

> Is this Accept-Language OK:

It is weird... but it is not ambiguous, hence I would say it is OK. The spec 
does not forbid repetitions of the *same* tag... though the cliend was not 
conservative in what it sent. Accept-Language: da would have sufficed.

> If the latter is OK, what's the precedence? How is it (supposed to be) 

The "q" parameter is optional and the default value is q=1.

It is equivalent to:

Accept-Language: da;q=0.8, de;q=1, fr;q=1, da;q=1, es;q=1

Why did the client send it? If it were the Accept header, something like
  Accept: text/*;q=0.8, text/plain
makes sense... but da;q=0.8;da ? It cannot have two preferences for the same 
language.

AFAIK, there is no explicit indication about how handling this case. I 
assume the bigger value applies. Your example may be interpreted as "I 
prefer German, French, Danish, or Spanish. If none of them is available, 
send me Danish if it is the best available after an 80% mark-down in 
quality"

Note that [[ "quality values" is a misnomer, since these values merely 
represent *relative degradation* in desired quality ]] (emphasis added). 
Therefore, if da=1 cannot be served, it is because no German, French, 
Danish, or Spanish variant exists (otherwise, at least one of them would 
have been the "best". It follows that da=0.8 cannot be served (and it was 
irrelevant in the header).

Best Regards,

Javier