Re: Advertising WebSocket support in the HTTPS resource record

On Thu, Oct 21, 2021 at 11:10 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

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

For HTTP/2 I think instead of 421, we could use HTTP_1_1_REQUIRED. Does
that sound right?

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