[
https://issues.apache.org/jira/browse/HTTPCLIENT-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156027#comment-17156027
]
ASF subversion and git services commented on HTTPCLIENT-2099:
-------------------------------------------------------------
Commit 5bdcb242f0297c9dca8f6284ed5a4dd062a210b7 in httpcomponents-client's
branch refs/heads/5.1.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=5bdcb24 ]
HTTPCLIENT-2099, HTTPCLIENT-2091: SSLConnectionSocketFactory connect timeout
fix (#241)
SSLConnectionSocketFactory no longer overrides the socket timeout
with the connect timeout when an unlimited socket timeout is
configured. This matches behavior of HTTPCLIENT-2091.
Note that in scenarios where SocketConfig sets an infinite timeout
and the RequestConfig sets a bounded timeout, this change results
in the connect-timeout no longer applying to the TLS handshake.
This behavior can be retained by setting the expected timeout in
the SocketConfig.
> unlimited socket timeout results in the connect timeout being used as a
> socket timeout
> --------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2099
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2099
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.0.1
> Reporter: Carter Kozak
> Priority: Critical
> Fix For: 5.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Problem:
> When setting an unlimited socket timeout (not a very good idea in most cases,
> I can't defend the practice) requests time out after a few moments, which
> turned out to exactly match the connect timeout.
> Tested using 5.0.1 classic client for both http and https requests.
> The problem appears to stem from
> [https://github.com/apache/httpcomponents-client/blob/986686535750a6a665a206ba0cc892d8fb24bbec/httpclient5/src/main/java/org/apache/hc/client5/http/ssl/SSLConnectionSocketFactory.java#L210-L212]
> {code:java}
> if (TimeValue.isPositive(connectTimeout) && sock.getSoTimeout() == 0) {
> sock.setSoTimeout(connectTimeout.toMillisecondsIntBound());
> }
> {code}
> I can understand setting the connect timeout as a socket timeout for some
> period of time setting up the connection, perhaps until the handshake
> completes, unfortunately when the connect timeout is set, it's never reverted.
> The solutions I can imagine, I think the difference boils down to whether or
> not we want the connect timeout to apply to tls handshakes.
> 1. Remove the highlighted conditional entirely, leaving connect timeout only
> used as an argument to Socket.connect. This would not cover tls handshakes
> with the connect timeout.
> 2. Update to use the configured connect timeout regardless of the current
> socket timeout, and set the socket timeout again once a connection has been
> established. This would apply the configured connect timeout to handshakes.
> Which option would you prefer, perhaps a third option I haven't considered?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
