W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: Call for Adoption: HTTP/2 Bis

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 3 Dec 2020 10:00:33 +0100
Cc: (wrong string) éky <bnc@google.com>, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>
Message-Id: <E5ED5826-8112-4060-93DA-623FAB7AE86E@greenbytes.de>
To: Willy Tarreau <w@1wt.eu>
What Willy said.

> Am 03.12.2020 um 07:01 schrieb Willy Tarreau <w@1wt.eu>:
> 
> 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 09:00:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 3 December 2020 09:00:52 UTC