hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCORE-397) HttpClient 4.4.1 may perform multiple requests on the same connection despite having "Connection: close" header.
Date Tue, 14 Apr 2015 02:06:12 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493449#comment-14493449

Shawn Heisey commented on HTTPCORE-397:

bq. All types of redirects are affected

As far as I know, Solr should never do any kind of redirect (302 or otherwise), at least if
you access it directly and not through a proxy.

I can't tell from what you just said whether I need to be worried about this defect for Solr.
 HttpSolrClient is used in SolrJ (the client), and SolrJ is used internally for distributed
query support.  All of our tests do pass, and distributed SolrCloud queries are well-pounded
by the test suites.

Will there be a 4.4.2 that includes this fix?

> 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
>            Priority: Minor
>             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
> This issue was not observed in HttpClient 4.2.6

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