[
https://issues.apache.org/jira/browse/HTTPCLIENT-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155995#comment-17155995
]
Carter Kozak commented on HTTPCLIENT-2099:
------------------------------------------
Hi [~olegk], I'm less concerned about default values, in my case they're always
overridden based on another configuration. The problem is when the
configuration sets an unlimited socket timeout and a bounded connect timeout,
the connect timeout is unexpectedly used instead of the socket timeout for the
life of the connection.
I never actually set the RequestConfig.responseTimeout because it wasn't clear
that it would simply be used as a socket timeout for the duration of the
request, I assumed it would only be set after the request bytes had been fully
sent, and reverted once the response line was received. Instead, it appears
that the value updates the socket timeout before sending the request, and is
removed once the request has completed and the connection is passivated. I'd be
happy to update the javadoc to describe this case.
> 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]
