- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 23 Aug 2023 07:54:13 +0200
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Cory Benfield <cory@lukasa.co.uk>, Ryan Hamilton <rch@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Aug 17, 2023 at 03:29:45PM +0100, Lucas Pardue wrote: > On Thu, 17 Aug 2023, 15:16 Cory Benfield, <cory@lukasa.co.uk> wrote: > > > It's a good catch that RFC 9113 doesn't explicitly call out what you > > should do here. > > > > The response code should not be propagated to the next hop: as RFC > > 9113 says, you are not permitted to send a 101 in HTTP/2. This is a > > stream error of type PROTOCOL_ERROR. > > > If I'm a client talking to an intermediary and my request (that is valid > and would never cause a 101) gets reset like that, I'm going to get > confused because I didn't break the protocol. > > So the intermediary in its client role might want to reset the stream with > PROTOCOL_ERRROR but in its server role would probably be better emitting a > 502 Bad Gateway, or closing stream with INTERNAL_ERROR. FWIW that's exactly what we're doing in haproxy, the response is rejected on PROTOCOL_ERROR and the client will get a 502 just as if the server would have returned unparsable headers for example. Willy
Received on Wednesday, 23 August 2023 05:54:25 UTC