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