Cache-Control is not appended to Dynamic Routing in Next.js 14.2.12

[yuta-hayashi]

Link to the code that reproduces this issue

https://github.com/yuta-hayashi/next-cache-control-test

To Reproduce

I am using Next.js AppRouter.
After upgrading to Next.js 14.2.12, the Cache-Control header is no longer given in Dynamic Routes.
In version 14.2.9, Cache-Control: private, no-cache, no-store, max-age=0 was given.

I am self-hosting Next.js and using a CDN, so this change is very significant.
CDNs like Cloudfront will apply the default cache settings if the Cache-Control header is not given.
This can lead to serious accidents if dynamic pages are cached.

Current vs. Expected behavior

Complete code repository: https://github.com/yuta-hayashi/next-cache-control-test

I tested it with a simple Dynamic Page as follows

dynamic/page.tsx

export const dynamic = 'force-dynamic';

export default function DynamicPage() {
  return (
    <div>
      <h1 className="text-4xl font-bold">Dynamic Page</h1>
    </div>
  )
}

next 14.2.12

Dynamic pages have no Cache-Control.
Is it correct??

curl --head http://localhost:3000/dynamic
HTTP/1.1 200 OK
Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding
link: </_next/static/media/4473ecc91f70f139-s.p.woff>; rel=preload; as="font"; crossorigin=""; type="font/woff", </_next/static/media/463dafcda517f24f-s.p.woff>; rel=preload; as="font"; crossorigin=""; type="font/woff"
X-Powered-By: Next.js
Content-Type: text/html; charset=utf-8
Date: Wed, 18 Sep 2024 11:13:18 GMT
Connection: keep-alive
Keep-Alive: timeout=5

next 14.2.9

I expect this behavior in Next.14.2.12 as well.

curl --head http://localhost:3000/dynamic
HTTP/1.1 200 OK
Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding
link: </_next/static/media/4473ecc91f70f139-s.p.woff>; rel=preload; as="font"; crossorigin=""; type="font/woff", </_next/static/media/463dafcda517f24f-s.p.woff>; rel=preload; as="font"; crossorigin=""; type="font/woff"
X-Powered-By: Next.js
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Wed, 18 Sep 2024 11:23:20 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 18.17.1
  npm: 9.6.7
  Yarn: N/A
  pnpm: 9.5.0
Relevant Packages:
  next: 14.2.12 // Latest available version is detected (14.2.12).
  eslint-config-next: 14.2.12
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.6.2
Next.js Config:
  output: N/A

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

Output (export/standalone)

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

next start (local), Other (Deployed)

Additional context

https://nextjs.org/docs/app/building-your-application/deploying#automatic-caching

Dynamically rendered pages set a Cache-Control header of private, no-cache, no-store, max-age=0, must-revalidate to prevent user-specific data from being cached. This applies to both the App Router and Pages Router. This also includes Draft Mode.

I believe this behavior in v14.2.12 is different from what the documentation says.

This may have changed in v14.2.10 because of changes related to Cache-Control.
https://github.com/vercel/next.js/releases/tag/v14.2.10

[ste26054]

We stumbled upon this very same issue, very glad we spotted it in our staging environment. This may indeed be problematic.

We had to modify our Cloudflare Edge cache TTL behavior to "Use cache-control header if present, bypass cache if not" as a workaround

[ktmouk]

I encountered the same issue. After inspecting what happened, I think the issue is caused by removing the fallback value. The revalidate variable became undefined due to this change, so the cache-control header is not added because of this condition. One workaround I've come up with is to specify the cache-control header ourselves, as it can be customized starting from v14.2.10.

[ijjk]

Hi, this has been fixed in v14.2.13 please upgrade and give it a try!

[yuta-hayashi]

Thank you!!
I've confirmed a fix for this issue in version 14.2.13.