How does it handle slow http attacks? If I open 10k TCP connections to your server and drip feed http requests 1 byte at a time on each connection, what happens?

You used to be able to easily DOS apache servers this way, because you just needed enough concurrent connections to exhaust its thread pool and then it wouldn't be able to handle any more requests. And then you need a bit rate on each connection just high enough not to trip apache's connection timeout. (So like, 20 TCP connections each sending 1 byte every 20 seconds would do it. Not sure about today but Apache used to be brought to its knees with 1 bps of bandwidth.)

You could probably mitigate this by putting nginx in front of your server, but this works because nginx uses async internally to handle requests. And that won't work if you ever do proxy passthrough (for SSE, websockets, etc).

Yes I use nginx. Yes I know websocket is different.

I got a kick out of this comment since nginx is just an event loop in a separate process.

It's a totally legitimate answer, though, it just made me smile.

> it handles thousands of requests per second just fine

It probably doesn't. Spawning threads per request is a lazy pattern.

We use Apache to handle billions of requests per day, and even its thread pool can be an issue.

Are you aware that rouille and tiny_http (it's underlying HTTP implementation) have been unmaintained for a while now?

And once starting and stopping threads adds to much delay to your request processing, there could be a thread pool that grows as needed and which will reuse threads that haven't been closed yet.

This mechanism is implemented by Apache httpd, Tomcat and pretty much every classic application server.

> This mechanism is implemented by Apache httpd, Tomcat and pretty much every classic application server.

True, but there's a reason that Apache usage is declining at the rate that it is.