Currently the wasm client does not implement `try_clone` on `Request` or `RequestBuilder` like the blocking and async clients.
This PR adds infallible `try_clone` implementations to the wasm client to improve the API parity.
*Note*: Even though these APIs are infallible on wasm (no streaming bodies), I chose to keep the API identical.
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.
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.
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
Previously, HTTP proxies loaded from the system settings were not
respected for non-HTTPS requests. Now the PROXY_AUTHORIZATION header is
supplied on HTTP requests with a system proxy.
I also added a simple sanity test to make sure it doesn't override
a `Body` with an actual size. I also double checked that this works
with a project where we are using streams.
Closes#1090
Now, callers have more control over the set of roots.
Note that, due to cargo unification, other dependencies in the
dependency tree might enable rustls-tls-webpki-roots
or rustls-tls.
This will affect connections initiated by code that explicitly
enabled rustls-tls-manual-roots.
So for now, the choice is done once per entire cargo
dependency graph. If people want more precise control
over things, they can add methods that allow controlling
this on a per-connection level. Even if such methods
are available, the *-manual-roots feature will still be
helpful with eliminating the webpki-roots dependency
for those cargo graphs where there is no unification.
