* refactor: Use async/await in client.rs
* refactor: Simplify client.rs a bit more
* refactor: Allow !Unpin in Lazy
* Remove some impl Future
* Remove some combinator use
Make it possible to refer to Connected, Connection, HttpConnector, etc.
without enabling either of the http1/http2 features. This makes feature
selection work better for downstream libraries like hyper-openssl, which
don't want to commit to any particular protocol.
Fix#2376.
The DNS resolver part of `HttpConnector` used to require resolving to
`IpAddr`s, and this changes it so that they resolve to `SocketAddr`s.
The main benefit here is allowing for resolvers to set the IPv6 zone ID
when resolving, but it also just more closely matches
`std::net::ToSocketAddrs`.
Closes#1937
BREAKING CHANGE: Custom resolvers used with `HttpConnector` must change
to resolving to an iterator of `SocketAddr`s instead of `IpAddr`s.
Add basic, module level example for the Builder performing a handshake,
spawning a task to run the Connection and sending a single request and
receiving the response.
Closes#2272
Tokio's `AsyncWrite` trait once again has support for vectored writes in
Tokio 0.3.4 (see tokio-rs/tokio#3149).
This branch re-enables vectored writes in Hyper for HTTP/1. Using
vectored writes in HTTP/2 will require an upstream change in the `h2`
crate as well.
I've removed the adaptive write buffer implementation
that attempts to detect whether vectored IO is or is not available,
since the Tokio 0.3.4 `AsyncWrite` trait exposes this directly via the
`is_write_vectored` method. Now, we just ask the IO whether or not it
supports vectored writes, and configure the buffer accordingly. This
makes the implementation somewhat simpler.
This also removes `http1_writev()` methods from the builders. These are
no longer necessary, as Hyper can now determine whether or not
to use vectored writes based on `is_write_vectored`, rather than trying
to auto-detect it.
Closes#2320
BREAKING CHANGE: Removed `http1_writev` methods from `client::Builder`,
`client::conn::Builder`, `server::Builder`, and `server::conn::Builder`.
Vectored writes are now enabled based on whether the `AsyncWrite`
implementation in use supports them, rather than though adaptive
detection. To explicitly disable vectored writes, users may wrap the IO
in a newtype that implements `AsyncRead` and `AsyncWrite` and returns
`false` from its `AsyncWrite::is_write_vectored` method.
cc #2223
BREAKING CHANGE: The HTTP client of hyper is now an optional feature. To
enable the client, add `features = ["client"]` to the dependency in
your `Cargo.toml`.
cc #2251
BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
`http1` cargo feature, which will not be enabled by default. To use
HTTP/1, add `features = ["http1"]` to the hyper dependency in your
`Cargo.toml`.
cc #2251
BREAKING CHANGE: This puts all HTTP/2 methods and support behind an
`http2` cargo feature, which will not be enabled by default. To use
HTTP/2, add `features = ["http2"]` to the hyper dependency in your
`Cargo.toml`.
Currently HttpConnector::set_local_address method accepts a single
argument. Server might not support IPv6 or IPv4. Therefore, the only
solution at the moment is to manually perform DNS resolution and pick
appropriate local address family. This is inefficient, as leads to
2 DNS lookups per request. This commit allows specifying both IPv4
and IPv6, so connector can decide which one to use based on DNS
resolution results.
Previously, calling `http1_writev(true)` would just keep the default behavior, which was to auto detect if writev was optimal. Now, the auto-detection is still default, but explicitly calling `http1_writev(true)` will skip the auto-detection, and always use writev queue strategy.
Closes#2282
I've moved Hyper from `log` to `tracing`. Existing `log`-based users shouldn't notice a difference, but `tracing` users will see higher performance when filtering data. This isn't the _end_ of the `tracing` integration that can happen in `Hyper` (e.g., Hyper can start using spans, typed fields, etc.), but _something_ is better than nothing. I'd rather address those points, including examples, in followups.
I've attached a screenshot of the `hello` example working, but the logged information is pulled from `tracing`, not `log`.
<img width="514" alt="Screen Shot 2020-05-16 at 1 23 19 PM" src="https://user-images.githubusercontent.com/2067774/82126298-d8103800-9779-11ea-8f0b-57c632c684d6.png">
If the runtime is dropped while a DNS request is being made, it can
lead to a panic. This patch checks if the task was cancelled, and
returns a generic IO error instead of panicking in that case.
The following code reproduces the problem on my macOS machine:
```
use hyper::Client;
use tokio::runtime;
type Result<T> = std::result::Result<T, Box<dyn std::error::Error + Send + Sync>>;
fn main() {
let rt = runtime::Builder::new()
.threaded_scheduler()
.core_threads(1)
.enable_all()
.build()
.unwrap();
// spawn a request and then drop the runtime immediately
rt.spawn(fetch_url());
}
async fn fetch_url() -> Result<()> {
let url: hyper::Uri = "http://example.com".parse()?;
let client = Client::builder().build_http::<hyper::Body>();
let res = client.get(url).await?;
println!("Response: {}", res.status());
Ok(())
}
```
This adds HTTP2 keep-alive support to client and server connections
based losely on GRPC keep-alive. When enabled, after no data has been
received for some configured interval, an HTTP2 PING frame is sent. If
the PING is not acknowledged with a configured timeout, the connection
is closed.
Clients have an additional option to enable keep-alive while the
connection is otherwise idle. When disabled, keep-alive PINGs are only
used while there are open request/response streams. If enabled, PINGs
are sent even when there are no active streams.
For now, since these features use `tokio::time::Delay`, the `runtime`
cargo feature is required to use them.
- Renamed `keep_alive_timeout` to `pool_idle_timeout`.
- Renamed `max_idle_per_host` to `pool_max_idle_per_host`.
- Deprecated `keep_alive(bool)` due to confusing name. To disable the
connection pool, call `pool_max_idle_per_host(0)`.
This adds support for calculating the Bandwidth-delay product when using
HTTP2. When a DATA frame is received, a PING is sent to the remote.
While the PING acknoledgement is outstanding, the amount of bytes of all
received DATA frames is accumulated. Once we receive the PING
acknowledgement, we calculate the BDP based on the number of received
bytes and the round-trip-time of the PING. If we are near the current
maximum window size, the size is doubled.
It's disabled by default until tested more extensively.
When the body type of a `Request` or `Response` implements `HttpBody`,
the `Request` or `Response` itself now implements `HttpBody`.
This allows writing things like `hyper::body::aggregate(req)` instead of
`hyper::body::aggregate(req.into_body())`.
Closes#2067
