Re: #428 Accept-Language ordering for identical qvalues

On 2013-01-24 11:17, Amos Jeffries wrote:
> 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.

I don't understand that sentence.

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

Then you need to explain the problem better.

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

I still don't understand what the problem is. Can you give a concrete 
example?

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

Recipients will still need to implement qvalues, so I don't see a big 
gain here.

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

Understood, but making A-L more compact will not fix HTTP/1.1's overhead 
significantly.

I think our priorities should be:

1) Get HTTP/1.1 out of the door. To get that done, it would be helpful 
not to make any new changes after WGLC (and this is the case here).

Then:

2) Think about compact header field serialization in HTTP/2.

Best regards, Julian

Received on Thursday, 24 January 2013 10:30:25 UTC