http-body

http-body defines a single, minimal trait — Body — that represents an asynchronous, streaming HTTP body: something that yields a sequence of data frames and trailers over time rather than a single in-memory buffer. It’s the interoperability layer that lets hyper, tower, axum, tonic, and other Rust HTTP libraries pass request/response bodies between each other without every crate needing to agree on one concrete body type.

Because it’s a trait rather than a body implementation, http-body itself has almost no logic — the companion http-body-util crate (developed in the same workspace) provides ready-made implementations (Empty, Full, Collected, Limited, a StreamBody adapter, and combinators) so most consumers never need to implement the trait by hand.

What You Get

• The core Body trait: poll_frame for pulling the next data/trailer frame asynchronously
• A Frame type distinguishing data chunks from HTTP trailers in the same streaming interface
• SizeHint for communicating known/estimated body length to callers (e.g. for Content-Length)
• A stable, minimal-dependency (only bytes + http) interop point other crates build concrete bodies against
• Companion http-body-util crate (same repo) with ready-made body implementations and combinators so most users don’t implement the trait directly

Common Use Cases

• Writing a middleware in tower/axum/tonic that needs to accept or return an arbitrary streaming HTTP body type
• Implementing a custom HTTP client or server body type that needs to interoperate with the hyper ecosystem
• Streaming large file or proxy responses through a Rust HTTP stack without buffering the whole body in memory
• Adapting a futures::Stream of bytes into an HTTP body accepted by hyper-based servers, via http-body-util’s StreamBody
• Building gRPC (tonic) handlers that need trailer support on top of a streaming body abstraction

Under The Hood

Architecture — The crate is deliberately tiny: http-body/src/lib.rs (~230 lines) defines the Body trait itself around a single poll_frame method, frame.rs defines the Frame<Data> enum distinguishing data chunks from trailers, and size_hint.rs provides the SizeHint type. It ships no concrete body implementations — those live in the sibling http-body-util crate in the same Cargo workspace (Empty, Full, Collected, Limited, StreamBody, plus combinators under combinators/), keeping the trait definition free of the implementation churn that would force every downstream crate to bump in lockstep.

Tech Stack — Pure Rust, edition 2018, MSRV 1.61. Its only dependencies are bytes (for zero-copy byte buffers) and http (for the HeaderMap used in trailers) — no async-runtime dependency at all, which is what lets it sit underneath both tokio-based and other-runtime-based HTTP stacks without imposing a runtime choice.

Code Quality — As a foundational, widely-depended-on interop trait (700M+ cumulative downloads per the registry), the crate is intentionally conservative: the trait surface has been stable since the 1.0 release with only incremental additions, CI runs on every push/PR, and the workspace’s http-body-util carries its own test suite for the concrete body implementations built on top of the trait. Recent commit velocity is modest, which is expected for a stabilized, narrowly-scoped interop crate rather than a sign of neglect.

API Design — The entire public contract is one trait with one required method (poll_frame) plus a size_hint() default, making implementing Body for a custom type a small, well-documented exercise; docs.rs hosts thorough rustdoc with the trait’s contract clearly spelled out. Because most consumers use http-body-util’s ready-made implementations instead of hand-rolling the trait, the practical day-to-day API surface most developers touch is Full::new(bytes) or StreamBody::new(stream) rather than the trait itself — keeping the common path simple despite the low-level nature of what it standardizes.