Re: Our Schedule

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:10:13 UTC