- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 4 Nov 2021 06:47:04 +0100
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: David Schinazi <dschinazi.ietf@gmail.com>, Martin Thomson <mt@lowentropy.net>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Lucas, On Wed, Nov 03, 2021 at 05:17:41PM +0000, Lucas Pardue wrote: > Dare I say that it sounds like we are reinventing RFC 2774[1]? > > Section 7 defines the 510 Not Extended status code: > > The policy for accessing the resource has not been met in the > request. The server should send back all the information necessary > for the client to issue an extended request. It is outside the scope > of this specification to specify how the extensions inform the > client. > > If the 510 response contains information about extensions that were > not present in the initial request then the client MAY repeat the > request if it has reason to believe it can fulfill the extension > policy by modifying the request according to the information provided > in the 510 response. Otherwise the client MAY present any entity > included in the 510 response to the user, since that entity may > include relevant diagnostic information. > > > [1] - https://datatracker.ietf.org/doc/html/rfc2774 I could be nit-picking here but I don't see a failure to connect using a specific protocol as a failure to reach an extension. We do use the extended CONNECT because it was already advertised as available, it's only the application-level protocol that's not available. Hence I tend to think that 501 is very close (no protocol stack is implemented for the requested protocol name). However I would see 510 as perfectly suited for an extended CONNECT sent over a connection that did not advertise support for it in the first place (except that here it's done using H2 after negotiating a setting). Willy
Received on Thursday, 4 November 2021 05:47:23 UTC