Client keep alive support under HTTP/1.0

Server NGINX
1

Hi,

We’re working on a server-to-server integration effort, using nginx as
our front end. The guys on the other side are using ab (ApacheBench) to
perform initial testing. ApacheBench includes a switch to turn on
keepalive request support, but it only sends HTTP/1.0 requests.

Our research on keepalives using HTTP/1.0 is inconclusive. Some
resources (HTTP persistent connection - Wikipedia)
state that it is loosely supported, while other sources don’t make that
claim.

Question: Is it possible to enable support for keep-alive connections
using HTTP/1.0?

If it matters, gzip is disabled in our config (we were hoping that it
would result in the content-length header being set).

Cheers,

Dean

Posted at Nginx Forum:

2

On Saturday 03 March 2012 02:04:00 dbanks wrote:

Hi,

We’re working on a server-to-server integration effort, using nginx as
our front end. The guys on the other side are using ab (ApacheBench) to
perform initial testing. ApacheBench includes a switch to turn on
keepalive request support, but it only sends HTTP/1.0 requests.

I don’t recommend to use it. “ab” is slow and buggy.

Our research on keepalives using HTTP/1.0 is inconclusive. Some
resources (HTTP persistent connection - Wikipedia)
state that it is loosely supported, while other sources don’t make that
claim.

Question: Is it possible to enable support for keep-alive connections
using HTTP/1.0?

NGINX supports it by default. If you need to disable it,
then set: keepalive_timeout 0;

wbr, Valentin V. Bartenev

3

Hi Valentin,

Thanks for your response. We’ve asked the other company if they might
try something other than ab for their testing, but so far they seem to
want to keep using it. As a result, we’re stuck with supporting it.

From the testing that the other company has done, and from the testing
that we’ve done to try to repeat their results, it does not appear that
nginx is supporting keepalives on HTTP/1.0 requests. We see the request
header go out with keepalives requested, but the response header
contains Connection: Close.

If nginx supports this by default, it implies that we have an
incompatible config option. keepalive_timeout is 600 for this virtual
server (tried it at 30s, also - same result). We aren’t using any other
keepalive configs.

Any suggestions as to where else we might look?

Cheers,

Dean

Posted at Nginx Forum:

4

Hi Valentin,

I can repeat your results with static files - keepalives work with
HTTP/1.0 in that scenario. However, for responses via FCGI, a
connection close is consistently sent. I found a post on the russian
forum (thank you Google translate) that implies that the content-length
header needs to be set on the application side. I had assumed that
nginx would calculate the length and add the header, but this does not
appear to be the case.

Thanks,

Dean

Posted at Nginx Forum:

5

On Monday 05 March 2012 07:55:41 dbanks wrote:

contains Connection: Close.

If nginx supports this by default, it implies that we have an
incompatible config option. keepalive_timeout is 600 for this virtual
server (tried it at 30s, also - same result). We aren’t using any other
keepalive configs.

Any suggestions as to where else we might look?

You may enable debug log, and look carefully for what happens.
http://nginx.org/en/docs/debugging_log.html

I cannot reproduce with my “ab -k” and nginx:

Request:

2012/03/04 17:32:34 [debug] 6990#0: *2 http header: “Connection:
Keep-Alive”
2012/03/04 17:32:34 [debug] 6990#0: *2 http header: “Host:
localhost:8000”
2012/03/04 17:32:34 [debug] 6990#0: *2 http header: “User-Agent:
ApacheBench/2.3”
2012/03/04 17:32:34 [debug] 6990#0: *2 http header: “Accept: /”

Response:

2012/03/04 17:32:34 [debug] 6990#0: *2 HTTP/1.1 200 OK
Server: nginx/1.1.16
Date: Sun, 04 Mar 2012 13:32:34 GMT
Content-Type: text/html
Content-Length: 2440
Last-Modified: Mon, 27 Feb 2012 12:42:11 GMT
Connection: keep-alive
Accept-Ranges: bytes

and connection is really keep-alive and reusable.

My test.conf:

error_log logs/error.log debug;

events {}

http {
server {
listen 8000;
server_name localhost;

    location / {
        root ..;
    }
}

}

wbr, Valentin V. Bartenev

6

This would lead to delay response until the entire body will be
buffered by
nginx.

The body is small, so the buffering isn’t an issue. But because nginx
buffers the full response, I had expected nginx to calculate the
response size and pass that back to the client.

I’m sure there’s an excellent reason that it doesn’t do this…it just
ended up being somewhat non-intuitive for me.

Cheers,

Dean

Posted at Nginx Forum:

7

On Tuesday 06 March 2012 02:00:06 dbanks wrote:
[…]

I had assumed that nginx would calculate the length and add the header, but
this does not appear to be the case.

This would lead to delay response until the entire body will be buffered
by
nginx.

wbr, Valentin V. Bartenev