Name Description Size
body
cfg.rs 864
client
common
error.rs Error and Result module. 21309
ext
ext.rs HTTP extensions. 6772
ffi
headers.rs 4598
lib.rs # hyper hyper is a **fast** and **correct** HTTP implementation written in and for Rust. ## Features - HTTP/1 and HTTP/2 - Asynchronous design - Leading in performance - Tested and **correct** - Extensive production use - [Client](client/index.html) and [Server](server/index.html) APIs If just starting out, **check out the [Guides](https://hyper.rs/guides) first.** ## "Low-level" hyper is a lower-level HTTP library, meant to be a building block for libraries and applications. If looking for just a convenient HTTP client, consider the [reqwest](https://crates.io/crates/reqwest) crate. # Optional Features hyper uses a set of [feature flags] to reduce the amount of compiled code. It is possible to just enable certain features over others. By default, hyper does not enable any features but allows one to enable a subset for their use case. Below is a list of the available feature flags. You may also notice above each function, struct and trait there is listed one or more feature flags that are required for that item to be used. If you are new to hyper it is possible to enable the `full` feature flag which will enable all public APIs. Beware though that this will pull in many extra dependencies that you may not need. The following optional features are available: - `http1`: Enables HTTP/1 support. - `http2`: Enables HTTP/2 support. - `client`: Enables the HTTP `client`. - `server`: Enables the HTTP `server`. - `runtime`: Enables convenient integration with `tokio`, providing connectors and acceptors for TCP, and a default executor. - `tcp`: Enables convenient implementations over TCP (using tokio). - `stream`: Provides `futures::Stream` capabilities. [feature flags]: https://doc.rust-lang.org/cargo/reference/manifest.html#the-features-section 3127
mock.rs 6213
proto
rt.rs Runtime components By default, hyper includes the [tokio](https://tokio.rs) runtime. If the `runtime` feature is disabled, the types in this module can be used to plug in other runtimes. 355
server
service
upgrade.rs HTTP Upgrades This module deals with managing [HTTP Upgrades][mdn] in hyper. Since several concepts in HTTP allow for first talking HTTP, and then converting to a different protocol, this module conflates them into a single API. Those include: - HTTP/1.1 Upgrades - HTTP `CONNECT` You are responsible for any other pre-requisites to establish an upgrade, such as sending the appropriate headers, methods, and status codes. You can then use [`on`][] to grab a `Future` which will resolve to the upgraded connection object, or an error if the upgrade fails. [mdn]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism # Client Sending an HTTP upgrade from the [`client`](super::client) involves setting either the appropriate method, if wanting to `CONNECT`, or headers such as `Upgrade` and `Connection`, on the `http::Request`. Once receiving the `http::Response` back, you must check for the specific information that the upgrade is agreed upon by the server (such as a `101` status code), and then get the `Future` from the `Response`. # Server Receiving upgrade requests in a server requires you to check the relevant headers in a `Request`, and if an upgrade should be done, you then send the corresponding headers in a response. To then wait for hyper to finish the upgrade, you call `on()` with the `Request`, and then can spawn a task awaiting it. # Example See [this example][example] showing how upgrades work with both Clients and Servers. [example]: https://github.com/hyperium/hyper/blob/master/examples/upgrades.rs 11289