[ziyziy89]

HTTP1xCodec::generateHeader writes every header it is given and appends the deferred Content-Length last, so a message carrying both Transfer-Encoding: chunked and Content-Length goes out with both while generateBody chunk-encodes the body. Ingress hands applications exactly such a message: http_parser frames TE+CL by the chunking, and HTTPTransaction only checks that the dechunked body adds up to the Content-Length. A relay that forwards it without calling stripPerHopHeaders (the bundled sample proxy is one) sends both headers upstream, and since egress re-chunks every body piece, the forwarded Content-Length no longer matches the bytes on the wire. A backend that frames by Content-Length (TE.CL desync, CWE-444) then parses the tail of the client's body as its own request. Example: 50 one-byte chunks followed by an fe chunk holding GET /admin HTTP/1.1 ..., sent with Content-Length: 304 (the dechunked size). proxygen forwards Content-Length: 304, the 304th forwarded body byte is the end of fe\r\n, and the backend's next request is GET /admin. Responses relayed to a client take the same path.

Skip the deferred Content-Length once Transfer-Encoding: chunked has actually been written. RFC 9112 section 6.1 says a sender MUST NOT send Content-Length in a message that has Transfer-Encoding, and doing it in the serializer covers relays and application-built messages alike; the HTTP/1.0 dechunk path is unchanged because no Transfer-Encoding is written there. HttpShortContentLength built its TE+CL request through the client codec, so it now writes those bytes directly and keeps covering the server-side Content-Length/body mismatch check. The two new HTTP1xCodecTest cases fail before the change and pass after it, and the full ctest run (1820 tests) passes.

[meta-codesync]

@afrind has imported this pull request. If you are a Meta employee, you can view this in D129465359.