The `--bun` flag causes duplicate `transfer-encoding` and `Date` response headers in NextJS rewrites.

[information-security]

What version of Bun is running?

1.2.14

What platform is your computer?

Tested on both Darwin 24.3.0 x86_64 i386 and Linux 5.14.0-427.13.1.el9_4.x86_64 x86_64 x86_64

What steps can reproduce the bug?

1. Create a NextJS project.
2. Configure next rewrites and proxy a test url (e.g. /blog) to a URL that already generates transfer-encoding: chunked (e.g. A WordPress site).
   My config is as below

  rewrites: async() => {
    return {
      beforeFiles: [
        {
          source: '/blog',
          destination: 'http://X.X.X.X:8080/blog/', /* WordPress enforces trailing slash */
        },
        {
          source: '/blog/:path*',
          destination: 'http://X.X.X.X:8080/blog/:path*/',
        }
      ],
    };
  },

3. Make a request to your proxied URL (/blog).

What is the expected behavior?

No duplicate transfer-encoding or any other headers must be set just like how bun run start is doing it.

What do you see instead?

Accessing the /blog URL in the given steps above, you'd see that duplicate transfer-encoding and date response headers are sent back to the browser.

The duplicate date flag is no problem but duplicate transfer-encoding headers are prohibited and non-standard. Services like CloudFlare do not skip this duplication and raise errors.

Additional information

The workaround is obviously using bun run start (removing --bun) but it took me hours to find it out.
One important side note is that when doing bun run start I am instantly getting following warning while bun --bun run start does not show that warning. Thought it might be related.

(node:97649) [DEP0060] DeprecationWarning: The `util._extend` API is deprecated. Please use Object.assign() instead.
(Use `node --trace-deprecation ...` to show where the warning was created)

[RiskyMH]

Fixed by @sponte in #20116