next.js

3bbb2e61 - prevent browser cache from using stale RSC responses from previous builds (#86554)

prevent browser cache from using stale RSC responses from previous builds (#86554) When we landed #76207 we started propagating the `stale-while-revalidate` value to RSC responses. We wanted a way to express to CDNs that it can keep serving the cached content for some time while a revalidation runs in the background, but we specifically don't want that for private caches. As a result of this header, when re-building your application locally (or doing something on the server that would have expired the cache), the browser's disk cache would serve a stale RSC response. We currently encode a buildId in RSC payloads, so the client router will discard RSC responses that don't match what it is expecting. Unfortunately there isn't a `s-stale-while-revalidate` header to express the intended semantics. This moves the `stale-while-revalidate` configuration into the `CDN-Cache-Control` header, which is becoming standardized and is supported by a wide variety of CDNs. This allows us to specify the SWR behavior more explicitly to CDNs while not impacting private caches like the browser. It restores the previous behavior of only setting `s-maxage` on the `cache-control` itself to avoid influencing browser cache. If Next.js is deployed to a CDN that doesn't support this header, it can be customized via `nextConfig.experimental.cdnCacheControlHeader`. Eg, if deployed to Fastly, you'd configure this to `cdnCacheControlHeader: 'Surrogate-Control'`. Closes NAR-525 Reference docs: [Vercel](https://vercel.com/docs/headers/cache-control-headers#cdn-cache-control-header) [Cloudflare](https://developers.cloudflare.com/cache/concepts/cdn-cache-control/) [Fastly](https://www.fastly.com/documentation/reference/http/http-headers/Surrogate-Control/) [RFC 9213](https://httpwg.org/specs/rfc9213.html)