mirrors/haproxy
1
0
Fork 0
mirror of https://git.haproxy.org/git/haproxy.git/ synced 2026-05-04 20:46:11 +02:00
Code Issues Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Willy Tarreau 2014-04-17 21:50:00 +02:00
parent 1234f4a210
commit 7ba235466d
1 changed files with 15 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
src/proto_http.c
View File

@ -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);