| Summary: | @MultipartConfig, getParts(), and getParameter() on PUT requests | ||
|---|---|---|---|
| Product: | Tomcat 9 | Reporter: | Robert Tupelo-Schneck <schneck> |
| Component: | Servlet | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 9.0.11 | ||
| Target Milestone: | ----- | ||
| Hardware: | Macintosh | ||
| OS: | All | ||
| Attachments: | HttpServlet subclass which will echo parameters for POST and for PUT before and after calling getParts() | ||
Thanks for the really good test case. I'll take a look. Fixed in: - trunk for 9.0.12 onwards - 8.5.x for 8.5.34 onwards - 7.0.x for 7.0.91 onwards |
Created attachment 36123 [details] HttpServlet subclass which will echo parameters for POST and for PUT before and after calling getParts() This is about a servlet annotated with @MultipartConfig. For POST requests, "parts with form-data as the Content-Disposition but without a filename" are available to getParameter*. For PUT requests, such parts are not initially available to getParameter*. If I call getParameter* before getParts(), they are never available to getParameter*, even after calling getParts(). If I call getParts() first, then they are available to getParameter*. The servlet spec does not appear to require that PUT and POST should behave differently for multipart requests in servlets annotated with @MultipartConfig. Even if it did, it seems very surprising that the call order of getParts() vs getParameter* would affect which parameters were available. Tried on Tomcat 9.0.11 (and also some earlier versions), with Oracle Java 8.