On Wed, Oct 20, 2021 at 6:35 PM Ben Schwartz <bemasc@google.com> wrote: > > > 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. > In case of WebSockets the url is wss:// and that can be serve using HTTP/1.1, HTTP/2 or HTTP/3 but a particular server may not support WS over HTTP/2 or WS over HTTP/3
Received on Wednesday, 20 October 2021 19:06:24 UTC