You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Ryan Schmitt (Jira)" <ji...@apache.org> on 2021/09/13 21:49:00 UTC
[jira] [Comment Edited] (HTTPCLIENT-2135) TLS handshake timeouts
cannot be controlled through RequestConfig
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414602#comment-17414602 ]
Ryan Schmitt edited comment on HTTPCLIENT-2135 at 9/13/21, 9:48 PM:
--------------------------------------------------------------------
[~olegk] The intention is to fall back on the {{connectTimeout}} when the {{handshakeTimeout}} is not specified, right? This fallback logic appears to work for the classic client, but not the async client. The async client seems to wait forever for the handshake to finish.
Meanwhile, on the classic client, I noticed that this connection timeout is being reported as a socket timeout, which then confuses our error handling (we report the error as a regular HTTP timeout, not as a connection timeout).
{code:java}
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:607)
at org.apache.hc.client5.http.socket.PlainConnectionSocketFactory.lambda$connectSocket$0(PlainConnectionSocketFactory.java:85)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.hc.client5.http.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:84)
at org.apache.hc.client5.http.impl.io.MultihomeSocketConnector.connect(MultihomeSocketConnector.java:70)
at org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:131)
at org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:418)
at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:159)
at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:169)
at org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:136)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:166)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:96)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:179)
at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:75)
{code}
I haven't had a chance yet to dig in to either of these issues and figure out exactly what is causing them. I also haven't had a chance to migrate to the new {{handshakeTimeout}} and connection-layer configuration and see how it works.
was (Author: rschmitt):
[~olegk] The intention is to fall back on the {{connectTimeout}} when the {{handshakeTimeout}} is not specified, right? This fallback logic appears to work for the classic client, but not the async client.
Meanwhile, on the classic client, I noticed that this connection timeout is being reported as a socket timeout, which then confuses our error handling (we report the error as a regular HTTP timeout, not as a connection timeout).
{code}
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:607)
at org.apache.hc.client5.http.socket.PlainConnectionSocketFactory.lambda$connectSocket$0(PlainConnectionSocketFactory.java:85)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.hc.client5.http.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:84)
at org.apache.hc.client5.http.impl.io.MultihomeSocketConnector.connect(MultihomeSocketConnector.java:70)
at org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:131)
at org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:418)
at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:159)
at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:169)
at org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:136)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:166)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:96)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:179)
at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:75)
{code}
I haven't had a chance yet to dig in to either of these issues and figure out exactly what is causing them. I also haven't had a chance to migrate to the new {{handshakeTimeout}} and connection-layer configuration and see how it works.
> TLS handshake timeouts cannot be controlled through RequestConfig
> -----------------------------------------------------------------
>
> Key: HTTPCLIENT-2135
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2135
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.0.3
> Reporter: Ryan Schmitt
> Priority: Major
> Fix For: 5.2-alpha1
>
>
> Apparently as a consequence of HTTPCLIENT-2091 and/or HTTPCLIENT-2099, TLS handshake timeouts can no longer be specified through any of the three {{RequestConfig}} timeout parameters (connect, connection request, response). The only way to limit TLS handshake duration is through low-level socket configuration (socket timeout), which of course affects more than just TLS handshakes.
--
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