Closed connection by peer is not reported to fastcgi/scgi service
|Missing in 1.5.x:||No|
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
#2 Updated by artik over 5 years ago
Simplest reproduction with mod_proxy.
Test no 1:
Run "dummy web server"
nc -l -p 8001
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:
Then press Ctrl+C
nc prints headers but when wget is stopped it does not exits -- it is not aware that client has gone.
#3 Updated by flynn almost 5 years ago
- File lighttpd-1.4.26-bug2058.patch added
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 ...
#4 Updated by stbuehler almost 5 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.
#6 Updated by stbuehler almost 4 years ago
- Category changed from mod_fastcgi to core
- Status changed from New to Wontfix
- Priority changed from High to Normal
- Target version deleted (
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).
Also available in: Atom