Strip Content-Length header when Transfer-Encoding header is set on response

[halter73]

I seems the HTTP the spec suggests removing the content-length header when a transfer-encoding header is set.

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.
https://tools.ietf.org/html/rfc7230#section-3.3.3

#1163 (comment)

Maybe this is just intended for proxies, but it makes sense not to send both headers. It might even be a good idea to throw when an app attempts to send both, but that would be breaking.

[cesarblum]

I was thinking about this again. The thing that bothers me a little about not implementing this change is that the spec says MUST. I agree it seems to be referring to proxies (though it's not 100% clear on this), I don't see why an endpoint shouldn't do the same. We should at least log a warning when sending a response containing both headers.

Thoughts?

[muratg]

@CesarBS I closed this based on seeing you removing the assignment. Happy to talk about this again.

[muratg]

In case someone's broken, we can consider bringing this back.