- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 24 Jan 2013 11:29:53 +0100
- 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 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