Re: Our Schedule

On Tue, May 27, 2014 at 08:29:37AM +0200, Eliot Lear wrote:
> 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.

At least what I'm seeing is the possibility to consider maybe http/2
as the legacy compression-less mode that anyone should support, then
on top of that we'll be able to experiment with various compression
schemes without requiring significant upgrades. For example, nowadays,
nobody cares what TLS version or extension is supported on a given
server, things upgrade smoothly. Here we could have the same mechanism,
with a common fallback.

Considering that 1.1 would be the fallback would keep people away from
2.0 for a longer time and cast a shadow over the protocol when small
issues face up at the beginning (which is normal).

Willy

Received on Tuesday, 27 May 2014 06:44:07 UTC