BUG/MEDIUM: mux-h1: Subscribe rather than waking up in h1_rcv_buf()
authorChristopher Faulet <cfaulet@haproxy.com>
Fri, 3 Jul 2020 13:38:11 +0000 (15:38 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Tue, 7 Jul 2020 12:44:03 +0000 (14:44 +0200)
commita1dde23e936adb66f6eaba33fc5bf93278b8efbd
tree88bb3500a597ceec0e99c4e3a9c6b57d45131afe
parent89cc83287a6c9536fa14243397ed1038192eb8de
BUG/MEDIUM: mux-h1: Subscribe rather than waking up in h1_rcv_buf()

At the end of h1_rcv_buf(), if the message was not fully processed (not in
HTTP_MSG_DONE state), it means some data are missing. But instead of waking up
the H1 connection, it is safer to subscribe for reads. Especially if the
splicing is enabled (or if we are waiting the input buffer is flushed). Because
in that case, waking up the H1 connection leads to a ping-pong loop with
h1_recv() function. Indeed, in h1_recv(), if the splicing is enabled, no receive
is performed and the H1 stream is woken up.

This bug is specific to the 2.1. Thus, there is no upstream commit ID for this
patch. But in the 2.2, it is part of the commit 2c1f37d35 ("OPTIM: mux-h1:
subscribe rather than waking up at a few other places"). The 2.0 must be
evaluated to know if this patch must be backported or not.
src/mux_h1.c