HTTP request smuggling begins when two components disagree about where one request ends and the next begins. A front-end proxy and back-end server may apply different rules to Content-Length, Transfer-Encoding, duplicate fields, invalid whitespace, folded lines, or line endings.
This analyzer checks the pasted HTTP/1.0 or HTTP/1.1 request text only. It does not send traffic, probe a host, emulate a named proxy, or prove whether an exact deployment resolves an ambiguity as CL.TE, TE.CL, or another variant.
A framing finding is therefore a trust-boundary warning: reject ambiguous requests at the first hop, normalize once, and ensure every intermediary follows the same parsing policy. Validate the actual component chain in an authorized environment before drawing exploitability conclusions.
Edge cases worth knowing
- Two identical Content-Length fields
- Identical values may be accepted by some recipients, but duplicate framing fields still expand the parser-differential surface and should be rejected or normalized before forwarding.
- Transfer-Encoding: gzip, chunked
- Chunked is final as required, but support for additional transfer codings varies. The analyzer reports only the non-canonical or ambiguous cases it can observe statically.
- A request with a body
- The first release analyzes the request line and header framing. It does not certify chunk sizes, trailers, or whether the supplied body length matches Content-Length.
Common mistakes
- Labeling every Content-Length plus Transfer-Encoding request as a proven CL.TE exploit.
- Testing request smuggling against systems without explicit authorization.
- Normalizing ambiguous headers differently at separate hops.
- Assuming a clean static header check proves the entire proxy chain parses requests identically.