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

[Lucas Pardue <[e-mail]>]

Hey Ben,

On Wed, Jan 18, 2023 at 11:59 PM Ben Schwartz <[e-mail]> wrote:

> On Wed, Jan 18, 2023 at 12:14 PM Lucas Pardue <[e-mail]>
> wrote:
> ...
>
>> When WebSockets over H2 was written, I might have agreed that
>> SETTINGS_ENABLE_CONNECT_PROTOCOL is a signal the server supports WebSockets
>> over H2.
>>
>
> (I don't think it ever meant that.)
>
>
>> But now we're adding multiple :protocol values into the mix with MASQUE
>> and WebTransport. Just because a page loaded over my infrastructure
>> includes a wss::// URL, it doesn't mean my infrastructure supports it for
>> all HTTP versions.
>>
>
> Are you sure?  I think it does.  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.

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?
That seems well beyond the extent of how RFC 8441 was written.

In this scenario, removing the wss:// from the content isn't an option, it
will just break the purpose of the page.


>
>
>> For instance, I might theoretically like to roll out support for
>> WebTransport and never roll out WebSockets.
>>
>
> That's fine, and has nothing to do with this.  However, you can't roll out
> WebTransport only on HTTP/X, and not on HTTP/Y, if your system offers both
> HTTP/X and HTTP/Y.  You have to roll it out on all versions before
> customers are allowed to use it.
>

> Whether a request can be serviced is a property of the target resource. So
>> if I had a server that understood CONNECT but wanted to reject :protocol:
>> websocket, then perhaps returning a 405 Method Not Allowed would be more
>> appropriate than a 501.
>>
>
> I don't think this will work.  Regardless of how the error is reported
> (via SETTINGS or via an HTTP error code), there is no requirement (e.g. in
> RFC 8441) that clients respond to an error by retrying a WebSocket setup
> using a different HTTP version, even if some clients today have some degree
> of fallback behavior.
>
> In the general case, this would be sheer madness.  For example, if I try
> WebTransport over HTTP/2, but the server says
> SETTINGS_ENABLE_CONNECT_PROTOCOL is not supported, should I retry it over
> HTTP/1.1 or  HTTP/3?
>

I mean that seems like a problem that WebTransport should design for. AFAIK
there is no WebTransport mapping to HTTP/1.1. Again, I can't control the
content, so if somebody includes JavaScript that uses the WebTransport API,
and has configured the CDN to disable HTTP/2 or HTTP/3 support, then
there's several possible failure scenarios. Even if the CDN supports
CONNECT_PROTOCOL on all versions and all versions are enable, if the client
attempts to use WebTransport over HTTP/3 and the local network is blocking
UDP, what is the fallback logic there?

This all gets a lot more complicated if websockets or webtransport are run
on third-party domains. And it also gets complicatedif we consider
multi-CDN and the mess that Alt-Svc is making there.

For a single orign that is running all of its own infratructure I might
agree that it should be self-consistent. But adding intermediaries into the
mix creates separation of concerns and responsibility that make it a lot
harder.

Cheers,
Lucas