Re: SETTINGS_ENABLE_CONNECT_PROTOCOL and new protocols

On Wed, Nov 03, 2021 at 10:21:49AM +0100, Stefan Eissing wrote:
> >> Am 03.11.2021 um 07:35 schrieb Willy Tarreau <w@1wt.eu>:
> >> 
> >> 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.
> > 
> > +1
> > 
> > I'd prefer a response instead of RST. 501 seems good.

I prefer a response as well since it can be forwarded end-to-end,
and in this case it may even convey a header announcing a possible
list of supported protocols, alternate URL to use or whatever we'll
think about when needed.

> Thinking about this some more, the H1 WebSocket's idea to
> verify the protocol negotiation via its Web-Sec-Key was
> a good idea. The client should be able to identify a
> successful negotiation of the end-to-end protocol
> established.

Sure but that's limited to websocket, and by then it was designed this
way to be absolutely certain that we were talking to a truly websocket-
aware server (since at this time nobody implemented the upgrade and the
fears of dealing with random responses were rightfully high). Over H2
there isn't this problem.

Willy

Received on Wednesday, 3 November 2021 10:14:27 UTC