MEDIUM: http: forward headers again while waiting for connection to complete

Thanks to the last updates on the message pointers, it is now safe again to
enable forwarding of the request headers while waiting for the connection to
complete because we know how to safely rewind this part.

So this patch slightly modifies what was done in commit 80a92c0 ("BUG/MEDIUM:
http: don't start to forward request data before the connect") to let up to
msg->sov bytes be forwarded when waiting for the connection. The resulting
effect is that a POST request may now be sent with the connect's ACK, which
still saves a packet and may even be useful later when TFO is supported.

diff --git a/src/proto_http.c b/src/proto_http.c
index 328f28b51bc8216f2c0a3ff0424c08ea1648b8df..8c54433927b4fcdd0445f2f722d6de0599b1e79c 100644 (file)
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -5021,18 +5021,6 @@ int http_request_forward_body(struct session *s, struct channel *req, int an_bit
                return 1;
        }
 
-       /* Some post-connect processing might want us to refrain from starting to
-        * forward data. Currently, the only reason for this is "balance url_param"
-        * whichs need to parse/process the request after we've enabled forwarding.
-        */
-       if (unlikely(msg->flags & HTTP_MSGF_WAIT_CONN)) {
-               if (!(s->rep->flags & CF_READ_ATTACHED)) {
-                       channel_auto_connect(req);
-                       goto missing_data;
-               }
-               msg->flags &= ~HTTP_MSGF_WAIT_CONN;
-       }
-
        /* Note that we don't have to send 100-continue back because we don't
         * need the data to complete our job, and it's up to the server to
         * decide whether to return 100, 417 or anything else in return of
@@ -5045,7 +5033,9 @@ int http_request_forward_body(struct session *s, struct channel *req, int an_bit
                 * must save the body in msg->next because it survives buffer
                 * re-alignments.
                 */
-               msg->next = msg->sov;
+               channel_forward(req, msg->sov);
+               msg->next = 0;
+               msg->sov  = 0;
 
                if (msg->flags & HTTP_MSGF_TE_CHNK)
                        msg->msg_state = HTTP_MSG_CHUNK_SIZE;
@@ -5053,6 +5043,18 @@ int http_request_forward_body(struct session *s, struct channel *req, int an_bit
                        msg->msg_state = HTTP_MSG_DATA;
        }
 
+       /* Some post-connect processing might want us to refrain from starting to
+        * forward data. Currently, the only reason for this is "balance url_param"
+        * whichs need to parse/process the request after we've enabled forwarding.
+        */
+       if (unlikely(msg->flags & HTTP_MSGF_WAIT_CONN)) {
+               if (!(s->rep->flags & CF_READ_ATTACHED)) {
+                       channel_auto_connect(req);
+                       goto missing_data;
+               }
+               msg->flags &= ~HTTP_MSGF_WAIT_CONN;
+       }
+
        /* in most states, we should abort in case of early close */
        channel_auto_close(req);