§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 and Server APIs

If just starting out, check out the 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 crate.

§Cancel safety

Futures returned by hyper are cancel safe: dropping a future before it completes is the supported way to cancel the operation. The protocol in use changes what that cancellation actually does on the wire:

• HTTP/1 has no in-protocol way to abort a single request without affecting the shared connection, so dropping an in-flight request future closes the underlying TCP connection. Any subsequent call on the same SendRequest returns a canceled error; the connection cannot be reused.
• HTTP/2 resets the single stream with RST_STREAM (CANCEL error code) and notifies the peer immediately rather than continuing to deliver a response body that would be discarded. The shared connection stays usable for other in-flight and future requests.

See the documentation on individual futures — for example SendRequest::send_request in client::conn::http1 and the equivalent in client::conn::http2 — for the protocol-specific behavior on cancellation.

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

§Unstable Features

hyper includes a set of unstable optional features that can be enabled through the use of a feature flag and a configuration flag.

The following is a list of feature flags and their corresponding RUSTFLAG:

• ffi: Enables C API for hyper hyper_unstable_ffi.
• tracing: Enables debug logging with hyper_unstable_tracing.

For example:

RUSTFLAGS="--cfg hyper_unstable_tracing" cargo build

§Stability

It’s worth talking a bit about the stability of hyper. hyper’s API follows SemVer. Breaking changes will only be introduced in major versions, if ever. New additions to the API, such as new types, methods, or traits will only be added in minor versions.

Some parts of hyper are documented as NOT being part of the stable API. The following is a brief list, you can read more about each one in the relevant part of the documentation.

• Downcasting error types from Error::source() is not considered stable.
• Private dependencies use of global variables is not considered stable. So, if a dependency uses log or tracing, hyper doesn’t promise it will continue to do so.
• Behavior from default options is not stable. hyper reserves the right to add new options that are enabled by default which might alter the behavior, for the purposes of protection. It is also possible to change what the default options are set to, also in efforts to protect the most people possible.