[
https://issues.apache.org/jira/browse/HTTPCLIENT-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143829#comment-17143829
]
Carter Kozak commented on HTTPCLIENT-2091:
------------------------------------------
Interesting, in the test that I put together for the classic client, my
configured socket timeout (via ConnectionManager.setDefaultSocketConfig) was
used when I removed the explicit setter. Async i/o doesn't have a comparable
socket timeout option, so I imagine the async case may need something along
these lines?
I'd like to put together a test that fails if no timeout is set to help me
understand why we need to set a timeout there.
> Connect timeout is used instead of socket timeout after a tls upgrade
> ---------------------------------------------------------------------
>
> Key: HTTPCLIENT-2091
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2091
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (async), HttpClient (classic)
> Affects Versions: 5.0.1
> Reporter: Carter Kozak
> Priority: Major
>
> After a TLS upgrade, the connect timeout is used instead of the configured
> socket timeout. In some configurations this results in unexpected socket
> timeouts earlier than expected.
>
> This impacts forward proxies using tunneling (CONNECT approach to pass tls
> bytes through a proxy server as opposed to individual plain http requests)
> which time out after the connect timeout is reached.
> This is a regression from hc4 which does not exhibit this issue.
> Some details here, where I thought the issues could be related:
> https://issues.apache.org/jira/browse/HTTPCLIENT-2090?focusedCommentId=17143321&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17143321
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
