Re: Advertising WebSocket support in the HTTPS resource record

On Wed, Oct 20, 2021 at 6:27 PM Ben Schwartz <bemasc@google.com> wrote:

>
>
> On Wed, Oct 20, 2021, 12:54 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>>
>> On Wed, Oct 20, 2021 at 5:35 PM Ben Schwartz <bemasc@google.com> wrote:
>>
>>>
>>> My expectation is that the supported :protocols are handled like the
>>> supported paths: the client knows which one it needs from the URI (e.g.
>>> wss://..., https://.../foo), and the origin had better support it if it
>>> is advertising those URIs anywhere.  I don't think we need a pre-connection
>>> hint about the supported :protocols.
>>>
>>
>> I don't follow. That implies the server would present different pages to
>> a client based on the protocol that the client connected with.
>>
>
> No, I'm trying to say the opposite of that.  These things are properties
> of the origin, not any specific endpoint or transport.
>
> ...
>
>> If it does, and finds that the server doesn't support the protocol that
>> it wants, then the request will fail, and the client wasted its time.
>>
>
> Sure.  That's just like a 404, and the solution is the same: don't tell
> your users to send requests that your origin doesn't support.
>

Again I don't know how you can make these two things align. There's a
difference between "my origin supports retrieving a resource using HTTP"
and a client and server actually selecting the HTTP version to use for
that. This is even more true when intermediaries are in the mix, because
the page that includes a URL could be very far removed from the (multi) CDN
that is responsible for the details of the connection that is formed
between it and a client. We purposefully avoided encoding the HTTP version
in the scheme, but it kind of all works ok due to Alt-Svc.

With WebSocket, the origin could support only WebSocket via HTTP/1.1
upgrade. An intermediary could support WebSocket over some of HTTP/1.1,
HTTP/2 or HTTP/3; converting to what the origin uses on the backend. It's
very hard for an origin to react to permutations of these setups,
especially across different providers. Just hoping everyone enables all
forms of support doesn't seem realistic to me.

Tangent:

How to respond to a client when SETTINGS_ENABLE_CONNECT_PROTOCOL is enabled
but a value of ":protocol" is not supported is IMO actually pretty poorly
defined in RFC 8441. And draft-ietf-masque-connect-udp doesn't really say
much either. If a server sends 404, it could imply the web socket resource
doesn't exist at all. That's not true, it exists but can only be accessed
using a specific HTTP version.

Cheers
Lucas