Uploaded image for project: 'HttpComponents HttpCore'
  1. HttpComponents HttpCore
  2. HTTPCORE-397

HttpClient 4.4.1 may perform multiple requests on the same connection despite having "Connection: close" header.



    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 4.4.1
    • Fix Version/s: 5.0-alpha1
    • Component/s: HttpCore
    • Labels:


      Question originally posted in Stack Overflow here. Answered by Oleg Kalnichevski.

      The quick summary of the question and its resolution:

      My use case involved a request to a server whose response back was a 302 redirect using non-persistence on the connection.

      The current implementation of the HttpClient on version 4.4.1 GA will implicitly launch a follow-up request to the path specified in the "location" header path from the 302 response. The problem is, when the httpclient is sent with the "Connection: close" header, it is not aware of having done so. The result is that, if the server responds WITHOUT a corresponding "Connection: close", the client will assume the connection must be kept alive, and perform the next request for the redirect path on the same connection. This obviously leads to a problem since the server will have closed the socket on its end of the connection by now.

      The problem was ultimately fixed by forcing the server to send a "Connection: close" header in response to the HttpClient's "Connection:close". However, according to the HTTP 1.1 spec, the server is not obliged to do this, although, it should. http://tools.ietf.org/html/rfc2616#section-8:

      An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
         maintain a persistent connection unless a Connection header including
         the connection-token "close" was sent in the request. If the server
         chooses to close the connection immediately after sending the
         response, it SHOULD send a Connection header including the
         connection-token close.

      However, on the client side, the rules on the matter are stricter.

      Persistent connections provide a mechanism by which a client and a
         server can signal the close of a TCP connection. This signaling takes
         place using the Connection header field (section 14.10). Once a close
         has been signaled, the client MUST NOT send any more requests on that

      Ideally, there should be a way for the HttpClient to realize it has announced its intention to close the connection via the "Connection: close" header, and stop itself from sending any more requests on the connection, without outside intervention from the server it's communicating with.

      This issue was not observed in HttpClient 4.2.6


          Issue Links



              • Assignee:
                Alan Silva Alan Silva
              • Votes:
                0 Vote for this issue
                6 Start watching this issue


                • Created: