Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to obtain statusCode on a client-side rendered error page in next 7.0.2 #5437

Closed
kachkaev opened this issue Oct 12, 2018 · 4 comments · Fixed by #6276
Closed

Unable to obtain statusCode on a client-side rendered error page in next 7.0.2 #5437

kachkaev opened this issue Oct 12, 2018 · 4 comments · Fixed by #6276
Assignees

Comments

@kachkaev
Copy link
Contributor

kachkaev commented Oct 12, 2018

Bug report

Describe the bug

Upgrading next to 7.0.2 makes it impossible to render a 404 page on the client when a person loads a server-rendered 404 page, then navigates to some other page and finally goes back to a 404 page using browser navigation. This applies to production environment only (in dev, 404 throws anyway).

To Reproduce

MWE: https://github.com/kachkaev/next.js-5437

  1. git clone git@github.com:kachkaev/next.js-5437.git
    cd next-issue-xxx
    yarn
    yarn build && yarn start
    
  2. Go to http://localhost:3000/asdf (non-existing page). You will see Error: 404 (it is server-rendered).

  3. Click on main page, see URL changed to http://localhost:3000/.

  4. Press back in your browser to return to http://localhost:3000/asdf. You will see Error: 404 again, now rendered on the client. So far so good – it's next@7.0.1. Here's where custom status code is coming from in pages/_error.js:

      static getInitialProps({ res, err }) {
        const statusCode = res ? res.statusCode : err ? err.statusCode : null;
        return { statusCode };
      }

    (res is used during SSR and err is used during the client-side rendering)

  5.  yarn add next@7.0.2
     yarn build && yarn start
  6. Repeat steps 2-4. In step 4, you will see Error: unknown instead of Error: 404. This means that the page will look like if the web app crashed badly. The cause of this behaviour is that err is now undefined in getInitialProps, unlike in 7.0.1.

System information

  • OS: macOS
  • Browser (if applies) Google Chrome
  • Version of Next.js: 7.0.2
@kachkaev
Copy link
Contributor Author

kachkaev commented Oct 12, 2018

Given that this issue is likely to be related with a security fix in 7.0.2, I'd like to add that a CVE link in release notes does not take a reader to a specific CVE as expected. I could not find a description of the recent vulnerability via their search as well.

UPD: CVE is finally there: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18282

@timneutkens
Copy link
Member

The CVE is on the way. It's a manual process on their side and we'll update the link soon.

@kachkaev
Copy link
Contributor Author

Is this being fixed in Next.js 8 as a result of the refactoring? Just curious 😉

@timneutkens timneutkens assigned Timer and unassigned shuding Jan 28, 2019
@timneutkens
Copy link
Member

timneutkens commented Jan 28, 2019

@kachkaev I'm not going to block v8 on this, but definitely having someone look into it ASAP 🙏 Thanks for the ping!

Timer added a commit to Timer/next.js that referenced this issue Feb 12, 2019
This is an appropriate default behavior because:

1. When the server encounters an error, the `err` property is set.
2. When the client-side application crashes, the `err` property is set.

This means the "only" way to render the `/_error` page without an error
is when a page is not found (special condition).

Fixes vercel#6243
Closes vercel#5437
Timer added a commit that referenced this issue Feb 13, 2019
* Set default `Error` status code to 404

This is an appropriate default behavior because:

1. When the server encounters an error, the `err` property is set.
2. When the client-side application crashes, the `err` property is set.

This means the "only" way to render the `/_error` page without an error
is when a page is not found (special condition).

Fixes #6243
Closes #5437

* Add new integration test for client side 404

* single quotes

* Remove unused variable

* Standard needs to go away

* Whoops

* Check for null status code in res and err

* Only check response for valid statusCode
@lock lock bot locked as resolved and limited conversation to collaborators Feb 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants