W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2023

Re: New Version Notification for draft-momoka-httpbis-settings-enable-websockets-00.txt

From: Momoka Yamamoto <momoka.my6@gmail.com>
Date: Thu, 19 Jan 2023 22:46:59 +0900
Message-ID: <CAD9w2qaGEG96hDrGEadMSRE+Kxr-DzuThyMmShBzjzmBarC_Jg@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, ietf-http-wg@w3.org
Hello,
Thank you both for your response.

Most clients have solved this problem by not implementing RFC 8441 at all.
> Chromium has implemented it, with an interesting workaround: Extended
> CONNECT is only used if a suitable socket with
> SETTINGS_ENABLE_CONNECT_PROTOCOL is already available.  If a fresh
> connection is needed for wss://, Chromium always uses HTTP/1.1. (See
> https://docs.google.com/document/d/1ZxaHz4j2BDMa1aI5CQHMjtFI3UxGT459pjYv4To9rFY/edit#
> .)
>

This is the use case I am thinking of but for WebSockets over HTTP/3.
Chromium uses WebSockets over HTTP/2 if there is an existing HTTP/2
connection that has received SETTINGS_ENABLE_CONNECT_PROTOCOL.
However, it cannot do the same for HTTP/3 because receiving
SETTINGS_ENABLE_CONNECT_PROTOCOL currently does not guarantee support for
WebSockets over HTTP/3. SETTINGS_ENABLE_CONNECT_PROTOCOL will be sent for
other protocols as well.
It would be nice if a client could know if the existing HTTP/3 connection
supports bootstrapping WebSockets.



Imagine a CDN that is responsible for infrastructure but not content
> (pages). For many years pages have been served over HTTP/2 or HTTP/3
> without advertising SETTINGS_ENABLE_CONNECT_PROTOCOL and wss://  scheme -
> everything has worked fine. Clients used HTTP/1.1 bootstrapped websockets.
> Even is a server offered the setting, a client might not support that
> feature and would act on wss:// by opening a HTTP/1.1 bootstrapped
> connection.

Now if I want to deploy e.g. a CONNECT-UDP proxy on that CDN
> infrastructure, then I have to support WebSocket over HTTP/2 or HTTP/3?
> That seems well beyond the extent of how RFC 8441 was written.

In this scenario, removing the wss:// from the content isn't an option, it
> will just break the purpose of the page.


This is also an example of when a server wants to advertise that it does
not support bootstrapping WebSockets over HTTP/2 or HTTP/3.
In this case, SETTINGS_ENABLE_WEBSOCKETS can be used to signal that it does
not support the protocol over HTTP/2 or HTTP/3.


It would be nice if a client could know if the server supports
Bootstrapping WebSockets over HTTP/2 or HTTP/3 before initiating a
connection to the server.
But at least with this settings parameter, we can know that at least when
there already is a connection to the server.

Momoka Y
Received on Thursday, 19 January 2023 13:47:24 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC