[
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 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: [email protected]
For additional commands, e-mail: [email protected]
