Re: Advertising WebSocket support in the HTTPS resource record

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

>
>
> On Wed, Oct 20, 2021 at 9:34 PM Ben Schwartz <bemasc@google.com> wrote:
>
>>
>>
>> On Wed, Oct 20, 2021 at 4:21 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Oct 20, 2021 at 9:05 PM Ben Schwartz <bemasc@google.com> wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> I'm not tied to any particular solution here, it seems we are agreeing
>>> on the problems though, which is good.
>>>
>>>
>>>> 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.
>>>>
>>>
>>> I can think of good reasons for a server to support only "websocket" and
>>> not "connect-udp", or vice versa.
>>>
>>
>> I can think of good reasons for an "origin" to support only one
>> :protocol.  I don't think we should allow a single origin to support
>> "websocket" on H2 but not H3, and "connect-udp" on H3 but not H2.  That's
>> the case I'm trying to rule out, because it would greatly complicate the
>> required client behavior.
>>
>
> That's the exact case I'm thinking about. There might be little value
> trying to backport connect-udp to H2 for some kinds of services, it might
> be better to fallback to plain old CONNECT. Meanwhile, someone might have
> websocket support left as a TODO for HTTP/3. Requiring feature parity
> across all versions just increases the bar to experimentation or deploying
> new versions of things.
>
>>
>>
>>> For intermediaries, what the origin is telling the client can be
>>> completely outside their control.
>>>
>>
>> That's fine.  You serve a 4XX.  Whoever told clients to use
>> wss://origin-that-doesn't-always-support-websockets is at fault.
>>
>
>
I think as well that this is too much. Thee should be graceful way to deal
with this. If we have one settings for all feature that use the extended
CONNECT, there should be a way for a server to gently say that it does not
support that particular protocol. Leaving everything to a good
configuration of a whole system with a lot of moving parts is not good.

dragana


> But there's not satisfactory means to correct that fault. Take for example
> a website today that provides index.html including a wss:// link, clients
> are already able to handle loading the document over H2 and opening the
> WebSocket via HTTP/1.1. If the response contains and Alt-Svc for h3, then
> the document can be loaded over H3 and the WebSocket via HTTP/1.1. Now, the
> server starts enabling H3 extended connect for some other ":protocol" that
> is part of an unrelated experiment. A client then attempts to use an H3
> connection for websocket and receives a 4xx; following your suggestion, the
> client can never open the websocket. The only recourse is to disable
> HTTP/3, which is worse than the situation we started with.
>
> It would be nice to avoid complexity. But the proposal seems to me like an
> all or nothing bet, which doesn't seem too accommodating to the HTTP server
> ecosystem.
>
>
>