> Please raise a JIRA if you think there is a defect.
I think the behavior is arbitrary. There's no way tell what the hostname
verification policy should be, based solely on the presence of a
non-default `HostnameVerifier`, because there's no way of knowing whether
the supplied verifier is stricter than the built-in one (in which case BOTH
is a good default) or more permissive (in which case CLIENT is the right
behavior).
Anyway, I found some actual problems. The first is that we have two Brotli
dependencies, one of which is marked as optional and one which is not:
<dependency>
<groupId>org.brotli</groupId>
<artifactId>dec</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.aayushatharva.brotli4j</groupId>
<artifactId>brotli4j</artifactId>
</dependency>
Can we take this opportunity to get rid of BrotliInputStreamFactory and
drop the dependency on org.brotli:dec? It hasn't had a release since 2017.
The other issue is that our commons-compress dependency is marked as
optional, but we import its classes as if it weren't:
httpclient5/src/main/java/org/apache/hc/client5/http/entity/compress/CommonsCompressingEntity.java
35:import org.apache.commons.compress.compressors.CompressorException;
36:import
org.apache.commons.compress.compressors.CompressorStreamFactory;
httpclient5/src/main/java/org/apache/hc/client5/http/entity/compress/CommonsCompressDecoderFactory.java
37:import org.apache.commons.compress.compressors.CompressorException;
38:import
org.apache.commons.compress.compressors.CompressorStreamFactory;
This results in ContentCodecRegistry throwing
an ExceptionInInitializerError at runtime. The issue here seems to be the
`catch` clause on `CompressorException`. We should probably just dial that
up to `IOException`.
On Sat, Oct 11, 2025 at 11:47 AM Oleg Kalnichevski <[email protected]> wrote:
>
>
> On 10/11/2025 4:32 AM, Ryan Schmitt wrote:
> > I ran our internal integration test suite against the current core+client
> > commits. I didn't find much, just two notes:
> >
> > 1. The async client has started decompressing responses. I had to add a
> > call to `.disableContentCompression()`. This API is new in 5.6. This may
> be
> > an issue for libraries that use the async client, since it makes it
> harder
> > to "straddle" multiple versions of the client and obtain consistent
> > behavior from all of them.
>
> This is a new feature in a feature release. Feature releases can have
> behavioral differences with earlier versions. There is going to be a
> note in the release notes regarding this change.
>
> > 2. Our tests for insecure mode SSL (self-signed certs, obsolete TLS
> > versions, etc) started failing. I had to fix this by adding a
> > `HostnameVerificationPolicy.CLIENT` argument to the
> > `DefaultClientTlsStrategy` constructor call, in addition to the custom
> > `HostnameVerifier` I am already supplying. I think this must have been
> > caused by a constructor delegation change in `DefaultClientTlsStrategy`,
> > where the default policy was changed from `CLIENT` to `null` (which later
> > gets turned into `BOTH`).
> >
>
> Please raise a JIRA if you think there is a defect.
>
> Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
