Re: Advertising WebSocket support in the HTTPS resource record

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

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.