DO NOT REPLY [Bug 49711] HttpServletRequest#getParts() does not work in a Filter

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=49711

--- Comment #6 from Christopher Schultz <ch...@christopherschultz.net> 2010-11-08 10:15:52 EST ---
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).

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org