Non-proper handling of Content-Length and Transfer-Encoding: chunked headers

Expected behavior

1.Only accept one Content-Length.RFC 7230 says duplicate Content-Length header fields have been generated or combined by an upstream message processor, then the recipient MUST either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length. 2.Only accept identity and chunked Transport-Encoding In this implementation, the order does not matter (it probably should). The Go implementation only uses the first value of the header.Seems to be in sync with the behaviour of AWS ALB. All other valid (gzip, compress, etc.) and invalid TE will return a 501, since we don’t have readers for them I figured this was the right move, but feel free to correct me

Actual behavior

1. But netty accept all. 2.Netty accpet random TE.

Steps to reproduce

Use two CL to reproduce the first. Use a chunked TE header and a random TE header. Smiliar with 9571. It also cause http smuggling. Or see the other issue benoitc/gunicorn#2176 and the PR benoitc/gunicorn#2181

Minimal yet complete reproducer code (or URL to code)

Netty version

all

JVM version (e.g. java -version)

OS version (e.g. uname -a)

[artem-smotrakov]

@normanmaurer No problem, I’ll open a pull request.

[normanmaurer]

@JLLeitschuh sorry but no backport will be done … netty 3.x is EOL for many years and if projects did not update yet they may have a reason to do now.