Missing `?_rsc=xxxx` after redirects() that lead to cache pollution and leak RSC response to browser page

[Fonger]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/next-js-rsc-cache-busting-redirect-not-working-5psn4k

To Reproduce

1. Open the homepage of this repro sandbox.

The next.config.js file is configured as

import type { NextConfig } from "next";
const nextConfig: NextConfig = {
  reactStrictMode: true,
  async redirects() {
    return [
      {
        source: "/fake-path",
        destination: "/real-path",
        permanent: true,
      },
    ];
  },
};
export default nextConfig;

2. Click "Go to Fake Path." This triggers a redirect from /fake-path to /real-path.
3. Observe that the ?_rsc query parameter is missing in the redirected request.

fetch /fake-path?_rsc=xxx and 308 to /real-path without query

Following the redirect, fetch /real-path again, it's text/x-component RSC response but there's no ?_rsc=xxx query busting. This make local browser or some CDN providers hard to distinguish "HTML Web Page" and "RSC Component Response".

I can confirm this can happen to browser in bf cache.

Current vs. Expected behavior

Current
308 Redirected RSC requests ?_rsc=xxx doesn't forward.

Expected
308 Redirected RSC request should also contain ?_rsc=xxx query to help Browser / CDN to separate cache.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4242
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 15.2.2-canary.4 // Latest available version is detected (15.2.2-canary.4).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.3.3
Next.js Config:
  output: N/A

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

Dynamic Routes, Redirects, Route Handlers

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

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

Additional context

Suspected Cause

I suspect this issue was introduced in #51195

It seems that the following code is intended to remove the ?_rsc query parameter when redirecting to a page router. However, in this case, the target destination is an app router, meaning the ?_rsc query should not have been removed.

next.js/packages/next/src/shared/lib/router/utils/prepare-destination.ts

Line 213 in 9118a0b

delete query[NEXT_RSC_UNION_QUERY]

Real-world Impact

This issue has also been observed on Cursor’s official website.

As shown below, the "200 OK (from disk cache)" response indicates that the browser is caching and serving an RSC response instead of a normal HTML page. While the browser correctly renders the cached content as-is, the problem arises because RSC responses are not meant to be directly presented to users. Without the proper client-side cache separation, users end up seeing raw, incomprehensible RSC data rather than a functional UI in html.

Expected behavior:
✅ The page should be rendered as a normal HTML document.

Actual behavior:
❌ The browser caches and serves an RSC response instead of HTML.

[KFrysztak]

We are having almost exactly the same problem.

From what I was able to trace in my case most likely NextResponse.redirect() is stripping _rsc. This is causing cache separation problems for cdn.

The final outcome is what @Fonger described, browser is getting RSC is served instead of HTML.

We are on next@15.2.3

[lexlemmens]

I also can confirm we have this issue. This is causing our CMS to have more requests than needed.

Also on next@15.2.3

[unstubbable]

I suspect this issue was introduced in #51195

This PR is unrelated. (EDIT: This is now the correct PR. Previously there was a wrong PR linked.) In fact, the behavior is unchanged since the feature was introduced in v13.4.6. As you've pointed out, prepareDestination is probably applied too broadly here. @huozhi maybe you can take a look at this when you have time.

[Fonger]

I suspect this issue was introduced in #51195

This PR is unrelated. (EDIT: This is now the correct PR. Previously there was a wrong PR linked.)

Apologies for pinging the wrong PR earlier—and for the deleted comment!

In fact, the behavior is unchanged since the feature was introduced in v13.4.6.

We’ve recently migrated to the App Router (RSC), so I’m not entirely sure whether this change affects older versions.

[huozhi]

The fix is landed in v15.3.1-canary.1, let us know if that resolves your issue 🙏

[KFrysztak]

Hey,
for us it still happens unfortunately on [v15.3.1-canary.1](https://github.com/vercel/next.js/releases/tag/v15.3.1-canary.1) :(

This is happening only when we are turning on SSG via:

export const generateStaticParams = () => supportedLocales.map((lang) => ({ lang }));
export const revalidate = 300;
export const dynamicParams = false;

We don't have any redirect in next.config.ts but we have middleware that is responsible for handling locale changes. MIddleware we have currently is the one from https://nextjs.org/docs/app/building-your-application/routing/internationalization

We cannot reproduce it locally with dev (both with and without turbo) or build/start. It happens only after deploying the app (digital ocean).

@Fonger can you please confirm if the fix is working for your case?