https://bz.apache.org/bugzilla/show_bug.cgi?id=57921
--- Comment #9 from Rainer Jung <[email protected]> --- The test case and the capture belong to different client server communications. Furthermore I couldn't reproduce with the test case, because at the time I tried the server seemed to use a much longer keep-alive timeout than the 60 seconds assumed in the test case (I observed 4 minutes timeout). Using the server from the original packet dump and increasing the timer sleep to 5 minutes, I could reproduce. In this case the server uses HTTP/1.1 but does *not* send a Connection header in the reponse. The request contains one, but not the response. Looking at the HttpClient code this situation means, that the default reuse strategy decides to reuse the connection (since it is HTTTP/1.1) and asks the keep alive strategy for how long. The default keep alive strategy when called without a Connection header will return the value "-1" which will disable the keep alive. But our own IDLE_STRATEGY will overwrite any value <=0 with the value 0 by default. Value 0 for HttpClient does not mean 0 seconds, but infinite keep-alive. So IMHO IDLE_STRATEGY needs fixing for the default case (value 0 for "httpclient4.idletimeout). I'm running out of time right now, but will come back to this if noone beats me to it. The likely fix is something like @@ -145,7 +145,7 @@ @Override public long getKeepAliveDuration(HttpResponse response, HttpContext context) { long duration = super.getKeepAliveDuration(response, context); - if (duration <= 0) {// none found by the superclass + if (duration <= 0 && IDLE_TIMEOUT > 0) {// none found by the superclass log.debug("Setting keepalive to " + IDLE_TIMEOUT); return IDLE_TIMEOUT; } -- You are receiving this mail because: You are the assignee for the bug.
