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

Re: Our Schedule

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Tue, 27 May 2014 13:38:18 +0300
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <79AF1F78-84EB-45E3-9ED4-1880A8EFD7DD@gmail.com>
To: Adrien de Croy <adrien@qbik.com>
I had this idea once about replacing the encoding of headers one by one, changing most of them to compact binary fields. I even wrote a (by now long-expired) draft. The advantage of Huffman or gzip is that they work on string texts without having to design a different encoding for each header field. 

A less ambitious change would be to change the encoding of headers to something like pascal strings (length field followed by data) which would allow for faster parsing than searching for commas, quotes, etc.

Either way, that would be a nice idea for HTTP/3. I donít think the benefit is great enough that we want to hold up HTTP/2.

Having a no-compression option in case a security flaw is discovered in HPACK is a good thing to add to HTTP/2 even at this point, but this kind of better compression?  I donít think so.



On May 27, 2014, at 1:09 PM, Adrien de Croy <adrien@qbik.com> wrote:

> Whilst I agree that a major benefit is compression, if we don't do something about having to parse strings (e.g. after we decompress them) searching linearly for delimiters, then IMO we're missing another major opportunity for benefit.
> Adrien
> ------ Original Message ------
> From: "Eliot Lear" <lear@cisco.com>
> To: "Willy Tarreau" <w@1wt.eu>; "Martin Nilsson" <nilsson@opera.com>
> Cc: "Michael Sweet" <msweet@apple.com>; "Mark Nottingham" <mnot@mnot.net>; "Patrick McManus" <pmcmanus@mozilla.com>; "James M Snell" <jasnell@gmail.com>; "Cory Benfield" <cory@lukasa.co.uk>; "Greg Wilkins" <gregw@intalio.com>; "HTTP Working Group" <ietf-http-wg@w3.org>
> Sent: 27/05/2014 6:29:37 p.m.
> Subject: Re: Our Schedule
>> Hi,
>> On 5/27/14, 7:44 AM, Willy Tarreau wrote:
>>> From a technical point of view, I'd also like the header compression to
>>> be optional, but I think that's a no-go as it will waste an RTT in the
>>> negotiation. However we might possibly consider having a simpler variant
>>> of HTTP/2 that does not implement header compression and which is
>>> advertised in the TLS or upgrade handshake (eg: http/2-). That could
>>> be useful for simple devices which don't need all the bells and whistles,
>>> and would not cost an extra RTT.
>> Since there are no negotiations this is the only way to get there. The
>> one nice thing about having the option is that if some problem *is*
>> found with HPACK browsers could switch to uncompressed without a
>> standards change. The real question is whether it is advisable to
>> continue with HTTP/2 without compression or to simply back off to 1.1.
>> You can do that too, and it wouldn't require an additional code path (or
>> bypass), and if Patrick is correct that the benefit of /2 is tied to
>> compression, maybe it's the right approach.
>> Eliot
Received on Tuesday, 27 May 2014 10:38:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC