Fix: do not encode slashes in catch-all routes #2291
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This applies to all custom regex routes which match a slash or contain one in their literal part fixes vuejs#1638
✅ Deploy Preview for vue-router ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
ll3006
added a commit
to ridamoe/rida
that referenced
this pull request
Aug 1, 2024
The patched version fixes the issue where url parameters specified with catch-all regex url-encode the slash character. The patched version correctly handles this case while also preserving encoding on standard parameters. A PR for this patch has been submitted upstream [here](vuejs/router#2291). TODO: if this is merged, switch to npm registry version
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes #1638
Encoding of the parameters is now done by the matcher and is dependend on the matcher keys: every key has a keepSlash property that reflects if it should encode the slash character or not.
The keepSlash currently applies to all custom regex that either match a slash or contain one in their literal part, excluding lookaheads, lookbehinds and negative ranges. This is very simplistic but should be enough to cover both catch-all (e.g. "(.*)" routes) and explicit path regexes (e.g. "(deep/path/[a-z]*/)" )
I have also added a few tests to ensure everyting is working properly.
The Router > 'can redirect to a star route when encoding the param' test is currently failing as it sets a parameter with an urlencoded slash (%2F) and expects to find it as it is in the route. However, since this PR allows literal slashes in star routes, the actual url contains the sequence as a literal (%252F) rather than keeping the escaped slash.
I could edit the test, but I am unsure if this is behaivour that is being relied upon. In case it is, more work is needed to distinguish user-set urlencoded path segments from the normal usecase.
To test this PR I have updated the sandbox from #1638 here: codesandbox.io