Hello Andrew, On Fri, Sep 03, 2010 at 02:16:29PM -0700, Andrew Farmer wrote: > I noticed that if I close the client connection to haproxy, it ignores me, > and leaves the connection open to the upstream server. Then it logs the > response it gets from the upstream server. The 'termination state' in this > situation is '----'. This gives me no indication that the client closed the > connection.
HTTP works on top of TCP, and TCP does not provide such a notion of closing a connection. In fact, a TCP connection are just two independant, unidirectional channels. When a user agent "closes", the only thing we know on the server side is that the user agent has closed its sending channel, which does not preclude anything for the other channel. Many users have monitoring scripts which rely on that without them being aware. For instance, when you do : $ echo -e "GET / HTTP/1.0\r\n\r\n" | nc server 80 what happens is that the request is send and the sending channel is immediately closed, but "nc" still waits for the response. That said, with normal browsers, a close of the send side generally means that the user has pressed the "Stop" button. Thus, there is an option "abortonclose" in haproxy that says that if a connection has its sending channel closed before the connection is established, then the connection is aborted. In 1.5 we have even improved that a bit further for users of long-polling requests. When "option abortonclose" is set, if the client closes the send side, then haproxy forwards this closing event to the server. That way, it lets the server decide how to handle the situation. For the server, it is just as if it only had the browser in front of it, without haproxy. Since this can improve the behaviour in some error situations, this will be backported to next 1.4 (in fact it's already in the latest snapshot). Regards, Willy
