Open
Description
Right now the 404 not found page is generated as string of HTML and CSS and is returned directly by the server, no React involved.
The most obvious downside of this approach is that the text on this page will never get translated to the user's current language, which is a barrier to accessibility.
I'm researching this a bit and realizing that we do need to serve something different from the server in order to get the correct HTTP status code on the page (404 rather than 200). But it seems like the server should return more of a skeleton and let React inject the content. In fact, I think it could still return the same index page? react-router can be set up to display the "page not found" content when there is no matched route.
Activity
dewanshDT commentedon Mar 18, 2023
I totally agree with this as rendering the 404 page in the front end would also provide a lot of customizability and flexibility over the current approach.
lindapaiste commentedon Mar 20, 2023
I've dug into the code and I see that we are actually sending a 200 status code on all 404 pages! The ones which are handled by
app.get('*'
have the correct 404 status, but the ones which are a result of a failed user/project/collection exists check have a 200 status. This could be fixed easily in the current setup, by changingget404Sketch((html) => res.send(html))
toget404Sketch((html) => res.status(404).send(html))
.On the flip side, if we aren't sending the correct status code now then there's no disadvantage to handling the 404 on the front-end (where it would always be a 200).
Switching to something like Next.js, as discussed here would eliminate the need to check content separately on the server and would put it all in one place. We would do the API call (or query mongo directly) and either render the page with those results or serve up a 404. But it's not easy to migrate all of the current content to that setup.