# Client keep alive support under HTTP/1.0

**URL:** <https://www.ruby-forum.com/t/client-keep-alive-support-under-http-1-0/217491>\
**Category:** NGINX\
**Created:** [March 2, 2012, 11:04pm UTC](https://www.ruby-forum.com/t/client-keep-alive-support-under-http-1-0/217491 "2012-03-02T23:04:19Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [March 2, 2012, 11:04pm UTC](https://www.ruby-forum.com/t/client-keep-alive-support-under-http-1-0/217491/1 "2012-03-02T23:04:19Z")

</div>

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](http://en.wikipedia.org/wiki/HTTP_persistent_connection))  
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:

> **[client keep alive support under HTTP/1.0](https://forum.nginx.org/read.php?2,223289,223289#msg-223289)**
>
> 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...

---

<div class="post-metadata">

**Author:** ![dbanks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c68b51/32.png) [@dbanks](https://www.ruby-forum.com/u/dbanks)\
**Post date:** [March 4, 2012, 2:44pm UTC](https://www.ruby-forum.com/t/client-keep-alive-support-under-http-1-0/217491/2 "2012-03-04T14:44:46Z")

</div>

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](http://en.wikipedia.org/wiki/HTTP_persistent_connection))  
> 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

---

<div class="post-metadata">

**Author:** ![dbanks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c68b51/32.png) [@dbanks](https://www.ruby-forum.com/u/dbanks)\
**Post date:** [March 5, 2012, 4:56am UTC](https://www.ruby-forum.com/t/client-keep-alive-support-under-http-1-0/217491/3 "2012-03-05T04:56:20Z")

</div>

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:

> **[Re: client keep alive support under HTTP/1.0](https://forum.nginx.org/read.php?2,223289,223370#msg-223370)**
>
> 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...

---

<div class="post-metadata">

**Author:** ![dbanks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c68b51/32.png) [@dbanks](https://www.ruby-forum.com/u/dbanks)\
**Post date:** [March 5, 2012, 11:00pm UTC](https://www.ruby-forum.com/t/client-keep-alive-support-under-http-1-0/217491/4 "2012-03-05T23:00:38Z")

</div>

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.

> **[fastcgi, Content-Length](https://forum.nginx.org/read.php?21,187285)**
>
> В ответе nginx не возвращается header Content-Length в связке nginx/0.8.53 + spawn-fcgi. location /spbpost/ { fastcgi\_pass unix:/var/run/spawn-fcgi/spawn-fcgi.www-1; fastcgi\_index test.php;

Thanks,

Dean

Posted at Nginx Forum:

> **[Re: client keep alive support under HTTP/1.0](https://forum.nginx.org/read.php?2,223289,223450#msg-223450)**
>
> 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...

---

<div class="post-metadata">

**Author:** ![dbanks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c68b51/32.png) [@dbanks](https://www.ruby-forum.com/u/dbanks)\
**Post date:** [March 5, 2012, 9:35am UTC](https://www.ruby-forum.com/t/client-keep-alive-support-under-http-1-0/217491/5 "2012-03-05T09:35:13Z")

</div>

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.

> **[A debugging log](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

---

<div class="post-metadata">

**Author:** ![dbanks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c68b51/32.png) [@dbanks](https://www.ruby-forum.com/u/dbanks)\
**Post date:** [March 6, 2012, 6:25pm UTC](https://www.ruby-forum.com/t/client-keep-alive-support-under-http-1-0/217491/6 "2012-03-06T18:25:55Z")

</div>

> > 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:  
[http://forum.nginx.org/read.php?2,223289,223523#msg-223523](http://forum.nginx.org/read.php?2,223289,223523#msg-223523)

---

<div class="post-metadata">

**Author:** ![dbanks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c68b51/32.png) [@dbanks](https://www.ruby-forum.com/u/dbanks)\
**Post date:** [March 6, 2012, 11:39am UTC](https://www.ruby-forum.com/t/client-keep-alive-support-under-http-1-0/217491/7 "2012-03-06T11:39:58Z")

</div>

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