Skip to content

fix(http1): discard content-length header when received before transfer-encoding#4124

Open
seanmonstar wants to merge 1 commit into
masterfrom
sean/mnuvznxsywvo
Open

fix(http1): discard content-length header when received before transfer-encoding#4124
seanmonstar wants to merge 1 commit into
masterfrom
sean/mnuvznxsywvo

Conversation

@seanmonstar

Copy link
Copy Markdown
Member

While hyper currently recognizes the correct message payload semantics when both content-length and transfer-encoding headers are sent, there are cases where it doesn't always strip the canceled content-length header.

This fix now correctly removes the header if it was seen before transfer-encoding.

It also now sets the connection to close at the end of the message, as recommended in the new RFC 9112.

(To be clear, the semantics have always been correct. This reduces the possibility of forwarding confusing headers to a remote that doesn't know how to act correctly.)

Thanks @bardiharborow

Closes #4123

…er-encoding

While hyper currently recognizes the correct message payload semantics when both
content-length and transfer-encoding headers are sent, there are cases where it
doesn't always strip the canceled content-length header.

This fix now correctly removes the header if it was seen before transfer-encoding.

It also now sets the connection to close at the end of the message, as
recommended in the new RFC 9112.

(To be clear, the semantics have always been correct. This reduces the possibility
of forwarding confusing headers to a remote that doesn't know how to act correctly.)

Closes #4123
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.

Server retains Content-Length when Transfer-Encoding is present if Content-Length appears first

2 participants