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.

    XMLWordPrintableJSON

    Details

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

      Description

      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
         connection.
      

      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

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: