HTTP Proxy / FastCGI / SCGI won't close connection when client disconnects - bug or feature?
I am working on Comet support for CppCMS through long XMLHttpRequest polls. In many cases, such a request is closed by the client before a response has been received from the server - for example, the page is closed, the user navigates to another page, or simply refreshes.
On the server side, I expect to receive a notification that the connection has been disconnected. I tested the application over 3 connectors: FastCGI, SCGI and a simple HTTP proxy.
From the 3 main UNIX web servers, Apache2, lighttpd and Nginx, only the last one closed as expected, allowing my application to remove the request from the wait queue - this worked for both FastCGI and HTTP proxy connectors. (By default, Nginx does not have a scgi module).
Others, Apache and Lighttpd do not close the connection or notify the server to disconnect clients, continue as if the client is still online. This happens for all 3 supported APIs: FastCGI, SCGI, and HTTP Proxy.
I opened the issue for Lighttpd , but what interests me more is the fact that Apache is a mature and well maintained web server like lighttpd and does not expose the server backend that the client had.
Questions:
- Is this a bug or is this a function? Is there any reason not to close the connection between the web server and the application server?
- Is there a real-world Comet app running behind these servers through FastCGI / SCGI / HTTP-Proxy servers?
- If this is true, how do they deal with this problem? I understand that every 10 seconds I can disconnect all connections, but I would like to keep them idle for as long as the client is listening, because this allows for easier scaling - every connection is very bad - the cost is only a parsed socket.
Thank!
source to share
(1) Function. Or, more accurately, the implications of implementation details.
A TCP / IP connection is not associated with a constant flow of traffic back and forth. So there is no way of knowing that the client has left without (a) the client telling you that it is closing the connection, or (b) a timeout.
(2) I am not familiar with Comet or CppCMS. But yes, there are all kinds of CMS servers that run behind the mentioned web servers and they all have to deal with this problem (and yes, it is a pain).
(3) Timeouts are the only way, but you can mitigate the pain, so to speak. Ask the client to ping the server through the connection every N seconds when there is otherwise no activity. You don't have to do anything and you can attack the answer; notifications about concurrent changes or whatever you need.
You are correct in that it is surprising that mod_fastcgi does not support telling the backend that Apache has detected a disconnect or connection timed out. And you are not the first one to be disappointed.
The second patch on this page should fix this specific issue:
source to share
http://ncannasse.fr/blog/tora_comet
I don't have specific information for you, but this article mentions that they might detect when a client disconnected from Apache. See tora.Queue
. And it looks like the source is available in neko CVS, so you might find some hints there. Good luck.
source to share