Lighttpd

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.

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.

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 ...

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.