Re: Question regarding RFC 8441

On Sat, Apr 6, 2019 at 7:48 PM Andy Green <andy@warmcat.com> wrote:

>
>
> On 05/04/2019 15:10, Anmol Sethi wrote:
>
> > 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.
>
> 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.


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
> 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.
>
> > 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.
> 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
>
>