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>
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
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.
The builders have mostly the same options and the blocking one is just a
wrapper around the async one. The possible conversion makes it easier to
support creating both kinds from configuration file, reducing some code
duplication.
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.
To allow for the default-tls to change to a different backend by
default, this adds a new `native-tls` optional feature. Any TLS feature
that was only available using native-tls now requires the `native-tls`
feature to be enabled.
Changed the redirect types to be from the `redirect` module:
- `reqwest::RedirectPolicy` is now `reqwest::redirect::Policy`
- `reqwest::RedirectAttempt` is now `reqwest::redirect::Attempt`
- `reqwest::RedirectAction` is now `reqwest::redirect::Action`
Changed behavior of default policy to no longer check for redirect loops
(loops should still be caught eventually by the maximum limit).
Removed the `too_many_redirects` and `loop_detected` methods from
`Action`.
Added `error` to `Action` that can be passed any error type.
Closes#717
If no proxies are configured for a client, the environment (system) will
be inspected automatically to set up proxies.
Configuring a `Proxy` on a client or calling `no_proxy` will disable the
use of the automatic system proxy.
Closes#403
- The `Error`'s kind is a now a set of variants depending on the context
of when an error could occur.
- If another error was the cause, it is now always the `source`.
Along with the `is_*` methods, this should help in understanding *when*
a certain error occurred. For example, an error setting the TLS
certificates will return a builder error, with the TLS error as the
source. This should help differentiate from a TLS error that happens
when connecting to a server.
It also makes the internal code less dependent on all the exact
dependencies that can be enabled or disabled.
"inflate" actually means decompress in the context of DEFLATE. "deflate" reduces the size of something, i.e. compression, and inflate is the opposite, i.e. decompression.
