Ignoring validation seems broken as some default functions actually do
check. That is fine for the proper TLS validation, but gets in the way
when someone wants to skip TLS validation (e.g. for self-signed
certificates).
This change re-implements these default functions in a way that they
do not check, but return "success" all the time.
Fixes#1210
This implements a conversion from `hyper::Body` to `reqwest::Body`,
which in turn enables converting a `http::Request<hyper::Body>` into
`reqwest::Request` through the existing `TryFrom` implementation.
Fixes#1156.
Documentation in examples recommends using
`tokio 0.2` as dependency, while README.md
recomends `tokio 0.1`.
I've updated comments according to readme.
This adds a new trait, `CookieStore`, which allows for custom
implementations of storage for a client's cookies. After implementing,
you can call `ClientBuilder::cookie_provider` to use it over the
default storage.
The default store is exposed as `Jar`, to ease the most common use case
which is to add a few cookies to the store when creating a client.
Co-authored-by: Patrick Fernie <patrick.fernie@gmail.com>
Other implementations (curl and Go) accept HTTPS_PROXY values with no
protocol scheme. When the scheme is not present, http:// is assumed.
For example 192.168.1.1 is interpreted as http://192.168.1.1
This commit adds support for http proxy addresses without a scheme by
retrying the URL parsing mechanisms with http:// prepended.
Use "cross" to cross-compile reqwest for Android. The job currently
errors out because the default linker doesn't know what to do with
object files generated for Android.
`hyper` implements idle connection cleanup by spawning a new task which
drops the connection after a while. This mechanism requires Tokio, so it
is hidden behing the "runtime" feature, which reqwest doesn't enable,
making some connections stay in the pool forever. Fixes#1162.
See discussion on #1017. This patch adds documentation to `blocking` at
module level and to its `Client::new` and `ClientBuilder::build`, noting
that you can’t create or use a blocking client from within an async
runtime, and suggesting potential alternatives.
Presumably, all the other methods on `Client` also have this property,
but hitting the failure mode would require building a `blocking::Client`
outside an async runtime and then moving it into a runtime to send
requests; seems potentially not worth polluting all the docs.
Test Plan:
Ran `cargo doc --features blocking` and verified that the links work.
wchargin-branch: docs-blocking-no-async
wchargin-source: 0eb36352959cd2ca0b19df5836e75230dc619b9d
