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

Re: SETTINGS_ENABLE_CONNECT_PROTOCOL and new protocols

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 2 Nov 2021 13:56:17 +0100
Cc: Martin Thomson <mt@lowentropy.net>, ietf-http-wg@w3.org
Message-Id: <773B97C2-FB49-46DA-8A8F-77BA79CDE8C7@greenbytes.de>
To: Willy Tarreau <w@1wt.eu>
Caveat: I have not written a Websocket h2 implementation and just
read up a bit about WebTransport. So many grains of salt here...

> Am 02.11.2021 um 08:35 schrieb Willy Tarreau <w@1wt.eu>:
> 
> Hi Martin,
> 
> On Tue, Nov 02, 2021 at 05:41:33PM +1100, Martin Thomson wrote:
>> SETTINGS_ENABLE_CONNECT_PROTOCOL is defined as enabling the :protocol
>> pseudo-header field on CONNECT.  The implication being that any protocol is
>> OK once this setting is negotiated.
>> 
>> In reviewing WebTransport proposals, I realized that this is probably a
>> mistake.  There, Victor (I think) realized that you need to negotiate the use
>> of :protocol AND the use of the specific protocol.  Otherwise, you might
>> attempt to use extended CONNECT when the server does not support some of the
>> extra fancy stuff that is in WebTransport.
>> 
>> That leads me to ask:
>> 
>> Should this setting be defined as **extended CONNECT for WebSockets** rather
>> than extended CONNECT more generally?
>> [...]
> 
> I suspect that we'd need something that more resembles a negotiation.
> But settings can be sent at once in both directions. But we could state
> that servers supporting some protocol extensions ought to wait for the
> client's settings frame before advertising their support for a requested
> application-layer protocol. Or we could have another setting back to
> indicate which one was chosen. The only thing is that we only have 32 bits
> to encode plenty of protocols and this would require some registration.
> 
> Or maybe we could have a sequence like this one, where when a client
> advertises support for such an extended CONNECT, a new frame of type
> ALPN advertises the list of protocols supported over CONNECT:
> 
>   client  --------> SETTINGS_ENABLE_APPLICATION_PROTOCOL -------->
>           <----- "ALPN" frame indicating supported protocols <---- server
> 
> But even with that I wouldn't be surprised that some want to advertise
> support for nothing in return (empty string maybe) and others would
> advertise support for everything (plain transparent tunnels).

I think it's beneficial to differentiate between a HTTP capability, like
Extended CONNECT, and something like "supported protocols". Because if
a specific protocol is supported or not depends on where the CONNECT
is really going to. E.g. one has to do it in order to learn if a 
protocol is supported or not.

SETTINGS_ENABLE_CONNECT_PROTOCOL says: "I, the server know about
H2 CONNECT and :protocol and my responses will be in accordance to
its definition." It does NOT say: "I support websockets".

hop-by-hop vs. end-to-end.

As Willy noted about HAProxy, some backend connections will support
it, some won't. The client needs to really say where it wants to go,
e.g. open the stream to find out. But without the CONNECT capability,
there is no use in trying.

Now, if WebTransport requires some additional capabilities, *on
the server it talks to* those seem to be what SETTINGS are for.

On scanning <https://www.ietf.org/archive/id/draft-ietf-webtrans-http2-02.html>
I was so far not able to detect those. All WT_ frames seems to happen
inside the H2 STREAM's DATA, but maybe I got that wrong.

Kind Regards,
Stefan
Received on Tuesday, 2 November 2021 12:56:42 UTC

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