If a server response includes Content-Encoding, then HC can be asked to decode it. If HC does this, then it removes the headers that no longer apply. This is entirely correct. Otherwise, downstream consumers would see an inconsistent response.
In particular, if HC did not remove the Content-Encoding header, consumers could attempt to decode the response again. I think it is wrong to change JMeter to restore the original Content- headers. They are no longer applicable to the sample result. So either we reject the bug as invalid, or we find a different way of providing the original headers (e.g. as X-headers) It may also be worth providing an option to tell HC not to decompress the response. This would allow the true server response to be saved. It would reduce the JMeter client processing slightly. However the response would not be viewable in the Tree View Listener.
