Re: #428 Accept-Language ordering for identical qvalues

Amos Jeffries <> Fri, 18 January 2013 08:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BF5721F8877 for <>; Fri, 18 Jan 2013 00:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tsliwQ28GOBV for <>; Fri, 18 Jan 2013 00:48:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A995721F887F for <>; Fri, 18 Jan 2013 00:48:43 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Tw7bZ-0005oR-Ba for; Fri, 18 Jan 2013 08:47:17 +0000
Resent-Date: Fri, 18 Jan 2013 08:47:17 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Tw7bV-0005nh-1n for; Fri, 18 Jan 2013 08:47:13 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1Tw7bT-0002Vf-Oo for; Fri, 18 Jan 2013 08:47:12 +0000
Received: from [] (unknown []) by (Postfix) with ESMTP id AF9A4E70F1 for <>; Fri, 18 Jan 2013 21:46:42 +1300 (NZDT)
Message-ID: <>
Date: Fri, 18 Jan 2013 21:46:39 +1300
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.499, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Tw7bT-0002Vf-Oo abea5f93a5547b733ba95eeecf904f6a
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/15988
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 18/01/2013 10:03 a.m., Julian Reschke wrote:
> On 2013-01-17 11:17, Roy T. Fielding wrote:
>> On Jan 17, 2013, at 1:14 AM, Julian Reschke wrote:
>>> On 2013-01-17 09:59, Roy T. Fielding wrote:
>>>> The change is to improve interoperability when the preferences sent
>>>> result in a tie or contain no qvalues.
>>>> Firefox and Chrome have an ordered language UI that takes whatever
>>>> list the user comes up with and creates q-values to associate with
>>>> each language tag after the first.  The languages are always listed
>>>> in order of preference.  I've heard that Opera and MSIE do the same
>>> But they have different qvalues, so these UAs do *not* rely on 
>>> ordering.
>> They order them *and* they send qvalues, because of broken sites like
> they do not rely on recipients treating the list as ordered.
>> and the change I made has no effect on UAs that send qvalues.
> Agreed.
>> It does, however, improve the lot for users of other user agents
>> that either do not send qvalues or allow the user to specify the
>> value by hand, either of which can result in same-valued tags.
> Well, it's doing that at the cost of making recipients non-compliant 
> that implement RFC 2068/2616. So this is a change that would need to 
> be listed in the Changes section.

I'm with Roy on this one. It's not adding any new requirement about 
interpretation, simply stating that the list is ordered, as is actually 
the case from most senders.
There is no requirement added/removed about server interpretation so 
those servers implementing random selection out of the ordered set are 
still compliant. Those servers implementing ordered interpretation are 
now compliant - where before with the list defined as un-ordered they 
would be non-compliant due to mis-interpreting an un-ordered list as 

>>>> but haven't tested.  Chrome has a bug with the ordering of tags to
>>>> match the UI, but that's orthogonal to this issue.
>>>> ...
>>>> Older browsers did not send qvalues. Hence, server implementations
>>>> of language negotiation do use the ordering provided as I described
>>>> in the change.
>>> Some, apparently. But not all. Servers have been written according 
>>> to the spec, ignoring ordering. If we make ordering significant, 
>>> these will not interoperate anymore.
>> In what way do they interoperate now, and in what way does that
>> change?  As far as I can tell, the only effect this change has
>> is a suggestion that they not respond randomly.
> Right now they interoperate as specified by the spec. If we change the 
> spec, they do not anymore (or only some of the time).

The new spec does not forbid random selection. Merely states that the 
client *wants* it to be interpreted non-randomly. Obeying that client 
preference is still optional.