Link to the code that reproduces this issue

https://github.com/lujjjh/nextjs-rsc-dirty-cache-repro

To Reproduce

1. Open https://nextjs-rsc-dirty-cache-repro.vercel.app in Chrome
2. Close the tab
3. Reopen closed tab using ctrl / cmd + T

Current vs. Expected behavior

Current behavior: The RSC response (text/x-component) is shown.

Expected behavior: The page content (HTML) is shown.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Tue, 29 Apr 2025 09:23:13 +0000
  Available memory (MB): 32083
  Available CPU cores: 16
Binaries:
  Node: 23.9.0
  npm: 11.3.0
  Yarn: N/A
  pnpm: 10.10.0
Relevant Packages:
  next: 15.3.2 // Latest available version is detected (15.3.2).
  eslint-config-next: 15.3.2
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.3
Next.js Config:
  output: N/A

Chrome: Version 136.0.7103.114 (Official Build) (arm64)

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

Headers

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

next start (local), Vercel (Deployed), Other (Deployed)

Additional context

1. The prefetch request to https://nextjs-rsc-dirty-cache-repro.vercel.app/en?_rsc=xxxx is redirected to / by the middleware. However, the _rsc query parameter is not visible to the middleware, so it gets dropped during the redirect — which results in the RSC response being cached by Chrome under /.
2. Maybe _rsc should be preserved while redirecting?
3. I believe that including Rsc in the Vary response header should resolve this issue, although I haven’t verified it yet.
4. When running under next start (self-hosted), the Cache-Control header is set to s-maxage=31536000 with no max-age or no-cache directives—unlike Vercel’s defaults. Is this intentional?

Related with #65783, #65787, #76925.