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

On Wed, Jan 18, 2023 at 7:33 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Hey Ben,
>
> On Wed, Jan 18, 2023 at 11:59 PM Ben Schwartz <bemasc@google.com> wrote:
>
...

> Or rather, if your infrastructure does not support WebSocket for all its
>> HTTP versions, then wss:// URLs that point to your infrastructure are not
>> valid.
>>
>
> 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.
>

By my reading, RFC 8441 permits a wss:// client to negotiate H2 via ALPN,
then fail hard because SETTINGS_ENABLE_CONNECT_PROTOCOL is missing.
However, I concede that this would result in connection failure with
servers that were in a valid configuration prior to RFC 8441.

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

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

I think that's eminently reasonable.  It's trivial to implement, given that
you already have a WebSocket implementation.  In the worst case you can
just forward the bytestream to your HTTP/1.1 gateway.

The alternatives push a lot more complexity onto the client, and likely
impair performance overall.

That seems well beyond the extent of how RFC 8441 was written.
>

I think that we probably need a short RFC to document the version
requirements associated with RFC 8441 (and RFC 9220).

...