Request smuggling happens when two HTTP processors, such as a front proxy and a back end server, disagree about where one request ends and the next begins. RFC 9112 gives clear framing rules for Content-Length and Transfer-Encoding. Trouble starts when a component accepts ambiguity the RFC says to reject.
How a body length is decided
RFC 9112 section 6.3 lists framing rules in order of precedence. The ones that matter here:
- If Transfer-Encoding is present and chunked is the final coding, the body ends when the chunked data is fully decoded.
- Otherwise, a valid Content-Length defines the body length in octets.
- A request with neither header has a zero length body. Requests are never delimited by closing the connection.
- A response with neither header ends when the server closes the connection.
When both headers appear
The RFC says Transfer-Encoding overrides Content-Length, and that such a message ought to be handled as an error. Senders must not send Content-Length in a message that contains Transfer-Encoding. A server may reject the request or process it using Transfer-Encoding alone, but either way it must close the connection afterward.
The warning is explicit: forwarding such a message can lead to request smuggling vulnerabilities. An intermediary that forwards one must remove the Content-Length and process Transfer-Encoding first. Section 11.2 defines smuggling as exploiting differences in protocol parsing among various recipients.
What an attack looks like in principle
Picture a proxy that frames a request using Content-Length and a back end that frames the same bytes using Transfer-Encoding. Bytes the proxy treats as part of one request, the back end treats as the start of a second. That second request is processed on a connection shared with other users, so it can interfere with someone else's request. We keep the explanation conceptual here on purpose, since the defense is about configuration, not about exploit strings.
Other parsing laxness that feeds smuggling
- Lenient whitespace. The RFC says accepting non-standard whitespace in the request line can cause smuggling when recipients interpret it differently.
- Bare CR. A bare CR must be treated as invalid or replaced with a space, and whitespace before the first header field must be rejected or stripped.
- Invalid Content-Length. In a request it is an unrecoverable error: respond 400 and close the connection.
- Unknown final coding. A request whose final Transfer-Encoding coding is not chunked gets a 400 and the connection closes.
Practical defenses
- Keep proxies, load balancers and application servers on supported versions, and update them promptly. Recent smuggling bugs in servers show up in advisories such as this one for async Python servers.
- Use the same HTTP parsing behavior end to end, or terminate and re-originate requests with HTTP/2 or a strict parser on the back end leg.
- Configure the front end to reject messages with both headers, or to normalize them.
- Close the connection after any framing error instead of reusing it.
- Do not process extra data after the final response as a separate response, which the RFC says would enable cache poisoning.
- Test your own stack with a scanner or a lab, never against systems you do not own.
Where Safeguard fits
Safeguard does not run your proxies or network layer. It scans dependencies and SBOMs for known vulnerabilities, including the HTTP servers and libraries you ship, and reachability analysis helps show which issues are actually used. A free scan is at gold.safeguard.sh/scan.
Quick check
Which header wins if both are present?
Transfer-Encoding overrides Content-Length under RFC 9112, and the message ought to be treated as an error.
What should a server do after a framing error?
Respond with an error such as 400 where the RFC says so, and close the connection instead of reusing it.
Sources
Last reviewed: 19 October 2026.
