- From: Eliot Lear <lear@cisco.com>
- Date: Tue, 27 May 2014 08:29:37 +0200
- 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>
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 06:30:07 UTC