[
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Egli updated CXF-8984:
-----------------------------
Description:
The package private class {{HttpClientWrappedOutputStream in
org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods
_getInputStream()_ and {_}closeInputStream(){_}.
There are several paths where _getInputStream()_ returns null. This will then
lead to a *NullPointerException* in _closeInputStream()_ because there is no
null check.
{code:java}
@Override
protected InputStream getInputStream() throws IOException {
HttpResponse<InputStream> resp = getResponse();
String method = (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
int sc = resp.statusCode();
if ("HEAD".equals(method)) {
try (InputStream in = resp.body()) {
return null;
}
}
if (sc == 204) {
//no content
return null;
}
if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
Optional<String> f =
resp.headers().firstValue("content-length");
Optional<String> fChunk =
resp.headers().firstValue("transfer-encoding");
if (f.isPresent()) {
long l = Long.parseLong(f.get());
if (l == 0) {
try (InputStream in = resp.body()) {
return null;
}
}
} else if (!fChunk.isPresent() ||
!"chunked".equals(fChunk.get())) {
if (resp.version() == Version.HTTP_2) {
InputStream in = resp.body();
if (in.available() <= 0) {
try (in) {
return null;
}
}
} else {
try (InputStream in = resp.body()) {
return null;
}
}
}
}
return new HttpClientFilteredInputStream(resp.body());
}
@Override
protected void closeInputStream() throws IOException {
getInputStream().close();
}
{code}
We encountered this issue with SOAP WS POST requests that return status 204.
A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced with
4.0.1.
The fix looks (too?) easy:
{code:java}
@Override
protected void closeInputStream() throws IOException {
InputStream is = getInputStream();
if (is != null) {
is.close();
}
}{code}
I will gladly create a PR for this, but maybe someone else can double-check if
this is really as simple as it looks like :)
Version 4.0.1 was released in May 2023, and it looks unlikely to me that no-one
else stumbled upon this problem until now.
was:
The package private class {{HttpClientWrappedOutputStream }}in
{{org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods
_getInputStream()_ and {_}closeInputStream(){_}.
There are several paths where _getInputStream()_ returns null. This will then
lead to a *NullPointerException* in _closeInputStream()_ because there is no
null check.
{code:java}
@Override
protected InputStream getInputStream() throws IOException {
HttpResponse<InputStream> resp = getResponse();
String method = (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
int sc = resp.statusCode();
if ("HEAD".equals(method)) {
try (InputStream in = resp.body()) {
return null;
}
}
if (sc == 204) {
//no content
return null;
}
if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
Optional<String> f =
resp.headers().firstValue("content-length");
Optional<String> fChunk =
resp.headers().firstValue("transfer-encoding");
if (f.isPresent()) {
long l = Long.parseLong(f.get());
if (l == 0) {
try (InputStream in = resp.body()) {
return null;
}
}
} else if (!fChunk.isPresent() ||
!"chunked".equals(fChunk.get())) {
if (resp.version() == Version.HTTP_2) {
InputStream in = resp.body();
if (in.available() <= 0) {
try (in) {
return null;
}
}
} else {
try (InputStream in = resp.body()) {
return null;
}
}
}
}
return new HttpClientFilteredInputStream(resp.body());
}
@Override
protected void closeInputStream() throws IOException {
getInputStream().close();
}
{code}
We encountered this issue with SOAP WS POST requests that return status 204.
A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced with
4.0.1.
The fix looks (too?) easy:
{code:java}
@Override
protected void closeInputStream() throws IOException {
InputStream is = getInputStream();
if (is != null) {
is.close();
}
}{code}
I will gladly create a PR for this, but maybe someone else can double-check if
this is really as simple as it looks like :)
Version 4.0.1 was released in May 2023, and it looks unlikely to me that no-one
else stumbled upon this problem until now.
> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in
> closeInputStream()
> ------------------------------------------------------------------------------------
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 4.0.1, 4.0.2, 4.0.3
> Reporter: Thomas Egli
> Priority: Major
>
> The package private class {{HttpClientWrappedOutputStream in
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then
> lead to a *NullPointerException* in _closeInputStream()_ because there is no
> null check.
> {code:java}
> @Override
> protected InputStream getInputStream() throws IOException {
> HttpResponse<InputStream> resp = getResponse();
> String method =
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
> int sc = resp.statusCode();
> if ("HEAD".equals(method)) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> if (sc == 204) {
> //no content
> return null;
> }
> if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
> Optional<String> f =
> resp.headers().firstValue("content-length");
> Optional<String> fChunk =
> resp.headers().firstValue("transfer-encoding");
> if (f.isPresent()) {
> long l = Long.parseLong(f.get());
> if (l == 0) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> } else if (!fChunk.isPresent() ||
> !"chunked".equals(fChunk.get())) {
> if (resp.version() == Version.HTTP_2) {
> InputStream in = resp.body();
> if (in.available() <= 0) {
> try (in) {
> return null;
> }
> }
> } else {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> }
> }
> return new HttpClientFilteredInputStream(resp.body());
> }
> @Override
> protected void closeInputStream() throws IOException {
> getInputStream().close();
> }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced
> with 4.0.1.
>
> The fix looks (too?) easy:
> {code:java}
> @Override
> protected void closeInputStream() throws IOException {
> InputStream is = getInputStream();
> if (is != null) {
> is.close();
> }
> }{code}
>
> I will gladly create a PR for this, but maybe someone else can double-check
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that
> no-one else stumbled upon this problem until now.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
