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.

diff --git a/src/mux_h1.c b/src/mux_h1.c
index 963f51e..401bf09 100644 (file)
--- a/src/mux_h1.c
+++ b/src/mux_h1.c
@@ -2644,7 +2644,7 @@ static size_t h1_rcv_buf(struct conn_stream *cs, struct buffer *buf, size_t coun
                        TRACE_STATE("disable splicing", H1_EV_STRM_RECV, h1c->conn, h1s);
                }
                if (h1m->state != H1_MSG_DONE && !(h1c->wait_event.events & SUB_RETRY_RECV))
-                       tasklet_wakeup(h1c->wait_event.tasklet);
+                       h1c->conn->xprt->subscribe(h1c->conn, h1c->conn->xprt_ctx, SUB_RETRY_RECV, &h1c->wait_event);
        }
        TRACE_LEAVE(H1_EV_STRM_RECV, h1c->conn, h1s,, (size_t[]){ret});
        return ret;