W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 24 Nov 2011 11:29:28 +1300
To: <ietf-http-wg@w3.org>
Message-ID: <27ace3781b4871cc017480ab8795085a@treenet.co.nz>
 On Wed, 23 Nov 2011 17:22:29 +0100, Harald Alvestrand wrote:
> On 11/23/2011 04:55 PM, Julian Reschke wrote:
>> On 2011-11-23 16:41, Harald Alvestrand wrote:
>>> I ran across this in a discussion, and went to check it up; it 
>>> might
>>> need fixing.
>>> ...
>> I'm not sure that "fixing" is the right term; HTTP doesn't assign 
>> semantics to the ordering, and AFAIU never has.
>> How is this a problem in practice?
> Well... either the semantics of the header
> Accept-language: en, no
> is that the languages are ordered by preference, or it does not imply
> an ordering.
> As of the time I wrote the RFC (2002), I observed multiple browsers
> offering an UI that let people rank their preferences for language,
> and observed the relevant Accept-Language: headers being sent without
> q= values.
> When I inquired, the response was that "leftmost language wins".
> If this is still "what people do", it should be documented.
> Note: Firefox and Chrome seem to send q= values in my current
> versions. The world might have changed.
> But digging around in server-side code, I find that some code (which
> I hope is not used) actually ignores q values totally and just picks
> languages starting at left. Perhaps it hasn't.
>                         Harald

 I've been keeping an eye on this since implementing language 
 negotiation in Squid.

 It appears that nearly all agents are sending the language codes sorted 
 by q value anyway. Whether they send the q value or not it is still 
 possible to optimize by using the left-most wins assumption.

 If anyone is interested in doing a deeper analysis I have a dataset 
 available covering the last year on several networks linking the 
 Accept-Language and User-Agent header pair.

Received on Wednesday, 23 November 2011 22:30:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:54 UTC