The HTTP server/framework vulnerabilities that have been discovered recently underscore the importance of request limits. E.g.:
It would be nice if Snap server and Snap Framework supported limits on requests including:
Limit on number of request headers (called LimitRequestFields by Apache)
This is particularly important because snap-core parses the request headers into a Data.HashMap.Strict from unordered-containers. An attacker might be able to exploit knowledge of the hashing function used by Data.HashMap.Strict to carry out a hashDoS.
Request header size limit – A per-header limit on the number of bytes that can be contained in the header (called LimitRequestFieldSize by Apache)
If request headers are merged, then the limit needs to be applied to the merged header.
Limit on the number of request parameters (framework limit) – A limit on the number of request parameters that will be parsed (called max_input_vars by PHP)
Snap Framework is not vulnerable to the hashDoS attack described at Effective DoS attacks against Web Application Platforms – #hashDoS [UPDATE3] because it parses the request parameters into a Data.Map (ordered map). However, when a repeat parameter is encountered, the value of the repeated parameter is appended to the end of the list of ByteStrings for that parameter name, an O(n) operation. That might be exploitable if the same parameter name is used thousands of times.
fwiw, readRequestBody has a mandatory parameter for stating the maximum allowed body content-length of a HTTP request...