Default 404 handler does not catch failure on bad characters in URL path

[lance]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Fastify version

3.20.1

Plugin version

No response

Node.js version

16.14.0

Operating system

macOS

Operating system version (i.e. 20.04, 11.3, 10)

12.3

Description

When a fastify server receives an incoming request containing certain character sequences, the server will return a 404 Not Found and indicates that the default 404 handler failed to catch the problem, requesting that it be reported. Here is the failure message, when a server running locally receives a request like this: http://localhost:8080/%C0.

{"level":40,"time":1648738852661,"pid":1,"hostname":"3e35ec351df6","reqId":"req-1","msg":"the default handler for 404 did not catch this, this is likely a fastify bug, please report it"}
{"level":40,"time":1648738852677,"pid":1,"hostname":"3e35ec351df6","reqId":"req-1","msg":"└── / (ACL)\n    / (BIND)\n    / (CHECKOUT)\n    / (CONNECT)\n    / (COPY)\n    / (DELETE)\n    / (GET)\n    / (HEAD)\n    / (LINK)\n    / (LOCK)\n    / (M-SEARCH)\n    / (MERGE)\n    / (MKACTIVITY)\n    / (MKCALENDAR)\n    / (MKCOL)\n    / (MOVE)\n    / (NOTIFY)\n    / (OPTIONS)\n    / (PATCH)\n    / (POST)\n    / (PROPFIND)\n    / (PROPPATCH)\n    / (PURGE)\n    / (PUT)\n    / (REBIND)\n    / (REPORT)\n    / (SEARCH)\n    / (SOURCE)\n    / (SUBSCRIBE)\n    / (TRACE)\n    / (UNBIND)\n    / (UNLINK)\n    / (UNLOCK)\n    / (UNSUBSCRIBE)\n    └── * (ACL)\n        * (BIND)\n        * (CHECKOUT)\n        * (CONNECT)\n        * (COPY)\n        * (DELETE)\n        * (GET)\n        * (HEAD)\n        * (LINK)\n        * (LOCK)\n        * (M-SEARCH)\n        * (MERGE)\n        * (MKACTIVITY)\n        * (MKCALENDAR)\n        * (MKCOL)\n        * (MOVE)\n        * (NOTIFY)\n        * (OPTIONS)\n        * (PATCH)\n        * (POST)\n        * (PROPFIND)\n        * (PROPPATCH)\n        * (PURGE)\n        * (PUT)\n        * (REBIND)\n        * (REPORT)\n        * (SEARCH)\n        * (SOURCE)\n        * (SUBSCRIBE)\n        * (TRACE)\n        * (UNBIND)\n        * (UNLINK)\n        * (UNLOCK)\n        * (UNSUBSCRIBE)\n"}

I would expect a 404 to be returned in this case, but since it prints a request that it be reported, I am doing that.

Steps to Reproduce

The easiest way that I can spin up a fastify server is using the module faas-js-runtime, so instructions are here to do just that. But the problem should be reproducible with any fastify server.

Create an index.js file containing the following contents.

function handle() { return "Hello" }
module.exports = handle

Then type the following command in that same directory.

npx faas-js-runtime index.js

The server should start, and begin listening on port 8080. You can validate that it is working correctly by typing curl http://localhost:8080 in another terminal window. To recreate the problem type the following command.

curl http://localhost:8080/%C0

Expected Behavior

I would still expect to receive a 404 error, but I would not expect to see the mesage "this is likely a fastify bug, please report it" in my server logs.

[climba03003]

Bad Url is handled by frameworkErrors

[climba03003]

Fixed by #3128
It is target to v4 only.

[lance]

Bad Url is handled by frameworkErrors

OK, but does it make sense to put this message in the logs then?

"the default handler for 404 did not catch this, this is likely a fastify bug, please report it"}

I did spend a decent amount of time writing up this issue and recreating it, etc. only to have it closed so tersely. Could the error message indicate possible places to look such as frameworkErrors?

[climba03003]

I think your issue is duplicate of #3127 which is fixed by #3128
It is shipped as v4 as it may potentially change the routing behavior of v3 and break someone else.

Note: The reason why I close it that fast because I remember it should be fixed before. And the related issue and PR is linked above.

[lance]

I think your issue is duplicate of #3127 which is fixed by #3128

My apologies! I did search for similar errors, but apparently did not see this one. Thanks for all of the engagement here.