Re: #428 Accept-Language ordering for identical qvalues

"Roy T. Fielding" <> Mon, 21 January 2013 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F1FA21F8443 for <>; Mon, 21 Jan 2013 00:40:04 -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 3V0dVz6lLkSA for <>; Mon, 21 Jan 2013 00:40:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8F58E21F8440 for <>; Mon, 21 Jan 2013 00:39:55 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1TxCsw-0001M4-7z for; Mon, 21 Jan 2013 08:37:42 +0000
Resent-Date: Mon, 21 Jan 2013 08:37:42 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1TxCss-0001LP-Su for; Mon, 21 Jan 2013 08:37:38 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1TxCss-0007Ce-3E for; Mon, 21 Jan 2013 08:37:38 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 979312F4059; Mon, 21 Jan 2013 00:37:16 -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=sZCVYALXMtmz4ATS4wpftDxf7E0=; b=sQUX5jmtkfHWBRCV2rV8GbAfXQVK 6W7+SeHvcRTGbBjQNqQtPqD6pvIzJBboO4NOF3uDXYjyO45vjgnnhFj3LbUuso3K 3SmAlf8W+KXZw2FRNcfls2NE8UMdNFgIfq7X2lGLjs9lrYkIUz19SLO2qHORUhkK 7HEG/PMZCj863v0=
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 24EF12F4057; Mon, 21 Jan 2013 00:37:16 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Mon, 21 Jan 2013 00:37:12 -0800
Cc: "Julian F. Reschke" <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Mark Nottingham <>
X-Mailer: Apple Mail (2.1283)
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-2.476, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: 1TxCss-0007Ce-3E bef6ff69cd6cc9a0ce129a86056f3d1c
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/16077
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Jan 20, 2013, at 1:51 PM, Mark Nottingham wrote:
> On 20/01/2013, at 11:52 PM, Roy T. Fielding <> wrote:
>> On Jan 19, 2013, at 6:34 PM, Mark Nottingham wrote:
>>> Julian et al,
>>> I think the important bit here is the context that we're talking about the semantics of an expressed preference -- which can be freely ignored, or selectively applied, without affecting conformance. The important thing is that the preference itself have clear semantics, which I think Roy's change does (especially in concert with changes elsewhere).
>>> As such, I think the relevant question is whether this is specific to A-L, or all A-* that take qvalues. Roy, thoughts?
>> I am pretty sure it is specific to languages.  Accept has never been
>> treated as an ordered list, Accept-Encoding was originally designed
>> to prefer the smallest representation (changing that to qvalues was
>> unfortunate), and Accept-Charset is almost deprecated at this point.
> So, wouldn't the same arguments (minus the implementation status) apply to Accept?
> I.e., if it's just a preference, and the server is free to choose among the preferences anyway (or even ignore them), why *not* say Accept is ordered?

I don't see any value in that given the lack of users setting the
values for Accept directly (outside of command-line tool usage)
and no assumption among UAs that Accept is ordered.

Apache httpd resolves ties in type negotiation using the
internal ordering of representation variants.  That is unlike
languages, for which the code deliberately checks the order received
in Accept-Language for resolving ties.

Regarding proactive negotiation in HTTP/2, I'll note that Waka
strips all negotiation fields.  I find the entire feature revolting,
from every architectural perspective, and would take the opportunity
of 2.x to remove it entirely.