In order to have the ability to process multipart/form-data transparently with help of the new Servlet 3.0 HttpServletRequest#getParts(), a Filter is the most suitable place for this. This works fine in Glassfish v3. However, in Tomcat the getParts() returns null and it works only inside a servlet with @MultipartConfig annotation. This is too strict. This makes it hard if not impossible to process multipart/form-data requests transparently with help of a Filter (i.e. creating a new parametermap and replacing the original one in HttpServletRequest). It is true that the Servlet 3.0 spec tells nothing about the use of this method inside a Filter, but this is in my opinion an oversight. There is no other way to obtain the parts than parsing the stream yourself with good 'ol Apache Commons FileUpload. Since it works fine in Glassfish v3, I'd suggest to make Tomcat 7 that lenient as well.
I've just read the spec and my reading of the spec is that this is expected to work. A quick look at the code suggests it should work. If you want to dig into this yourself, start at line 2499 of o.a.catalina.connector.Request
Correction: it didn't return null, it returned an empty collection. I will dig in the source.
Well, the getWrapper().getMultipartConfigElement() at line 2493 always returns null and thus an empty collection will be returned. Only when I call getParts() inside a Servlet with @MultipartConfig, it works. But the intent is to call getParts() inside a Filter. The getWrapper() always returns the target JSP/Servlet associated with the request which in my case does not necessarily have the @MultipartConfig annotation (or cannot have one because it's a 3rd party one out of your control, e.g. FacesServlet).
If the Servlet doesn't have the @MultipartConfig annotation then getParts() should not work. Tomcat is therefore specification compliant in this regard. I'm not adverse to adding a (probably per context) configuration attribute to relax this requirement. Therefore, I am changing this to an enhancement request.
Thank you. This is imo an oversight in the Servlet 3.0 specification. I will report it sooner or later.
If @MultipartConfig in a servlet is the sole way to trigger multipart handling during a request, then a Filter must be able to check the target servlet to determine if Request.getParts will work (which I don't believe is possible). I agree with balusc's assertion that this is an oversight in the specification. My only question is what the overall behavior should be. If a Filter calls Request.getParts and the content-type of the request is multipart/form-data, should Tomcat simply parse it as a multipart request regardless of the presence (or absence) of an @MultipartConfig annotation on the servlet? I would argue that Tomcat /should/ go ahead and do this. I would also argue that this ought to be the /default configuration/ as well. There are some web applications where a Filter is expected to be the content generator. All Apache Struts 2 applications are like this: the front controller is implemented as a Filter instead of as a Servlet (don't ask me why this is the case). Ignoring the fact that S2 provides multipart parsing itself, S2 applications would not be able to use the 3.0 specification for loading multipart data because the request will never reach a servlet (or, at best, the request would have to be mapped to both a Filter which does the real work, and to a dummy servlet that simply has the @MultipartConfig annotation just to achieve the goal).
FYI: this issue is currently reported on servlet-spec-public: https://servlet-spec-public.dev.java.net/issues/show_bug.cgi?id=14
Working on a patch.
Fixed. Will be available in 7.0.7 onwards. See documentation for <Connector> for how to enable this.
Patch needs tweaking. Configuration belongs in the Context, not in the Connector.
Fixed (again). Will be in 7.0.7 onwards.
Fixed in 7.0.7, but back in 7.0.16?? Please tell me if I'm wrong, but the code from BalusC works with Glassfish v3.1 it dosn't with Tomcat 7.0.16. HttpServletRequest#getParts() in the filter returns an empty collection. Do anybody know more about it?
See allowCasualMultipartParsing on the Context and ask on the users list if you have any further questions.
This problem also exists in Tomcat 7.0.47.
(In reply to noel from comment #14) > This problem also exists in Tomcat 7.0.47. The burden of proof is yours. You provided no proof. Please discuss this on the users mailing list so that others confirm that there is an issue, before reopening or submitting other issue. Note that 1. The testsuite contains testcases for this feature, org.apache.catalina.core.TestStandardContext#testBug49711() org.apache.catalina.connector.TestRequest#testBug54984() So it does work, if configured properly. 2. You must read documentation on "allowCasualMultipartParsing" option, as mentioned above. It is off by default. http://tomcat.apache.org/tomcat-7.0-doc/config/context.html Re-closing as FIXED.