Router incorrectly uses encodeURIComponent in path segemtns

[mitsuhiko]

Describe the bug

solid-router uses the wrong way to encode path parameters. It uses encodeURIComponent (which is for query strings) instead of encodeURI. This causes +foo to be encoded as %2Bfoo.

https://github.com/solidjs/solid-router/blob/e54fc4a3bc51d0727df052603a7c92d9da8e099b/src/routing.ts#L295C63-L295C81

Your Example Website or App

have none

Steps to Reproduce the Bug or Issue

1. register a URL with +foo as segment
2. encounter a 404 when navigating to it as it encodes it to %2Bfoo.

Expected behavior

It should navigate to +foo instead.

Screenshots or Videos

No response

Platform

• OS: macOS
• Browser: any browser

Additional context

No response

[mitsuhiko]

Some follow up detail about what I think should be happening.

First some things the clanker found:

• src/routing.ts:295 encodes every static path segment with encodeURIComponent
• src/utils.ts:createMatcher() later compares that encoded pattern against raw location.pathname segments

So for a route like +foo:

• route pattern becomes /%2Bfoo
• browser pathname stays /+foo
• matcher compares +foo vs %2bfoo
• result: no match / 404

And the clanker made a verification for it:

const route = createRoutes({ path: "+foo" })[0];

expect(route.pattern).toBe("/%2Bfoo");
expect(route.matcher("/+foo")).toBeNull();
expect(route.matcher("/%2Bfoo")).not.toBeNull();

What should happen? Well RFC 3986 suggests this:

• 3.3: path segments are segment = *pchar
• 3.3 / 2.2: pchar includes sub-delims, :, and @
• 2.2: sub-delims includes +

So + is a valid literal path character.

Also, RFC 3986 explicitly says reserved characters are protected from normalization:

URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent.

That matters here: +foo and %2Bfoo are not guaranteed to be interchangeable. Extra point of clarification: + means space rule is query/form behavior and does not apply to path segments.

For example:

• new URL("https://x/+").pathname → "/+"
• new URL("https://x/?q=+").searchParams.get("q") → " "

So the router is definitely wrong to rewrite literal + in a path segment and then match against raw pathname.

There is a related issue here: #509.