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