W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021

Re: Advertising WebSocket support in the HTTPS resource record

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 20 Oct 2021 21:21:25 +0100
Message-ID: <CALGR9obt_4ZrOmFFjyZAmJYTB2g99YJ-V1mEScB7wA=-vS_EUQ@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: Dragana Damjanovic <dragana.damjano@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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).
Received on Wednesday, 20 October 2021 20:21:49 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:06 UTC