Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Sat, 11 Apr 2015 10:03:12 +0000 (UTC)
From: "Oleg Kalnichevski (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12820185.1428697584000.62841.1428746592492@Atlassian.JIRA>
In-Reply-To: <JIRA.12820185.1428697584000@Atlassian.JIRA>
References: <JIRA.12820185.1428697584000@Atlassian.JIRA>
 <JIRA.12820185.1428697584560@arcas>
Subject: [jira] [Moved] (HTTPCORE-397) HttpClient 4.4.1 may perform multiple
 requests on the same connection despite having "Connection: close" header.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org