Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0

2016-05-01 Thread Oleg Kalnichevski 
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=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

2016-05-01 Thread Philippe Mouawad 
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=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

2016-05-01 Thread Oleg Kalnichevski 
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=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

2016-05-01 Thread Philippe Mouawad 
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=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

2016-05-01 Thread Oleg Kalnichevski 
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

2016-05-01 Thread Oleg Kalnichevski 
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

2016-05-01 Thread Philippe Mouawad 
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.