Re: #428 Accept-Language ordering for identical qvalues

Nicholas Shanks <> Tue, 22 January 2013 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 937A121F87CC for <>; Tue, 22 Jan 2013 05:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.977
X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8BHaj5nz1HMk for <>; Tue, 22 Jan 2013 05:42:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 13D5421F85C3 for <>; Tue, 22 Jan 2013 05:42:03 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Txe6G-0006mZ-N2 for; Tue, 22 Jan 2013 13:41:16 +0000
Resent-Date: Tue, 22 Jan 2013 13:41:16 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Txe6B-0006lk-Rd for; Tue, 22 Jan 2013 13:41:11 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Txe69-0006d6-Qv for; Tue, 22 Jan 2013 13:41:11 +0000
Received: by with SMTP id er20so1965418lab.18 for <>; Tue, 22 Jan 2013 05:40:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=vxqR+QGpft807loO1IH9HafBZObH2Lt9Jo/+J1tC67A=; b=gqgxMbAq30FYIsCGTAxM7a6o5G62WhEra5nxlAOwW2Ru0Ez5jJxijJw4XPoNX70v1S X+VonJJg0jDVxMIwkRAIUbsGwEjPot5xbPo3uFj6fUO68exYchcJdSto5R4MSKG6VaRj kIPKSWcHGCT5xhtuPLTHXcQH9gwJ5vZzVmxgtRVjpND71Cz65uNx16qDmg+60dEvzq5X QFpRiC48FTw9wQotAm7SruoCJ3Hn2AV5ByVlqtK1tr+nuMxeQ5frU+igHQWyXmNBMtdb d/dbe1YmlAiE5rswbGGFGkoJhwILXlCi+XsTes/+eOlLg957WcxQkvdEMVnzTj2xefHX 8ZVA==
X-Received: by with SMTP id f1mr3342806lbi.71.1358862043225; Tue, 22 Jan 2013 05:40:43 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 22 Jan 2013 05:40:02 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Nicholas Shanks <>
Date: Tue, 22 Jan 2013 13:40:02 +0000
X-Google-Sender-Auth: l69UJRVrDcmchKKowrssAfh8Q18
Message-ID: <>
To: HTTP Working Group <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.710, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Txe69-0006d6-Qv b105f351bdead5fdaa0add99175e38f9
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/16108
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 17 January 2013 09:14, Julian Reschke <> wrote:
> On 2013-01-17 09:59, Roy T. Fielding wrote:
>> 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.

I think no implication of randomness should be permitted by the specifications.
They should instead require that a deterministic process be used, and
that, other than requests to services which explicitly exist to
provide random results (e.g. Wikipedia's "Random Page" link), the same
request should generate the same result providing nothing pertinent to
the resource has changed on the server.

Someone, I don't recall who, gave the example of a home page loading
blog posts via AJAX, where the blog posts are available in two
languages. Random selection between the variants, where (q * qs)
values are equal for both languages, or are being ignored, would
result in a mixture of languages being presented in the resultant web
page, and a reload of the page would generate a different mixture. I
agree that such behaviour is undesirable in all cases I can think of,
(excepting the case of a 'randomizer' service URI) and should be
discouraged or better, prohibited in the spec text.

I believe Apache uses file size in it's TCN mechanism to resolve equal
(q*qs) results. It then falls back to a non-exhaustive ordered list in
it's config in the highly unlikely case that two static files varying
by language have the same byte length. Apache seems to try, therefore,
to be wholly deterministic. (Roy may know whether this is accurate for
A-L in Apache.)

At it's most basal extreme, the deterministic process could be an
ASCII value comparison of the language tags' bytes using strcmp()
implemented by the httpd software.

This should apply to all Accept-* headers.