On Tue, 2026-06-23 at 22:08 -0400, Ryan Tate wrote: > Some behavior in CachingHttpAsyncClientBuilder surprised me and > I'm curious if it is by design. >
Hi Ryan No, it is not. Truth to be told, async client + transparent decompression + caching combo has not been tested. If you see anything that looks wrong or funny do raise a JIRA ticket for it, or better yet, raise a pull request with a proposed fix. > A client built with CachingHttpAsyncClients.custom (which > delegates to CachingHttpAsyncClientBuilder.create) receives some > responses that have been transparently decompressed (from gzip > etc) and some that are still compressed. The deciding factor is if > the response touched the cache. So for example a response that > exceeds maxObjectSize will be transparently decompressed, whereas > one that falls below will come back with gzipped bytes (or > deflated bytes). > > My naive read is this is due to HTTPCLIENT-1822 being specific to > HttpAsyncClient(Builder) so when things fall through the caching > layer they end up their. Going further out on a speculative limb, > I deduce that maybe the caching async stuff was not integrated yet > with this transparent compression work? > > (If so, are you open to patches and do you have any clue where one > should start (the caching seems to work partly via response > interceptors vs compression which seems entirley done via the exec > chain, which seems to be request oriented)) > We are very much open to patches, especially if they come with unit tests. Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
