You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (Jira)" <ji...@apache.org> on 2020/07/31 16:33:00 UTC

[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17168990#comment-17168990 ] 

Oleg Kalnichevski commented on HTTPCLIENT-2102:
-----------------------------------------------

[~tapter] 
 # HttpClient 4.5 does _not_ support SOCKS _at all_. SOCKS support has been introduced in HttpClient 5.0 but is still considered experimental.
 # {{RequestConfig}} parameters apply to request execution. They do _not_ apply to connection routing or connection management.
 # Please use {{SocketConfig}} for connection socket configuration.

Oleg

> 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