Re: #428 Accept-Language ordering for identical qvalues

[Julian Reschke <[e-mail]>]

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.

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

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

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

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

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

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

Best regards, Julian