Re: #428 Accept-Language ordering for identical qvalues

"Roy T. Fielding" <> Thu, 17 January 2013 09:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 018E621F8946 for <>; Thu, 17 Jan 2013 01:01:41 -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 5a5bxIPLByQe for <>; Thu, 17 Jan 2013 01:01:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CCD2721F8934 for <>; Thu, 17 Jan 2013 01:01:39 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1TvlKW-000810-1L for; Thu, 17 Jan 2013 09:00:12 +0000
Resent-Date: Thu, 17 Jan 2013 09:00:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1TvlKO-00074c-Kh for; Thu, 17 Jan 2013 09:00:04 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1TvlKN-0002VG-HT for; Thu, 17 Jan 2013 09:00:04 +0000
Received: from (localhost []) by (Postfix) with ESMTP id CCF4021DE7E; Thu, 17 Jan 2013 00:59:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=SyM7t9aPe9VMm1NvZwHJ3Zzprrw=; b=mSO9btmdtFPAgbgKAse24gkxrxlw bxA3jqGPZ2eJR6XazJ1WLw6UDecmgveI5Fjl5zOJ3HFBhtXKbHYVYTqOMHEMQ0CU lIBSjfxOwvqPeO7RbM3BoNRuSYYMt7+qXXmhdCS2Foth7zBzpCzshhAlkkim8sVy 4rzGjsMv3n/RmEw=
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 840FB21DE7D; Thu, 17 Jan 2013 00:59:40 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=utf-8
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Thu, 17 Jan 2013 00:59:39 -0800
Cc: HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Julian Reschke <>
X-Mailer: Apple Mail (2.1283)
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.423, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: 1TvlKN-0002VG-HT edd37afad6be874b7bb788ddf0d7c396
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/15953
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Jan 16, 2013, at 7:56 AM, Julian Reschke wrote:

> Hi there,
> with <>, the spec now says:
> "If no quality values are assigned or multiple language tags have been assigned the same quality, the same-weighted languages are listed in descending order of priority."
> This is a change from both RFC 2068 and RFC 2616 which we *did* discuss back in the thread starting with <​>gt;; back then we decided not to make this change because we know of implementations ignoring the ordering, and no convincing argument was given for making the ordering significant.

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 haven't tested.  Chrome has a bug with the ordering of tags to
match the UI, but that's orthogonal to this issue.

Safari does not support languages other than the list set in the
user's system settings, and it only provides the first of those,
which is wrong for both functionality and privacy reasons.
The system settings define the core UI in OS X, so the user can't
turn it off.

Older browsers did not send qvalues. Hence, server implementations
of language negotiation do use the ordering provided as I described
in the change.

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

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.

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

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

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.

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.