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

Closed
bagder opened this issue Aug 26, 2021 · 0 comments
Closed

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

bagder opened this issue Aug 26, 2021 · 0 comments
Assignees
Labels

Comments

@bagder
Copy link
Member

@bagder 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant