On Sun, 2016-05-01 at 17:41 +0200, Philippe Mouawad wrote: > Hi, > Because during load testing you want: > - to simulate browser behaviour, in a lot of case compression will be > enabled > - user will want to check server returns compressed response and also have > information about response sizes compressed which is the real traffic > taking place > - but then user will want to check data in the responses using assertion, > to do that we need responses to be uncompressed >
Right. There is nothing that should stop one from disabling automatic content decompression (and thus response message modification) and manually decompressing response entity as appropriate. Oleg > Regards > > On Sunday, May 1, 2016, Oleg Kalnichevski <ol...@apache.org> wrote: > > > On Sun, 2016-05-01 at 17:22 +0200, Philippe Mouawad wrote: > > > Hi Oleg, > > > I understand, but in our particular case users want to have information > > > about original response headers. > > > > > > > Why do not just disable content decompression if it is not needed? > > > > Oleg > > > > > Does this way of implementing it look ok to you: > > > > > > - https://bz.apache.org/bugzilla/attachment.cgi?id=33817&action=diff > > > > > > Or can it break something in HttpClient ? > > > > > > Thanks > > > Regards > > > > > > On Sun, May 1, 2016 at 5:18 PM, Oleg Kalnichevski <ol...@apache.org > > <javascript:;>> wrote: > > > > > > > On Sun, 2016-05-01 at 16:08 +0200, Philippe Mouawad wrote: > > > > > Hello, > > > > > We have a regression report in JMeter 3.0 due to what seems to be a > > new > > > > > behaviour of HttpClient 4.5.2, introduced on Feb 25, 2014 by: > > > > > > > > > > - > > > > > > > > > > > https://github.com/apache/httpclient/commit/5d11a3e751fe0c02a7a4539d3436b06e0be35876#diff-c54e3439558bee75dd7e2953280a7e08 > > > > > > > > > > > > > > > As per following code: > > > > > > > > > > - > > > > > > https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/protocol/ResponseContentEncoding.java#L142 > > > > > > > > > > > > > > > When uncompressing HttpClient removes 3 headers: > > > > > - Content-Length > > > > > - Content-Encoding > > > > > - Content-MD5 > > > > > > > > > > > > > This behavior was introduced in 4.2 (4 years ago). See HTTPCLIENT-1164. > > > > https://issues.apache.org/jira/browse/HTTPCLIENT-1164 > > > > > > > > > So in JMeter 3.0, we lose these 3 headers compared to 2.13: > > > > > - https://bz.apache.org/bugzilla/show_bug.cgi?id=59401 > > > > > > > > > > Is there a reason for removing them ? > > > > > > > > > > > > > Automatic decompression invalidates these headers. Decompressed content > > > > stream no longer has the same length, encoding and MD5 checksum as > > > > declared in the original response message. > > > > > > > > Oleg > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > <javascript:;> > > > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > <javascript:;> > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > <javascript:;> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > <javascript:;> > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
