Duplicate Content-Length header with same value, recent change in behavior intentional?

[Thomas Ward]

This sounds like your backend and nginx are both generating the header.  NGINX hasn't changed to the point it would create two headers, but if your backend is adding the header as well as nginx then there's your problem.



Sent from my Galaxy



-------- Original message --------
From: Jesse Stimpson via nginx <nginx at nginx.org>
Date: 4/19/23 08:57 (GMT-05:00)
To: nginx at nginx.org
Cc: Jesse Stimpson <jstimpson at relaypro.com>
Subject: Duplicate Content-Length header with same value, recent change in behavior intentional?

Hello,

I've noticed a recent change in behavior that occurred between releases 1.22.1 and 1.23.4, and I'm unable to find this particular change documented.

If an upstream proxy sends a response with duplicate Content-Length headers, both of the same value, nginx 1.22.1 allows the response to be sent to the client, removing the duplicate. However, nginx 1.23.4 (and 1.24.0) responds to the client with a 502. I did not explicitly test with any other versions.

I won't try to make any claims on the correctness of either behavior, but it is a change that may affect some workloads.

Here is an example response that exhibits the change:

"""
HTTP/1.1 200 OK
Server: http_tcp
Content-Length: 12
Content-Length: 12
Connection: Closed

Hello World\n
"""
------

jstimpson:[~/dev/c/nginx-1.22.1]: curl -i localhost
HTTP/1.1 200 OK
Server: nginx/1.22.1
Date: Wed, 19 Apr 2023 12:17:05 GMT
Content-Length: 12
Connection: keep-alive

Hello World

-----


jstimpson:[~/dev/c/nginx-1.23.4]: curl -i localhost
HTTP/1.1 502 Bad Gateway
Server: nginx/1.23.4
Date: Wed, 19 Apr 2023 12:13:09 GMT
Content-Type: text/html
Content-Length: 497
Connection: keep-alive
ETag: "643fd39e-1f1"

...<snip>...


---------

These tests were done with this simple config, the rest of the conf is defaults.

        location / {
            proxy_pass http://localhost:4040;
        }


Is this change intentional? Did I overlook it in the Changelog?

Thanks,
Jesse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230419/db0ac108/attachment-0001.htm>