redwood: NotFoundPage incorrectly gives 200 status error instead of 404

Same for GraphQL, I think the web don’t care about HTTP code anymore 😅

Per Core Team Discussion:

• bump this as a priority to post-v1; will be incorporated with SSR solution

But if it redirects to a page that exists (the NotFoundPage) then by definition that’s a 200! The page has to either really not exist (and the web server returns a 404), of if you have access to the config of the web server itself you can tell it to return a 404 even though that page exists on disk and can be served.

I don’t think we can get around this in Jamstack land because everything is served from a CDN and the provider is probably not going to let you override response codes at the granular a level. But I could be wrong!

So we were taking about having React redirect you to a URL that React doesn’t own, and that can always return a 404

I don’t like that solution. It’s a documented bad way of doing it. See below.

What Are The Most Common 404 Mistakes? Mistakes and improper setups with 404 pages are not uncommon. Here are some of the most prevalent mishaps involving 404 setups.

• Redirecting to a 404 page. This hurts everyone. Users are lost, search engines think everything is honky-dory when it’s not, and since you don’t know when it’s happening - you can’t fix it.

- _https://thegray.company/blog/how-to-make-a-404-page-for-seo-usability#what-are-common-404-setup-mistakes_

I’m hoping we can come up with a better solution when we move to Vite+SSR. @dac09 What do you think?

Right, and that’s a web app acting in the correct manner: that URL doesn’t exist and so the web server returns 404 with a friendly UI. Our issue arises because of React, where ALL URLs are assumed to exist as far as the web server is concerned. It’s only React that knows, via the router, if that URL is correct. But the 200 has already come down from the server. It’s too late to return a 404.

So we were taking about having React redirect you to a URL that React doesn’t own, and that can always return a 404, but I don’t think that’s “correct” from an HTTP standpoint. But we haven’t got any updates in a while so I’m not sure where this stands…

@thedavidprice linked a page about 404s earlier in this thread. That page links to another page where we can read this:

What Are the Most Common Improper Setups For 404 Pages? What Are The Most Common 404 Setup Mistakes/Errors?

• Redirecting to a 404 page. This hurts everyone. Users are lost, search engines think everything is honky-dory when it’s not, and since you don’t know when it’s happening - you can’t fix it.
• Automatically redirecting to the page you assume search engines and users want. A risky solution, that can easily go wrong (typically because they are sent to irrelevant content - like your homepage.) It’s best not to assume. Find the issue and fix it.
• Serving a 404 message on the page visually, but not delivering the corresponding 404 http response code. This hurts everyone (for the same reason as the “redirect to a 404 page” item above.)

We’re currently doing no3 in that list. Redirecting to a function that returns the 404 would be what they have at the top of their “don’t do this” list.

https://thegray.company/blog/how-to-make-a-404-page-for-seo-usability#what-are-common-404-setup-mistakes

AFAICT the only proper way to handle this is to mirror the router config on the server side and use that to determine if the page exists or not.

One interesting way to do that is to remove this config (for Netlify, other providers have something similar)

[[redirects]]
from = "/*"
status = 200
to = "/index.html"

And then, when building the RW app, you look at the router and generate a bunch of index.html files in directories matching the routes and put that on the web server.

One downside with that approach is that you wouldn’t get a nice customized 404 page.

Not an optimal solution, but I proved this behavior would work:

1. Create a serverless function “notFound” that returns html to render the page and a 404 status

export const handler = async (_event: APIGatewayEvent, _context: Context) => {
  logger.info('Invoked notFound function')

  return {
    statusCode: 404,
    headers: {
      'Content-Type': 'text/html',
    },
    body: '<html><body><h1>Not Found</h1></body></html>',
  }
}

1. In a custom not found page

      <MetaTags title="CustomNotFound" description="CustomNotFound page">
        <meta
          httpEquiv="refresh"
          content="0; url = http://localhost:8911/notFound"
        />
      </MetaTags>

redirect to the function

1. Better (not not great) update the Framework NotFoundPage to do the redirect

This of course doesn’t help when you customize since need to add the redirect logic etc – and many other DX considerations make this less than optimal.

But, the idea of a redirect (from Router) to a serverless function can set an actual 404 status

HOW DOES THIS WORK

Exactly. I have only had some success with Netlify redirects and even then not 100% on the magic.

But really do need it for SEO and such

Note Remix touts proper 404s as a feature: https://remix.run/docs/en/v1/guides/not-found#how-to-send-a-404