From: Willy Tarreau <w@1wt.eu>
Date: Sun, 13 May 2012 06:44:16 +0000 (+0200)
Subject: OPTIM: proto_http: don't enable quick-ack on empty buffers
X-Git-Tag: v1.5-dev10~3
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=93548be1498ee6de88f3bc696f82bf5297a79b53;p=thirdparty%2Fhaproxy.git

OPTIM: proto_http: don't enable quick-ack on empty buffers

Commit 5e205524 was a bit overzealous by inconditionally enabling
quick ack when a request is not yet in the buffer, because it also
does so when nothing has been received yet, causing a useless ACK
to be emitted.

Improve the situation by doing this only if the input buffer is
empty (indicating that nothing was sent by the client).

In case of keep-alive, an empty buffer means we already have a
response in flight which will serve as an ACK.
---

diff --git a/src/proto_http.c b/src/proto_http.c
index 6cc9c9fbe9..18db42f748 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -2213,7 +2213,7 @@ int http_wait_for_request(struct session *s, struct buffer *req, int an_bit)
 		req->flags |= BF_READ_DONTWAIT; /* try to get back here ASAP */
 		s->rep->flags &= ~BF_EXPECT_MORE; /* speed up sending a previous response */
 #ifdef TCP_QUICKACK
-		if (s->listener->options & LI_O_NOQUICKACK) {
+		if (s->listener->options & LI_O_NOQUICKACK && req->i) {
 			/* We need more data, we have to re-enable quick-ack in case we
 			 * previously disabled it, otherwise we might cause the client
 			 * to delay next data.