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

Jesse Stimpson jstimpson at relaypro.com
Wed Apr 19 12:57:28 UTC 2023


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/338ab473/attachment.htm>


More information about the nginx mailing list