inconsistent application of `encodeUri`
See original GitHub issuePrerequisites
- I have written a descriptive issue title
- I have searched existing issues to ensure the bug has not already been reported
Fastify version
3.21.1
Plugin version
4.2.3
Node.js version
14.17.6
Operating system
macOS
Operating system version (i.e. 20.04, 11.3, 10)
11.6
Description
I needed to disable the wildcard
setup in favor of explicit static routes so I could use the catch all route for handling non-static pages.
This broke some unrelated route handling later on and I’ve tracked it back to this change. I have files that need to be served from the /page-data/app/[...]/page-data.json
route. This works fine when wildcard: true
. However, when wildcard: false
the code uses encodeUri
on all the file names meaning the server is now listening for /page-data/app/%5B...%5D/page-data.json
and breaks my app.
Steps to Reproduce
Try serving a file with fastify-static
and wildcard: false
. If the file has characters modified by encodeUri
then the file will 404.
Expected Behavior
I’d expect that setting wildcard: false
would still allow /page-data/app/[...]/page-data.json
to be served at it’s correct path.
Issue Analytics
- State:
- Created 2 years ago
- Comments:13 (5 by maintainers)
@moonmeister according to rfc the
[
and]
characters must always be encoded (stackoverflow). But it looks like browsers (like chrome) and node-fetch just ignore that rule and send[
and]
as is. When you setwildcard: false
the framework lists all the files inroot
directory and creates handlers for each file doingencodeURI
for files paths which is the right thing to do. But node-fetch or chrome send un-escaped[
]
so the path does not match to any file. When you setwildcard: true
obviously the framework creates a single handler forroot + '*'
path. Then no matter if browser encodes the path or not it gets to the handler with asterisk. In your case I would suggest to always encode path when requesting the file (which won’t work in browser):Another solution would be to PR the code and add un-encoded (decoded) routes along with encoded ones. But I am not sure how bad this solution is.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.