BUG/MINOR: stream: unblock stream on wait-for-handshake completion

wait-for-handshake is an http-request action which permits to delay the
processing of content received as TLS early data. The action yields
as long as connection handshake is in progress. In the meantime, stconn
is flagged with SE_FL_WAIT_FOR_HS.

When the handshake is finished, MUX layer is responsible to woken up
SE_FL_WAIT_FOR_HS flagged stconn instances to restart the stream
processing. On sc_conn_process(), SE_FL_WAIT_FOR_HS flag is removed and
stream layer is woken up.

However, there may be a blocking after MUX notification. sc_conn_recv()
may return 0 due to no new data reception, which prevents
sc_conn_process() execution. The stream is thus blocked until its
timeout.

To fix this, checks in sc_conn_recv() about the handshake termination
condition. If true, explicitely returns 1 to ensure sc_conn_process()
will be executed.

Note that this bug is not reproducible due to various conditions related
to early data implementation in haproxy. Indeed, connection layer
instantiation is always delayed until SSL handshake completion, which
prevents the handling of early data as expected.

This fix will be necessary to implement wait-for-handshake support for
QUIC. As such, it must be backported with the next commit up to 2.6,
after a mandatory period of observation.

diff --git a/src/stconn.c b/src/stconn.c
index 3fa9dc827c18945936dea473f49384955aa40eaf..bf9f7b0aa51e1a0dd697beabe216c3cbf244035d 100644 (file)
--- a/src/stconn.c
+++ b/src/stconn.c
@@ -1525,6 +1525,12 @@ int sc_conn_recv(struct stconn *sc)
                ret = 1;
        }
 
+       /* Ensure sc_conn_process() is called if waiting on handshake. */
+       if (!(conn->flags & (CO_FL_WAIT_XPRT | CO_FL_EARLY_SSL_HS)) &&
+           sc_ep_test(sc, SE_FL_WAIT_FOR_HS)) {
+               ret = 1;
+       }
+
        if (sc->flags & (SC_FL_EOS|SC_FL_ERROR)) {
                /* No more data are expected at this stage */
                se_have_no_more_data(sc->sedesc);