[
https://issues.apache.org/jira/browse/HTTPCLIENT-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280711#comment-15280711
]
Philippe Mouawad edited comment on HTTPCLIENT-1742 at 5/11/16 8:05 PM:
-----------------------------------------------------------------------
Hi [~olegk], [[email protected]],
The issue is indeed due to this line of code in JMeter:
((AbstractHttpClient) httpClient).addResponseInterceptor(new
org.apache.http.client.protocol.ResponseContentEncoding());
What happens is what Rainer described:
ResponseContentEncoding removes the 3 headers related to compression
(Content-Encoding, Content-Length, Content-MD5) then keeplive is called , as
the Content-Length is no more there, we end up not keeping alive the connection.
It didn't happen in JMeter 2.13, because previous version of HttpClient did not
touch these 3 headers.
It happens now in JMeter 3.0 as we rely on HC 4.5.2 which does.
There is no bug in HttpClient as JMeter is using DefaultRequestDirector which
is deprecated .
The processing in @olegk sample is very different, it uses MainClientExec which
first manages keepalive and only after that manages the response.
was (Author: pmouawad):
Hi [~olegk], [[email protected]],
The issue is indeed due to this line of code in JMeter:
((AbstractHttpClient) httpClient).addResponseInterceptor(new
org.apache.http.client.protocol.ResponseContentEncoding());
What happens is what Rainer described:
ResponseContentEncoding removes the 3 headers related to compression
(Content-Encoding, Content-Length, Content-MD5) then keeplive is called , as
the Content-Length is no more there, we end up not keeping alive the connection.
It didn't happen in JMeter 2.13, because previous version of HttpClient did not
touch these 3 headers.
It happens now in JMeter 3.0 as we rely on HC 4.5.2 which does.
I am investigating on why this does not happen with your sample.
> No connection reuse if response is compressed
> ---------------------------------------------
>
> Key: HTTPCLIENT-1742
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1742
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.5.2
> Environment: Linux, Java 8
> Reporter: Rainer Jung
>
> Trying current JMeter trunk I ran into a problem, that connections were not
> being reused. Debugging into it revealed IMHO a HttpClient/HttpCore problem.
> Below you'll find a wire dump of the response headers:
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "HTTP/1.1 200
> OK[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Date: Tue, 10 May 2016
> 20:44:15 GMT[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Server: Apache[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Pragma:
> no-cache[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Cache-Control:
> no-cache, no-store, must-revalidate[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Expires: 0[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Pragma:
> no-cache[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Cache-Control:
> no-cache, no-store, must-revalidate[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Expires: 0[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Pragma:
> no-cache[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Cache-Control:
> no-cache, no-store, must-revalidate[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Expires: 0[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Vary:
> Accept-Encoding[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Content-Encoding:
> gzip[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: <<
> "X-Content-Type-Options: nosniff[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "X-Frame-Options:
> sameorigin[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Content-Length:
> 1194[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Keep-Alive:
> timeout=60, max=9999[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Connection:
> Keep-Alive[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Content-Type:
> text/html;charset=utf-8[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "[\r][\n]"
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << HTTP/1.1 200 OK
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Date: Tue, 10 May
> 2016 20:44:15 GMT
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Server: Apache
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Pragma: no-cache
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Cache-Control:
> no-cache, no-store, must-revalidate
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Expires: 0
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Pragma: no-cache
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Cache-Control:
> no-cache, no-store, must-revalidate
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Expires: 0
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Pragma: no-cache
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Cache-Control:
> no-cache, no-store, must-revalidate
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Expires: 0
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Vary: Accept-Encoding
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Content-Encoding: gzip
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: <<
> X-Content-Type-Options: nosniff
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << X-Frame-Options:
> sameorigin
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Content-Length: 1194
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Keep-Alive:
> timeout=60, max=9999
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Connection: Keep-Alive
> 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Content-Type:
> text/html;charset=utf-8
> As you can see, the response contains a Content-Length header, is not chunked
> but is gzip compressed. The server sets a Connection header keep-alive and
> sends keep-alive values that would let the connection be reused. But instead
> DefaultConnectionReuseStrategy.keepAlive() returns false, because in the code
> block
> if (canResponseHaveBody(response)) {
> final Header[] clhs = response.getHeaders(HTTP.CONTENT_LEN);
> // Do not reuse if not properly content-length delimited
> if (clhs.length == 1) {
> the value of clhs.length is 0. So although the wire dump shows a
> content-length header, and the request is not chunked, somewhere the
> content-length header is being removed.
> As soon as I remove the "Accept-Encoding: gzip, deflate" request header,
> connections get reused and the content-length header no longer gets removed.
> I expect the class ResponseContentEncoding to be responsible: it removes the
> header via
> response.removeHeaders("Content-Length");
> in line 141.
> Regards,
> Rainer
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
