Re: Advertising WebSocket support in the HTTPS resource record

On Thu, Oct 21, 2021 at 6:46 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> In theory, in terms of HTTP semantics, if someone mints wss://
> websocket.example.org and sends an h3 Alt-Svc for websocket.example.org,
> then that means that the client can use WebSocket over HTTP/3.
>
> However, in practice, as Stefan points out, that might not always hold. In
> the scenario where someone accidentally misconfigured their server by not
> having enough communication between h1/h2/h3, they can rectify the
> situation by replying with HTTP status code 421. That'll cause the client
> to fallback to an earlier version of HTTP.
>

I don't think 421 is the right status here. The example I would actually
use is a document loaded from https://example.com/index.html that includes
wss://example.com/chat. If this is loaded via an H2 connection, which
supports extended connect for :protocol connect-udp but not websocket, then
the CONNECT request should fail but 421 is a status about authority
(generally caused by coalescing, a whole additional ballgame), and there is
no authority problem here. The client fallback to a fresh connection would
have to be careful to use HTTP/1.1.


> This all sounds like we have a semantically coherent answer, with a
> pragmatic fallback in case of misconfiguration. The only downside is that
> the fallback might waste time. Given that the fallback is caused by
> misconfiguration, I'm not sure there's value in creating a new mechanism to
> avoid it: if you really really care about performance, configure your
> server correctly.
>

There might be a path, but it sounds like abusing the wrong status code is
not semantically coherent :)


>
> The proposed mechanism using HTTPS records requires the server operators
> to make changes to their DNS which isn't always possible. If a server
> operator can/wants to do this, they can just as easily create a new
> hostname websocket-but-only-on-h1.example.org hostname and not advertise
> HTTP/3 support for that origin.
>

That sounds a lot easier than it is. And it is a solution for a problem
that doesn't exist for most WebSocket deployments today. If the answer to
making HTTP/2 WebSockets (as an example) work is to update an entire fleet
and change all the URLs, the simplest solution approach is to really never
ship WebSockets over a version other than HTTP/1.1.