From 3ad5d31bdf66c3a9449bb4af4cb131ff8e2ca662 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Tue, 29 Jan 2019 18:33:26 +0100 Subject: [PATCH] BUG/MEDIUM: mux-h2: only close connection on request frames on closed streams A subtle bug was introduced with H2 on the backend. RFC7540 states that an attempt to create a stream on an ID not higher than the max known is a connection error. This was translated into rejecting HEADERS frames for closed streams. But with H2 on the backend, if the client aborts and causes an RST_STREAM to be emitted, the stream is effectively closed, and if/once the server responds, it starts by emitting a HEADERS frame with this ID thus it is interpreted as a connection error. This test must of course consider the side the mux is installed on and not take this for a connection error on responses. The effect is that an aborted stream on an outgoing H2 connection, for example due to a client stopping a transfer with option abortonclose set, would lead to an abort of all other streams. In the logs, this appears as one or several CD-- line(s) followed by one or several SD-- lines which are victims. Thanks to Luke Seelenbinder for reporting this problem and providing enough elements to help understanding how to reproduce it. This fix must be backported to 1.9. --- src/mux_h2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mux_h2.c b/src/mux_h2.c index 90895e288..f74ae3288 100644 --- a/src/mux_h2.c +++ b/src/mux_h2.c @@ -2344,7 +2344,7 @@ static void h2_process_demux(struct h2c *h2c) * Some frames have to be silently ignored as well. */ if (h2s->st == H2_SS_CLOSED && h2c->dsi) { - if (h2_ft_bit(h2c->dft) & H2_FT_HDR_MASK) { + if (!(h2c->flags & H2_CF_IS_BACK) && h2_ft_bit(h2c->dft) & H2_FT_HDR_MASK) { /* #5.1.1: The identifier of a newly * established stream MUST be numerically * greater than all streams that the initiating