Re: Advertising WebSocket support in the HTTPS resource record

On Wed, Oct 20, 2021 at 9:03 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

>
> 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.
>
>
I agree with this point. I think my messages was sent at the almost same
time as this.

I have open an issue at w3c about adding hint when opening WebSockets as
well, but I am not sure that would salve all the problems:
https://github.com/whatwg/html/issues/7243


> 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.
>
>
This is a very good point I think we need more specific
SETTINGS_ENABLE_CONNECT_PROTOCOL or a new response code somewhat similar to
421 (but it is not the same).

 dragana

Cheers
> Lucas
>