RequestParamMethodArgumentResolver does not resolve multiparts using HTTP PUT [SPR-9079]

[spring-projects-issues]

Christoffer Soop opened SPR-9079 and commented

Using the HiddenHttpMethodFilter and MultipartFilter as described in their respective JavaDoc produces a stack trace with the message:

The current request is not a multipart request.

... when used with Spring MVC's DispatcherServlet.

To my understanding the HiddenHttpMethod wraps the HTTP Request and changes the POST method to PUT. This makes the method isMultipartRequest (lines 187-193) in RequestParamMethodArgumentResolver always return false:

private boolean isMultipartRequest(HttpServletRequest request) {
  if (!"post".equals(request.getMethod().toLowerCase())) {
    return false;
  }
  String contentType = request.getContentType();
  return (contentType != null && contentType.toLowerCase().startsWith("multipart/"));
}

An obvious fix would be to remove the if-clause and rely only on the HTTP content-type header. Another is to include the HTTP PUT method as a valid multipart HTTP method in the if-clause.

---

Affects: 3.1 GA

Attachments:

• 20120131-multipart-stack-trace.txt (1.91 kB)

Referenced from: commits 64a69f7

[spring-projects-issues]

Rossen Stoyanchev commented

The Apache Commons FileUpload on which CommonsMultipartResolver is built, recognizes "POST" multipart requests only and so does the Servlet 3 based StandardMultipartResolver. So currently a true PUT request would not even be parsed.

It sounds like in your case the actual request is a POST converted to a PUT by the HiddenHttpMethodFilter, correct? We should drop the check of the HTTP method from RequestParamMethodArgumentResolver (and also from RequestPartMethodArgumentResolver). It should be sufficient to verify the content type starts with "multipart/" at that point.

[spring-projects-issues]

Christoffer Soop commented

Great, thanks for the excellent response and rapid resolution!