You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Matthias Keller (Jira)" <ji...@apache.org> on 2020/07/31 11:39:00 UTC
[jira] [Updated] (HTTPCLIENT-2102) Socks Proxy connection ignores
sotimeout (thus never times out)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthias Keller updated HTTPCLIENT-2102:
----------------------------------------
Description:
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!
was:
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!
> 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
> Priority: Major
> Attachments: image-2020-07-30-18-33-01-762.png
>
>
> 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!
--
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