Szczepanski Dominik created HTTPCLIENT-2426:
-----------------------------------------------
Summary: NullPointerException in InflatingGzipDataConsumer kills
I/O reactor when following redirects with Content-Encoding: gzip
Key: HTTPCLIENT-2426
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2426
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient (async)
Affects Versions: 5.6.1
Reporter: Szczepanski Dominik
## How to reproduce
Make an async HTTP/1.1 request to an endpoint that responds with a 302 redirect
where the intermediate response includes `Content-Encoding: gzip`. The I/O
reactor thread dies with:
```
java.lang.NullPointerException
at
org.apache.hc.client5.http.async.methods.InflatingGzipDataConsumer.streamEnd(InflatingGzipDataConsumer.java:148)
at
org.apache.hc.client5.http.impl.async.HttpAsyncMainClientExec$1.failed(...)
...
at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
```
## Why it fails
When `AsyncRedirectExec` detects a redirect it returns `null` from
`handleResponse()` - which I think is intentional with the meaning "discard
this response body". The problem is that `ContentCompressionAsyncExec` passes
the null downstream straight into `InflatingGzipDataConsumer`:
```java
AsyncDataConsumer downstream = cb.handleResponse(rsp,
wrapEntityDetails(details));
for (int i = codecs.size() - 1; i >= 0; i--) {
final String codec = codecs.get(i);
final UnaryOperator<AsyncDataConsumer> op = decoders.lookup(codec);
if (op != null) {
downstream = op.apply(downstream);
} else {
throw new HttpException("Unsupported Content-Encoding: " + codec);
}
}
```
So when the redirect response has `Content-Encoding: gzip`,
`InflatingGzipDataConsumer` gets instantiated with `null` as `downstream`. The
class has no null checks, so once the body is drained and `streamEnd()` or
`releaseResources()` is called it NPEs.
## Fix
Add null guards on `downstream` in `updateCapacity()`, `consume()`,
`streamEnd()`, and `releaseResources()`. When `downstream` is null the body is
being discarded anyway, so skipping the delegation is the right behaviour.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
