W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021

Re: Advertising WebSocket support in the HTTPS resource record

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 21 Oct 2021 19:06:25 +0100
Message-ID: <CALGR9oa9pcL_X47gMNuTcA3MZ=TaLfXZSTgvCrbRPvivoON5NQ@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Ben Schwartz <bemasc@google.com>, Dragana Damjanovic <dragana.damjano@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.
Received on Thursday, 21 October 2021 18:06:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 21 October 2021 18:06:52 UTC