https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #4 from Christopher L. Simons <christopherleesim...@gmail.com> --- (In reply to Christopher Schultz from comment #1) > Look into how Globals.PARAMETER_PARSE_FAILED_ATTR is used to communicate > this situation to the application and see if you can come up with something > that might work better than your current proposal. It appears that both checks for maxPostSize do result in Globals.PARAMETER_PARSE_FAILED_ATTR being set: in Request#parseParts, an exception is thrown, and in the finally block of the try/catch/finally block parameters.setParseFailed(true) is set. In Request#parseParameters, the try/catch/finally block is exited without setting 'success' to true, and the finally block calls parameters.setParseFailed(true) in this case. So it appears the original concern about return 200 in this case is addressed. The documentation for maxParameterCount notes that FailedRequestFilter can be used to reject requests that exceed this limit. I've attached a patch to include the same note in the maxPostSize documentation after verifying 400 is returned in this case (as noted above). > It does almost what you want, except that it returns a 400 response instead > of 413 Unconditionally sending a 400 from FailedRequestFilter upon failure seems incorrect as the HTTP spec states that 400 is to be used when the request failed "due to malformed syntax,"[1] which isn't the case for maxPostSize and maxParameterCount violations; in some parse failure cases 400 is correct, but for these violations 413 seems more appropriate. I'd propose implementing a mechanism to indicate from the parsing code which status should be returned from FailedRequestParameter. Thoughts? [1] HTTP/1.1: Status Code Definitions http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1 -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
