Hi Oleg, Thank you. I did think I subscribed but the first attempt gave me an error. Thought the second worked but honestly been a few years since I have used these things.
Thanks for the link. Understood. My intuition aligns a bit with Stephane here honestly but I appreciate you are supporting a lot of users with many different requirements. I’ll reach out to the http4k guys on it because I guess they have the same issue as Spring here. Thanks for your help, and all the hard OSS work. It is not appreciated enough by the industry (and I should be doing more of it). Wes Sent from my iPhone > On 24 Jan 2026, at 08:58, Oleg Kalnichevski <[email protected]> wrote: > > On Sat, 2026-01-24 at 00:44 +0000, Wesley Hall wrote: >> Hi folks, >> >> I didn’t really know where to address this. Apologies in advance if >> this is the wrong place, it feels as good a place as any to start. >> >> In my day job, we recently experienced a bug that was caused by >> picking up an update to the Apache http client that includes the >> behaviour of automatically gunzipping response bodies received with a >> Content-Encoding: gzip response header. >> >> The problem was, we already had a client wrapper to do this further >> up our stack. Gunzip functions are not, as it turns out, a fan of >> already unzipped data :). >> >> We fixed the problem but it lead to an interesting debate. Should the >> http-client *remove* the Content-Encoding header when it mutates the >> body by unzipping it? Our problem was that the filter sees this >> header, expects the body to be gzipped data, but it is not. There are >> byte prefixes in the data for gzip so we can check but it does feel >> that the header is now inconsistent. If a gzipping filter would gzip >> the body and add the header, should not the decompression routine do >> the full inverse? >> >> The counter of course is that clients may need to see the full set of >> original response headers. >> >> I didn’t want to go charging in creating issues and things because I >> am aware that there may well be a long standing philosophy on this >> stuff, or some tremendously important thing that I am missing, so it >> seemed worth asking here first. >> >> Did I do a good thing? >> >> Thanks >> >> Wes > > Hi Wes > > The issue has been discussed here > > https://issues.apache.org/jira/browse/HTTPCLIENT-2409 > > In summary, one should be using attributes of HttpEntity when consuming > response messages. Those attributes always correctly reflect the > properties of the message content in case of its automatic > transformation. > > ``` > HttpEntity#getContentLength > HttpEntity#getContentType > HttpRntity#getContentEncoding > ``` > HttpClient's tampering with the original response prior to version 5.6 > was a mistake. > > Oleg > > PS: Always subscribe to the mailing list before posting. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
