-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
Post by Mark ThomasTomcat only processes these requests for Servlet 3.0 file upload
and there are already sufficient limits in place for that case to
prevent a DoS.
Aah, right: multipart is only supported if the servlet has been marked
as such, and therefore the developer knows to expect large mounts of
data (and can configure such limits).
The wildcard is the "casual multipart parsing" which allows any
multipart request to be parsed without regard for such limits. Any
limits (data size) imposed on the connector will be used in those
cases, but "maximum number of parameters" is not one of them. I should
probably update the documentation for that feature to make a note of
this caveat.
From the documentation of Commons/fileUpload, it would seem rather simple - for a Java
guru - to implement a counter while processing the POSTed parameters, and ignore what is
above maxParameterCount :
Sample code from http://commons.apache.org/fileupload/using.html :
// Process the uploaded items
Iterator iter = items.iterator();
while (iter.hasNext()) {
FileItem item = (FileItem) iter.next();
if (item.isFormField()) {
processFormField(item);
} else {
processUploadedFile(item);
}
}
(Maybe the "items" object above already has a "size" or "length" method, avoiding the
counter logic altogether)
Of course by then, the POST has already been parsed, so I don't know if this would help a
lot to avoid a DOS attack.
But the maximum acceptable total size of the POST can be specified in advance, to avoid
this. After all, if someone wants to allow POSTs with 10,000 small parameters, then why not ?
I do not understand on the other hand the OP's later reference to a "hash collision".
That sounds like a JVM issue, rather than a specifically Tomcat one, no ?