Skip to content

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

Closed
@ZeddYu

Description

@ZeddYu

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)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions