Clarify guidance for requests that have both content-length and transfer-encoding headers

[jpeach]

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.

[royfielding]

This is for backwards compatibility. It probably should be

An intermediary MUST remove the received Content-Length field if it intends to forward the message downstream.