fix: encode path params per RFC 3986 path-segment rules in href/generatePath#15310
Merged
brophdawg11 merged 2 commits intoJul 14, 2026
Merged
Conversation
Contributor
✅ CLA SignedThanks for signing the Contributor License Agreement. |
Contributor
✅ Change File FoundOne or more change files found.
|
nowells
force-pushed
the
fix/encode-path-params-pchar
branch
2 times, most recently
from
c5cf922 to
0773fcb
Compare
…atePath Follow-up to remix-run#15277, which fixed `href()` to URL-encode param values to match `generatePath()`. Both now encode with `encodeURIComponent`, which implements *query-string* escaping — a stricter rule than URL paths require. This over-escapes characters that RFC 3986 explicitly allows literally in a path segment: pchar = unreserved / pct-encoded / sub-delims / ":" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" https://datatracker.ietf.org/doc/html/rfc3986#section-3.3 `$ & + , ; = : @` only act as delimiters in a query string; in a path segment they carry no special meaning, and browsers keep them literal in `location.pathname`. Encoding them needlessly rewrites URLs: href("/releases/:v", { v: "1.0.0+1" }) // before: /releases/1.0.0%2B1 // after: /releases/1.0.0+1 which breaks apps that compare generated URLs against `window.location.pathname` (the browser reports the literal `+`), churns canonical/shareable URLs, and makes `href()` output disagree with what users see in the address bar. Changes: - Add an internal `encodePathParam()` that escapes structural/unsafe characters (`/ ? # %`, whitespace, non-ASCII) exactly as before, but restores the RFC 3986 pchar set that `encodeURIComponent` over-escapes - Use it for named params in `generatePath()` and for named params and splat segments in `href()` - Document path-segment vs query-string encoding semantics (with the RFC reference) in the `href()` and `generatePath()` JSDoc - Update and extend unit tests; add a change file Behavior is unchanged for every character outside `$ & + , ; = : @`, and `generatePath()`'s splat values remain un-encoded, as before. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
nowells
force-pushed
the
fix/encode-path-params-pchar
branch
from
0773fcb to
3f9701e
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Follow-up to #15277, which fixed
href()to URL-encode param values to matchgeneratePath(). Both now encode withencodeURIComponent, which implements query-string escaping — a stricter rule than URL paths require. This over-escapes characters that RFC 3986 explicitly allows literally in a path segment:$ & + , ; = : @only act as delimiters in a query string; in a path segment they carry no special meaning, and browsers keep them literal inlocation.pathname. Encoding them needlessly rewrites URLs:which breaks apps that compare generated URLs against
window.location.pathname(the browser reports the literal+), churns canonical/shareable URLs, and makeshref()output disagree with what users see in the address bar.Changes:
encodePathParam()that escapes structural/unsafe characters (/ ? # %, whitespace, non-ASCII) exactly as before, but restores the RFC 3986 pchar set thatencodeURIComponentover-escapesgeneratePath()and for named params and splat segments inhref()href()andgeneratePath()JSDocBehavior is unchanged for every character outside
$ & + , ; = : @, andgeneratePath()'s splat values remain un-encoded, as before.