Re: Question regarding RFC 8441

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

Received on Saturday, 6 April 2019 23:45:44 UTC