[
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: [email protected]
For additional commands, e-mail: [email protected]
