Re: Possible issue: Accept-language priority based on language order

On 2011-11-27 07:44, Harald Alvestrand wrote:
> ...
>> I just tried FF8/IE9/Chrome15/Opera11, and they all send q values.
>> (For Safari, I couldn't figure out how to get multiple languages into
>> the header).
> They are all over the map, it seems.
> Some Android versions, some Chrome versions, some MSIE Media Center
> edition, some Safari versions, some crawlers ...... it seems that these
> are the long tail of the browser market, and stuff that uses HTTP but
> isn't really browsers.
>
> Example:
>
> en-us,en Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; Valve Steam
> Client/1672; ) AppleWebKit/534.1 (KHTML, like Gecko) Chrome/6.0.444.0
> Safari/534.1
>
> That's likely not a Chrome or a Safari, but an embedded browser in Valve
> Steam.

Staying with the example: in all cases, this browser sent either no A_L 
header, or

   en-us, en

That really doesn't look like a sufficient reason to make a change.

> If practice out there is consistent with regard to this interpretation,
>>> I think it is good to document it, so that we might reduce the chance of
>>> future practice from diverging from current practice.
>>
>> I'm still unconvinced that there is a problem here:
>>
>> - we have no proof that the order is intentional and that it matters
>> in these cases
> We have code examples that pick the leftmost language at the server.
> We have no code examples that do anything else (so far).
>>
>> - there may be implementations written to what HTTP always said that
>> treat values with same q value (or missing q value) as having the same
>> preference, and a change to the spec would make those non-compliant
> Hm. The Apache 1.3 documentation:
> http://httpd.apache.org/docs/1.3/content-negotiation.html
> seems to indicate that Apache treats them like a set.
>
> The Apache 2.2 documentation:
>
> http://httpd.apache.org/docs/2.2/content-negotiation.html
> says "Select the variants with the best language match, using either the
> order of languages in the Accept-Language header (if present), or else
> the order of languages in the LanguagePriority directive (if present)."
>
> (this step is applied only if two or more variants have the same preference)
>
> So it seems that Apache 1.3 did not document the RFC 3282 behaviour, but
> Apache 2.2 documents that it behaves according to RFC 3282.

No. What it says is "or else the order of languages in the 
LanguagePriority directive (if present)." - that's the order in the 
httpd config entry, not the header field.

>> - changing Accept-Language would make it inconsistent with the other
>> Accept header fields (or do we want to change them all?)
> What other fields do we have?
> The four Accept headers are Accept, Accept-Charset, Accept-Encoding and
> Accept-Language.
>>
>> We *could* add a note that the interpretation is different here to the
>> MIME variant, and point out that some senders may rely on it (if we
>> really believe that).
> I don't believe this header is in significant use outside HTTP. The
> writeup in RFC 3282 was intended specifically to capture HTTP usage. If
> you really have evidence that common HTTP usage is not consistent with
> RFC 3282, an errata should be filed against RFC 3282.

Hm, no. So far, the header type registry refers to RFC 2616 as normative 
specification for Accept-Language. It only mentions RFC 3283 for mail.

> I have so far seen no such evidence.
>
>                       Harald

What I see is that all major desktop browsers send q values. Sure, there 
are many non-browser UAs, but so far we don't have any statistics that 
could help making a decision.

Best regards, Julian

Received on Sunday, 27 November 2011 09:02:36 UTC