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` doesn't actually care how hyper-rustls gets its root certs. By
not specifying any feature for hyper-rustls, `reqwest` is able to work
with `rusoto_core` and others better.
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.
Update Requirements for Linux to include OpenSSL 1.1.1.
sfackler/rust-openssl supports OpenSSL 1.0.1 through 1.1.1, but its docs are out of date.
Closes#889
As by default, when executing tests with -C opt-level=n where "n"
is greater than 0, debug assertions are disabled, which removes the
panic!() this test is expecting.
With this tweak, tests no longer fail with any choice of -C opt-level,
and additionally, tests still execute correctly if these tests are
compiled with:
-C opt-level=3 -C debug-assertions=yes
Closes: https://github.com/seanmonstar/reqwest/issues/831
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
