repository·master·Indexed 12 days ago
https://github.com/hyperium/hyperA fast, correct, and asynchronous HTTP implementation for Rust supporting HTTP/1 and HTTP/2. Version 1.11.0 provides low-level Client and Server APIs, serving as a foundational building block for other Rust web frameworks. It features a shift toward connection-level APIs in 1.0, an unstable C API for FFI, and a design that avoids implicit runtime dependencies by requiring explicit Executor and Timer implementations.
In hyper 1.0, the primary API focus has shifted from high-level Client and Server abstractions to lower-level Connection types. The previous high-level hyper::Client and hyper::Server helpers have been removed from the core crate and moved to hyper-util.
Developers should now interact directly with connection management via version-specific modules. This design provides more flexibility and stability, especially as the project prepares for HTTP/3 support which requires different transport abstractions than the standard AsyncRead + AsyncWrite model.
hyper-util crate contains useful components that do not yet meet hyper's stability promise. While hyper is highly stable, hyper-util is intended for experimentation and providing utilities that might eventually be promoted into the core hyper crate. Use hyper-util when you need features that are not yet part of the stable public API.To choose the right tool for your project, note that the following features are explicitly out of scope for hyper and should be handled by other libraries:
hyper is designed as a layered library where the user provides their own runtime and IO. hyper operates on top of the provided IO and returns Futures that the user polls using their chosen runtime.
The architecture consists of three main layers:
content-length, managing frame order/flags, handling connection-terminating headers (e.g., Connection: close), and processing connection-level frames in HTTP/2 and HTTP/3.http::Requests and http::Responses via a client or server Connection interface, abstracting away version-specific framing. Version-specific functionality can be accessed via http::Extensions.hyper follows semantic versioning and provides the following stability guarantees:
The hyper-util crate is intended to be more flexible but is explicitly less stable than the core hyper crate.
Best Practices:
hyper-util in your own library's public API.hyper-util (e.g., for a high-level Client or Server), it is recommended to define your own abstraction and provide an internal adapter for your users. This prevents your users from being forced to depend on an unstable crate.hyper uses the default configuration of rustfmt. Note that cargo fmt --all is not supported in this repository. Instead, use the platform-specific commands below to check the formatting of all .rs files using the 2021 edition.
# Mac or Linux
rustfmt --check --edition 2021 $(git ls-files '*.rs')
# Powershell
Get-ChildItem . -Filter "*.rs" -Recurse | foreach { rustfmt --check --edition 2021 $_.FullName }To compile the C API as part of the Rust library, use cargo rustc with the required unstable flag and specific features enabled. You must specify --crate-type cdylib to produce a dynamic library suitable for C consumption.
RUSTFLAGS="--cfg hyper_unstable_ffi" cargo rustc --features client,http1,http2,ffi --crate-type cdylibIf you are using cargo-c, you can build and install a shared library version of the C API using the cbuild command. Ensure you include the ffi feature and the unstable configuration flag.
RUSTFLAGS="--cfg hyper_unstable_ffi" cargo cbuild --features client,http1,http2,ffi --releaseIf you have cloned the hyper repository locally, you can run any of the provided examples using cargo run. You must enable the full feature to ensure all dependencies required by the examples are available.
cargo run --example {example_name} --features="full"