res.statusCode=404 in getServerSideProps results in unnecacery redirect

Bug report

Describe the bug

export async function getServerSideProps({ res }) {
  res.statusCode = 404
  return {
    props: {
      error: `couldn't find the thing`
  };
};

this will return 404 on both /my-route and /_next/data/..../my-route.json?slug=my-route, which in it self is fine, but client side navigation will react to a 404 with a redirect.

So the current behaviour is:

1. if I request /my-route I get a 404 http status code and the rendered 404 page
2. if I (client side) navigate to /my-route it will request /_next/data/..../my-route.json?slug=my-route in the background, then because of the 404 response, it will do a redirect with a full page refresh to /my-route and then (1) happens

(This means that for every 404 that is accessed with (client side) navigation, the getServerSideProps is called 2 times)

Expected behavior

1. if I request /my-route I get a 404 http status code and the rendered 404 page
2. if I (client side) navigate to /my-route it should use the data from /_next/data/..../my-route.json?slug=my-route (if there is data, it should be used even if 404) to render the 404 page directly without a page refresh

Screenshots

First request in the screenshot is the loading of / (full page load). The second is XHR by next which then performs a redirect to /foo which is a full page load.

System information

• Version of Next.js: 9.5.5
• Version of Node.js: v14.12.0

[timneutkens]

You can now return notFound: true https://nextjs.org/blog/next-10#redirect-and-notfound-support-for-getstaticprops--getserversideprops

[Zauberfisch]

Workaround:

I’ve worked around this for now by only setting 404 when it’s /my-route but not when it’s /_next/data/..../my-route.json?slug=my-route:

export async function getServerSideProps({ res }) {
  if (!req.url.match(/^\/_next\/data\/.*slug=.*$/)) {
    res.statusCode = 404
  }
  return {
    props: {
      myStatusCode: 404,
      error: `couldn't find the thing`
  };
};

This results in the expected behaviour described in the bug above