§ Summary
➊ The slowloris attacks of last year consumed all of a host's available HTTP server connections with minimal bandwidth by trickling out HTTP headers forever at a slow pace. Countermeasures were developed and applied.
➋ This exploit consumes connections similarly, but does so by trickling out data in the content section of a POST request. Countermeasures targeting slowloris are ineffective.
➌ Countermeasures for this will include HTTP request timeouts, but to support distant users operating over potentially saturated links you will have to set the timeout high enough that any well connected attacker will still be able to kill your server. (That has some extrapolation from me.)
§ Discussion
The real solution will be to not consume a process or other expensive resource until the entire POST request has been received by the server. (Expand to PUT and any other method with content in the request.)
This becomes difficult in HTTP/1.1. To really support 1.1 you have to give the request the option to reject before the content is sent. (Yes you other old farts, the client doesn't necessarily blindly send the content, but waits for your server to say "ok, the method, resource, and headers look good, send me the content".) I suppose you could force all those decisions to be made by the HTTP server, but that would be sad.