Skip to content

fix(http1): drop Content-Length when a response also has Transfer-Encoding - #4264

Merged
seanmonstar merged 1 commit into
hyperium:masterfrom
kevin9327:fix-http1-client-te-drops-content-length
Nov 13, 2026
Merged

seanmonstar merged 1 commit into
hyperium:masterfrom
kevin9327:fix-http1-client-te-drops-content-length

Conversation

@kevin9327

Copy link
Copy Markdown
Contributor

The HTTP/1 server decoder already removes Content-Length when Transfer-Encoding is present. The client decoder already used Transfer-Encoding for the body length, but still left both headers on the response.

RFC 7230 §3.3.3 says Transfer-Encoding overrides Content-Length. This removes Content-Length from parsed HTTP/1 responses in that case, so callers cannot treat it as authoritative.

test_decoder_response now covers both header orders, including a 5-byte chunked body advertised with Content-Length: 100000 as in #4263.

Closes #4263

…oding

The HTTP/1 server decoder already removes Content-Length when
Transfer-Encoding is present. The client decoder preferred
Transfer-Encoding for the body length, but still exposed both headers.

RFC 7230 §3.3.3 says Transfer-Encoding overrides Content-Length. Remove
the Content-Length header from parsed responses so callers cannot treat
it as authoritative.

Closes hyperium#4263
@cratelyn cratelyn closed this Nov 12, 2026
@cratelyn

Copy link
Copy Markdown
Member

duplicate of #4181.

@seanmonstar seanmonstar reopened this Nov 13, 2026
@seanmonstar

Copy link
Copy Markdown
Member

Actually, I much prefer the simplicity of this fix over the other PR 🤓

@seanmonstar
seanmonstar merged commit 378f847 into hyperium:master Nov 13, 2026
23 of 25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

http1 client keeps content-length when transfer-encoding is also present

3 participants