Transfer-Encoding Streaming
Transfer-Encoding chunked streams a response of unknown length by framing each chunk with its size, so the server can begin sending before the total is computed.
Definition
Transfer-Encoding chunked is the HTTP/1.1 mechanism where the response body is sent as a sequence of length-prefixed chunks terminated by a zero-length chunk, so that the server can stream a response whose total length is unknown or not yet computed without buffering it to set Content-Length.
Context and scope
Applied in server-sent events, streaming APIs, and any response where the body is produced incrementally and the total length is not known up front.
Common misconceptions
- Chunked is just streaming — it is the HTTP/1.1 streaming mechanism; HTTP/2 and HTTP/3 stream natively with length-prefixed frames and do not need chunked
- Content-Length and chunked are interchangeable — they are not; a response can use one or the other, and intermediaries may buffer chunked to compute Content-Length, defeating streaming
Anti-patterns
- Sending chunked through a buffering proxy that waits for the end to compute Content-Length, turning a stream into a blocking response
- Mixing chunked with a Content-Length header, which is a protocol violation and produces undefined behavior
Related concepts
Authoritative source
https://datatracker.ietf.org/doc/html/rfc9112#chunked.encoding
What it is
Transfer-Encoding chunked is the HTTP/1.1 mechanism where the response body is sent as a sequence of length-prefixed chunks terminated by a zero-length chunk, so that the server can stream a response whose total length is unknown or not yet computed without buffering it to set Content-Length. Applied in server-sent events, streaming APIs, and any response where the body is produced incrementally and the total length is not known up front. 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.