Subject: Question regarding RFC 8441

From: Anmol Sethi <[email-masked]>
Date: Fri, 05 Apr 2019 07:10:38 +0000

RFC 8441 doesn’t allow clients to gracefully begin using WebSocket’s over HTTP/2.

The only option right now will be to make a CONNECT request over a HTTP/2 connection first to see if the client supports WebSockets over HTTP/2 and then if not, close the connection and fallback to HTTP/1.1.

This is unideal because at least for now, most of the time WebSockets will only be available over HTTP/1.1 so the extra request will just add latency.

I propose a new protocol ID be added to the ALPN list at https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

This will allow a client to efficiently check the TLS handshake to see whether a server supports WebSocket’s over HTTP/2.

---

From: Andy Green <[email-masked]>
Date: Sun, 7 Apr 2019 07:45:12 +0800

> This is unideal because at least for now, most of the time WebSockets will only be available over HTTP/1.1 so the extra request will just add latency.

That's right... however in the browser use-case, the typical pattern is 
the user visits a webpage, and the page brings in and runs JS that opens 
the ws link back to the save host.  Under those conditions, the browser 
already picked up on the server capabilities including 8441 support 
returned from the server when it started the h2 connection to get the 
initial webpage.

However the usecase you're implying is also valid... for example, 
headless IoT devices may just want the ws connection to do its business 
and no use for any html / js first.  Or the place an initial webpage 
tells it to go to open the ws connection is not the same server where it 
got the webpage / js part from.

Alt-Svc doesn't help if you never met the server before, since it's also 
in-band for h2.

What you could do to limit the impact is cache clientside which vhosts 
turned out to have 8441 support last time they were tried... you will 
know very quickly after tls setup if 8441 is available or not.  And if 
you cache it, you have a high probability of getting it right first time 
subsequently.

> This will allow a client to efficiently check the TLS handshake to see whether a server supports WebSocket’s over HTTP/2.
This is a bit different than the normal alpn protocol negotiation. 
Servers would list h2 and / or h2-8441 or whatever, but if you support 
h2-8441, it's a superset of h2 actually, with an extra option 
implemented... which can be discovered in-band.  If discrete protocol 
capabilities started getting exposed on alpn, the alpn string could get 
pretty large over time.  Maybe it would have been a nice idea if ALPN 
let you define like h2:<bitfield of protocol-specific capabilities> in 
ALPN, but it doesn't today afaik so no clients would understand it.

-Andy

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 11 Apr 2019 17:15:54 -0400

On Sat, Apr 6, 2019 at 7:48 PM Andy Green <[email-masked]> wrote:

> > The only option right now will be to make a CONNECT request over a
> HTTP/2 connection first to see if the client supports WebSockets over
> HTTP/2 and then if not, close the connection and fallback to HTTP/1.1.
> >
> > This is unideal because at least for now, most of the time WebSockets
> will only be available over HTTP/1.1 so the extra request will just add
> latency.
>
> and no use for any html / js first.

In this case, the device can simply continue to use HTTP/1.1 WebSockets.
I'm not aware of WebSocket over H2 having any advantage for a client who
just wants a WebSocket.

>   Or the place an initial webpage
> > I propose a new protocol ID be added to the ALPN list at
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
> >
> > This will allow a client to efficiently check the TLS handshake to see
> whether a server supports WebSocket’s over HTTP/2.