- From: Momoka Yamamoto <momoka.my6@gmail.com>
- Date: Sat, 21 Jan 2023 03:07:41 +0900
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Ben Schwartz <bemasc@google.com>, ietf-http-wg@w3.org
- Message-ID: <CAD9w2qajqHy+JbSPGKUjfPL0Bh94CaOyNn=iRouBS1PWRUBZkA@mail.gmail.com>
Hello, Thanks for helping me to understand the motivation for this proposal. Do >> you believe there are existing origins that >> 1. Offer SETTINGS_ENABLE_CONNECT_PROTOCOL in HTTP/3 AND >> 2. Operate WebSocket services AND >> 3. Don't support WebSocket over HTTP/3 AND >> 4. Are not willing to implement WebSocket over HTTP/3 >> ? >> >> If so, then I agree we have a problem. If not, I think the best course >> of action is to assume that the origin's supported "Upgrade >> Tokens"/":protocol values" are independent of HTTP version, except where >> the IETF has ruled out support for a particular combination of :protocol >> and HTTP version. >> > > I think this is an excellent way to look at the landscape. > > My take is that SETTINGS_ENABLE_CONNECT_PROTOCOL declares that a H2 or H3 > server is willing to consider a request with the :protocol pseudo-header as > valid syntax. There's nothing saying what values of :protocol it has it has > to support. > > To question 4, I'd say that is equally a product question as much a > technical one. RFC 8441 has been knocking around a while but my feeling is > that deployments are light. There could be situations where interop or > implementation bugs mean WebSockets over HTTP/X behave badly while > WebSockets over HTTP/Y are fine, meanwhile WebTransport over X and Y also > work fine. In that scenario, temporarily disabling a problem variant until > it can be investigated and fixed is helpful, because the other variants can > continue delivering the feature. So allowing fine tuned control over > variants, such as via an explicit WebSocket setting, would seem to satisfy > the server and stop the client from having to guess. > For Ben's question with the 4 statements, 3 and 4 are very likely to be yes because there are close to no servers implementing WebSockets over HTTP/3 at the moment. So then the question will be, "if a server Operate WebSocket services, will the server never use extended CONNECT mechanisms such as WebTransport?" And I think this is an assumption that should not be made. It would be nice if a client could know if the existing HTTP/3 connection >>> supports bootstrapping WebSockets. >>> >> >> In my view, clients are free to assume this when they see a wss:// link >> to an origin that offers SETTINGS_ENABLE_CONNECT_PROTOCOL in HTTP/3. >> > > Thanks for the earlier link to Chrome's behaviour, it helps to frame the > discussion. Quoting it for ease > > > This would only be used for secure WebSockets requests, and only if > there is already an HTTP/2 connection where the server has already > advertised support for WebSockets over HTTP/2 via the HTTP/2 SETTINGS > parameter defined in the specification. > > SETTINGS_ENABLE_CONNECT_PROTOCOL doesn't imply that bootstrapping > websockets is supported IMO, which would mean this assumption doesn't > strictly hold true. Content that includes a wss:// parameter could be > generated without any knowledge of the various caches or edges features - > there's typically administrative and business relationships between these > groups. > > Since Chrome only sends WebSocket over HTTP/2 on a warm connection with a > SETTING of a particular value, changing that value to be > SETTINGS_ENABLE_WEBSOCKET instead seems like it aligns well with the > current flow and wouldn't be too disruptive. > > For reference, WebTransport over HTTP/3 has been discussing related > matters; see > https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/68. > My understanding is that the discussion has aligned on advertising all > "layered settings", that is, advertising SETTINGS_ENABLE_CONNECT_PROTOCOL > and SETTINGS_ENABLE_WEBTRANSPORT. Defining SETTINGS_ENABLE_WEBSOCKETS would > be consistent with that. > One thing that was very confusing for me when reading RFC8441 was that it's about "Bootstrapping WebSockets with HTTP/2" but it defines a general purpose HTTP/2 Extended CONNECT mechanism and SETTINGS_ENABLE_CONNECT_PROTOCOL. A new settings frame will minimise this confusion. And even if we follow Dragana's draft, SETTINGS_ENABLE_WEBSOCKETS will still be needed to distinguish between advertising support for :protocol pseudo-headers and support for WebSockets. Momoka
Received on Friday, 20 January 2023 18:08:06 UTC