They do mention botnets deploying the attack, the "connections per IP" filtering will not help there. I agree the chunked encoding statement makes no sense, no

They do mention botnets deploying the attack, the "connections per IP" filtering will not help there. I agree the chunked encoding statement makes no sense, nor does the "break the protocol" statement. Some rough calculations (a simpler attack, with this timeout byte trickling isn't required): Given: 200 bytes of header/transport can get a POST started and down to its content. Given: A legitimate customer on a shabby, long latency link might take 5 seconds to get his POST request and data sent. Compute: With a 5 second timeout, a bad person can hold a resource for 40 bytes/second of bandwidth. Compute: 256[1] resource limit takes only 80kbps. Compute: 20000 resource limit takes 6Mbps. Still, you are right, the sky isn't falling: • identify and throttle bad actors • throttle single IPs (be careful about your giant corporate customer that NATs everyone) • reduce the cost of the resource. Don't start a process until you have all the POST data. I would leave the data in the kernel until I had all the POST data or a lot of data (MSG_PEEK is your friend. 'real' requests will all come in the first datagram anyway) (Yes, kernel memory is special, but I sure don't want these attackers to cause swapping, so bytes are bytes and a billion of them are cheap.) Ultimately the TCP connection count will be the expensive resource. Google your way past the 64k limit. • data tricklers are probably easy to see if you are watching the size of your read()s. • crazy over the top solution: use a separate IP address on a virtual mac address in your linux box without a kernel IP stack on it. Do your own TCP blending the TCP state machine with your own HTTP request decoding state machine. (Actually, if you have slots, maybe just use another physical controller, it will be faster and you won't shoot your own leg off by accidentally engaging the kernel TCP stack. When you see a spurious RST in response to a SYN, look for that leg.) EOM [1] random self discovery of the day: I consider 256 to be one significant digit.