Re: Call for Adoption: HTTP/2 Bis

Hi Ian,

On Wed, Dec 02, 2020 at 08:46:00PM -0500, Ian Swett wrote:
> That seems sensible to me, but I'd like a better understanding of
> whether we ever expect to be able to ship extensions to HTTP/2 or not
> before I support the lack of a new ALPN.

My personal feeling on this is that adding a new ALPN will not solve a
real issue but will introduce more interop issues. The problem is always
the same, no single stack implements 100% of the features of a protocol,
and by advertising sub-versions we imply that all of these features are
supported instead of making them discoverable or negotiable. For example,
plenty of hand-written clients advertising support for HTTP/1.1 did not
support chunking. And dealing with these only adds extra work on all
implementations. I think that the ALPN number should reflect what the
client can instantly trust to save a round trip without waiting for
settings, i.e. on-wire format, protocol elements (e.g HPACK), limits and
retryable defaults. I don't see how a new ALPN will help for websocket
because I'm fairly sure we'll find this new ALPN deployed by new
implementations to support the new protocol elements even if they don't
implement websocket or don't know where to forward it. In this essence,
the client will still have to be able to retry it a different way. So
really a new ALPN will not solve websocket interoperability issues.

> A few IETF contributors I trust have put forth the idea that in 5 years, H2
> will no longer be worth supporting given the widespread deployment of H3,
> so possibly this is a self-solving problem?

I'm not that much convinced that H3 will have that much love in the
datacenter until it supports being transported over TCP, and for now H2
is much more capable than H1 for application-to-application exchanges.
What I suspect once H3 becomes popular is that we'll see attempts at
transporting it over TCP to replace H2 though. Will that take off ? I
cannot predict.

Cheers,
Willy

Received on Thursday, 3 December 2020 06:01:39 UTC