1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
//! Zero-allocation thread-per-core HTTP/1.1 server.
//!
//! For the `hyper-backend` feature's design and build plan, see
//! `docs/superpowers/specs/2026-08-03-hyper-backend-design.md` and
//! `docs/superpowers/plans/2026-08-03-hyper-backend.md`.
//!
//! # Design
//!
//! Request heads are parsed into [`Bytes`](bytes::Bytes) slices of the
//! connection's own read buffer, so header values and bodies cost a refcount
//! increment rather than an allocation. That buffer is allocated once when the
//! connection is created and reused for every request on it — there is no
//! cross-connection buffer pool, because a buffer that outlives its connection
//! is a buffer a handler can still be holding a slice of. Framing decisions live
//! in one pure function and every rejection closes the connection rather than
//! resynchronizing the stream.
//!
//! # Backends
//!
//! The `hyper-backend` cargo feature swaps the per-connection serving path
//! from this crate's bespoke protocol stack to hyper's `conn::http1`, behind
//! the identical public API. **This feature is non-additive**: enabling it
//! anywhere in a dependency graph changes what every consumer of this crate
//! gets, because Cargo unifies features across the whole build — it is not
//! possible for one crate to opt in while another stays on the native
//! backend. The two backends diverge in parsing, status-code choice, and
//! timing in ways that cannot be fully shimmed; see `BACKENDS.md` at the
//! crate root for the exhaustive, version-pinned list. Anyone depending on
//! this crate, directly or transitively, should read it before enabling the
//! feature.
pub use serve_connection;
pub use ByteStr;
pub use ;
pub use ;
pub use ConnDeadline;
pub use ;
pub use Head;
pub use ;
pub use Limits;
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;