[
https://issues.apache.org/jira/browse/HTTPCLIENT-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156002#comment-17156002
]
Oleg Kalnichevski commented on HTTPCLIENT-2099:
-----------------------------------------------
[~ckozak] For the sake of consistency with HTTPCLIENT-2091 let's just remove
that conditional statement. I actually should have done it as a part of
HTTPCLIENT-2091.
Oleg
> 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
>
> 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]
