Link to the code that reproduces this issue

https://github.com/hbystrom91/next-vary-header-content-encoding-bug

To Reproduce

1. Start the application using the README.md instructions
2. Navigate to the root page and open the networks tab
3. Inspect the Vary header

Current vs. Expected behavior

Current behavior

Looking at the image, you can see that the arbitrary header is added, but the X-Foo entry isn't appended to the Vary header.

Expected behavior

Not being able to do this causes our CDN not being able to invalidate cache based on the Vary tag. Since it also compresses all responses, this is needed. By adding compress: true in the next.config.js the appropriate Accept-Encoding entry is added to the Vary header, but we need this to happen at the CDN level. Right now we cannot compress our app router pages, because Next.JS simply doesn't give us the flexibility. There's many other use cases for when flexibility is needed in this regard.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.1.0: Mon Oct 20 19:33:00 PDT 2025; root:xnu-12377.41.6~2/RELEASE_ARM64_T6020
  Available memory (MB): 32768
  Available CPU cores: 12
Binaries:
  Node: 22.20.0
  npm: 10.9.3
  Yarn: N/A
  pnpm: 10.18.3
Relevant Packages:
  next: 16.0.1 // Latest available version is detected (16.0.1).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Headers, Middleware

Which stage(s) are affected? (Select all that apply)

Other (Deployed)

Additional context

No response