A Cargo feature `runtime` is added, which is enabled by default, that
includes the following:
- The `client::HttpConnector`, which uses `tokio::net::TcpStream`.
- The `server::AddrStream`, which uses `tokio::net::TcpListener`.
- The `hyper::rt` module, which includes useful utilities to work with
the runtime without needing to import `futures` or `tokio` explicity.
Disabling the feature removes many of these niceties, but allows people
to use hyper in environments that have an alternative runtime, without
needing to download an unused one.
This introduces the `hyper::service` module, which replaces
`tokio-service`.
Since the trait is specific to hyper, its associated
types have been adjusted. It didn't make sense to need to define
`Service<Request=http::Request>`, since we already know the context is
HTTP. Instead, the request and response bodies are associated types now,
and slightly stricter bounds have been placed on `Error`.
The helpers `service_fn` and `service_fn_ok` should be sufficient for
now to ease creating `Service`s.
The `NewService` trait now allows service creation to also be
asynchronous.
These traits are similar to `tower` in nature, and possibly will be
replaced completely by it in the future. For now, hyper defining its own
allows the traits to have better context, and prevents breaking changes
in `tower` from affecting hyper.
Closes#1461
BREAKING CHANGE: The `Service` trait has changed: it has some changed
associated types, and `call` is now bound to `&mut self`.
The `NewService` trait has changed: it has some changed associated
types, and `new_service` now returns a `Future`.
`Client` no longer implements `Service` for now.
`hyper::server::conn::Serve` now returns `Connecting` instead of
`Connection`s, since `new_service` can now return a `Future`. The
`Connecting` is a future wrapping the new service future, returning
a `Connection` afterwards. In many cases, `Future::flatten` can be
used.
The `hyper::Server` is now a proper higher-level API for running HTTP
servers. There is a related `hyper::server::Builder` type, to construct
a `Server`. All other types (`Http`, `Serve`, etc) were moved into the
"lower-level" `hyper::server::conn` module.
The `Server` is a `Future` representing a listening HTTP server. Options
needed to build one are set on the `Builder`.
As `Server` is just a `Future`, it no longer owns a thread-blocking
executor, and can thus be run next to other servers, clients, or
what-have-you.
Closes#1322Closes#1263
BREAKING CHANGE: The `Server` is no longer created from `Http::bind`,
nor is it `run`. It is a `Future` that must be polled by an
`Executor`.
The `hyper::server::Http` type has move to
`hyper::server::conn::Http`.
- `Client::new()` no longer needs a `Handle`, and instead makes use of
tokio's implicit default.
- Changed `Client::configure()` to `Client::builder()`.
- `Builder` is a by-ref builder, since all configuration is now
cloneable pieces.
BREAKING CHANGE: `Client:new(&handle)` and `Client::configure()` are now
`Client::new()` and `Client::builder()`.
**The `Error` is now an opaque struct**, which allows for more variants to
be added freely, and the internal representation to change without being
breaking changes.
For inspecting an `Error`, there are several `is_*` methods to check for
certain classes of errors, such as `Error::is_parse()`. The `cause` can
also be inspected, like before. This likely seems like a downgrade, but
more inspection can be added as needed!
The `Error` now knows about more states, which gives much more context
around when a certain error occurs. This is also expressed in the
description and `fmt` messages.
**Most places where a user would provide an error to hyper can now pass
any error type** (`E: Into<Box<std::error::Error>>`). This error is passed
back in relevant places, and can be useful for logging. This should make
it much clearer about what error a user should provide to hyper: any it
feels is relevant!
Closes#1128Closes#1130Closes#1431Closes#1338
BREAKING CHANGE: `Error` is no longer an enum to pattern match over, or
to construct. Code will need to be updated accordingly.
For body streams or `Service`s, inference might be unable to determine
what error type you mean to return. Starting in Rust 1.26, you could
just label that as `!` if you never return an error.
The original `Connect` trait had some limitations:
- There was no way to provide more details to the connector about how to
connect, other than the `Uri`.
- There was no way for the connector to return any extra information
about the connected transport.
- The `Error` was forced to be an `std::io::Error`.
- The transport and future had `'static` requirements.
As hyper gains HTTP/2 support, some of these things needed to be
changed. We want to allow the user to configure whether they hope to
us ALPN to start an HTTP/2 connection, and the connector needs to be
able to return back to hyper if it did so.
The new `Connect` trait is meant to solve this.
- The `connect` method now receives a `Destination` type, instead of a
`Uri`. This allows us to include additional data about how to connect.
- The `Future` returned from `connect` now must be a tuple of the
transport, and a `Connected` metadata value. The `Connected` includes
possibly extra data about what happened when connecting.
BREAKING CHANGE: Custom connectors should now implement `Connect`
directly, instead of `Service`.
Calls to `connect` no longer take `Uri`s, but `Destination`. There
are `scheme`, `host`, and `port` methods to query relevant
information.
The returned future must be a tuple of the transport and `Connected`.
If no relevant extra information is needed, simply return
`Connected::new()`.
Closes#1428
This dedicated `Entity` trait replaces the previous `Stream<Item=impl
AsRef<[u8]>, Error=hyper::Error>`. This allows for several improvements
immediately, and prepares for HTTP2 support.
- The `Entity::is_end_stream` makes up for change away from
`Option<Body>`, which was previously used to know if the body should be
empty. Since `Request` and `Response` now require a body to be set,
this method can be used to tell hyper that the body is actually empty.
It also provides the possibility of slight optimizations when polling
for data, by allowing to check `is_end_stream` before polling again.
This can allow a consumer to know that a body stream has ended without
polling for `None` afterwards.
- The `Entity::content_length` method allows a body to automatically
declare a size, in case a user doesn't set a `Content-Length` or
`Transfer-Encoding` header.
- It's now possible to send and receive trailers, though this will be
for HTTP2 connections only.
By being a trait owned by hyper, new methods can be added later as new
features are wanted (with default implementations).
The `hyper::Body` type now implements `Entity` instead of `Stream`,
provides a better channel option, and is easier to use with custom
streams via `Body::wrap_stream`.
BREAKING CHANGE: All code that was assuming the body was a `Stream` must
be adjusted to use an `Entity` instead.
Using `hyper::Body` as a `Stream` can call `Body::into_stream`
to get a stream wrapper.
Passing a custom `impl Stream` will need to either implement
`Entity`, or as an easier option, switch to `Body::wrap_stream`.
`Body::pair` has been replaced with `Body::channel`, which returns a
`hyper::body::Sender` instead of a `futures::sync::mpsc::Sender`.
Closes#1438
BREAKING CHANGE: `Method`, `Request`, `Response`, `StatusCode`,
`Version`, and `Uri` have been replaced with types from the `http`
crate. The `hyper::header` module is gone for now.
Removed `Client::get`, since it needed to construct a `Request<B>`
with an empty body. Just use `Client::request` instead.
Removed `compat` cargo feature, and `compat` related API.
