Re: Advertising WebSocket support in the HTTPS resource record

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.

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.

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.

David

On Thu, Oct 21, 2021 at 1:09 AM Stefan Eissing <stefan.eissing@greenbytes.de>
wrote:

>
>
> > Am 20.10.2021 um 23:19 schrieb Lucas Pardue <lucaspardue.24.7@gmail.com
> >:
> >
> > That's the exact case I'm thinking about. There might be little value
> trying to backport connect-udp to H2 for some kinds of services, it might
> be better to fallback to plain old CONNECT. Meanwhile, someone might have
> websocket support left as a TODO for HTTP/3. Requiring feature parity
> across all versions just increases the bar to experimentation or deploying
> new versions of things.
>
> +1
>
> Some servers are also configurable in their protocol implementations. H1,
> H2 and H3 implementations may not be aware of each others capabilities. Or
> a particular implementation's feature is flawed and disabled until patched.
> It would be good to allow other H* implementations to still be available as
> fallback.
>
> Stefan
>