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.
1.9 KiB
Examples of using hyper
Run examples with cargo run --example example_name.
Available examples
-
client- A simple CLI http client that request the url passed in parameters and outputs the response content and details to the stdout, reading content chunk-by-chunk. -
client_json- A simple program that GETs some json, reads the body asynchronously, parses it with serde and outputs the result. -
echo- An echo server that copies POST request's content to the response content. -
hello- A simple server that returns "Hello World!" using a closure wrapped to provide aService. -
multi_server- A server that listens to two different ports, a differentServiceby port, spawning twofutures. -
params- A webserver that accept a form, with a name and a number, checks the parameters are presents and validates the input. -
proxy- A webserver that proxies to the hello service above. -
send_file- A server that sends back content of files using tokio_fs to read the files asynchronously. -
single_threaded- A server only running on 1 thread, so it can make use of!Sendapp state (like anRccounter). -
state- A webserver showing basic state sharing among requests. A counter is shared, incremented for every request, and every response is sent the last count. -
upgrades- A server and client demonstrating how to do HTTP upgrades (such as WebSockets orCONNECTtunneling). -
web_api- A server consisting in a service that returns incoming POST request's content in the response in uppercase and a service that call that call the first service and includes the first service response in its own response.