I\'m developing a spring mvc app with framework 3.2.3.RELEASE
In my app I handle Multipart with StandardServletMultipartResolver, but with apache commons-fileupload
PUT refers to a single resource, for example one file. So, by definition, a multi-part form doesn't match the PUT verb.
So I guess they made these checks for POST to be able to apply to the HTTP specs: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
I guess you could argue that PUTting a custom object that contains multiple fields, including one or more files, should be ok, it could still be considered as being one resource in REST terms, but this is not the way most implementers seem to interpret this.
RFC said
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.
So PUT request represent a single resource.
But multiparts means multiple resources in a single body.
http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
In the case of multiple part messages, in which one or more different sets of data are combined in a single body, a "multipart" Content-Type field must appear in the entity's header. The body must then contain one or more "body parts," each preceded by an encapsulation boundary, and the last one followed by a closing boundary.
Therefore by semantic of PUT request doesn't match with multipart data. And the POST is matched because requested URI of POST request is "handler of enclosed entities".