Regression in 3.0 / Bug 59401 - is it really a bug?

[sebb <se...@gmail.com>]

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.

Re: Regression in 3.0 / Bug 59401 - is it really a bug?

[UBIK LOAD PACK Support <su...@ubikloadpack.com>]

Hello sebb,

On Mon, May 2, 2016 at 3:09 PM, sebb <se...@gmail.com> 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>