Take the 2-minute tour ×

From what I understand, a HTTP connection could either be "keep-alive" or "close".

I sent a HTTP request to a server:

GET /raw/ HTTP/1.1
Host: server.com
Connection: keep-alive

And it responded with:

HTTP/1.1 200 OK
Connection: keep-alive, close

Essentially, I believe the server is bugged because a response like keep-alive, close is ambiguous.

However, as the receiver, should we interpret this header value as keep-alive or close?

share|improve this question
Have you read the RFC of HTTP protocol? tools.ietf.org/html/rfc2616 –  Jack Jul 12 '12 at 0:58
It might have to do with trying to support [certain] HTTP 1.0 clients, see en.wikipedia.org/wiki/HTTP_persistent_connection However, since close (which is defined in 1.1 is specified) then it's interpreted as "not a persistent connection" by a compliant HTTP 1.1 server/client? –  user166390 Jul 12 '12 at 1:04
add comment

2 Answers

up vote 1 down vote accepted

TL; DR: Chrome interprets this response header as keep-alive and maintain a peristent connection while Firefox closes each connection.

I stumbled over this question as I tried to optimize the page loading time for my website.

In the referenced RFC I didn't find anything about how multiple entries in the Connection header may be properly handled. It seemed to me like the implementation may choose from two possibilites:

  1. If there are multiple entries, you may choose that fits best to your needs
  2. If there is a close inside, you may close the connection after transmission

So, I needed to find out. Let's make some deeper investigation:

I noticed that Chrome was always sending a HTTP/1.1 request with Connection: keep-alive and my Apache default configuration was always responding with a Connection: close header. So I began investigating and took a look at the TCP segments with Wireshark.

Chrome has to fetch 14 elements to display the website, mostly of them static things like images or css files. And it took in complete 14 TCP connections and that took a lot of time (approximately 1,2 seconds). After each request for an image (e.g.) there came a TCP segment with the FIN flag set to 1.

So what about Chrome vs. Firefox? Chrome seems to have a maximum number of concurrent connections to one server of 6. Firefox has a more granular configuration and distinguishs persistent (maxium of 6, seen in about:config) and non-persistent (the maximum numbers differed a lot in different sources). But wait... Both, Chrome and Firefox are sending HTTP/1.1 request headers with Connection: keep-alive, so both should be limited to 6 (as this is a request for opening up a persistent connection).

I decided to try a simple trick and added the following lines to my .htaccess in the web root folder:

<ifModule mod_headers.c>
Header set Connection keep-alive

The server now responds with:

Connection: keep-alive, close

Now I took a look at the TCP segments again: There were only 9 connections from Chrome to my server now and only 3 with the FIN flag set to 1. So this trick seemed to work. But why were there those 3 connections, that closed the connection after data transmission? These were the PHP requests, as the HTTP header X-Powered-By: PHP/5.4.11 confirmed.

And what about Firefox? There were still those 14 requests!

How to fix that and get the fcgi processes to work with keep-alive too?

I added the following lines to my virtualhost section of the httpd.conf configuration:

KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 100

and removed the ones added in the .htaccess. Now the server isn't sending any confusing - Connection: keep-alive, close, but only Connection: keep-alive and everything works fine!


A header with the connection field set to

HTTP/1.1 200 OK
Connection: keep-alive, close

will be interpreted by Chrome as keep-alive while Firefox seems to close each connection. It seems to depend on the actual implementation.

So if you're willing to implement a client for handling response headers that contain Connection: keep-alive, close, I would propose to try using keep-alive if you need more than one request. The worst thing that may happen: The server will close the connection and you need to connect again (that's exactly the other option you would have had!)

share|improve this answer
What should be the proper behavior then? –  Pacerier Mar 4 at 7:18
As the RFC doesn't mention how to handle this situation, I would assume (if you're acting like a client): take the best possible for your needs! If there is nothing that needs to be transfered, close the connection, if there are still requests left in the queue, keep the connection alive. That's IMHO how Chrome handles it. –  ConcurrentHashMap Mar 4 at 7:32
add comment

It means that the server won't do persistent connections and will close the connection after this request.

share|improve this answer
Hmm then why did it say keep-alive in the first place? –  Pacerier Jul 12 '12 at 1:23
Probably because you sent keep-alive. You should not send keep-alive as that's assumed for HTTP 1.1, keep-alive is used only for HTTP 1.0. –  Francis Upton Jul 12 '12 at 7:12
add comment

Your Answer


