hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Silva (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HTTPCLIENT-1639) HttpClient 4.4.1 may perform multiple requests on the same connection despite having "Connection: close" header.
Date Fri, 10 Apr 2015 20:27:13 GMT
Alan Silva created HTTPCLIENT-1639:

             Summary: HttpClient 4.4.1 may perform multiple requests on the same connection
despite having "Connection: close" header.
                 Key: HTTPCLIENT-1639
                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1639
             Project: HttpComponents HttpClient
          Issue Type: Bug
          Components: HttpClient
    Affects Versions: 4.4 Final
            Reporter: Alan Silva

Question originally posted in Stack Overflow [here|http://stackoverflow.com/questions/29523143/apache-httpclient-4-x-302-redirects-with-keepalive-off].
Answered by [~olegk]. 

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

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message