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

On Thu, Jan 19, 2023 at 8:47 AM Momoka Yamamoto <>

> 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
>> .)
> 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.

Thanks for helping me to understand the motivation for this proposal.  Do
you believe there are existing origins that
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.

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


> 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.

Interesting!  Publishing a flag for SETTINGS_ENABLE_CONNECT_PROTOCOL in the
HTTPS record seems plausible to me.


Received on Thursday, 19 January 2023 14:36:52 UTC