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

Hello,
I have submitted a new revision of this
draft draft-momoka-httpbis-settings-enable-websockets.

The changes include Lucas's suggestion of a section explaining why this
would be useful.

   The SETTINGS_ENABLE_WEBSOCKETS parameter is an explicit signal about
   the server support for bootstrapping WebSockets on the connection.
   Where a server declares it does not support WebSockets, clients can
   avoid sending WebSocket handshake requests that would fail.  This
   saves unnecessary work for both client and server, and potentially
   reduces delays.  For instance, a client that learns an HTTP/2 or
   HTTP/3 connection does not support WebSockets via the setting, could
   instead attempt to create a WebSocket using the HTTP/1.1 Upgrade
   mechanism at the immediate moment it is required.

   Other protocols also rely on the extended CONNECT extension for
   bootstrapping.  This mechanism provides clients with a stronger
   signal about whether the WebSocket protocol is supported on a
   connection.  This can help improve compatibility with other extended
   CONNECT-based protocols by avoiding the client making assumption
   about the supported protocols.

   Clients that do not implement this extension will not be able to use
   its signal.  In order to support legacy deployments, clients MAY
   initiate a WebSocket request when they receive
   SETTINGS_ENABLE_WEBSOCKETS with a value of 0, or if the parameter is
   omitted from received settings.  Such requests could fail,
   introducing additional latency, which this extension is intended to
   help avoid.


The proposed parameter will be useful if an active HTTP/2 (or HTTP/3)
connection to the server already exists when a document with a wss:/ URL is
loaded. The browser can then choose whether to try opening the WebSocket
stream over the connection, as the proposed SETTINGS_ENABLE_WEBSOCKETS has
likely been received by that point.

However, the proposed parameter won't be useful when a browser tries to
establish a new connection because the SETTINGS will not be received when a
decision to use HTTP/2 or HTTP/1 is made.

Best,

Momoka


A new version of I-D, draft-momoka-httpbis-settings-enable-websockets-01.txt
> has been successfully submitted by Momoka Yamamoto and posted to the
> IETF repository.
>
> Name:           draft-momoka-httpbis-settings-enable-websockets
> Revision:       01
> Title:          SETTINGS_ENABLE_WEBSOCKETS settings parameter for HTTP/2
> and HTTP/3
> Document date:  2023-02-28
> Group:          Individual Submission
> Pages:          6
> URL:
> https://www.ietf.org/archive/id/draft-momoka-httpbis-settings-enable-websockets-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-momoka-httpbis-settings-enable-websockets/
> Html:
> https://www.ietf.org/archive/id/draft-momoka-httpbis-settings-enable-websockets-01.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-momoka-httpbis-settings-enable-websockets
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-momoka-httpbis-settings-enable-websockets-01
>
> Abstract:
>    This document proposes a new HTTP settings parameter,
>    SETTINGS_ENABLE_WEBSOCKETS.  This parameter indicates whether the
>    server supports bootstrapping WebSockets over the established
>    connection.
>
> The IETF Secretariat
>


On Sat, Jan 21, 2023 at 2:07 AM Momoka Yamamoto <momoka.my6@gmail.com>
wrote:

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