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:21:49 +0100
Cc: Martin Thomson <mt@lowentropy.net>, David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <F6705DB9-2BDC-400A-83DF-D0A125FDEE33@greenbytes.de>
To: Willy Tarreau <w@1wt.eu>


> Am 03.11.2021 um 10:00 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>:
> 
> 
>> 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.

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.

- Stefan
Received on Wednesday, 3 November 2021 09:22:07 UTC

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