[jira] [Commented] (HTTPCLIENT-2102) Socks Proxy connection ignores sotimeout (thus never times out)

["Matthias Keller (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169484#comment-17169484 ] 

Matthias Keller commented on HTTPCLIENT-2102:
---------------------------------------------

[~olegk]: Thanks for your reply. Yes you are right, I probably got carried away because the socket impl is of type "SocksSocketImpl", but this is tunnelling. But nevertheless, this bug cost us about 2 days of debugging because it is absolutely not clear that when using *some* proxies you also have to set this magic socketconfig where for most other cases you don't (for example for a proxy with a http target where the request is not done using the CONNECT verb but directly using the original GET or POST or whatever.

In the end, the request is executed over this connection, thus maybe the so timeout is later aplied to this connection, but it's absolutely uncomprehensible why for a CONNECT tunnel the timeouts must be configured somewhere completely different whereas for a GET/POST 'tunnel' this is not necessary. Reading on the net, a lot of people have the same problem, most of them never solved them and in our case, production stood still multiple times because the threads blocked forever.

This should at least go very clearly in the documentation as this is a very hidden 'feature' noone can understand without comprehensive documentation. Could you please add this information at least to the proxy section of the documentation?

> 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