Hello sebb, On Mon, May 2, 2016 at 3:09 PM, sebb <[email protected]> wrote:
> 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. > Yes, Absolutely true regular users of the API. But in the particular case of JMeter, can this happen ? In the particular case of JMeter, users usually want to: - Check that server response was Compressed or not (ie what were the original headers) and the size of the original response (headers + body compressed if applies) - They also want usually to check some data in the response through Assertion, which means it needs to be uncompressed Usually also, users will compare headers in the browser with headers in JMeter to see if they match, and it will be suspicious if they don't. I am afraid a lot of plan and users expect these headers to be here (but maybe we can ask on user mailing list and twitter) > > 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. > Yes option might be interesting although it is then hard to know if received response is OK or a 404 page masked under a 200 response code or similar cases. > However the response would not be viewable in the Tree View Listener. > -- Regards Ubik Load Pack <http://ubikloadpack.com> Team Follow us on Twitter <http://twitter.com/ubikloadpack> Cordialement L'équipe Ubik Load Pack <http://ubikloadpack.com> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
