[
https://issues.apache.org/jira/browse/HTTPCLIENT-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Silva updated HTTPCLIENT-1639:
-----------------------------------
Description:
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
was:
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.
> 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:
> {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]
