Re: Advertising WebSocket support in the HTTPS resource record

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. Either because their library was written
before capsules existed or because they outright disable some form of
protocol they don't want a particular server to satisfy. For
intermediaries, what the origin is telling the client can be completely
outside their control. Even ignoring intermediaries, there's often a gulf
between webdevs and the server infra folk. Unless there is a scheme like
"wss-h1://", "wss-h2://" etc. then I can't see a way to link these two up
robustly (FWIW I think putting versions in schemes is bad).