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

Hey,

On Thu, Jan 19, 2023 at 2:36 PM Ben Schwartz <bemasc@google.com> wrote:

>
>
> On Thu, Jan 19, 2023 at 8:47 AM Momoka Yamamoto <momoka.my6@gmail.com>
> wrote:
>
>> 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.
>>
>
> 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.


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


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

In the context of Chrome: this seems like a new flow that is a performance
optimization. That's useful too but is still a separate issue IMO. We could
fix both at the same time, but we should be clear what they address.

In Dragana's draft [1], the proposal was to advertise "extended-connect" in
an SvcParamKeys. If we were to follow a layered approach, we could also
consider having a signal for the upgrade tokens that are also supported.


Cheers,
Lucas

[1] -
https://www.ietf.org/archive/id/draft-damjanovic-websockets-https-rr-00.html


> ...
>