Skip to content

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

Closed
@bagder

Description

@bagder

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.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions