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: Wed, 3 Nov 2021 10:00:59 +0100
Cc: Martin Thomson <mt@lowentropy.net>, David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <468ACDA6-A097-4808-AEDC-67C514B0EDBC@greenbytes.de>
To: Willy Tarreau <w@1wt.eu>

> 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

This archive was generated by hypermail 2.4.0 : Wednesday, 3 November 2021 09:01:22 UTC