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: [email protected]
For additional commands, e-mail: [email protected]
