RFC 2616 HTTP Content-Length and Transfer-Encoding

Question

RFC 2616 states that the Content-Length header must not be sent if a Transfer-Encoding is present.

The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present).

However, if both headers are received, the client should ignore the Content-Length

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

Is my interpretation correct that the client should treat the case where both headers are present as a proper HTTP response? Or is this clause implementation specific?

I'm asking because the Go standard net/http package returns an error when such scenario happens.

Answer 1

The standard does not really specify what should happen in this case, only that if the message is accepted at all then the Content-length should be ignored. To cite from RFC 7230:

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.

Note the weak "ought to" here which is far from MUST. But at least net/http is fully correct in that this kind of response is wrong and can be handled as error. But it is not required to be treated as error.

In practice all browsers seem to accept such a response and usually ignore the Content-length header. But I've seen als a behavior with MS Edge in the past where it correctly treated the response body as chunked but additionally used Content-length and ignored any bytes from the response body not covered by the Content-length.