Chunked: unit-http response Transfer-Encoding being duplicated

[dbit-xia]

When nodejs-app already includes Transfer-Encoding in the response headers, Unit will add an additional one, causing abnormal forwarding in Traefik.

level=debug msg="'500 Internal Server Error' caused by: net/http: HTTP/1.x transport connection broken: too many transfer encodings: [\"chunked\" \"chunked\"]"

The issue can be found at: https://github.com/traefik/traefik/issues/8623.

Version: #1085 build version >1.31.1

[tippexs]

Hi @dbit-xia thanks for reaching out and sorry for the long delay in my answer! Currently the behavior is not documented elsewhere as in the code itself when a Transfer-Encoding header will be added or not by Unit.

Can you make a request to the NodeJS Application outside of Unit and check if it has a Content-Length. As you are saying that Node or better Express sets the Transfer-Encoding: chunked header I guess there will be no Content-Length. But would be worth a test.

RFC7230 just says that the Server might combine headers with the same values. So thats what we do with NGINX for example.

Traeffic is saying this is an issue from the backend and thats why they are closing it. Good. The RFC is saying multiple headers with the same value are allowed and should be combined if that is not impacting the overall request processing.

Long Story short. Different as in the issue from traeffic described I think NGINX WILL error if there are two Transfer-Encoding or a Transfer-Enconding and Content-Length header. See the Changes from 1.21.1 http://nginx.org/en/CHANGES

This change in NGINX as well as in traeffic was part of some hardening against potential HTTP Request smuggeling attacks. I will need some time to come up with test applications with different headers and scenarios. Once finished with that we will come back to this issue. Thanks for reporting!

[callahad]

Assigning to @tippexs to investigate and characterize Unit's behavior; this does seem like a bug on our end, so marking a T-Defect