An HTTP/1.1 request arrives carrying both a Content-Length header field and Transfer-Encoding: chunked. What do the framing rules say a recipient must do, and why does disagreement between a front-end proxy and a back-end server on this point create a security problem?

## The precedence rule HTTP/1.1's message-length algorithm is ordered. Roughly: responses to HEAD and 1xx, 204, 304 have no body regardless of fields; otherwise, if `Transfer-Encoding` is present with `chunked` as the final coding, chunked framing applies and any `Content-Length` is ignored; otherwise a valid Content-Length applies; otherwise a request has no body and a response is close-delimited. So formally Transfer-Encoding wins. But the specification also forbids senders from combining the two, and instructs recipients to treat the combination as an error: a server should respond `400 Bad Request` and close the connection, and an intermediary must remove Content-Length before forwarding, or reject outright. The reason is not pedantry — it is that the only way both fields appear on the same request is a bug or an attack. Related ambiguities carry the same treatment: two `Content-Length` fields with different values, a Content-Length that is not a plain decimal number, or a Transfer-Encoding whose final coding is not chunked in a request. All are unrecoverable framing errors, not things to normalise into a best guess. ## How disagreement becomes an exploit HTTP request smuggling exploits two servers in a chain that resolve the ambiguity differently, while sharing one persistent connection between them. **CL.TE:** the front end frames by Content-Length and forwards the whole byte range; the back end frames by chunked and stops at the terminal `0` chunk. The bytes after that chunk stay in the back end's buffer and are prepended to whatever arrives next on that connection. **TE.CL:** the mirror image. The front end honours chunked, the back end honours Content-Length, and again a tail of attacker bytes is left over. **TE.TE:** both honour Transfer-Encoding in principle, but the attacker obfuscates the field (odd whitespace, duplicated field, a bogus additional coding) so that exactly one of them fails to recognise it and falls back to Content-Length. The leftover tail is chosen by the attacker to look like the beginning of a request: a method, a path, and headers with no terminating blank line. When the next victim's request arrives on the same connection, it is appended to that fragment. The consequences are severe: bypassing front-end authorisation and path-based access control (the front end never saw the smuggled path), capturing the victim's request — including their session cookie — into a body the attacker can read back, cache poisoning, and forced responses to other users. ## Defences that actually work 1. **Reject, do not normalise.** Any request with both fields, duplicate conflicting Content-Length, or malformed chunked syntax gets `400` and the connection is closed — closing matters, because leaving the connection open leaves the desynchronised buffer in play. 2. **Make the front end strict and identical to the back end.** Ambiguity is only exploitable when two parsers disagree; the fix is a single canonical parse, not two lenient ones. 3. **Prefer HTTP/2 (or HTTP/3) end to end.** Their framing is explicit in the binary layer, with length carried by DATA frames and END_STREAM, so the class of ambiguity largely disappears. Note the caveat: HTTP/2 front end downgrading to HTTP/1.1 upstream reintroduces it, since the proxy must synthesise Content-Length or chunked — this is the well-known H2.CL and H2.TE family. Do not let HTTP/2 pseudo-header values or a smuggled `transfer-encoding` field survive the downgrade. 4. **Limit connection reuse to the back end** where you cannot audit the stack. One connection per request removes the shared buffer that smuggling depends on, at a throughput cost. 5. **Reject requests carrying Transfer-Encoding over HTTP/2**, which the specification forbids anyway. ## How to talk about it A strong answer names the precedence rule, states that the correct response is rejection rather than resolution, explains the desync as a shared persistent connection whose two ends disagree about a message boundary, and lists mitigations in the order of highest leverage: uniform strict parsing, then protocol upgrade, then connection hygiene.