Until this commit, servers have required that `Service` and their
`Future` to be `Send`, since the server needs to spawn some internal
tasks to an executor, and by default, that is `tokio::spawn`, which
could be spawning to a threadpool. This was true even if the user were
certain there was no threadpool involved, and was instead using a
different single-threaded runtime, like
`tokio::runtime::current_thread`.
This changes makes all the server pieces generic over an `E`, which is
essentially `Executor<PrivateTypes<Server::Future>>`. There's a new set
of internal traits, `H2Exec` and `NewSvcExec`, which allow for the type
signature to only show the generics that the user is providing. The
traits cannot be implemented explicitly, but there are blanket
implementations for `E: Executor<SpecificType>`. If the user provides
their own executor, it simply needs to have a generic `impl<F>
Executor<F> for MyExec`. That impl can have bounds deciding whether to
require `F: Send`. If the executor does require `Send`, and the
`Service` futures are `!Send`, there will be compiler errors.
To prevent a breaking change, all the types that gained the `E` generic
have a default type set, which is the original `tokio::spawn` executor.
While the upgrades feature enabled HTTP upgrades in both and the server and client, and the goal was for `CONNECT` requests to work as well, only the server could use them for `CONNECT`. The `Client` had some specific code rejecting `CONNECT` requests, and this removes it and prepares the `Client` to handle them correctly.
- Adds `Body::on_upgrade()` that returns an `OnUpgrade` future.
- Adds `hyper::upgrade` module containing types for dealing with
upgrades.
- Adds `server::conn::Connection::with_upgrades()` method to enable
these upgrades when using lower-level API (because of a missing
`Send` bound on the transport generic).
- Client connections are automatically enabled.
- Optimizes request parsing, to make up for extra work to look for
upgrade requests.
- Returns a smaller `DecodedLength` type instead of the fatter
`Decoder`, which should also allow a couple fewer branches.
- Removes the `Decode::Ignore` wrapper enum, and instead ignoring
1xx responses is handled directly in the response parsing code.
Ref #1563Closes#1395
If an HTTP/1 connection has a parse error, but it starts with the HTTP2 preface, converts the connection automatically into an HTTP2 server connection.
Closes#1486
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.
