Cache headers on 404 pages with getStaticProps

[gdorsi]

What version of Next.js are you using?

10.0.6

What version of Node.js are you using?

14.15.1

What browser are you using?

Chrome

What operating system are you using?

macOS

How are you deploying your application?

Other platform

Describe the Bug

The 404 error page responds with the cache headers cache-control: s-maxage=31536000, stale-while-revalidate when the getStaticProps function is exported.

This could be a problem when the resource is temporary unavailable.

Expected Behavior

The cache headers for the 404 responses should be cache-control: public, max-age=0, must-revalidate like when the getStaticProps function is not exported.

To Reproduce

1. npx create-next-app
2. Add a 404.js page with getStaticProps
3. npm run build && npm start
4. Request a non-existent route, like http://localhost:3000/_next/static/give-me-a-404-response

[JellyBellyDev]

Hi, i have the same problem.
And I would like to add further analysis.

If we set the revalidate option we have:

value	header
false	Cache-Control: s-maxage=31536000, stale-while-revalidate
0	error a build time
1	Cache-Control: s-maxage=1, stale-while-revalidate

Is it possible to have feedback?
Thank you

[jhiesey]

This is problematic when deploying a new version of an app behind a caching proxy/CDN (e.g. cloudflare).

If a request comes in and is routed to the new server, the user's browser will request a given newly built chunk (e.g. https://example.com/_next/static/chunks/12345.js). If that request gets routed to the old server that does not have that chunk, the 404 response will get cached by the proxy/CDN and the app will be broken for subsequent visitors until the cache is manually cleared.

It would be great to get this fixed!

[feross]

This issue is affecting our Next.js app – https://wormhole.app – which is uses a zero-downtime deployment system. During a new deployment, two version of the server, old and new, are running. If a request for a new chunk URL is routed to the old Next.js server, then a 404 will be returned, which will be cached by the user's browser (or Cloudflare).

This leaves the site in a permanently broken state until the browser cache or Cloudflare cache is cleared.

[timneutkens]

Had a look at this and it seems that getStaticProps usage incorrectly causes the 404 page to have s-maxage. I've started a PR that should change the behavior to be what you're expecting based on the initial report: #24983

curl results

Without `getStaticProps` on `pages/404.js`

curl -I http://localhost:3000/abc
HTTP/1.1 404 Not Found
X-Powered-By: Next.js
ETag: "798-WQUy0ByHB4W58/50r7ifSltsAbM"
Content-Type: text/html; charset=utf-8
Content-Length: 1944
Vary: Accept-Encoding
Date: Tue, 11 May 2021 11:04:27 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Without `getStaticProps` requesting `/_next/`

curl -I http://localhost:3000/_next/abc
HTTP/1.1 404 Not Found
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
X-Powered-By: Next.js
ETag: "798-WQUy0ByHB4W58/50r7ifSltsAbM"
Content-Type: text/html; charset=utf-8
Content-Length: 1944
Vary: Accept-Encoding
Date: Tue, 11 May 2021 11:04:41 GMT
Connection: keep-alive
Keep-Alive: timeout=5

With `getStaticProps` on `pages/404.js`

curl -I http://localhost:3000/abc
HTTP/1.1 404 Not Found
X-Powered-By: Next.js
ETag: "798-fxRfc/NYKqzkn+F/LMxeV/y7drY"
Content-Type: text/html; charset=utf-8
Content-Length: 1944
Cache-Control: s-maxage=31536000, stale-while-revalidate
Vary: Accept-Encoding
Date: Tue, 11 May 2021 11:11:46 GMT
Connection: keep-alive
Keep-Alive: timeout=5

With `getStaticProps` requesting `/_next/`

curl -I http://localhost:3000/_next/abc
HTTP/1.1 404 Not Found
Cache-Control: s-maxage=31536000, stale-while-revalidate
X-Powered-By: Next.js
ETag: "798-fxRfc/NYKqzkn+F/LMxeV/y7drY"
Content-Type: text/html; charset=utf-8
Content-Length: 1944
Vary: Accept-Encoding
Date: Tue, 11 May 2021 11:12:42 GMT
Connection: keep-alive
Keep-Alive: timeout=5

[tomsonpl]

@jhiesey Hi John, we are facing the exactly same issue as you described above. Did you find any solutions so far? Thanks!

[tomsonpl]

Or maybe somebody knows to which version of Next we should revert to not be facing this issue? Thanks!

[iandeherdt]

Hi, we are experiencing the exact same issue. Can anyone review and merge @timneutkens PR please?
Thanks a lot.

[PsyGik]

As a "workaround", we manually set the cache-control headers for 404 pages. Since we use a custom server, it's simply a matter of adding a middleware to override the headers. Not a clean solution, but it's something until #24983 gets merged.

[mocantimoteidavid]

Hello @jhiesey & @tomsonpl! Did your issue get fixed with the merged changes from @timneutkens ?
I'm experiencing the same exact issue (getting a 404 on .js chunks while the deployment is rolling). I would be honestly fine for now to set some a Cache-control: private on those requests manually for now, but I cannot make that work either.

[tomsonpl]

If I remember correctly, we just added the ''revalidate'' option (it wasn't there at first) and it never happened again.

[mocantimoteidavid]

@tomsonpl, thank you for your reply!
Would it be maybe too much to ask for a bit more guidance on this? As in where exactly did you set those headers and how?
I have Next.js running with a custom server, so any header I set in Node.js after the getRequestHandler is called, is not reached at all. And any cache control header I set before that, seems that it gets overwritten by what Next is doing.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.