On Wed, Oct 20, 2021 at 12:27 PM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > > > On Wed, 20 Oct 2021, 17:11 Ben Schwartz, <bemasc@google.com> wrote: > >> >> >> Rather than optimize the performance of origins that use WebSockets, and >> support HTTP/2 and HTTP/3, but only support WebSockets on HTTP/1.1, I would >> prefer to encourage server deployment of WebSockets support on all HTTP >> versions. We could also consider documenting a parallel connection >> strategy for clients, if it's important to avoid a fallback delay. >> > > That's an interesting point. Extended CONNECT isn't just for Websockets, > as we are seeing with MASQUE developments. So I would expect cases where a > server only :protocol connect-udp and NOT websockets, or vice versa. So to > make this type of thing work, it seems like what is needed is a protocol > hint (singular or a list) too. > 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.
Received on Wednesday, 20 October 2021 16:35:46 UTC