mirrors/haproxy
1
0
Fork 0
mirror of https://git.haproxy.org/git/haproxy.git/ synced 2025-09-24 15:21:29 +02:00
Code Issues Projects Releases Wiki Activity

[MINOR] http: partially revert the chunking optimization for now

Browse Source 
Commit 57f5c1 used to provide a nice improvement on chunked encoding since
it ensured that we did not set a PUSH flag for every chunk or buffer data
part of a chunked transfer.

Some applications appear to erroneously abuse HTTP chunking in order to
get interactive exchanges between a user agent and an origin server with
very small chunks. While it happens to work through haproxy, it's terribly
slow due to the latency added after passing each chunk to the system, who
could wait up to 200ms before pushing them onto the wire.

So we need an interactive mode for such usages. In the mean time, step back
on the optim, but not completely, so that we still keep the flag as long as
we know we're not finished with the current chunk.

This change should be backported to 1.4 too as the issue was discovered
with it.
This commit is contained in:
Willy Tarreau 2011-05-11 19:56:11 +02:00
parent ae94d4df8f
commit 5c62092ca1
1 changed files with 22 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
src/proto_http.c
View File

@ -4445,9 +4445,6 @@ int http_request_forward_body(struct session *s, struct buffer *req, int an_bit)
goto return_bad_req;
}
/* otherwise we're in HTTP_MSG_DATA or HTTP_MSG_TRAILERS state */
/* Don't set a PUSH at the end of that chunk if it's not the last one */
if (msg->msg_state == HTTP_MSG_DATA)
req->flags |= BF_EXPECT_MORE;
}
else if (msg->msg_state == HTTP_MSG_DATA_CRLF) {
/* we want the CRLF after the data */
@ -4561,6 +4558,17 @@ int http_request_forward_body(struct session *s, struct buffer *req, int an_bit)
if (txn->flags & TX_REQ_TE_CHNK)
buffer_dont_close(req);
/* We know that more data are expected, but we couldn't send more that
* what we did. In theory we could always set the BF_EXPECT_MORE so that
* the system knows it must not set a PUSH on this first part. However
* there exists some applications which incorrectly rely on chunks being
* interactively exchanged. So we set the flag only if the current chunk
* is not finished, or we're not DONE and interactive mode is not set.
*/
if (txn->req.msg_state >= HTTP_MSG_DATA &&
txn->req.msg_state <= HTTP_MSG_TRAILERS)
req->flags |= BF_EXPECT_MORE;
http_silent_debug(__LINE__, s);
return 0;
@ -5491,9 +5499,6 @@ int http_response_forward_body(struct session *s, struct buffer *res, int an_bit
goto return_bad_res;
}
/* otherwise we're in HTTP_MSG_DATA or HTTP_MSG_TRAILERS state */
/* Don't set a PUSH at the end of that chunk if it's not the last one */
if (msg->msg_state == HTTP_MSG_DATA)
res->flags |= BF_EXPECT_MORE;
}
else if (msg->msg_state == HTTP_MSG_DATA_CRLF) {
/* we want the CRLF after the data */
@ -5594,6 +5599,17 @@ int http_response_forward_body(struct session *s, struct buffer *res, int an_bit
(txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL)
buffer_dont_close(res);
/* We know that more data are expected, but we couldn't send more that
* what we did. In theory we could always set the BF_EXPECT_MORE so that
* the system knows it must not set a PUSH on this first part. However
* there exists some applications which incorrectly rely on chunks being
* interactively exchanged. So we set the flag only if the current chunk
* is not finished, or we're not DONE and interactive mode is not set.
*/
if (txn->rsp.msg_state >= HTTP_MSG_DATA &&
txn->rsp.msg_state <= HTTP_MSG_TRAILERS)
res->flags |= BF_EXPECT_MORE;
/* the session handler will take care of timeouts and errors */
http_silent_debug(__LINE__, s);
return 0;