Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
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 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 > > 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 > > > > > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > > > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > > - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
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 Regards On Sunday, May 1, 2016, Oleg Kalnichevski 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 > 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 > > > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > > > > > > > > > > - > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > -- Cordialement. Philippe Mouawad.
Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
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 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 > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
Hi Oleg, I understand, but in our particular case users want to have information about original response headers. 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 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 > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
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 For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Question about ThreadSafeClientConnManager change maxTotal on fly
On Fri, 2016-04-29 at 14:51 +0200, NGUYEN-VIET Quang wrote: > Hello, > > We use httpclient 4.1. ( we plan to upgrade soon) > > Juste a simple question about how connection pool behave when we change > maxTotal on fly, without releasing connetions in use. ( with > releaseConnection() for instance ) > > If i increase the maxTotal size, I guess that it's not a problem, it simply > allocate more possible connection in pool. > > But how about when we decrease the pool's size and all connexions are > pending or occupied, do they become some kind of zombi connection and we > lost control on these connections. > No, they are not. Those connections will still be kept in the pool and re-used until they expire. The connection manager however is not going to allocate new connections until the total number of connections becomes less or equal to maxTotal. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
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 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 ? What are our options to fix it ? 1/ Register a ResponseInterceptor before it that extracts headers ? 2/ Override process method and do this: private static final HttpResponseInterceptor RESPONSE_CONTENT_ENCODING = new ResponseContentEncoding() { @Override public void process( final HttpResponse response, final HttpContext context) throws HttpException, IOException { List headersToRestore = new ArrayList<>(3); headersToRestore.addAll(Arrays.asList(response.getHeaders("Content-Length"))); headersToRestore.addAll(Arrays.asList(response.getHeaders("Content-Encoding"))); headersToRestore.addAll(Arrays.asList(response.getHeaders("Content-MD5"))); super.process(response, context); for (Header headerToRestore : headersToRestore) { response.addHeader(headerToRestore); } } }; 3/ Submit a patch to make this removal optional ? But this would delay a lot our Release which was in RC3. Thanks in advance for your help Regards Philippe M. -- Cordialement. Philippe Mouawad.