mirrors/haproxy
1
0
Fork 0
mirror of https://git.haproxy.org/git/haproxy.git/ synced 2026-02-27 04:01:45 +01:00
Code Issues Projects Releases Wiki Activity

[OPTIM] http: optimize chunking again in non-interactive mode

Browse Source 
Now that we support the http-no-delay mode, we can optimize HTTP
chunking again by always waiting for more data to come until the
last chunk is met.

This patch may or may not be backported to 1.4, it's not a big deal,
it will mainly help for chunks which are aligned with the buffer size.
This commit is contained in:
Willy Tarreau 2011-05-30 18:29:28 +02:00
parent 96e312139a
commit 0729303fb0
1 changed files with 8 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
src/proto_http.c
View File

@ -4564,15 +4564,11 @@ int http_request_forward_body(struct session *s, struct buffer *req, int an_bit)
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.
* what we did. So we always set the BF_EXPECT_MORE flag so that the
* system knows it must not set a PUSH on this first part. Interactive
* modes are already handled by the stream sock layer.
*/
if (txn->req.msg_state >= HTTP_MSG_DATA &&
txn->req.msg_state <= HTTP_MSG_TRAILERS)
req->flags |= BF_EXPECT_MORE;
req->flags |= BF_EXPECT_MORE;
http_silent_debug(__LINE__, s);
return 0;
@ -5605,15 +5601,11 @@ int http_response_forward_body(struct session *s, struct buffer *res, int an_bit
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.
* what we did. So we always set the BF_EXPECT_MORE flag so that the
* system knows it must not set a PUSH on this first part. Interactive
* modes are already handled by the stream sock layer.
*/
if (txn->rsp.msg_state >= HTTP_MSG_DATA &&
txn->rsp.msg_state <= HTTP_MSG_TRAILERS)
res->flags |= BF_EXPECT_MORE;
res->flags |= BF_EXPECT_MORE;
/* the session handler will take care of timeouts and errors */
http_silent_debug(__LINE__, s);