Re: #428 Accept-Language ordering for identical qvalues

["Roy T. Fielding" <[e-mail]>]

On Jan 16, 2013, at 7:56 AM, Julian Reschke wrote:

> Hi there,
> 
> with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2119#file1>, the spec now says:
> 
> "If no quality values are assigned or multiple language tags have been assigned the same quality, the same-weighted languages are listed in descending order of priority."
> 
> This is a change from both RFC 2068 and RFC 2616 which we *did* discuss back in the thread starting with <​ http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0223.html>; back then we decided not to make this change because we know of implementations ignoring the ordering, and no convincing argument was given for making the ordering significant.

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 haven't tested.  Chrome has a bug with the ordering of tags to
match the UI, but that's orthogonal to this issue.

Safari does not support languages other than the list set in the
user's system settings, and it only provides the first of those,
which is wrong for both functionality and privacy reasons.
The system settings define the core UI in OS X, so the user can't
turn it off.

Older browsers did not send qvalues. Hence, server implementations
of language negotiation do use the ordering provided as I described
in the change.

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

http://forums.thedailywtf.com/forums/t/15895.aspx

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.

There are far more examples on the Web where applications
incorrectly assume the list is ordered

  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.

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.

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.

....Roy