Re: #428 Accept-Language ordering for identical qvalues

Amos Jeffries <> Thu, 24 January 2013 10:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FDD621F8552 for <>; Thu, 24 Jan 2013 02:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.845
X-Spam-Status: No, score=-9.845 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w9ifZw96BJWR for <>; Thu, 24 Jan 2013 02:19:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0078421F8941 for <>; Thu, 24 Jan 2013 02:19:25 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1TyJt3-0006KR-AT for; Thu, 24 Jan 2013 10:18:25 +0000
Resent-Date: Thu, 24 Jan 2013 10:18:25 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1TyJsy-0006Hy-OK for; Thu, 24 Jan 2013 10:18:20 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1TyJsx-0002el-58 for; Thu, 24 Jan 2013 10:18:20 +0000
Received: from [] (unknown []) by (Postfix) with ESMTP id EEB26E6ED4; Thu, 24 Jan 2013 23:17:53 +1300 (NZDT)
Message-ID: <>
Date: Thu, 24 Jan 2013 23:17:45 +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
To: Julian Reschke <>
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=-3.0
X-W3C-Hub-Spam-Report: AWL=-3.043, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1TyJsx-0002el-58 af5ccdcc0b715da419fa2980a80dc9e5
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/16146
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 24/01/2013 10:50 p.m., Julian Reschke wrote:
> On 2013-01-24 09:54, Amos Jeffries wrote:
>> On 24/01/2013 9:26 p.m., Julian Reschke wrote:
>>> On 2013-01-24 02:17, Mark Nottingham wrote:
>>>> So, does anyone have an issue with making ordering significant when
>>>> there's no qvalue for *all* headers that use qvalues?
>>>> ..
>>> I still do, and I'd prefer we go back to what the spec has been saying
>>> for well over a decade.
>>> What *real* problem are we solving with this change that justifies
>>> making current implementations broken?
>> Problem 1) a lot of agents (~57% by unique U-A string) are using
>> q-values to specify ordering where the spec says "unordered".
> Not sure what you're trying to say here. If they send q-values there 
> is no doubt about the semantics, right?
> Also, counting unique UA strings generates a totally distorted statistic.

Somewhat yes. However IME it distorts the numbers to be more inline with 
total traffic load %'s each agent places on the network overall.

>> Problem 2) a majority of the remaining agents appear to be treating the
>> field-value as an ordered list of preferences even without q-values.
> Recipients, I assume? How is that a problem? They choose one plausible 
> interpretation where the spec doesn't define one.


The pattern is clearly a country-specific code, a generic language code 
and possibly followed by a few similar languages in decreasing order of 
similarity, possibly followed by wildcards.
The pattern is strong and almost identical for both agents sending 
ordered q-values and agents sending no q-values at all.
The errors all appear to be at the interface between mechanisms with 
confusion evident when they are mixed in one request header.

Problem is that the original spec wording you are arguing to keep says 
it is a wrong interpretation. One which leads to all these being problems.

>> Problem 3)  ~1% of agents are incorectly implementing q-values. (see my
>> earlier post responding to your request for examples).
> Are these agents widely used? Can they be fixed? Did you report bugs 
> against them?
>> Problem 4) q-values being mandatory when preference order is wanted adds
>> complexity on both ends of the transaction, causing unnecessary CPU
>> burden on the recipient. Misunderstandings and a host of needless
>> mistakes by end-users and developers alike. (again see my earlier post
>> for examples).
> That is true, but we can't remove q values at this point. Note we are 
> discussing HTTP/1.1.

But we can make the primary need for them decrease by making the header 
ordered by default.

>> Problem 5) On the Accept-Language header the bandwidth required to
>> transmit q-values inflates the header size by at least 55% (ISO code:
>> 2-5 bytes, q-v component: 6 bytes).
> For that field value, yes.

That is the field-value we are discussing though.