Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP/1.1 Transfer-Encoding uses wrong Content-Length handling #7643

bagder opened this issue Aug 26, 2021 · 0 comments

HTTP/1.1 Transfer-Encoding uses wrong Content-Length handling #7643

bagder opened this issue Aug 26, 2021 · 0 comments


Copy link

bagder commented Aug 26, 2021

As laid out in RFC 7230 section 3.3.3 Content-Length must be ignored if any Transfer-Encoding is present in the response. Not only chunked like curl behaves now.

As the spec (clarified like this long after curl's initial implementation) says

If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding,
the message body length is determined by reading the connection until it is closed by the server.

Transfer-Encoding for anything else but chunked is rarely used, which is probably why this hasn't been reported earlier.

Right now, curl acknowledges and uses the content-length as the size of the compressed presentation in the body.

@bagder bagder added the HTTP label Aug 26, 2021
@bagder bagder linked a pull request Aug 30, 2021 that will close this issue
@bagder bagder self-assigned this Aug 30, 2021
@bagder bagder closed this as completed in 8a16e54 Aug 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Successfully merging a pull request may close this issue.

1 participant