Re: #428 Accept-Language ordering for identical qvalues

[Amos Jeffries <[e-mail]>]

On 24/01/2013 10:50 p.m., Julian Reschke wrote:
> On 2013-01-24 09:54, Amos Jeffries wrote:
>> On 24/01/2013 9:26 p.m., Julian Reschke wrote:
>>> On 2013-01-24 02:17, Mark Nottingham wrote:
>>>> So, does anyone have an issue with making ordering significant when
>>>> there's no qvalue for *all* headers that use qvalues?
>>>> ..
>>>
>>> I still do, and I'd prefer we go back to what the spec has been saying
>>> for well over a decade.
>>>
>>> What *real* problem are we solving with this change that justifies
>>> making current implementations broken?
>>
>> Problem 1) a lot of agents (~57% by unique U-A string) are using
>> q-values to specify ordering where the spec says "unordered".
>
> Not sure what you're trying to say here. If they send q-values there 
> is no doubt about the semantics, right?
>
> Also, counting unique UA strings generates a totally distorted statistic.

Somewhat yes. However IME it distorts the numbers to be more inline with 
total traffic load %'s each agent places on the network overall.

>
>> Problem 2) a majority of the remaining agents appear to be treating the
>> field-value as an ordered list of preferences even without q-values.
>
> Recipients, I assume? How is that a problem? They choose one plausible 
> interpretation where the spec doesn't define one.
>

Senders.

The pattern is clearly a country-specific code, a generic language code 
and possibly followed by a few similar languages in decreasing order of 
similarity, possibly followed by wildcards.
The pattern is strong and almost identical for both agents sending 
ordered q-values and agents sending no q-values at all.
The errors all appear to be at the interface between mechanisms with 
confusion evident when they are mixed in one request header.

Problem is that the original spec wording you are arguing to keep says 
it is a wrong interpretation. One which leads to all these being problems.

>> Problem 3)  ~1% of agents are incorectly implementing q-values. (see my
>> earlier post responding to your request for examples).
>
> Are these agents widely used? Can they be fixed? Did you report bugs 
> against them?
>
>> Problem 4) q-values being mandatory when preference order is wanted adds
>> complexity on both ends of the transaction, causing unnecessary CPU
>> burden on the recipient. Misunderstandings and a host of needless
>> mistakes by end-users and developers alike. (again see my earlier post
>> for examples).
>
> That is true, but we can't remove q values at this point. Note we are 
> discussing HTTP/1.1.

But we can make the primary need for them decrease by making the header 
ordered by default.

>
>> Problem 5) On the Accept-Language header the bandwidth required to
>> transmit q-values inflates the header size by at least 55% (ISO code:
>> 2-5 bytes, q-v component: 6 bytes).
>
> For that field value, yes.

That is the field-value we are discussing though.


Amos