BUG/MEDIUM: http: don't start to forward request data before the connect
Currently, "balance url_param check_post" randomly works. If the client
sends chunked data and there's another chunk after the one containing the
data, http_request_forward_body() will advance msg->sov and move the start
of data to the beginning of the last chunk, and get_server_ph_post() will
not find the data.
In order to avoid this, we add an HTTP_MSGF_WAIT_CONN flag whose goal is
to prevent the forwarding code from parsing until the connection is
confirmed, so that we're certain not to fail on a redispatch. Note that
we need to force channel_auto_connect() since the output buffer is empty
and a previous analyser might have stopped auto-connect.
The flag is currently set whenever some L7 POST analysis is needed for a
connect() so that it correctly addresses all corner cases involving a
possible rewind of the buffer, waiting for a better fix.
Note that this has been broken for a very long time. Even all 1.4 versions
seem broken but differently, with ->sov pointing to the end of the arguments.
So the fix should be considered for backporting to all stable releases,
possibly including 1.3 which works differently.
diff --git a/src/proxy.c b/src/proxy.c
index 5458f1b..ef0f63d 100644
--- a/src/proxy.c
+++ b/src/proxy.c
@@ -863,6 +863,15 @@
hdr_idx_init(&s->txn.hdr_idx);
}
+ /* If an LB algorithm needs to access some pre-parsed body contents,
+ * we must not start to forward anything until the connection is
+ * confirmed otherwise we'll lose the pointer to these data and
+ * prevent the hash from being doable again after a redispatch.
+ */
+ if (be->mode == PR_MODE_HTTP &&
+ (be->lbprm.algo & (BE_LB_KIND | BE_LB_PARM)) == (BE_LB_KIND_HI | BE_LB_HASH_PRM))
+ s->txn.req.flags |= HTTP_MSGF_WAIT_CONN;
+
if (be->options2 & PR_O2_NODELAY) {
s->req->flags |= CF_NEVER_WAIT;
s->rep->flags |= CF_NEVER_WAIT;