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.

diff --git a/src/mux_h2.c b/src/mux_h2.c
index 90895e288cec604d78f662251a7c2cdef3cd56b9..f74ae3288864b63a310fd3e9df291a9dba65cd9b 100644 (file)
--- 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