-
Notifications
You must be signed in to change notification settings - Fork 101
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
Fix for files with %
in filename
#452
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@@ -221,7 +221,8 @@ async function fastifyStatic (fastify, opts) { | |||
} | |||
} | |||
|
|||
const stream = send(request.raw, pathnameForSend, options) | |||
// `send(..., path, ...)` will URI-decode path so we pass an encoded path here | |||
const stream = send(request.raw, encodeURI(pathnameForSend), options) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
your comment: we uri decode path in send? How about apply a change in @fastify/send , like pass decodeUri option in options, by default true for backwards compat and we set it here to false and then we dont need to encodeURI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the docs of @fastify/send
is seems the path passed is intended to be URL-encoded:
path
is a urlencoded path to send (urlencoded, not the actual file-system path)
https://github.com/fastify/send?tab=readme-ov-file#api
While I agree that this seems like a little extra overhead it looks like the @fastify/send
API was not being used correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe send could be refactored to do what Uzlopak suggests
@@ -149,7 +149,7 @@ const dirList = { | |||
route = path.normalize(path.join(route, '..')) | |||
} | |||
return { | |||
href: path.join(prefix, route, entry.name).replace(/\\/gu, '/'), | |||
href: encodeURI(path.join(prefix, route, entry.name).replace(/\\/gu, '/')), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder, can we avoid this regex?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This regex was already there. I tried switching to path.posix.join
but that failed the tests on Windows.
@@ -149,7 +149,7 @@ const dirList = { | |||
route = path.normalize(path.join(route, '..')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we change it to?
Maybe on top of the file we do:
const pathPosixNormalize = path.posix.normalize
and then do:
route = path.normalize(path.join(route, '..')) | |
route = pathPosixNormalize(path.join(route, '..')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might work but it's not part of the fix for this PR. See #452 (comment)
I have the feeling, that we would reduce the performance with this change, and with a little bit more effort we can improve the overall performance. wdyt? |
In my opinion the slight performance hit is worth it for the correctness. It's worth noting that |
@Uzlopak the performance of this module is already pretty bad. We can't even try to match NGINX and similar in hosting static files. I don't think adding this is a problem. |
@mcollina would fastify/send#15 improve performance? |
To be honest, I think performance is not much of a consideration here and is a little off-topic. This change is about fixing a behaviour that is clearly a bug. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I benchmarked and did not see a significant performance loss.
Thanks all! 🙏🏼 When do you expect this to be in a release? |
Just released v7.0.4 |
Resolves #451
400 Bad Request
error when serving files with a%
in the filenamehref
parameter for directory listings (otherwise files with a%
in the filename generate an invalidhref
)Checklist
npm run test
andnpm run benchmark
and the Code of conduct