https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #7 from Konstantin Kolinko <knst.koli...@gmail.com> --- (In reply to Mark Thomas from comment #5) > I was thinking a using the existing attribute to trigger a 400 response and > a new attribute to trigger a 413 response. That should cover all the current > possibilities for parameter/part issues. -1. By my '-1' vote I mean that when "using a new attribute to trigger a 413 response" I am against changing the meaning of the existing attribute. If something failed, the existing attribute should continue to indicate failure. It can be 1) Globals.PARAMETER_PARSE_FAILED_ATTR to signal presence of an error 2) additional attribute to signal the kind of an error. Originally when introducing PARAMETER_PARSE_FAILED_ATTR I have not defined what its value is. It was documented as "absent = success", "any not-null value = failure" with an intent to introduce different not-null values for different use cases. Nowadays javadoc for Globals.PARAMETER_PARSE_FAILED_ATTR explicitly mentions Boolean.TRUE as the value. Thus for compatibility it is better to go with a separate attribute to communicate the reason of the failure. Technically, PARAMETER_PARSE_FAILED_ATTR is a facade that exposes the value of internal coyoteRequest.getParameters().isParseFailed() flag. For reference: r1200218 Historically this attribute and FailedRequestFilter were introduced as a review of CVE-2012-0022 fix that introduced "maxParameterCount" limit. The intent was to be able to perform a simple test that none parameters were lost. Also I think that exceeding the "maxParameterCount" limit also would better result in response status 413. I wish there were a Servlet API way to communicate parameter processing errors. HttpServletRequest.getParts() and getPart() methods implement some way to indicate errors by throwing an exception, but an IllegalStateException thrown there is used to indicate both "size limit exceeded" and "missing multipart-config" conditions. [1] There exist "javax.servlet.error.exception" and other standard Request attributes as defined in ch.10.9.1 of Servlet 3.1 specification, but IIRC they are used only when performing an error processing dispatch. [1] http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts%28%29 -- 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
