Re: #428 Accept-Language ordering for identical qvalues

[Amos Jeffries <[e-mail]>]

On 18/01/2013 10:03 a.m., Julian Reschke wrote:
> On 2013-01-17 11:17, Roy T. Fielding wrote:
>> On Jan 17, 2013, at 1:14 AM, Julian Reschke wrote:
>>
>>> On 2013-01-17 09:59, Roy T. Fielding wrote:
>>>> The change is to improve interoperability when the preferences sent
>>>> result in a tie or contain no qvalues.
>>>>
>>>> http://www.w3.org/International/questions/qa-lang-priorities.en.php
>>>>
>>>> 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 they have different qvalues, so these UAs do *not* rely on 
>>> ordering.
>>
>> They order them *and* they send qvalues, because of broken sites like
>>
>>     http://wiki.nginx.org/AcceptLanguageModule
>
> ...so they do not rely on recipients treating the list as ordered.
>
>> and the change I made has no effect on UAs that send qvalues.
>
> Agreed.
>
>> It does, however, improve the lot for users of other user agents
>> that either do not send qvalues or allow the user to specify the
>> value by hand, either of which can result in same-valued tags.
>
> Well, it's doing that at the cost of making recipients non-compliant 
> that implement RFC 2068/2616. So this is a change that would need to 
> be listed in the Changes section.
>

I'm with Roy on this one. It's not adding any new requirement about 
interpretation, simply stating that the list is ordered, as is actually 
the case from most senders.
There is no requirement added/removed about server interpretation so 
those servers implementing random selection out of the ordered set are 
still compliant. Those servers implementing ordered interpretation are 
now compliant - where before with the list defined as un-ordered they 
would be non-compliant due to mis-interpreting an un-ordered list as 
ordered.


>>>> but haven't tested.  Chrome has a bug with the ordering of tags to
>>>> match the UI, but that's orthogonal to this issue.
>>>>
>>>> ...
>>>>
>>>> Older browsers did not send qvalues. Hence, server implementations
>>>> of language negotiation do use the ordering provided as I described
>>>> in the change.
>>>
>>> Some, apparently. But not all. Servers have been written according 
>>> to the spec, ignoring ordering. If we make ordering significant, 
>>> these will not interoperate anymore.
>>
>> In what way do they interoperate now, and in what way does that
>> change?  As far as I can tell, the only effect this change has
>> is a suggestion that they not respond randomly.
>
> Right now they interoperate as specified by the spec. If we change the 
> spec, they do not anymore (or only some of the time).
>

The new spec does not forbid random selection. Merely states that the 
client *wants* it to be interpreted non-randomly. Obeying that client 
preference is still optional.

Amos