Re: Our Schedule

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.

Regards,

Yoav


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