[
https://issues.apache.org/jira/browse/CXF-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736701#comment-15736701
]
ASF GitHub Bot commented on CXF-7174:
-------------------------------------
GitHub user andymc12 opened a pull request:
https://github.com/apache/cxf/pull/213
CXF-7174: Avoid NPE when content-type not set in http request
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andymc12/cxf master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/213.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #213
----
commit 96e5325b013ecb43ab81ae1ee2094a7b0ff06e20
Author: andymc12 <j.andrew.mccri...@gmail.com>
Date: 2016-12-09T23:41:33Z
CXF-7174: Avoid NPE when content-type not set in http request
----
> NullPointerException when Content-Type is not specified in the http request
> ---------------------------------------------------------------------------
>
> Key: CXF-7174
> URL: https://issues.apache.org/jira/browse/CXF-7174
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.1.8
> Reporter: Andy McCright
>
> When the Content-Type header is not specified in the HttpServletRequest, a
> null pointer is possible when calling Headers.copyFromRequest(...) followed
> by Headers.determineContentType(). This scenario is possible when using
> non-traditional clients like curl.
> Here is an example (snippet) of the NPE:
> 2016-12-09T09:29:47.24-0600 [APP/0] ERR Caused by:
> java.lang.NullPointerException
> 2016-12-09T09:29:47.24-0600 [APP/0] ERR at
> org.apache.cxf.transport.http.Headers.determineContentType(Headers.java:374)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERR at
> org.apache.cxf.transport.http.Headers.setProtocolHeadersInConnection(Headers.java:363)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERR at
> org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.setProtocolHeaders(URLConnectionHTTPConduit.java:279)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERR at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1301)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERR at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1337)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERR ... 56 more
> The failing line of code is:
> if (ctList != null && ctList.size() == 1) {
> ct = ctList.get(0).toString(); // <--- here
> The reason it fails is that copyFromRequest(...) will create a singleton list
> and wrap the request's content-type value in it. If the content-type from
> the request is null, then ctList will be a singleton list with a null value
> in it, so the call to toString() will be on a null value.
> Instead, the code should be:
> if (ctList != null && ctList.size() == 1 && ctList.get(0) != null) {
> ct = ctList.get(0).toString();
> ...
> This ensures that a default content type of text/xml is returned when no
> content-type is specified in the request -- or whatever was specified in the
> Message.
> This approach is preferable to just setting ctList (via the
> headers.get(Message.CONTENT_TYPE) field) to null because other places in the
> code depend on that list to be non-null.
> I have a patch and test case to be delivered shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
