Project

General

Profile

Actions

Bug #2058

closed

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

Added by artik about 15 years ago. Updated over 8 years ago.

Status:
Fixed
Priority:
Normal
Category:
core
Target version:
ASK QUESTIONS IN Forums:

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.


Files

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

Related issues 1 (0 open1 closed)

Related to Bug #399: FastCGI performance on high loadFixedActions
Actions #1

Updated by artik about 15 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.

Actions #2

Updated by artik about 15 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.

Actions #3

Updated by flynn over 14 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 ...

Actions #4

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

Actions #5

Updated by nitrox over 13 years ago

  • Target version changed from 1.4.x to 1.4.29
Actions #6

Updated by stbuehler over 13 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).

Actions #7

Updated by gstrauss over 8 years ago

  • Related to Bug #399: FastCGI performance on high load added
Actions #8

Updated by gstrauss over 8 years ago

  • Status changed from Wontfix to Patch Pending
  • Target version set to 1.4.40
Actions #9

Updated by gstrauss over 8 years ago

  • Status changed from Patch Pending to Fixed
Actions

Also available in: Atom