- Adds `client::connect::Connected::extra()`, which allows connectors to
specify arbitrary custom information about a connected transport.
If a connector provides this extra value, it will be set in the
`Response` extensions.
Closes#1402
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.
rustc issue: https://github.com/rust-lang/rust/issues/55105
Steps to reproduce:
```
rustup target add armv7-linux-androideabi
RUSTFLAGS="-Ctarget-feature=+neon" cargo build --target armv7-linux-androideabi --release
```
Output without this change:
```
Compiling hyper v0.12.11 (/home/simon/projects/servo-deps/hyper)
LLVM ERROR: ran out of registers during register allocation
error: Could not compile `hyper`.
```
This adds a "combinator" method to `Server`, which accepts a user's
future to "select" on. All connections received by the `Server` will
be tracked, and if the user's future finishes, graceful shutdown will
begin.
- The listener will be closed immediately.
- The currently active connections will all be notified to start a
graceful shutdown. For HTTP/1, that means finishing the existing
response and using `connection: clone`. For HTTP/2, the graceful
`GOAWAY` process is started.
- Once all active connections have terminated, the graceful future
will return.
Closes#1575
Change behaviour of connection or server response when the request is
version 1.0 and the Connection: keep-alive header is not present.
1. If the response is also version 1.0, then connection is closed if the
server keep-alive header is not present.
2. If the response is version 1.1, then the keep-alive header is added
when downgrading to version 1.0.
Closes#1614
If a user makes use of `Body::is_end_stream` to optimize so as to not
need to do make a final poll just to receive `None`, previously the
connection would not have progressed its reading state to a finished
body, and so the connection would be closed.
Now, upon reading any chunk, the connection state will check if it
can know that the body would be finished, and progresses to a body
finished state sooner.
The integration tests were amplified by adding a naive hyper proxy
as a secondary test, which happens to make use of that optimization,
and thus caught the issue.
