Re: #428 Accept-Language ordering for identical qvalues

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

and the change I made has no effect on UAs that send qvalues.
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.

>> 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.

>>> I believe this change should be backed out.
>> 
>> The change has no impact on user agents that send distinct
>> qvalues.  At most, it would change the interpretation for those
>> few requests that still rely on ordered language tags, for which
>> the prior specs had no interpretation at all.
> 
> Well, it had an interpretation ("same weight").
> 
> It's good that there are only few requests on relying on this. Do you want to encourage more, potentially breaking servers that ignore ordering?

It isn't possible to break those servers any more than they
are already broken by responding in a random fashion.

>> http://forums.thedailywtf.com/forums/t/15895.aspx
> 
> Yes, I'm aware that this is a FAQ. But we're not starting from scratch here.
> 
>> What I added is how Apache httpd has implemented it since before
>> any of the HTTP specs were RFCs, which was compatible with how
>> CERN httpd implemented it before that (no qvalues at all).
>> The change has no impact on conformance because language
>> negotiation is optional and the change is not expressed as a
>> requirement.  It also resolves an inconsistency with RFC4647.
> 
> It does have an impact, because servers that previously implemented the optional feature now do not anymore.

A server is not required to obey Accept-Language.

>> There are far more examples on the Web where applications
>> incorrectly assume the list is ordered
> 
> That'll be hard to count. :-)
> 
>>   http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=%2Fcom.ibm.itame.doc_6.1%2Fam61_webseal_admin134.htm
>> 
>>   http://www.developershome.com/wap/detection/detection.asp?page=acceptLanguageHeader
>> 
>> 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.

Yes, which is why we are changing the spec so that they can eventually
improve their implementation (or not).  An unordered list is not
sufficient because users don't send unordered lists, not even when
they are hand-crafted.  Everyone assumes they are ordered or they
send them with correct qvalues.

>> As Harald said,
>> 
>>> it seems still to be fairly normal to give a sequence of
>>> language-ranges in this header without any q= values, and expect the
>>> result to be deterministic.
> 
> I'd like so see evidence of that, not hearsay. Browsers do *not* rely on this.

ENOCARE.

>> because that's how it works in practice for the vast majority
>> of systems that implement content negotiation.  The spec should
>> reflect what is most interoperable for the users.
> 
> As far as I can tell, what's interoperable is the exact opposite: not relying on ordering, but sending qvalues.

One has nothing to do with the other.  The added text does not
change the ordering for UAs that send proper, non-identical
qvalues on language tags, even if they choose not to sort them
by order (which the latest browsers do for a good reason).

....Roy

Received on Thursday, 17 January 2013 10:17:34 UTC