[ https://issues.apache.org/jira/browse/HTTPCORE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski moved HTTPCLIENT-1639 to HTTPCORE-397: -------------------------------------------------------- Component/s: (was: HttpClient) HttpCore Affects Version/s: (was: 4.4 Final) 4.4.1 Workflow: classic default workflow (was: Default workflow, editable Closed status) Key: HTTPCORE-397 (was: HTTPCLIENT-1639) Project: HttpComponents HttpCore (was: HttpComponents HttpClient) > HttpClient 4.4.1 may perform multiple requests on the same connection despite > having "Connection: close" header. > ---------------------------------------------------------------------------------------------------------------- > > Key: HTTPCORE-397 > URL: https://issues.apache.org/jira/browse/HTTPCORE-397 > Project: HttpComponents HttpCore > Issue Type: Bug > Components: HttpCore > Affects Versions: 4.4.1 > Reporter: Alan Silva > Fix For: 5.0-alpha1 > > > 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: > {code} > 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. > {code} > However, on the client side, the rules on the matter are stricter. > {code} > 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. > {code} > 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 -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org