| 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 |