How it works

The classic ambiguity: Content-Length vs Transfer-Encoding. A request can declare its body length two ways. If a front-end honours one and the back-end the other, bytes "leak" past the boundary.

   CL.TE  -- front-end uses Content-Length, back-end uses Transfer-Encoding:
     POST / HTTP/1.1
     Host: victim
     Content-Length: 6
     Transfer-Encoding: chunked

     0

     G
   Front-end: body is 6 bytes ("0\r\n\r\nG"), forwards the whole thing.
   Back-end: chunked; "0\r\n\r\n" ends the request; "G" is left in the
     buffer and PREPENDED to the next request on that connection ->
     "GPOST / HTTP/1.1 ..." (a broken method for the victim), or a fuller
     payload smuggles a complete request.

   TE.CL  -- front-end uses TE, back-end uses CL: mirror image, chunk-size
     line games.

   TE.TE  -- both do TE, but one is tricked into NOT processing it via
     obfuscation:
       Transfer-Encoding : chunked          (space before colon)
       Transfer-Encoding: xchunked
       Transfer-Encoding:\tchunked
       Transfer-Encoding\n : chunked
       (two TE headers, one valid one junk)

HTTP/2 makes it worse via downgrade. HTTP/2 has an unambiguous, explicit length — so h2-to-h2 is safe. But a front-end that speaks h2 to the client and downgrades to h1 for the back-end must synthesise Content-Length/TE, and:

   H2.CL / H2.TE   the h2 request declares one length; the front-end
     rewrites to h1 with a conflicting CL or an injected TE that the
     back-end honours.
   H2 CRLF INJECTION   h2 header names/values can contain bytes that,
     when serialised to h1, become "\r\n" -> the attacker injects entire
     headers or a request line -> request splitting.
   H2 request smuggling via header-name/pseudo-header abuse.

Client-side desync (James Kettle, 2022): the browser itself is the smuggling engine. A malicious page makes a fetch() whose body is left straddling the connection boundary; the next request the browser sends on that reused connection is poisoned — no back-end proxy required, and it works against the victim's own authenticated session.

Impact:

   - bypass front-end controls: smuggle a request to /admin past a WAF /
     auth proxy that only inspected the outer request.
   - capture other users' requests: smuggle a request whose body is a
     large parameter; the victim's following request gets appended into
     that parameter and (if the app stores/reflects it) you read their
     headers, cookies, CSRF tokens.
   - response queue poisoning: desync the response stream so User B gets
     User A's response (or your injected one) -> mass credential/session
     theft, cache poisoning (Ch 31).
   - forced browser cache poisoning / persistent XSS via the above.

Detection: timing probes (a partial smuggled request makes the next request hang for the socket timeout — a reliable differential), and differential responses. Tools: Burp HTTP Request Smuggler extension, smuggler.py, h2csmuggler, Burp's "Turbo Intruder" for the concurrency.