Re: Advertising WebSocket support in the HTTPS resource record

On Wed, Oct 20, 2021 at 5:35 PM Ben Schwartz <bemasc@google.com> wrote:

>
> My expectation is that the supported :protocols are handled like the
> supported paths: the client knows which one it needs from the URI (e.g.
> wss://..., https://.../foo), and the origin had better support it if it
> is advertising those URIs anywhere.  I don't think we need a pre-connection
> hint about the supported :protocols.
>

I don't follow. That implies the server would present different pages to a
client based on the protocol that the client connected with. That sounds
hard and I'm not sure it would help much. In today's, a client that doesn't
support WebSocket over H2 would simply see wss:// and open a new HTTP/1.1
connection for the upgrade. We should hope that a H2 websocket client that
sees wss:// would try to create the websocket over a connection that
support it, or an H3 websocket client see wss:// and does likewise. This
gets a bit murky when Alt-Svc is thrown in the mix.

A DNS record or an ALPS value only tells the H2 client that it is allowed
to send a request that contains the :protocol pseudo-header. If it does,
and finds that the server doesn't support the protocol that it wants, then
the request will fail, and the client wasted its time. Saving time seems to
be what this proposal is about.