I’ll take a look on this later today
Arturo On Sun, 12 Oct 2025 at 12:07 AM, Ryan Schmitt <[email protected]> wrote: > > 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] > > > > >
