From: Willy Tarreau Date: Mon, 30 May 2011 16:29:28 +0000 (+0200) Subject: [OPTIM] http: optimize chunking again in non-interactive mode X-Git-Tag: v1.5-dev8~228 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=0729303fb0a4d43df35f0bf00619154a93345788;p=thirdparty%2Fhaproxy.git [OPTIM] http: optimize chunking again in non-interactive mode 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. --- diff --git a/src/proto_http.c b/src/proto_http.c index 391d630102..1fc7c94b92 100644 --- a/src/proto_http.c +++ b/src/proto_http.c @@ -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);