Rust HTTP types
1.4k
Stars
369
Forks
177
Open issues
30
Contributors
AI Analysis
The `http` crate provides foundational Rust types for HTTP—Request, Response, StatusCode, headers, and URIs—without prescribing an I/O strategy. It is best suited for library and framework authors who need a shared, dependency-light HTTP type abstraction; end-user applications typically depend on it transitively through higher-level frameworks like Hyper or Tokio, rather than directly.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Low-level HTTP primitives library providing foundational types for Rust HTTP ecosystems
The `http` crate provides a minimal, zero-copy set of HTTP type definitions (Request, Response, StatusCode, Headers, etc.) for Rust. It is intentionally upstream of full HTTP implementations like Hyper and is used as a dependency by HTTP client/server frameworks to maintain API compatibility without coupling to specific implementations. Adoption appears substantial but largely invisible—embedded deep in dependency chains rather than used directly by end applications.
Created in 2017 as part of the Hyperium project ecosystem. Designed to separate HTTP type definitions from transport/protocol implementation, allowing multiple HTTP stacks (Hyper, Actix, Tokio, etc.) to interoperate via a common type vocabulary.
Growth has been steady but modest (1,360 stars, 2 gained in last 7 days). This reflects its role as infrastructure: high adoption doesn't translate to visibility because it's rarely chosen explicitly—it's inherited as a transitive dependency. The slow star growth is expected for foundational types; saturation is reached early and maintained thereafter.
Adoption not formally documented in README, but indirect evidence is strong: the crate is listed as a dependency by Hyper (16K stars), H2 (1.5K stars), and likely numerous downstream frameworks. Crates.io version history and dependency graphs would confirm scale, but README contains no case studies or user testimonials.
Appears to be a lightweight, purely-typed crate providing builder patterns for HTTP primitives. Based on README examples, the design follows Rust's type-safety paradigm with struct builders (Request::builder(), Response::builder()). Likely no network I/O, protocol parsing, or async runtime—strictly data structures.
Not documented in README.
Last push 2026-06-16 (17 days before evaluation date) indicates active maintenance. Project maintains MSRV 1.57 aligned with Hyper's policy, suggesting discipline. CI badge present. Update cadence appears regular but infrequent—consistent with a stable, mature foundational library.
ADOPT IF: you are building an HTTP library, framework, or tool in Rust and need a dependency-light, stable type contract that interoperates across the ecosystem. AVOID IF: you need a complete HTTP implementation—use Hyper, Reqwest, or Actix instead; `http` provides only types. MONITOR IF: you are considering standardizing HTTP types across a polyglot codebase or unsure whether your dependency chain already pulls `http` in transitively (likely it does).
Independent dimensions
Mainstream potential
3/10
Technical importance
7/10
Adoption evidence
6/10
- Tight coupling to Rust language evolution; MSRV changes could break downstream users if not managed carefully.
- No formal governance or RFC process visible in README; changes may lack broad ecosystem input.
- Type definitions lack semantic richness (e.g., no validation of header names/values at the type level)—consumer responsibility to enforce rules.
- Upstream of high-traffic projects (Hyper, etc.); bugs or API changes have wide blast radius despite small team.
- Documentation and examples minimal; most users learn through indirect dependency, not direct study.
Will remain a stable, essential foundational layer for Rust HTTP tooling. Growth will remain flat or decline slightly as ecosystem matures and dependency graphs stabilize. No signs of replacement or significant API evolution needed.
Explore similar
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Rust
- License
- Apache-2.0
- Last updated
- 3w ago
- Created
- 113mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Implement PartialEq/Eq for InvalidUri?
Uri Builder path change broke parsing and reconstructing the Uri with empty path
`Uri` does not accept percent-encoded characters in hostname
Method on Authority to get the host without [] for IPv6 addresses
`HeaderName` implements `Borrow<str>` but doesn't hash like `str`
Top contributors
Recent releases
Similar repos
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
1.4k | +3 | Rust | 8/10 | 3w ago |
|
|
16.2k | — | Rust | 9/10 | 3d ago |
|
|
1.5k | — | Rust | 8/10 | 21h ago |
|
|
2.2k | — | Rust | 8/10 | 2w ago |
|
|
1.3k | — | Rust | 8/10 | 13h ago |
Hyper is a full-featured HTTP client/server implementation; `http` is its upstream type dependency. They are complementary, not competitive. Hyper re-exports `http` types for user-facing APIs.
H2 is the HTTP/2 protocol implementation; `http` provides the type layer beneath it. Same complementary relationship.
`http` does not overlap—it provides structure, not serialization. These are orthogonal.
Tonic likely depends on `http` indirectly; it is not a replacement but a higher-level abstraction built atop shared types.