Cybersecurity glossary
What is Transfer-Encoding?
Learn what the Transfer-Encoding HTTP header does, how chunked encoding streams bodies, why it conflicts with Content-Length, and how parser disagreements enable HTTP request smuggling.
Definition
Transfer-Encoding is an HTTP message header that specifies encodings applied to the payload body so it can be safely transferred—most notably chunked, which sends the body as a sequence of chunks—while defining how receivers determine message boundaries on the wire.
Why Transfer-Encoding matters
HTTP/1.1 messages need a reliable way to know where the body ends—especially for streaming responses and dynamic content. Transfer-Encoding: chunked solves that without precomputing Content-Length. But the same mechanism becomes dangerous when two parsers in a chain disagree about which header defines the boundary.
That disagreement is the root of HTTP request smuggling: a proxy may think the request ends at one byte while the origin treats trailing bytes as a new, attacker-controlled request on a reused connection.
How chunked Transfer-Encoding works
Sender chooses chunked
When body length is unknown or streaming is desired, Transfer-Encoding: chunked is set.
Body is split into chunks
Each chunk has a hex size line, data, and CRLF; a zero chunk terminates the message.
Receiver reassembles
The parser reads chunks until the terminating zero chunk and optional trailers.
Connection may be reused
On keep-alive connections, the next bytes must be a new message—not leftover smuggled data.
Ambiguity enables smuggling
If another hop uses Content-Length instead, boundary mismatch hides a second request.
Transfer-Encoding vs Content-Length
Transfer-Encoding: chunked
Boundary defined by chunk framing; supports streaming and unknown lengths.
Content-Length
Fixed byte count defines the entire body; simple but requires known size.
Mutual exclusion
Valid HTTP/1.1 messages should not combine both; reject ambiguous inputs.
Parser agreement
Every hop must use the same rule or desync attacks become possible.
Smuggling patterns involving Transfer-Encoding
| Pattern | Frontend honors | Backend honors |
|---|---|---|
| CL.TE | Content-Length (stops early) | Transfer-Encoding (reads smuggled tail) |
| TE.CL | Transfer-Encoding (chunked) | Content-Length (ignores chunk tail) |
| TE.TE | Conflicting TE variants | Different TE normalization |
| HTTP/2 downgrade | HTTP/2 gateway | HTTP/1.1 origin with TE ambiguity |
Security checklist
- Reject requests and responses that send both Content-Length and Transfer-Encoding.
- Normalize HTTP parsing at one trusted edge; do not let each microservice reinterpret boundaries.
- Disable HTTP/1.1 keep-alive reuse on paths where frontend and backend parsers may disagree.
- Patch reverse proxies, CDNs, and WAFs; smuggling is often a known-class desync bug.
- Prefer HTTP/2 or HTTP/3 between client and edge to avoid classic CL/TE on that segment.
- Test authorized desync scenarios on the real CDN-to-origin chain, not only the origin alone.
- Treat unexpected 400-series rejects at the edge as preferable to silent desynchronization.
Legitimate uses of chunked encoding
Chunked encoding remains essential for live-generated responses, progressive HTML, long-polling style streams, and backends that flush output before the total size is known. Problems arise not from chunked itself but from inconsistent chunked handling between components.
Trailers—optional headers after the final chunk—add further parser surface area. Strict implementations should accept only standards-compliant trailer sets.
Limits and pitfalls
HTTP/2 and HTTP/3 remove chunked bodies on those hops, but many architectures still downgrade to HTTP/1.1 toward legacy apps. A “modern” client path does not eliminate smuggling if the origin speaks HTTP/1.1 behind a translating gateway.
Teams also confuse Transfer-Encoding (hop-by-hop body coding on HTTP/1.1) with Content-Encoding (compression such as gzip). They solve different problems; mixing terminology leads to misconfigured proxies.
The practical takeaway
Transfer-Encoding—especially chunked—defines how HTTP/1.1 bodies are framed on the wire. Treat consistent boundary parsing as a security requirement: when a proxy and origin disagree with Content-Length, request smuggling follows. Reject ambiguous messages, align parsers across the chain, and validate the full edge-to-origin path.
Related security terms
HTTP Request Smuggling
Attacks that exploit conflicting Content-Length and Transfer-Encoding parsing.
HTTP Header Injection
CRLF injection that can manipulate headers including Transfer-Encoding.
Reverse Proxy
Intermediaries that must parse chunked bodies the same way as origins.
HTTP/2
Uses DATA frames instead of HTTP/1.1 chunked bodies on that hop.
Frequently asked questions
What is Transfer-Encoding in simple terms?
It tells the receiver how the HTTP body is packaged on the wire. The most common value is chunked, which sends the body in pieces so the sender does not need to know the total size upfront.
What does chunked mean?
chunked splits the body into chunks, each with its own size line, followed by a zero-length chunk that ends the message. Receivers reassemble the chunks into the full body.
How does Transfer-Encoding relate to request smuggling?
When a frontend and backend disagree on whether to use Content-Length or Transfer-Encoding to find the end of a message, leftover bytes can be interpreted as a second request. That desync is the basis of CL.TE and TE.CL smuggling.
Can a message have both Content-Length and Transfer-Encoding?
HTTP/1.1 forbids sending both on the same message in most cases. Ambiguous or duplicated signals are exactly what smuggling exploits; compliant stacks should reject them.
Is Transfer-Encoding used on HTTP/2 responses?
HTTP/2 does not use chunked Transfer-Encoding on the wire; framing handles stream bodies. Gateways that translate HTTP/2 to HTTP/1.1 may reintroduce chunked encoding toward legacy origins.
How do you reduce Transfer-Encoding security risk?
Reject ambiguous messages, normalize parsing at a single trusted edge, disable risky HTTP/1.1 reuse when parsers disagree, patch proxies, and prefer HTTP/2 end-to-end where possible.
References
Explore authoritative guidance and frameworks related to transfer-encoding.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.