- From: David Schinazi <dschinazi.ietf@gmail.com>
- Date: Thu, 21 Oct 2021 10:46:25 -0700
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, Ben Schwartz <bemasc@google.com>, Dragana Damjanovic <dragana.damjano@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAPDSy+5JxQZtsAreC=DyNSNrFSJVjz8WuqWEJJsHTVusBYQ4Qg@mail.gmail.com>
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 >
Received on Thursday, 21 October 2021 17:46:51 UTC