]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: mux-h2: only close connection on request frames on closed streams
authorWilly Tarreau <w@1wt.eu>
Tue, 29 Jan 2019 17:33:26 +0000 (18:33 +0100)
committerWilly Tarreau <w@1wt.eu>
Tue, 29 Jan 2019 17:49:27 +0000 (18:49 +0100)
commit3ad5d31bdf66c3a9449bb4af4cb131ff8e2ca662
treec506c204ca9b82528a891b4ed846821d1a4802ea
parent6254a9257e296f8439c92f43430fe8805f4cd8f2
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