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

(v3.x) fix: handle invalid url #3806

Merged
merged 3 commits into from Apr 1, 2022
Merged

(v3.x) fix: handle invalid url #3806

merged 3 commits into from Apr 1, 2022

Conversation

climba03003
Copy link
Member

@climba03003 climba03003 commented Apr 1, 2022

Backport #3128 to v3 branch and some new changes as requested.
After revisit the code, I think it should not break people but provide a better experience to the developer.

Checklist

* fix: handle invalid url

* refactor: handle as 404 instead of 400

* fix: respect disableRequestLogging
@climba03003 climba03003 changed the title fix: handle invalid url (#3128) (v3.x) fix: handle invalid url Apr 1, 2022

// 404 router, used for handling encapsulated 404 handlers
const router = FindMyWay({ defaultRoute: fourOhFourFallBack })
const router = FindMyWay({ onBadUrl, defaultRoute: fourOhFourFallBack })
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am unclear how this is different from the default route. Both are handling the 404 case, correct?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I don't understand why both are needed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can check this issue #3127

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is right. It's a 404. The 404 handler should handle it. As implemented, we should be exposing two 404 handlers for the Fastify user to override. Basically:

const server = fastify({
  404Handler1: () => {},
  404Handler2: () => {}
})

This is not a good dev experience, and is confusing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the url invalid, it cannot go to the correct /* handler. Then it fallback to defaultRoute.
The fourOhFourFallBack is actually giving the user warning in this case.

The below one should be the correct handler for 404 case.
https://github.com/fastify/fastify/blob/v3.x/lib/fourOhFour.js#L50-L59
https://github.com/fastify/fastify/blob/v3.x/lib/fourOhFour.js#L150-L151

fourOhFourFallBack should never be run.
https://github.com/fastify/fastify/blob/v3.x/lib/fourOhFour.js#L154-L171

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. The 404 handler should handle any case where a route is not found.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the new approach is good, I will create a PR for v4.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have stepped through the new tests. Everything is working as I think it should. Without a custom 404 handler defined, the basic404 handler is invoked when a "bad url" is encountered. When a custom 404 handler is defined, it is invoked.

Copy link
Member

@jsumners jsumners left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@mcollina mcollina merged commit e7d7e59 into fastify:v3.x Apr 1, 2022
@github-actions
Copy link

github-actions bot commented Apr 2, 2023

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 2, 2023
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 this pull request may close these issues.

None yet

4 participants