Non-existing page 200 status code in network tab

[wouter-blockken]

Hello there,

I think i might have found a bug. Not too sure if it's solvable with additional configuration, but this is what happens. Whenever we go to an url withouth the language param included in the url (localhost:8000/random) we get a 404 error as expected in the network tab.

But when i do include the language param (/en/) we get a 200 status (even tho the page doesn't exist).

Someone that knows what's going on? Thanks for helping out!

[graysonhicks]

I believe this is an example of this issue. When following this guide, you will see a 200 code on non-default 404 pages.

There isn't a current workaround, but I believe a solution could be allowing a statusCode option to be passed to createPage. So the new example would look like:

exports.onCreatePage = async ({ page, actions }) => {
  const { createPage, deletePage } = actions
  // Check if the page is a localized 404
  if (page.path.match(/^\/[a-z]{2}\/404\/$/)) {
    const oldPage = { ...page }
    // Get the language code from the path, and match all paths
    // starting with this code (apart from other valid paths)
    const langCode = page.path.split(`/`)[1]
    page.matchPath = `/${langCode}/*`
    // Recreate the modified page
    deletePage(oldPage)
    createPage(
      ...page,
      // add status code here
      statusCode: '404'
    )
  }
}

This would then match the same option that is available in createRedirect. Currently 404 and 500 pages are made by creating the 404.html directly in the root which is how many static hosting services know what code to return for it, so I'm not sure how the statusCode would be translated to making sure the multi-lang 404 pages return 404 from the server.

[wouter-blockken]

Hey there @graysonhicks,

Was wondering if this issue was added somewhere on the roadmap to be fixed/worked around. Thanks a lot for the reply and keep up the good work!

[graysonhicks]

Not that I know of at the moment, but PRs welcome. 😄 I did discuss briefly with @wardpeet at a point and decided that a simpler is404 may be more likely, as I don't know of this request ever wanting anything other than to flag as a 404. The code logic would probably be the same either way.

Another layer of this I think is handling the server aspect of this. Having the flag would be simple, but I think several plugins would actually need to handle the statusCode (gatsby-plugin-gatsby-cloud, gatsby-plugin-netlify, etc).