Bug #1807
closedLong fcgi sessions is closed due to server.max-keep-alive-idle
Description
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...
Updated by rwe almost 12 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...)
Thanks
Updated by stbuehler almost 12 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.
Updated by gstrauss about 8 years ago
- Status changed from New to Fixed
Fixed in
commit 3605a3bec31f5e1bc79fdfb830b84e188f060982
Author: Stefan Bühler <stbuehler@web.de>
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 <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2962 152afb58-edef-0310-8abb-c4023f1b3aa9
Also available in: Atom