Re: SETTINGS_ENABLE_CONNECT_PROTOCOL and new protocols

> 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.

> 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.

Error causes and/or available protocols as response headers. If more than
one protocol is allowed in negotiation, return in a 200 the protocol 
switched to (header or content type?).

Imagine there being a version 1 and 2 of WebTransfer one day.

Kind Regards,
Stefan

Received on Wednesday, 3 November 2021 09:01:20 UTC