HTTP client library for Rust
This library is composed of 3 feature-gated layers:
- Low-level I/O-free coroutines: no_std-compatible state machines containing the whole HTTP logic, usable anywhere
- Mid-level light client: a standard, blocking client wrapping a stream you opened yourself
- High-level full client: the light client plus TCP connections and TLS negotiations handled for you
- I/O-free coroutines: no_std state machines with no sockets and no async runtime, resumable from any blocking, async or in-memory test harness.
- HTTP/1.0 and HTTP/1.1: send a request and receive its response, with fixed-length, chunked and read-to-EOF body strategies; redirects are surfaced to the caller, never followed silently.
- Streaming: decode a long-lived chunked response one chunk at a time and consume server-sent events as they arrive.
- Authentication helpers: build and parse basic and bearer authorization values, with credentials redacted from debug output and logs.
- Well-known discovery: probe the reserved well-known location of a service and surface where it redirects.
- Light standard, blocking client wrapping a stream you opened yourself
- Full standard, blocking client with TLS support:
- Rustls with ring crypto (requires
rustls-ringfeature, enabled by default) - Rustls with aws crypto (requires
rustls-awsfeature) - Native TLS (requires
native-tlsfeature)
- Rustls with ring crypto (requires
Tip
I/O HTTP is written in Rust and uses cargo features to gate backend support. The default feature set is declared in Cargo.toml or on docs.rs.
| RFC | What is covered |
|---|---|
| 1945 | HTTP/1.0: send a request and receive its response, connections closing after each exchange by default |
| 6750 | Bearer authentication: carry an OAuth 2.0 access token in the authorization header |
| 7617 | Basic authentication: carry a base64-encoded username and password pair in the authorization header |
| 8615 | Well-known discovery: probe the reserved well-known path of an origin and surface the redirect target |
| 9110 | HTTP semantics: the version-agnostic request, response, status code and authentication challenge model shared by every wire format |
| 9112 | HTTP/1.1: send a request and receive its response, including chunked bodies, both whole and streamed |
| SSE | Server-sent events (WHATWG HTML Living Standard): decode an event stream one event at a time |
The whole API is documented on docs.rs, including runnable snippets for every coroutine and client.
Complete runnable programs live in ./examples; the tests also demonstrate real usage.
This project is developed with AI assistance. This section documents how, so users and downstream packagers can make informed decisions.
- Tools: Claude Code (Anthropic), invoked locally with a persistent project-scoped memory and a small set of repo-specific rules.
- Used for: Refactors, mechanical multi-file edits, boilerplate (feature gates, error enums, derive macros, trait impls), test scaffolding, doc polish, exploratory design conversations.
- Not used for: Engineering, critical code, git manipulation (commit, merge, rebase…), real-world tests.
- Verification: Every AI-assisted change is read, compiled, tested, and formatted before commit. Behavioural correctness is verified against the relevant RFC or upstream spec, not assumed from the model output. Tests are never adjusted to fit AI-generated code; the code is adjusted to fit correct behaviour.
- Limitations: AI models occasionally produce code that compiles and passes tests but is subtly wrong. The verification workflow catches most of this; it does not catch all of it. Bug reports are welcome and taken seriously.
- Last reviewed: 13/06/2026
This project is licensed under either of:
at your option.
- Chat on Matrix
- News on Mastodon or RSS
- Mail at pimalaya.org@posteo.net
Contributions are welcome: start with CONTRIBUTING.md, which opens with the Pimalaya-wide guides to read first.
Special thanks to the NLnet foundation and the European Commission that have been financially supporting the project for years:
- 2022 → 2023: NGI Assure
- 2023 → 2024: NGI Zero Entrust
- 2024 → 2026: NGI Zero Core
- 2027 in preparation…
If you appreciate the project, feel free to donate using one of the following providers:
