It's important to note that you can protect against Slowloris itself not only by the various apache modules available specifically for Slowloris and specifically for this kind of HTTP attack, but also through Apache's native configuration settings that (among others) govern the number of simultaneous connections any single IP is allowed to have. Slowloris itself is not much different in terms of the effect it has on the HTTPd than a script pulling data from the server using curl or wget.
I don't know how the Apache modules to guard against Slowloris work, but I can think of a modified attack that would still work if connections per IP were limited. You can't limit connections per IP to just one, as browsers will pipeline requests, they may have multiple tabs open, asynchronous requests, &c . . . 256 is obviously very high, let's say you set the limit to 10 simultaneous requests per IP.
It's now impossible for a user to Slowloris your webserver, but they only need to get hold of 26 separate IP addresses to be able to once more. Depending on your setup, this may be far less than they would need for a naive DDOS attack.
I think a way to mitigate both attacks would be to limit how long the client can send headers for (and perhaps refuse connections for X amount of time if a client repeatedly acts in a way that appears malicious, but that's possibly beyond the scope of "native configuration").
First off, as others have pointed out you can successfully run thousands of threads, so the default 256 does not mean much. Also, HTTP pipelining is not what you think it is: http://en.wikipedia.org/wiki/HTTP_pipelining
I know, I was one of those people - I just wasn't sure if Apache can do that well, I know of other servers that can. And yes, you are correct, that's what I get for posting when tired - I meant simultaneous requests!
