`tower` 0.4.5 introduced `Shared` which is a `MakeService` that produces
services by cloning an inner service. This works quite well with `hyper`
if your service doesn't need the incoming connection and implements
`Clone`.
However that might not be entirely obvious so I thought it made sense to
add an example to the docs.
I wasn't quite sure if the example should go in the server or service
module docs but since there already is an example using
`make_service_fn` in the server docs I opted to add it there. Let me
know if you'd rather have it somewhere else.
Closes#2326
BREAKING CHANGE: hyper no longer emits `log` records automatically.
If you need hyper to integrate with a `log` logger (as opposed to `tracing`),
you can add `tracing = { version = "0.1", features = ["log"] }` to activate them.
This branch updates `bytes` and `http-body` to the latest versions. The
`http-body` version that uses `bytes` 0.6 hasn't been released yet, so
we depend on it via a git dep for now. Presumably Hyper and `http-body`
will synchronize their releases.
Other than that, this is a pretty mechanical update. Should fix the
build and unblock the `h2` update to use vectored writes.
cc #2223
BREAKING CHANGE: The HTTP server code is now an optional feature. To
enable the server, add `features = ["server"]` to the dependency in
your `Cargo.toml`.
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.
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">
Without this, you can end up with tokio 0.2.4 and hyper 0.13.5 in your
project, leading to a compile error like this:
```
error[E0599]: no method named `try_recv` found for struct `tokio::sync::mpsc::unbounded::UnboundedReceiver<client::dispatch::Envelope<T, U>>` in the current scope
--> src/client/dispatch.rs:161:26
|
161 | match self.inner.try_recv() {
| ^^^^^^^^ method not found in `tokio::sync::mpsc::unbounded::UnboundedReceiver<client::dispatch::Envelope<T, U>>`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0599`.
error: could not compile `hyper`.
```
