W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: #428 Accept-Language ordering for identical qvalues

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 24 Jan 2013 11:29:53 +0100
Message-ID: <51010D21.3020409@gmx.de>
To: Amos Jeffries <squid3@treenet.co.nz>
CC: ietf-http-wg@w3.org
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 

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

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


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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC