HTTP Trailers Streaming
HTTP trailers send headers after the body, so a streaming response can include a checksum or final status that is only known once the body is complete.
Definition
HTTP trailers are header fields sent in a chunk after the body, so that a server streaming a response of unknown length can include metadata — a checksum, a final row count, a commit status — that is only computable once the body is fully generated, without buffering the body to compute a header up front.
Context and scope
Applied in streaming APIs, large data exports, and any response where the body is produced incrementally and a summary or integrity check is needed at the end.
Common misconceptions
- Trailers are just footers — they are footers in the HTTP sense, with a defined parsing model; an ad-hoc footer in the body is not a trailer
- Trailers work in every client — they work in HTTP/1.1 chunked and HTTP/2; some clients and intermediaries drop them, so the client must handle their absence
Anti-patterns
- Putting a checksum in a trailer without announcing it in the header, so the client does not know to look for it
- Relying on a trailer passing through a proxy that strips unknown trailers, losing the integrity check silently
Related concepts
Authoritative source
What it is
HTTP trailers are header fields sent in a chunk after the body, so that a server streaming a response of unknown length can include metadata — a checksum, a final row count, a commit status — that is only computable once the body is fully generated, without buffering the body to compute a header up front. Applied in streaming APIs, large data exports, and any response where the body is produced incrementally and a summary or integrity check is needed at the end. The protocol’s semantics — safe versus unsafe, idempotent versus non-idempotent, cacheable versus non-cacheable — are contracts the client and intermediary rely on, and violating them breaks the web.
How it works
Headers carry the negotiation: content type, encoding, caching directives, and conditional request validators together let a client and server reach the cheapest correct response. Connection reuse eliminates handshake overhead; multiplexing removes head-of-line blocking; streaming avoids buffering the entire body. Each feature has a failure mode — keep-alive on a broken proxy, multiplexing with a misbehaving server — that must be detected and handled.
When to apply and pitfalls
Apply whenever a client and server communicate across a trust boundary the protocol already spans. The pitfall is treating HTTP as a transport and ignoring its semantics — POSTing a retrieval, marking a mutating request cacheable, or omitting the validator that would enable a 304. Intermediaries — CDNs, proxies — implement the standard literally, so semantic violations produce surprising behavior far from the origin.