W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: consensus on :query ?

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sun, 20 Jul 2014 20:59:29 +0000
To: Mark Nottingham <mnot@mnot.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <32840.1405889969@critter.freebsd.dk>
In message <089DE71E-C5B4-41F7-AD23-4529A43ED04E@mnot.net>, Mark Nottingham wri
tes:

><https://github.com/http2/http2-spec/issues/556>
>
>I'm not hearing anyone else express interest in this.
>
>Comments? Unless there's a clamour of support soon, I'm inclined to 
>close with no action.

It would be interesting if somebody with a setup and data
could try to see how it affects compression.

>On 12 Jul 2014, at 3:19 am, Poul-Henning Kamp <phk@phk.freebsd.dk> 
>wrote:
>
>> Some time ago I proposed and argued that :query should be split out
>> from :path and as I perceived it, there were a lot of people nodding
>> on that.
>> 
>> I don't want to inject it right now, we have plenty of balls in the
>> air, but can I get you top open an issue for it, so we don't forget ?
>> 
>> (Some of) the arguments for :query:
>> 
>> 	Load balancers and other "triage" proxies seldom if ever
>> 	look at the :query part to determine handling, splitting
>> 	this field out of :path means they don't have as much data
>> 	to run through the decompressor to make their decisions.
>> 
>> 	Semantically :path is much more static than :query is, which
>> 	means that :path can be compressed by back-reference, whereas
>> 	:query almost always will need huffman coding.
>> 
>> -- 
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk@FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe    
>> Never attribute to malice what can adequately be explained by 
>incompetence.
>
>--
>Mark Nottingham   http://www.mnot.net/
>
>

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Sunday, 20 July 2014 20:59:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC