Bug #2058
closedClosed connection by peer is not reported to fastcgi/scgi service
Description
I'm trying to run some COMET applications behind lighttpd. Such request usually involve XmlHTTPRequest with long poll that is handled in FastCGI or SCGI service.
It is important to report connections that are reset by peer. It is usually done in SCGI by shutting down the socket or in FastCGI by shutting down the socket or by sending FCGI_ABORT_REQUEST record.
So, I noticed that browser connection reset is not reported to FastCGI and SCGI applications. In order to be sure I tested this behavior with Nginx web server -- it reported disconnected requestes.
Without this feature, the creation of COMET web serveices behind lighttpd is very
problematic.
Files
Updated by artik over 15 years ago
After some checks I had found same issue with HTTP Proxy module -- the disconnect on client side is not reported to the server and may cause dangling connections on the server side.
So this is issue for proxy servers as well.
Updated by artik over 15 years ago
Simplest reproduction with mod_proxy.
Lighttpd configuration:
server.modules = ("mod_proxy") server.document-root = "./" # mimetype mapping mimetype.assign = ( ".gif" => "image/gif", ".jpg" => "image/jpeg", ".jpeg" => "image/jpeg", ".png" => "image/png", ".css" => "text/css", ".html" => "text/html", ".htm" => "text/html", ".js" => "text/javascript", ".xml" => "text/xml", # default mime type "" => "application/octet-stream", ) server.port = 8080 server.bind = "0.0.0.0" proxy.server = ( "/hello" => (( "host" => "127.0.0.1", "port" => 8001 )))
Test no 1:
Run "dummy web server"
nc -l -p 8001
Run client
wget http://localhost:8001/hello
And hit Ctrl+C.
Observe, the dummy web server, prints headers and exits when wget is stopped.
Now start lighttpd with above configuration.
/usr/sbin/lighttpd -D -f light.conf
nc -l -p 8001
And now run wget via proxy:
wget http://localhost:8080/hello
Then press Ctrl+C
Observe:
nc prints headers but when wget is stopped it does not exits -- it is not aware that client has gone.
Updated by flynn over 14 years ago
The problem is, that lighttpd does not add an event on the input connection, after the request ist parsed. The only event that could happen is closing the socket, which should reset the whole connection (which closes the socket to scgi or fcgi processes too).
Otherwise only the write timeout detects this situation, usually after 6 minutes ( server.max-write-idle = 360 ).
The attached patch fixes this, but I'M not sure about side effects, so somebody who knows the state machine better should have a look ...
Updated by stbuehler over 14 years ago
- Missing in 1.5.x set to No
There is a feature called "pipelining" - which means browser can send the next request before the previous was finished.
So there can be normal read events too.
You could try writing some "keep-alive" data to check whether the connection is still active.
Updated by stbuehler over 13 years ago
- Category changed from mod_fastcgi to core
- Status changed from New to Wontfix
- Priority changed from High to Normal
- Target version deleted (
1.4.29)
I'm sorry, but i don't think we will fix this in 1.x; changing the connection state machine is not easy, and i fear we will get too many bugs when we try to fix this.
I want to fix this in 2.0 (but right now it has the same problem).
Updated by gstrauss over 8 years ago
- Related to Bug #399: FastCGI performance on high load added
Updated by gstrauss over 8 years ago
- Status changed from Wontfix to Patch Pending
- Target version set to 1.4.40
proposed patch is part of https://github.com/lighttpd/lighttpd1.4/pull/53
Also available in: Atom