Re: #428 Accept-Language ordering for identical qvalues

["Adrien W. de Croy" <[e-mail]>]

RFC 2616 already strongly implies (in prose not ABNF) order preference

>From 14.4

"The quality value defaults to "q=1". For example,

Accept-Language: da, en-gb;q=0.8, en;q=0.7

would mean: "I prefer Danish, but will accept British English and
other types of English."

The prose states a preference of Danish over the following languages.

Actually the non-requirement for a server to take into account any 
indicated preferences in Accept-* leads to some interesting conundra for 
caching.

For instance,

GET /something HTTP/1.1
Host: someserver.org
Accept-Language: fr
...

200 OK Document follows
Content-Language: en
Vary: Accept-Language
...

leads to problems when the cache sees a request

GET /something HTTP/1.1
Host: someserver.org
Accept-Language: en
...

Even though it's obvious to send the cached resource, it's not correct 
since the selecting header does not match between requests.  This could 
be ameliorated if there were ETags since at least the cached version 
could be checked?

Adrien




------ Original Message ------
From: "Amos Jeffries" <[e-mail]>
To: "Nicholas Shanks" <[e-mail]>
Cc: "Roy T. Fielding" <[e-mail]>; "Julian Reschke" 
<[e-mail]>; "[e-mail]" <[e-mail]>
Sent: 19/01/2013 5:29:20 p.m.
Subject: Re: #428 Accept-Language ordering for identical qvalues
>On 19/01/2013 1:50 a.m., Nicholas Shanks wrote:
>>>>On 2013-01-18 09:46, Amos Jeffries wrote:
>>>>>I'm with Roy on this one. It's not adding any new requirement about
>>I feel I concur with Julian the most.
>>
>>On 18 January 2013 12:11, Roy T. Fielding <[e-mail]> wrote:
>>>Yes. It would also be conformant to send Mäori text.
>>Use a macron or leave it off ;-)
>>[Option-a] [a] on a Mac with one of the "Extended" keyboard layouts
>>
>>>Ignoring the preferences sent in Accept-Language is conforming 
>>>behavior.
>>>
>>>Conformance is not a relevant issue here. What matters is what the
>>>user actually prefers. It is my opinion that when a user sets an
>>>Accept-Language header to
>>>
>>>    Accept-Language: en, de
>>>
>>>what they are actually saying is that they accept both languages
>>>but would prefer en if the de representation is no better.
>>You cannot assume that. They are either using a broken client, or both
>>are acceptable. Please don't change the standard to accomodate broken
>>clients, especially as these are going to become fewer in number as
>>time progresses and machines get upgraded.
>>
>>>The reason I believe this is because user agents that allow a
>>>user to send such a header field have explicitly instructed the
>>>user that the field is ordered (or based the value on some other
>>>ordered list for the host UI, as is the case for some cell phones).
>>All UAs I know of that allow users to set an ordered list of
>>languages, also send auto-generated q-values.
>>
>>Do you actually have any statistics to back up your belief, or is it
>>just a gut feeling?
>>Some numbers to say that "versions x and earlier of so-and-so browser
>>on X-series phones allow users to define an ordered list but do not
>>send q-values; those browsers currently have a worldwide market share
>>of 0.0001%" would be useful to know whether it's worth ignoring such
>>broken UAs to pandering to them.
>>
>>
>>FWIW, my usual AL string, in browsers that let you set one, is:
>>"en-GB, en-IE, en-AU, en-US;q=0, en;q=0.95, fr;q=0.5, de;q=0.5,
>>zh-Hant;q=0.1, *;q=0.2"
>>My goals should be self-evident from the q-values, specifically to get
>>english, french or german, to demote 'complicated' Han script and fall
>>back to anything else. The US thing is to see if sites are actually
>>obeying my preferences (I get many more "y'all"s than 406's sadly!)
>
>According to the 2616 spec we are quibbling over you would get en-GB, 
>en-IE, or en-AU if any of them were available. These being assumed to 
>be q=1 and all equal valued; one is supposed to be selected *randomly*.
>
>Now suppose you had a blog page with each comment loaded by XHR as a 
>separate GET request using that AL header and auto-translation of 
>comments - your page looks like a group of multi-cultural responses 
>some possibly with pidgin-English style wording despite probably all 
>actually being en-US text to begin with. AND if you refresh the page 
>everybodies language changes from what it was last load.
>
>Versus a server which assumed en-GB, en-IE, en-AU were equal q=1 and 
>ordered by preference would supply you with the en-GB for each response 
>part of the page.
>
>Which is the better outcome for web developers to rely on?
>Which one is easier for servers to write fast code for?
>
>Amos
>