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