[
https://issues.apache.org/struts/browse/WW-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46473#action_46473
]
Wes Wannemacher commented on WW-3128:
-------------------------------------
I had every intention of having this in 2.1.7, but you can see it took two
commits for me to get it right. There was nothing wrong with the patch, I
simply applied it, built, then checked the rest-showcase with mvn jetty:run.
When everything looked okay to me, I did an 'svn commit' and I hadn't 'svn add'
ed one of the files. So, the commit went upstream with no errors or problems,
and my local copy of the source was intact. I didn't notice anything was wrong
until I deployed on another test system. Since I screwed up the commit, we
voted 2.1.7 down and are working to get 2.1.8 out pretty quickly. The second
commit came after I ran the release process for 2.1.7, so this won't be fully
fixed until we get 2.1.8 out.
> struts2-rest-plugin incorrectly handles multipart/form-data content-type data
> -----------------------------------------------------------------------------
>
> Key: WW-3128
> URL: https://issues.apache.org/struts/browse/WW-3128
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - REST
> Affects Versions: 2.1.6
> Reporter: Brian Ferris
> Assignee: Wes Wannemacher
> Fix For: 2.1.7
>
> Attachments: struts2-rest-plugin-MultiPartFormDataHandler.patch
>
>
> When a POST request is made with "multipart/form-data" encoding, such as to
> upload a file, the "DefaultContentTypeHandlerManager" has no custom input
> handler registered to handle "multipart/form-data" data. The plugin assumes
> a default input handler based on the request extension. In case of "xml"
> (which is also the default handler failing all else), the handler attempts to
> parse the payload as xml, which results in an exception being thrown.
> The solution is to write a custom content-type handler similar to the
> "FormUrlEncodedHandler" that ignores the form payload. In addition, the
> "DefaultContentTypeHandlerManager" needs to be modified, since the
> content-type of the form data is not actually "multipart/form-data", but
> rather ""multipart/form-data; boundary=abcdefg". Simple parsing is done to
> remove the additional parameters of the content-type so that the proper
> handler can be correctly resolved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.