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

olivier Thereaux wrote,

olivier Thereaux <>

> 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

Yes.

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

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.

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

"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.

> 2) multiple instances of an accept value
>
> Is this Accept-Language OK:
> Accept-Language: da, da

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.

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

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

Received on Wednesday, 13 February 2008 05:31:30 UTC