You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (Jira)" <ji...@apache.org> on 2020/07/11 13:35:00 UTC
[jira] [Commented] (HTTPCLIENT-2099) unlimited socket timeout
results in the connect timeout being used as a socket timeout
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155986#comment-17155986 ]
Oleg Kalnichevski commented on HTTPCLIENT-2099:
-----------------------------------------------
[~ckozak] This is another example that no matter how hard I try I cannot make everyone happy.
As of next release HttpCore 5.x will use a finite socket timeout by default (see HTTPCLIENT-2091), so this logic will no longer be necessary or useful. Let's remove it in 5.1
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org