There are functions to check if the error is from an array of different
reasons, but there were no functions to check if the failure was due to
the rest of the possible error reasons. This commit adds though.
Fixes#942
* feat(proxy): Adds NO_PROXY environment variable support
Adds support for loading from the `NO_PROXY` or `no_proxy` environment
variables. This should make reqwest support the system proxy settings.
Please note that I brought in one additional dependency in order to
handle CIDR blocks in the no proxy settings.
Closes#705
Normally hyper is in charge of rejecting non-http URLs, but because
reqwest supports both http and https URLs, it calls enforce_http(false),
disabling hyper's checks.
This adds back a check in reqwest itself, plus a test.
There may still need to be an additional check in connect.rs.
reqwest exposes the “pool_max_idle_per_host” option of hyper’s client
builder. This option used to be called “max_idle_per_host” in the hyper
crate, but it has recently been renamed [1].
This patch renames the reqwest representation of this option to make it
consistent with its name in the hyper crate again.
[1] https://github.com/hyperium/hyper/pull/2142
hyper’s ClientBuilder has an option to define the idle timeout of the
connection pool. As it’s quite useful to be able to modify this value,
this patch extends reqwest’s ClientBuilder to expose that option as
well. The default value of 90 seconds is taken from hyper.
As ENV is process global, modifying it within a thread (as is normal
for all test targets in a rust libtest) results in a concurrency
data-race.
This patch fences the two known cases of needing to modify this by
locking all ENV modifications, and collection of data dependent on
said modifications, into a narrow path isolated by a Mutex lock, with
no test assert!()'s while the Mutex is held
( to avoid a Mutex Posioning ).
However, the code doesn't treat lock failure as a special circumstance,
and if the lock fails, then the pre-existing risk of conccurent ENV
modification returns, and these 2 tests can still randomly fail, but
_in that situation_.
And as mutexes can _only_ be poisoned by the 2 threads holding this
mutex, this regression can now only trip into concurrency issues when
either of these 2 tests are already failing from _non test_ assertions,
so this patch still improves the status quo substantially.
Closes: https://github.com/seanmonstar/reqwest/issues/829
This tweaks the tokio runtime checker (only used in debug mode) in
order to use a single thread.
Performing the CPUs auto-detection step on each check adds significant
syscall-tracing noise and runtime latency. This completely skips it.
