caching, async, and compression in a client

[Ryan Tate <ry...@ryantate.com>]

Some behavior in CachingHttpAsyncClientBuilder surprised me and 
I'm curious if it is by design.

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))

Thanks for any information.

R

PS Great client, thank you for it.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: caching, async, and compression in a client

[Oleg Kalnichevski <ol...@apache.org>]

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: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org