getStaticPaths with fallback true: Allow custom HTTP status codes

Feature request

Is your feature request related to a problem? Please describe.

Using getStaticPaths with fallback: true, pages that are not SSG’ed yet get served with HTTP status 200 no matter what, which makes sense as the response is immediate and getStaticProps is then called in the background.

However, i need a way to:

1. server side generate static pages on demand (e.g. i have a lot of product pages and can’t generate them all at build time), AND:
2. serve a proper 404 status code for product page urls that don’t exist

Describe the solution you’d like

I should be able to configure the “fallback” mode so that it’s possible that the response is not immediate and Next instead waits for getStaticProps to return and only then sends the response, allowing me to set the HTTP status code.

For example, instead of only having one fallback prop, have an onDemand prop and a fallback prop.

• onDemand: If true enables on-demand generation of static pages. If false, all pages returned by getStaticPaths are generated at build time and any other pages return 404s.
• fallback: If true enables fallback mode as it is currently implemented. If false, for pages that are not generated yet a response is sent only after the Promise returned by getServerProps resolved, allowing tweaks to a server response (e.g. setting statusCode). Only has any effect if onDemand is true.

Of course that would not be backwards compatible so it needs some thought. But i guess something like this could work, no?

Describe alternatives you’ve considered

n/a

Additional context

#11644

[JonCognioDigital]

Still thinking about this one and it’s the one issue stopping me from using SSG for most of my pages with CMS content at the moment.

My proposed solution is to have two different options which are mutually exclusive;

fallback:true

Behaves as it does now. If a page has already been generated it is served, otherwise we fall back to a loading screen and the browser gets a 200 status code. In my opinion this is broken and nobody should use it but it has to stay for backwards compatibility.

fallbackServer:true

If the page has been previously generated then we’re served the static file. If not then getStaticProps behaves exactly like getServerProps and “falls back” on a server load rather than a JavaScript loading indicator. Correct 404s and 301/302s could be served.

The second option would still serve a stale static version and regenerate in the background if the “revalidate” time has passed so the SSR version will only happen the first time somebody visits a page.

Personally, I’d only ever use option 2 but I guess some people might still use option 1 if they don’t care about SEO.

[Timer]

We’ve just shipped experimental support for Blocking (“SSR”) Fallback (in lieu of the static placeholder fallback)!

See https://github.com/vercel/next.js/pull/15672 for usage.

This does not yet cover the 404 use case, which is coming 🔜.