Matthias Keller created HTTPCLIENT-2102:
-------------------------------------------
Summary: Socks Proxy connection ignores sotimeout (thus never
times out)
Key: HTTPCLIENT-2102
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2102
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient (classic)
Affects Versions: 4.5.12
Reporter: Matthias Keller
This bug report is related to HTTPCLIENT-1478 and HTTPCLIENT-2091 though a
different bug again.
We've discovered that for socks proxy connections, there is no SO-Timeout
defined when opening the connection.
Thus if the proxy accepts the request but never responds, the thread is
blocked infititely. This does not happen for http proxies or without proxy;
thus is a socks-specific bug.
The code flow is as follows:
# We have all the official timeouts set:
{code:java}
requestConfigBuilder
.setConnectTimeout(timeoutInMillis)
.setSocketTimeout(timeoutInMillis)
.setConnectionRequestTimeout(timeoutInMillis) {code}
# {{org.apache.http.impl.conn.DefaultHttpClientConnectionOperator#connect}}
opens the connection
# For the socket config, it calls
{{org.apache.http.impl.conn.PoolingHttpClientConnectionManager#resolveSocketConfig}}
to get the parameters. However since we don't override the default connection
manager, its socket config is the {{DEFAULT}} config, having a timeout=0
# This infinite timeout is set via {{java.net.Socket#setSoTimeout}} on the
socket.
This can easily be reproduced by configuring a socks proxy (thus target URI
must be https and a proxy configured) and using a localhost port as proxy where
a netcat listens. By just letting it sit there, receive the request but never
respond, the calling thread is blocked infinitely.
The problem here is, that the connectTimeout is set correctly, but the read
timeout (so timeout) is zero (infinite).
The bug can be circumvented by specifying a custom
PoolingHttpClientConnectionManager and setting a defaultSocketConfig on it.
However, httpclient should honor the requestconfig parameters here.
For reference, here's a stacktrace exhibiting this problem on the blocking
thread:
!image-2020-07-30-18-33-01-762.png|id=cp-img!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
