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 6cc9c9fbe9c902999b2455b14eef813d5b059052..18db42f74851c595188ccbfcc6359da8847c0cda 100644 (file)
--- 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.