Re: #428 Accept-Language ordering for identical qvalues

Julian Reschke <> Thu, 17 January 2013 09:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E49E221F88B2 for <>; Thu, 17 Jan 2013 01:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.216
X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[AWL=1.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2ObTfnMGi+Cb for <>; Thu, 17 Jan 2013 01:15:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BD21121F8640 for <>; Thu, 17 Jan 2013 01:15:53 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1TvlYU-0003ZS-26 for; Thu, 17 Jan 2013 09:14:38 +0000
Resent-Date: Thu, 17 Jan 2013 09:14:38 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1TvlYP-0003Yj-LG for; Thu, 17 Jan 2013 09:14:33 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1TvlYO-00062C-Pw for; Thu, 17 Jan 2013 09:14:33 +0000
Received: from ([]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M2aaZ-1T3OPL1Gpp-00sNIj for <>; Thu, 17 Jan 2013 10:14:06 +0100
Received: (qmail invoked by alias); 17 Jan 2013 09:14:05 -0000
Received: from (EHLO []) [] by (mp012) with SMTP; 17 Jan 2013 10:14:05 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+6Z+ViINC6gzSffp0dqo4zgclg5n1XebL8pFRRRC FmeUs3nq/YaSsf
Message-ID: <>
Date: Thu, 17 Jan 2013 10:14:04 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Roy T. Fielding" <>
CC: HTTP Working Group <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-3.293, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1TvlYO-00062C-Pw ba8514bc17ccb4f54ddf68f974a4a10e
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/15955
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.

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

>> I believe this change should be backed out.
> The change has no impact on user agents that send distinct
> qvalues.  At most, it would change the interpretation for those
> few requests that still rely on ordered language tags, for which
> the prior specs had no interpretation at all.

Well, it had an interpretation ("same weight").

It's good that there are only few requests on relying on this. Do you 
want to encourage more, potentially breaking servers that ignore ordering?


Yes, I'm aware that this is a FAQ. But we're not starting from scratch here.

> What I added is how Apache httpd has implemented it since before
> any of the HTTP specs were RFCs, which was compatible with how
> CERN httpd implemented it before that (no qvalues at all).
> The change has no impact on conformance because language
> negotiation is optional and the change is not expressed as a
> requirement.  It also resolves an inconsistency with RFC4647.

It does have an impact, because servers that previously implemented the 
optional feature now do not anymore.

> There are far more examples on the Web where applications
> incorrectly assume the list is ordered

That'll be hard to count. :-)

> than there are servers that implement language negotiation and
> actually want to resolve ties at random.

They do not "want" to resolve at random; they do so because they have 
implemented what the spec says. There's no reason to create an ordered 
list structure when the spec says that an unordered list is sufficient.

> As Harald said,
>> it seems still to be fairly normal to give a sequence of
>> language-ranges in this header without any q= values, and expect the
>> result to be deterministic.

I'd like so see evidence of that, not hearsay. Browsers do *not* rely on 

> because that's how it works in practice for the vast majority
> of systems that implement content negotiation.  The spec should
> reflect what is most interoperable for the users.

As far as I can tell, what's interoperable is the exact opposite: not 
relying on ordering, but sending qvalues.

Best regards, Julian