GO — Healthy across the board

• Last commit 3d ago
• 44+ active contributors
• Distributed ownership (top contributor 36% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

hyper is a low-level, high-performance HTTP/1 and HTTP/2 library for Rust with an asynchronous design built on tokio. It provides both client and server APIs and emphasizes correctness and production-ready performance, serving as the foundational HTTP transport layer for higher-level frameworks like Axum and reqwest. Modular library structure: src/ contains core HTTP logic split into client and server submodules, benches/ includes real-world performance tests (connect.rs, end_to_end.rs, pipeline.rs), examples/ shows usage patterns (client.rs, echo.rs, graceful_shutdown.rs), and capi/ provides a C FFI binding layer for non-Rust consumers via cbindgen.

Rust systems engineers and library authors who need a robust, minimal HTTP transport layer for building web services, HTTP clients, or frameworks; developers at companies like Discord and AWS who require battle-tested HTTP handling in production systems.

Highly mature and production-ready—at version 1.9.0 with extensive real-world deployment, active CI/CD via GitHub Actions (.github/workflows/CI.yml, bench.yml, cargo-audit.yml), comprehensive test coverage, and continuous maintenance. The repository demonstrates production-grade quality with explicit MSRV documentation, security policy, and governance guidelines.

Standard open source risks apply.

Active maintenance with benchmark-driven development (GitHub Actions: bench.yml runs on each commit), security auditing (cargo-audit.yml), and external types checking (external-types.toml). Documentation and governance practices are explicit in docs/ suggesting recent focus on community standards.

git clone https://github.com/hyperium/hyper.git
cd hyper
cargo build
cargo test
cargo run --example client

Optionally install Rust 1.63+ via rustup if needed.

Daily commands:

cargo build
cargo test                    # Run test suite
cargo bench                   # Run benchmarks in benches/
cargo run --example client    # Run the client example
cargo run --example echo      # Run the echo server example

Set RUST_LOG=debug for tracing output if tracing feature enabled.

• src/lib.rs — Main entry point and public API surface exposing Client, Server, Body, Request/Response types, and feature gates.
• src/client/mod.rs — Client connection management and request dispatch logic; required reading for anyone building HTTP client functionality.
• src/body/mod.rs — Core Body abstraction handling streaming payloads; critical for understanding request/response payload handling.
• src/proto/h1/conn.rs — HTTP/1 connection state machine implementation; foundational for understanding protocol-level framing.
• src/client/conn/http2.rs — HTTP/2 multiplexing and stream management; essential for HTTP/2 protocol knowledge.
• src/error.rs — Error type definitions and conversions; required for proper error handling across the library.
• Cargo.toml — Dependency manifest with feature flags controlling HTTP/2, client, server, and protocol features.

Add a new HTTP client feature (e.g., custom timeout handling)

1. Define public API in src/client/mod.rs, adding methods to ClientBuilder or Client struct (src/client/mod.rs)
2. Implement protocol-specific logic in src/client/conn/http1.rs or http2.rs (src/client/conn/http1.rs)
3. Add tests in src/client/tests.rs (src/client/tests.rs)
4. Create an example in examples/ demonstrating the new feature (examples/client.rs)

Add support for a new HTTP extension (e.g., custom headers or trailers)

1. Define extension trait in src/ext/mod.rs (src/ext/mod.rs)
2. Implement serialization/parsing in the relevant protocol handler (src/proto/h1/decode.rs or http2.rs) (src/proto/h1/decode.rs)
3. Export the extension from src/lib.rs if public-facing (src/lib.rs)
4. Add example demonstrating the extension in examples/ (examples/hello.rs)

Optimize body streaming performance (e.g., buffer sizing, chunking strategy)

1. Adjust buffer constants and strategies in src/body/mod.rs (src/body/mod.rs)
2. Refine frame sizing or buffering in src/proto/h1/conn.rs or http2.rs dispatcher (src/proto/h1/conn.rs)
3. Add benchmark in benches/body.rs to track throughput improvements (benches/body.rs)
4. Profile with benches/end_to_end.rs to validate improvements (benches/end_to_end.rs)

Add feature flag for optional dependency (e.g., compression support)

1. Add optional dependency and feature in Cargo.toml with [features] section (Cargo.toml)
2. Gate implementation behind #[cfg(feature = "...")] in src/lib.rs or relevant module (src/lib.rs)
3. Add integration tests in src/client/tests.rs or new test module (src/client/tests.rs)

• Tokio async runtime — Native async/await support; required for 1000s of concurrent connections with minimal threads
• http and http-body crates — Standard HTTP type ecosystem; enables interop with other Rust HTTP libraries (axum, tonic, etc.)
• bytes crate — Zero-copy buffer reference counting; critical for efficient body streaming without allocations
• HTTP/1 and HTTP/2 dual support — Ensures compatibility with all HTTP deployments; HTTP/2 multiplexing improves latency under high concurrency

• Low-level, protocol-focused design

  • Why: Provides maximum flexibility and control for library authors and framework builders
  • Consequence: Developers prefer higher-level libraries (reqwest, axum) for typical applications; requires careful error handling

• Connection pooling at Client level, not automatic global pool

  • Why: Explicit control allows per-connector tuning (timeouts, pool size, resolver strategy)
  • Consequence: Overhead for users to create and manage multiple clients; poor ergonomics for one-off requests

• Streaming Body abstraction (not buffered by default)

  • Why: Supports arbitrary payload sizes; memory efficient for large uploads/downloads
  • Consequence: Requires backpressure handling; harder to implement retries mid-stream

• Separate HTTP/1 and HTTP/2 state machines

  • Why: Protocol differences (multiplexing, settings, frames) justify separate codepaths for clarity
  • Consequence: More code duplication; independent bug fixes required for each protocol

• Does not provide high-level convenience APIs (e.g., built-in JSON serialization, cookies, redirects)
• Does not handle DNS resolution directly; delegates to underlying resolver (system or provided)
• Does not bundle TLS/HTTPS; expects user to wrap with tokio-rustls or rustls-native-roots
• Does not implement HTTP semantics (caching, conditional requests, authentication schemes)
• Not suitable for synchronous or blocking I/O patterns

Feature flags required: HTTP/2 support is behind the 'http2' feature flag and requires h2 crate—must enable explicitly in Cargo.toml or via cargo build --features http2. Async runtime locked: tokio is mandatory and cannot be swapped; other async runtimes are not supported. MSRV strict: Rust 1.63+ required (see docs/MSRV.md)—older toolchains will fail at build. C FFI maintenance: capi/ requires cbindgen to regenerate headers; manual edits to capi/include/hyper.h will break C consumers. Backpressure handling: want crate is optional but critical for proper flow control in streaming scenarios.

• HTTP/2 Multiplexing — hyper's HTTP/2 support (via h2 crate) multiplexes multiple concurrent requests over a single TCP connection—understanding how streams and settings frames differ from HTTP/1's keep-alive is critical for performance optimization and debugging connection issues
• Async/await and Pinning — hyper is pure async-await with heavy use of pin-project-lite—must understand Future trait, Pin<T>, and Unpin to modify protocol handlers or implement custom Service types without data races
• Tokio task scheduling and work stealing — hyper relies on Tokio's runtime for fair task scheduling across concurrent connections; understanding work-stealing queues and task spawning helps diagnose starvation or latency spikes under load
• Stream-based chunked transfer encoding — HTTP/1 bodies are streamed via HttpBody trait with optional chunked encoding; hyper must handle partial reads, backpressure signaling, and EOF detection—critical for large file uploads/downloads and proxying
• Connection pooling and backpressure (want crate) — hyper's client uses the want crate for demand-driven backpressure signaling between connection pools and request senders—prevents memory bloat under slow consumer scenarios
• HTTP/1 parser state machine (httparse) — hyper uses httparse for zero-copy HTTP/1 header parsing; understanding the state machine (incomplete vs. complete vs. error) is essential for debugging malformed request/response handling
• Service trait abstraction — hyper's server API is built around the Service<Request> → Future<Response> pattern (not explicit in Cargo.toml but core to architecture)—allows composing middleware and handlers; understanding this pattern is crucial for building server applications

• tokio-rs/tokio — Mandatory async runtime dependency; hyper's entire concurrency model depends on tokio's task scheduler and I/O reactor
• seanmonstar/reqwest — Higher-level HTTP client built on hyper—recommended by hyper's README for developers wanting convenience over control
• tokio-rs/axum — Web framework built on hyper's server APIs; demonstrates idiomatic use of hyper for real-world routing and middleware
• hyperium/http-body — Sibling crate defining the HttpBody trait that hyper depends on; required for streaming request/response bodies
• seanmonstar/warp — Alternative web framework (functional style) also built on hyper, showing different API design on the same foundation

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive HTTP/2 upgrade and protocol negotiation tests

The repo contains HTTP/2 support (h2 dependency, hello-http2.rs example) and upgrade examples (upgrades.rs) but the test coverage for protocol negotiation, ALPN handling, and H2C upgrades appears minimal based on the visible file structure. This is critical for correctness in production HTTP libraries.

• [ ] Create tests/h2_upgrade_integration.rs covering HTTP/1 to HTTP/2 upgrade flows
• [ ] Add tests for ALPN negotiation in src/client/conn/http1.rs and equivalent server paths
• [ ] Test H2C (HTTP/2 Cleartext) upgrade scenarios with Connection headers
• [ ] Verify proper fallback and error handling when HTTP/2 is unavailable

Add missing platform-specific CI workflows for MSRV validation and alternative runtimes

The repo documents MSRV (1.63) in docs/MSRV.md and mentions alternative runtimes like TokioRT in benches/support/tokiort.rs, but .github/workflows/ only shows CI.yml, bench.yml, and cargo-audit.yml. No workflow validates MSRV compliance or tests alternative executor compatibility.

• [ ] Create .github/workflows/msrv.yml to test against Rust 1.63 on each PR
• [ ] Add .github/workflows/alternative-runtimes.yml to validate non-Tokio executor compatibility
• [ ] Include a matrix testing different Tokio feature combinations (fs, macros, net, rt variants)
• [ ] Reference docs/MSRV.md in CI to ensure documented MSRV matches tested version

Expand C API binding examples and add FFI safety documentation

The capi/ directory exists with cbindgen configuration and basic client.c/upload.c examples, but there's no comprehensive guide for safe FFI usage, memory management patterns, or error handling in C. This is a barrier for C/C++ users adopting hyper.

• [ ] Create capi/docs/SAFETY.md documenting memory ownership, lifetime rules, and cleanup patterns
• [ ] Add capi/examples/error_handling.c showing proper error code handling and resource cleanup
• [ ] Add capi/examples/streaming.c demonstrating body streaming and backpressure handling
• [ ] Update capi/README.md with links to safety docs and example patterns for common use cases

• Add missing doctest examples to src/client/mod.rs and src/server/mod.rs—many public types lack runnable doc examples despite having doc comments; pick one struct and add a complete, standalone example demonstrating its use.
• Extend benches/pipeline.rs with HTTP/2 multiplexing scenarios—current benchmarks favor HTTP/1; add a realistic test comparing sequential vs. multiplexed HTTP/2 request performance to guide optimization efforts.
• Write integration tests for graceful shutdown patterns in tests/ directory—examples/graceful_shutdown.rs exists but there are no automated tests validating shutdown semantics; create a test that verifies in-flight requests complete before listener stops accepting.

The hyper HTTP library demonstrates a strong security posture with proper dependency management (MIT license, established packages from hyperium ecosystem), a transparent security policy with private advisory process, and Rust's memory safety guarantees mitigating common HTTP vulnerabilities (buffer overflows, use-after-free). Minor concerns exist around dependency version consistency, optional feature coverage, and C API binding safety. The codebase shows no evidence of hardcoded secrets, SQL injection risks, or XSS vulnerabilities (appropriate for a low-level protocol library). The project maintains good CI/CD practices and encourages responsible disclosure. No critical vulnerabilities identified.

• Medium · Dependency Version Pinning - futures-core — Cargo.toml - dependencies section. The dependency 'futures-core' is pinned to version 0.3.31 in dev-dependencies but uses a caret requirement in regular dependencies (0.3), which allows minor version updates. This could introduce unexpected behavior changes between development and production builds. Fix: Consider using consistent version pinning strategies across all dependency declarations, or explicitly document the rationale for version flexibility.
• Low · Optional Dependency Security Coverage — Cargo.toml - optional dependencies section. Several security-critical optional dependencies (h2, httparse, http-body-util) lack explicit MSRV alignment documentation. If features are selectively enabled, different versions may be pulled with different MSRV compatibility. Fix: Document which optional features are security-sensitive and ensure consistent MSRV compliance across all dependency combinations. Consider running cargo-audit with all feature combinations.
• Low · Missing Cargo.lock in Repository — .github/workflows/CI.yml. As a library crate, the absence of Cargo.lock is appropriate. However, the CI pipeline should explicitly verify reproducible builds and dependency auditing. Fix: Ensure CI includes 'cargo audit' for all dependency checks (noted in the file structure, but not visible in the provided excerpt). Verify the CI.yml includes dependency security scanning.
• Low · C API (capi) Binding Security — capi/ directory (client.c, upload.c examples). The capi directory contains C language bindings generated via cbindgen. C FFI code has inherent security risks (memory safety, bounds checking). The provided excerpts show client.c and upload.c examples. Fix: Ensure all C examples and generated bindings undergo security review. Add safety documentation to the capi/README.md regarding proper memory management and input validation. Consider adding fuzz testing for C API boundaries.
• Low · Incomplete Security Policy — SECURITY.md. SECURITY.md directs users to GitHub Security Advisory private reports, which is correct. However, there are no specific security guarantees mentioned regarding HTTP parsing, TLS, or protocol compliance. Fix: Enhance SECURITY.md to specify scope of security guarantees (e.g., 'covers HTTP protocol parsing but not TLS implementation'). Document supported versions and security patch timelines.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/hyperium/hyper shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live hyperium/hyper repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/hyperium/hyper.

What it runs against: a local clone of hyperium/hyper — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in hyperium/hyper | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of hyperium/hyper. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/hyperium/hyper.git
#   cd hyper
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of hyperium/hyper and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "hyperium/hyper(\\.git)?\\b" \\
  && ok "origin remote is hyperium/hyper" \\
  || miss "origin remote is not hyperium/hyper (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/lib.rs" \\
  && ok "src/lib.rs" \\
  || miss "missing critical file: src/lib.rs"
test -f "src/client/mod.rs" \\
  && ok "src/client/mod.rs" \\
  || miss "missing critical file: src/client/mod.rs"
test -f "src/body/mod.rs" \\
  && ok "src/body/mod.rs" \\
  || miss "missing critical file: src/body/mod.rs"
test -f "src/proto/h1/conn.rs" \\
  && ok "src/proto/h1/conn.rs" \\
  || miss "missing critical file: src/proto/h1/conn.rs"
test -f "src/client/conn/http2.rs" \\
  && ok "src/client/conn/http2.rs" \\
  || miss "missing critical file: src/client/conn/http2.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/hyperium/hyper"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.