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]
