-
-
Notifications
You must be signed in to change notification settings - Fork 389
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 the invalid matching of the ":name*" parameter #261
Fix the invalid matching of the ":name*" parameter #261
Conversation
I've added a failing test that captures the issue. The test result:
The test result seems to reproduce the unexpected behavior described in #260. I'll provision the fix as suggested sometime tomorrow. Thank you for your effort in reviewing this. Feel free to point out if I'm adding things in the wrong order/structure. |
src/index.spec.ts
Outdated
], | ||
[[null, "/test"]] | ||
[[null, "/test"]], |
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.
Unexpected autoformatting, although I have no autoformatting enabled. I suspect the commit hook has formatted the files using the wrong Prettier configuration or something. Will resolve.
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.
Running npm run prettier src/**/*.ts
in a freshly cloned repository produces massive changes in formatting. I suspect that Prettier was introduced to the code base but the code was never formatted. I'd also recommend having an explicit Prettier configuration defined in the project.
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've raised this as a separate issue in #262.
79b5591
to
5df644e
Compare
4208215
to
80d4d03
Compare
primary use case: * regex pattern matches a subset of the URL pathname example (configs): - source: '/foo/:bar*' - destination: '/:bar' - purpose: * 'rewrites' rule would be used to silently ignore the leading 'foo/' directory in path * 'redirects' rule would be used to trigger a 301 redirect to a new URL that removes the leading 'foo/' directory in path example (behavior): - request URL path: '/foo/a/b/c/d/e/f.txt' - :bar interpolates to value (before encoding): 'a/b/c/d/e/f.txt' - :bar interpolates to value (after default encoding): encodeURIComponent('a/b/c/d/e/f.txt') === 'a%2Fb%2Fc%2Fd%2Fe%2Ff.txt' * if the corresponding 'rewrites' or 'redirects' rule includes the flag: {"raw": true} then the raw value will be returned without any encoding based on: * upstream PR 85 vercel/serve-handler#85 references: * pathToRegExp.compile(data, options) https://github.com/pillarjs/path-to-regexp#compile-reverse-path-to-regexp road blocks: * pathToRegExp bug pillarjs/path-to-regexp#260 pillarjs/path-to-regexp#261 status: - the desired behavior will remain broken until this PR is merged - 'source' patterns that match one or more '/' characters cause the library to throw an Error for a failed assertion
This fixes the problem where: const p = new URLPattern({ pathname: ':name*' }); const r = p.exec('foobar'); console.log(r.pathname.groups.name); Would log 'r' instead of 'foobar'. This is an upstream bug in path-to-regexp: pillarjs/path-to-regexp#260 This commit essentially applies the proposed fix in: pillarjs/path-to-regexp#261 And adds the WPT tests from: https://chromium-review.googlesource.com/c/chromium/src/+/3123654
This fixes the problem where: const p = new URLPattern({ pathname: ':name*' }); const r = p.exec('foobar'); console.log(r.pathname.groups.name); Would log 'r' instead of 'foobar'. This is an upstream bug in path-to-regexp: pillarjs/path-to-regexp#260 This commit essentially applies the proposed fix in: pillarjs/path-to-regexp#261 And adds the WPT tests from: https://chromium-review.googlesource.com/c/chromium/src/+/3123654
This fixes the problem where: const p = new URLPattern({ pathname: ':name*' }); const r = p.exec('foobar'); console.log(r.pathname.groups.name); Would log 'r' instead of 'foobar'. This is an upstream bug in path-to-regexp: pillarjs/path-to-regexp#260 This commit essentially applies the proposed fix in: pillarjs/path-to-regexp#261 And adds the WPT tests from: https://chromium-review.googlesource.com/c/chromium/src/+/3123654
This fixes the problem where: const p = new URLPattern({ pathname: ':name*' }); const r = p.exec('foobar'); console.log(r.pathname.groups.name); Would log 'r' instead of 'foobar'. This is an upstream bug in path-to-regexp: pillarjs/path-to-regexp#260 This commit essentially applies the proposed fix in: pillarjs/path-to-regexp#261 And adds the WPT tests from: https://chromium-review.googlesource.com/c/chromium/src/+/3123654
64fde72
to
27766e2
Compare
Codecov Report
@@ Coverage Diff @@
## master #261 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 1 1
Lines 243 246 +3
Branches 96 98 +2
=========================================
+ Hits 243 246 +3
Continue to review full report at Codecov.
|
GitHub
:name*
pattern #260Changes
:name*
problematic parameter pattern.