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

Re: SETTINGS_ENABLE_CONNECT_PROTOCOL and new protocols

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 3 Nov 2021 07:35:23 +0100
To: Martin Thomson <mt@lowentropy.net>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20211103063523.GA11459@1wt.eu>
On Wed, Nov 03, 2021 at 02:38:33PM +1100, Martin Thomson wrote:
> On Wed, Nov 3, 2021, at 12:03, David Schinazi wrote:
> > I'm not sure it's really possible to solve the "as a client I want to 
> > know all the feature set of this server" because the first intermediary 
> > might know what all its backends support.
> 
> That's a nice philosophy.  That seems like the cleanest outcome.

I agree with this as well, and that's also why I retract my very first
proposal of seeing the server advertise what protocol it supports.

>  However, it doesn't give me an answer to the dilemma from before:
> 
> > That means that there are cases where the connection supports the ability
> > to negotiate :protocols in general, the resource supports this specific
> > :protocol, and the combination of the two doesn't.
> 
> I'm aware of cases where this happens already and we jump through all sorts
> of hoops as a result.  Are you suggesting that we just live with this
> situation because it is unavoidable?

If we consider that :protocol is hop-by-hop and that 200 is end-to-end,
then I think we should be able to address most if not all use cases. By
this I mean that each intermediary in the chain is responsible for
negotiating a tunnel (or any other form) with its next hop for the
requested protocol, and only ought to respond after being certain that
it was properly set up, and that in case of failure the first element
in the chain aware of the trouble and able to fall back on other methods
(e.g. HTTP/1 for WebSocket) ought to try this before responding.

It's not the easiest to implement (and at least requires to hold the
data before the 200) but I don't think we can do much more without
knowing upfront if some backend servers will support the protocol or
not.
A CDN front node could very well advertise support for extended CONNECT
and deal with it by itself depending on what the origin servers support.

I think the main issue in RFC8441 is that it doesn't speak about failures
to set up the tunnel, only the successful case is documented, because it
immediately remaps to RFC6455 as it was initially intended to deal with
WebSocket only, and uses WebSocket's header-based signaling. We'd need
to indicate what to return when :protocol is not supported (status code
such as 501?  RST with a new error code?). This is what a client or
intermediary needs to know if it ought to retry, fall back, or fail.

But I do think that having the ability to support multiple protocols,
and letting the server choose, or signal in response which alternatives
it suggests could be useful for the long term.

Willy
Received on Wednesday, 3 November 2021 06:35:44 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:44 UTC