Bug #2058

Closed connection by peer is not reported to fastcgi/scgi service

Added by artik about 5 years ago. Updated about 3 years ago.

Status:WontfixStart date:2009-08-27
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:core
Target version:-
Missing in 1.5.x:No

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.

lighttpd-1.4.26-bug2058.patch Magnifier (515 Bytes) flynn, 2010-04-13 15:51

History

#1 Updated by artik about 5 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.

#2 Updated by artik about 5 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.

#3 Updated by flynn over 4 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 ...

#4 Updated by stbuehler over 4 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.

#5 Updated by nitrox about 3 years ago

  • Target version changed from 1.4.x to 1.4.29

#6 Updated by stbuehler about 3 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).

Also available in: Atom