Re: Advertising WebSocket support in the HTTPS resource record

On Wed, Oct 20, 2021 at 3: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.
>

Yes.  That's why you MUST NOT tell a user to use a :protocol or path unless
it is reachable on all the server endpoints for your origin, including all
relevant supported HTTP versions.


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

Yes.  We've walked ourselves into an ugly corner here by allowing some
aspects of the origin to differ between versions.


> Just hoping everyone enables all forms of support doesn't seem realistic
> to me.
>

With extended-connect, we've created a problem, as Dragana highlighted.  I
think allowing the supported :protocol set to vary arbitrarily between HTTP
versions, with some hint mechanism to tell you what's supported where,
would make this worse, not better.

My preferred solution would be to say:
 * ALPS can be used to get the SETTINGS sooner.
 * Clients that need extended-connect (e.g. WebSockets, likely MASQUE)
should fall back to HTTP/1.1 if the server doesn't support
extended-connect.  If performance is crucial, clients may start HTTP/1.1 in
parallel with HTTP/2+, but must not use it until after receiving the
SETTINGS frame.
 * Servers should enable extended-connect on all HTTP/2+ versions or none
 * Any :protocol advertised to clients must be supported on all
extended-connect endpoints (except if it is deemed incompatible with some
HTTP version).
 * If the IETF deems a :protocol value incompatible with a specific HTTP
version, this cannot later be reversed.
 * Clients must not fall back to a lower HTTP version if CONNECT returns an
error code.