- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 11 Dec 2020 09:48:35 +0100
- To: Willy Tarreau <w@1wt.eu>
- Cc: Mike Bishop <mbishop@evequefou.be>, Ian Swett <ianswett@google.com>, David Benjamin <davidben@chromium.org>, Cory Benfield <cory@lukasa.co.uk>, Mark Nottingham <mnot@mnot.net>, Bence Béky <bnc@google.com>, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>
> Am 11.12.2020 um 05:41 schrieb Willy Tarreau <w@1wt.eu>: > > Hi Mike, > > On Thu, Dec 10, 2020 at 10:05:22PM +0000, Mike Bishop wrote: >> And to me, that's the real question over a new ALPN. If we can keep the >> token "h2" and add GREASE successfully, let's do that. If we can't add >> GREASE without changing the ALPN token, we should consider changing the ALPN >> token. > > But why would GREASE require a new ALPN ? Bence is already doing some > greasing and managed to find bugs in several of our implementations. I'd > rather push stronger in this direction after some code points can be > reserved for various purposes. +1 >> Of course, that means we're effectively minting "h2.1" or >> "h2-nobugs", at which point we need not necessarily be limited to >> non-breaking changes. > > What I hate with changing ALPN is that it's a user-visible change. Asking > users to change their ALPN string from "h2,http/1.1" to "h2.1,h2,http/1.1" > just because a working group decided to slightly change the protocol for > the sake of better interoperability is hard to justify, especially after > it was claimed that the protocol is called "HTTP/2" because it will not > have a sub-version. As a revised h2 would need to be h4, this seems like a silly way to go. I am doubtful that fixing the situation of broken implementations by new protocol versions can be applied very often. I think servers would rather publish special resources to make capabilities known. A client could check the resource /.well-known/h2/capabilities, for example. Not everything is page load time sensitive. > If we'd change the ALPN we should then think about all the on-wire changes > that were discussed in the past, like the poor hpack encoding, changing > initial settings etc. It doesn't seem worth doing with H3 knocking at the > door in my opinion. I was only half-joking when I said it would be "h4". > > Cheers, > Willy Cheers, Stefan
Received on Friday, 11 December 2020 08:48:53 UTC