* The idea is to trick the web server into keeping a connection open and waiting for data, e.g. by keeping on sending pointless headers, not sending enough (< content-length bytes of) data in the body, etc. Unlike a SYN flood or so, this doesn't require much traffic from the attacker.
* The reason this works is that apache has a limit of one thread or process per active connection, and there is typically an upper bound on
* The way to fix this once and for all in apache et al would be to handle socket I/O asynchronously, thus lifting the 1:1 ratio of connections to threads/processes.
Is that accurate? I'm mostly curious so that I can try to avoid any such pitfalls in any server software I might write.
One way to fix this in apache without breaking too many existing modules and extensions might be to use fibers to hide the asynchronicity and schedule them in the "blocking" I/O functions which would actually use non-blocking I/O underneath. (I don't actually know the apache architecture, so I might be wrong about the blocking I/O)