Defaults are another good topic of discussion. I personally think that
there should be some reasonable, finite default value for every
timeout. (I also think that max conns should be unlimited by default.)
But the first order of business is deciding exactly how we want the
existing timeout paramete
Hi Ryan,
I'm glad you've brought this up as I've often considered this and have been
asked about it, in general, and for our apps at work.
In the end, a lot of users say something like "I do not want the default
behavior to wait forever, that looks like the app is hanging. I want some
timeout but
I've been looking into an issue with TLS handshake timeouts on the
async client (see
https://github.com/apache/httpcomponents-client/pull/118), and I think
that this topic might benefit from a broader audit.
Currently, there are three types of timeouts we expose through RequestConfig:
1. Connecti
GitHub user rschmitt opened a pull request:
https://github.com/apache/httpcomponents-client/pull/118
Use connectTimeout as TLS handshake timeout
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rschmitt/httpcomponents-client maste
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685450#comment-16685450
]
Bo Xi commented on HTTPCLIENT-1272:
---
I have a similar issue where the proxy server
On Mon, 2018-11-12 at 19:31 -0500, Karl Wright wrote:
> Hi Michael,
>
> I did not contribute this work; I merely obliquely helped integrating
> it.
> If I recall correctly, there was a reasonable case made for it, but I
> don't
> remember what it wasy.
>
> Karl
>
>
Hi Michael
For full backgro
