Dev server: prevent stale document restores with Cache-Control no-store

[ask-bonk]

Next.js Change

Commit: 2839982
PR: #97505

What changed

Next.js development documents and RSC/data responses now send Cache-Control: no-store, rather than no-cache, must-revalidate. Browsers can restore a stored document during a back/forward navigation without revalidating it, which otherwise displays output from before the latest edit.

Development static assets remain no-cache, must-revalidate: they have ETags, so the browser can make a conditional request, receive 304, and reuse the cached body rather than re-download chunks on every page load.

Impact on vinext

vinext must match this response split in development for both App and Pages Router paths. HTML documents and RSC/data responses must never be stored, while static assets should remain revalidatable. This prevents a history navigation from restoring stale pre-HMR document output without unnecessarily disabling asset caching.

Acceptance criteria

• App Router development HTML and RSC responses return Cache-Control: no-store.
• Pages Router development HTML and data responses return Cache-Control: no-store.
• Development static assets retain Cache-Control: no-cache, must-revalidate and continue to return 304 for unchanged conditional requests.
• Add regression coverage that edits a page after navigating away, then verifies browser back navigation displays the edited result.
• Cover both router families and verify the static-asset behavior independently.

Related

• test: reproduce stale page after back navigation vercel/next.js#96503 — upstream stale-development-page report