Hi, thanks for the quick fix!

PR #610 fully addresses Finding 2 (duplicate Content-Length) -- the duplicate header is correctly dropped before insertion.

Finding 1 (CL/TE) is partially addressed. The else branch at line 929 removes the Content-Length header from forwarded headers, but content_length.client still holds the CL value. So tinyproxy reads CL bytes from the client internally, while only Transfer-Encoding: chunked reaches the backend. The backend parses the body as chunked, which means an attacker can embed a chunked terminator (0\r\n\r\n) early in the CL-delimited body and the backend treats everything after it as a new HTTP request.

For example with Content-Length: 50 + Transfer-Encoding: chunked, tinyproxy reads 50 bytes and forwards them, but the backend stops at the chunked terminator and parses the remaining bytes as a new request.

The else branch should also set content_length.client = -2 to switch to chunked body reading, or alternatively reject the request with 400 (which is what RFC 7230 Section 3.3.3 recommends for proxies that cannot handle the ambiguity).

ah sure, you're right.
force-pushed a fix, looking good now?

Looks good, both findings are addressed now. Thanks for the quick turnaround!

Same feedback: now that this is merged, would you be open to requesting CVE IDs? There are two distinct smuggling vectors (CL/TE desync and duplicate Content-Length), so ideally two CVEs. No rush -- happy to help with the process if needed.

would you be open to requesting CVE IDs?

i was under the impression that's something the security people can do on their own. so far it never needed my assistance to get CVEs assigned.

Sure, I'll handle the CVE requests. Thanks for the quick turnaround on the fix.