Re: Advertising WebSocket support in the HTTPS resource record

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.


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