You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Philippe Mouawad <ph...@gmail.com> on 2016/05/01 16:08:37 UTC
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<Header> 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.
Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <olegk@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-unsubscribe@hc.apache.org
> > <javascript:;>
> > > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > <javascript:;>
> > > >
> > > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > <javascript:;>
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > <javascript:;>
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <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 <olegk@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-unsubscribe@hc.apache.org
> <javascript:;>
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> <javascript:;>
> > >
> > >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> <javascript:;>
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> <javascript:;>
>
>
--
Cordialement.
Philippe Mouawad.
Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
Posted by Oleg Kalnichevski <ol...@apache.org>.
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> 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-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <ol...@apache.org> 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-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
--
Cordialement.
Philippe Mouawad.
Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org