-
-
Notifications
You must be signed in to change notification settings - Fork 574
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
feat: decode percent-encoded path in getPath #2714
feat: decode percent-encoded path in getPath #2714
Conversation
…already decoded in `getPath()`
…hey are already decoded in `getPath()`" This reverts commit 7192497.
…decoding Co-authored-by: Szymon Marczak <36894700+szmarczak@users.noreply.github.com>
deno_dist/utils/url.ts
Outdated
// Although this is a performance disadvantage, it is acceptable since we prefer cases that do not include percent encoding. | ||
const queryIndex = url.indexOf('?', i) | ||
return decodeURI( | ||
url.slice(start, queryIndex === -1 ? undefined : queryIndex).replace(/%25/g, '%2525') |
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 my benchmarks it seems like str.includes('%25') ? str.replaceAll('%25', '%2525') : str
is faster than calling .replace
with regex. Can you verify?
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.
Thank you. You are right!
It's faster to check in .includes
first.
s/replace/replaceAll/
didn't change in my benchmark results, so I'll leave replace(//g)
as it is, as it is generally used elsewhere in Hono.
Applied in 0eeaa7e
…2525" Co-authored-by: Szymon Marczak <36894700+szmarczak@users.noreply.github.com>
…ecode as much as possible
Thanks! I'll include this in the next minor release and merge it into the |
#2672
This PR contains #2688 + #2688 (comment)
Specification Changes
There are no major release-level changes, but there are some minor changes as follows
Symbols and multibyte characters can be included in the static string of the routing definition
When you define a routing as follows, it will now match, whereas before it did not match because the percent encoding for static strings was not taken into account when routing.
Requests made with a URL that are encoded more than necessary are now matched with a decoded URL
Suppose we have a routing definition like this,
Even if unreserved characters are extra encoded, they are now decoded and matched.
Regular expressions for path parameters are now tested against decoded characters
We do not think that this will break any applications, but applications that use regular expressions in path parameters should check when updating to see if they are affected.
Suppose we have a routing definition like this,
The following URLs match
The author should do the following, if applicable
bun denoify
to generate files for Denobun run format:fix && bun run lint:fix
to format the code