In 3.3.3, RFC 7230 describes how to determine the message body length for requests that have both content-length and (final) transfer-encoding headers.
If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 9.5) or response splitting
(Section 9.4) and ought to be handled as an error. A sender MUST
remove the received Content-Length field prior to forwarding such
a message downstream.
This paragraph is open to an ambiguous reading, since this case "ought to be handled as an error". The "ought" here is non-normative IIUC. The normative requirement is that the message is forwarded but the content-length MUST be removed. So if the message is forwarded, then it's not really handled as an error (which I'm assuming would mean the intermediary responds with a 400 Bad Request).
I think my reading of the requirement is supported by "the Transfer-Encoding overrides the Content-Length", and the first paragraph in item 3:
If a Transfer-Encoding header field is present and the chunked
transfer coding (Section 4.1) is the final encoding, the message
body length is determined by reading and decoding the chunked
data until the transfer coding indicates the data is complete.
In 3.3.3, RFC 7230 describes how to determine the message body length for requests that have both content-length and (final) transfer-encoding headers.
This paragraph is open to an ambiguous reading, since this case "ought to be handled as an error". The "ought" here is non-normative IIUC. The normative requirement is that the message is forwarded but the content-length MUST be removed. So if the message is forwarded, then it's not really handled as an error (which I'm assuming would mean the intermediary responds with a 400 Bad Request).
I think my reading of the requirement is supported by "the Transfer-Encoding overrides the Content-Length", and the first paragraph in item 3: