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

[Momoka Yamamoto <[e-mail]>]

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