Details
-
Bug
-
Status: Resolved
-
Critical
-
Resolution: Fixed
-
5.0.1
-
None
Description
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
if (TimeValue.isPositive(connectTimeout) && sock.getSoTimeout() == 0) {
sock.setSoTimeout(connectTimeout.toMillisecondsIntBound());
}
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!
