[
https://issues.apache.org/jira/browse/CXF-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934896#action_12934896
]
Dobes Vandermeer commented on CXF-3147:
---------------------------------------
This also affects the use of FormParam where no message body (and no content
type) is provided; if the default values of the parameters are enough for the
method, people might expect to be able to POST with no entity and get a
response instead of an error 500.
> FormParam parsing fails when no content-type is provided
> --------------------------------------------------------
>
> Key: CXF-3147
> URL: https://issues.apache.org/jira/browse/CXF-3147
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.3.0
> Reporter: Dobes Vandermeer
> Priority: Trivial
>
> Ran into this writing unit tests - if no Content-Type is provided when doing
> a POST, some code handles a null media type and some doesn't:
> In org.apache.cxf.jaxrs.utils.JAXRSUtils.processFormParam(Message, String,
> Class<?>, Type, String, boolean) it treats a null media type as if it was the
> same as the form media type:
> if (mt == null || mt.isCompatible(MediaType.APPLICATION_FORM_URLENCODED_TYPE))
> However, when reading the body of the form fields, it calls getCharset(mt) to
> get the character set to use when decoding the form fields, which doesn't
> check for null and thus throws an error.
> Either the null media type should fall through and return an error (wrong
> content type) or it should be handled.
> Suggested fix: In org.apache.cxf.jaxrs.utils.FormUtils.getCharset(MediaType),
> add if(mt == null) return "UTF-8"; to the start of the method.
> Easy workaround: only use clients that provide a content type for form field
> POSTs
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
