cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CXF-7174) NullPointerException when Content-Type is not specified in the http request
Date Fri, 09 Dec 2016 23:46:03 GMT


ASF GitHub Bot commented on CXF-7174:

GitHub user andymc12 opened a pull request:

    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 master

Alternatively you can review and apply these changes as the patch at:

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 <>
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:
>             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(
> 2016-12-09T09:29:47.24-0600 [APP/0]      ERR    at org.apache.cxf.transport.http.Headers.setProtocolHeadersInConnection(
> 2016-12-09T09:29:47.24-0600 [APP/0]      ERR    at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.setProtocolHeaders(
> 2016-12-09T09:29:47.24-0600 [APP/0]      ERR    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(
> 2016-12-09T09:29:47.24-0600 [APP/0]      ERR    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(
> 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

View raw message