Bug #1807


Long fcgi sessions is closed due to server.max-keep-alive-idle

Added by HenrikHolst almost 14 years ago. Updated about 6 years ago.

Target version:


IMHO there is a problem in lighttpd in that there is no CON_STATE_HANDLE_REQUEST_CONTENT state meaning that when for example a fcgi application is handling a request the state remains CON_STATE_READ_REQUEST_CONTENT.

And in lighty_mainloop() if the state is CON_STATE_READ_REQUEST_CONTENT, then the connections is checked against server.max-keep-alive-idle even though the connection is not idle (it is beeing processed in the fcgi process).

I guess that this is the reason for people disabling keep-alive when they notice problems with fcgi.

Increasing max-keep-alive-idle solves the problem but then there is no protection against the real idle keep-alive sessions that simply hangs around...

Actions #1

Updated by rwe over 10 years ago

I'm having issues that sound quite similar to what is described in this ticket (on 1.5.0 r2533, used as reverse proxy with mod_proxy_core/mod_proxy_backend_http).

I experienced issues with long-running requests (GET and POST) e.g. from a simple form submission, that sometimes appear to actually be sent (and processed) multiple times on the backend server. Doing some traces on the client network showed that the TCP connection gets closed from the server side, while the request is still being processed (always after 5 seconds). Subsequently, the request is sent once again by the browser, leading to multiple invocations on the backend server.

Increasing server.max-keep-alive-idle to a higher value than the default of 5 seconds finally solved the problem (as long as the chosen time is high enough, that is), so it's really lighttpd causing the problem as it seems.

I guess this config option is not really supposed to close connections on which an HTTP request is still being processed, right (i.e. the connection not in fact being idle)? Of course I'd like to have a better solution than just setting the max-keep-alive-idle very high (which may lead to the same problem again anyway...)


Actions #2

Updated by Olaf-van-der-Spek over 10 years ago

  • Target version set to 1.4.31
Actions #3

Updated by stbuehler about 10 years ago

  • Target version changed from 1.4.31 to 1.4.x
  • Missing in 1.5.x set to No

You may be right; the problem is that the connection state machine is very complex, and i really don't want to change it in 1.4.x, as i fear i'll break too much.

If you have a simple patch that is easy to review... well, very unlikely.

Actions #4

Updated by gstrauss over 6 years ago

  • Status changed from New to Fixed

Fixed in

commit 3605a3bec31f5e1bc79fdfb830b84e188f060982
Author: Stefan Bühler <>
Date:   Wed Apr 2 10:04:11 2014 +0000

    use keep-alive timeout while waiting for HTTP headers; use always the read timeout while waiting for the HTTP body

    From: Stefan Bühler <>

    git-svn-id: svn:// 152afb58-edef-0310-8abb-c4023f1b3aa9

Actions #5

Updated by stbuehler about 6 years ago

  • Target version deleted (1.4.x)

Also available in: Atom