nextjs - 💡(How to fix) Fix basePath stripped from Location header in validateRSCRequestHeaders 307 [1 comments, 2 participants]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Debian 5.10.0
Binaries:
  Node: 20.x
  npm: N/A
  Yarn: N/A
  pnpm: 10.x
Relevant Packages:
  next: 16.3.0-canary.9 (also reproduced on 16.1.1-canary.29)
  react: 19.x
  react-dom: 19.x
Next.js config:
  basePath: '/app'
  output: 'standalone'

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

App Router, Caching, Middleware

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

next start (local), Other (Deployed)

Additional context

When experimental.validateRSCRequestHeaders is enabled (the default on canary builds — config-shared.ts defaults to !!(process.env.__NEXT_TEST_MODE || !isStableBuild())), Server.renderToResponseWithComponentsImpl issues a 307 redirect whenever the client-supplied _rsc cache-busting search param does not match the hash computed from the RSC request headers. This is the cache-poisoning defense added in #80669 and gated behind the flag in #80157.

The redirect's Location header is built from req.url:

// packages/next/src/server/base-server.ts
const url = new URL(req.url || '', 'http://localhost')
setCacheBustingSearchParamWithHash(url, expectedHash)
res.statusCode = 307
res.setHeader('location', `${url.pathname}${url.search}`)

But by the time this code runs, basePath has already been stripped from req.url earlier in handleRequestImpl:

// base-server.ts ~line 1055
if (pathnameInfo.basePath) {
  req.url = removePathPrefix(req.url!, this.nextConfig.basePath)
}

So for any app configured with basePath: '/app' (or any non-root basePath), the redirect's Location is /<page>?_rsc=… instead of /app/<page>?_rsc=…. The browser then navigates outside the app's basePath.

Reproduction steps

1. App with basePath: '/app' and validateRSCRequestHeaders: true (or canary defaults).
2. Issue an RSC request to /app/<page> with valid RSC headers but no _rsc= query param. (This is what the browser naturally does when following a same-origin redirect chain that lands on an in-app page without a _rsc= query — for example, a route handler that 307s to an app-router page without forwarding _rsc.)
3. Server emits a 307 with Location: /<page>?_rsc=<expectedHash> — /app is missing.
4. Browser navigates outside the app.

# Minimal repro:
curl -sI -H 'rsc: 1' \
  -H 'next-router-prefetch: 1' \
  -H 'next-router-segment-prefetch: /_tree' \
  http://localhost:3000/app/some-page

# Expected: HTTP/1.1 307
#           Location: /app/some-page?_rsc=<hash>
# Actual:   HTTP/1.1 307
#           Location: /some-page?_rsc=<hash>

Real-world impact

Hit in production on an app deployed under a non-root basePath and sharing a hostname with another backend (a marketing site mounted at /, with the Next app at /app/*). After a router.push('/api/cookie?…') whose route handler 307s to /app/subscribe?… (without forwarding _rsc=), the browser ended up outside the basePath and landed on the wrong backend (/subscribe → 404 from the other service). Diagnosis took several hours because the Location header is generated several layers below where most users instrument logs — the defense fires silently before page handlers run.

The same flow will affect any deployment that:

• Uses a non-root basePath,
• Is on canary (where validateRSCRequestHeaders is on by default), and
• Has any redirect chain that lands on an app-router page through an RSC navigation without an explicit _rsc= on the final URL.

Fix

Two-line patch — re-prepend nextConfig.basePath to the Location header. Originally introduced in #80669, neither that PR nor #80157 (which gated the flag) accounted for basePath.

Pull request: vercel/next.js#93434 — includes a regression test under test/e2e/app-dir/segment-cache/cdn-cache-busting-base-path/.

cc the original authors of the relevant area: @acdlite (#80157, surrounding code) — happy to make any requested changes.