- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Wed, 3 Nov 2021 10:21:49 +0100
- To: Willy Tarreau <w@1wt.eu>
- Cc: Martin Thomson <mt@lowentropy.net>, David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
> 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