[karthickeyan-dev]

Closes #798

Problem

A rewrite (c.rewrite(), routing.rewrites, routing.fallbacks, _redirects 200) serves another route without changing the browser URL. But the page data's url was built from the rewritten request, so the client router took the destination as the current URL. After a rewrite, useRouter().url, .path and .query described the destination, router.refresh() loaded the destination, and active-link matching treated the visitor as being on it.

Change

requestPathWithSearch() in packages/void/src/pages/protocol.ts now builds the URL from c.originalUrl() when the request was rewritten:

• The path goes through decodePagePath(), so it is decoded the same way c.req.path is (/caf%C3%A9 → /café). Requests that were not rewritten get the same URL as before.
• The action re-render branch uses the same helper and still leaves out the action key.
• Build-time renders (createStaticNotFound) run without the routing context middleware, so the helper falls back to the served request when c.originalUrl is absent.

The client already keeps the requested URL in history after a mutation rewrite (3c53034). One assertion in pages-client.test.ts checked that the server sent the destination URL; it now expects the visible URL.

Tests

• New routing-runtime.test.ts cases cover middleware and rule rewrites for GET page loads, an encoded path, and named-action re-renders. All five fail without the fix (/maintenance?tab=1 instead of /app/account?tab=1).
• vp run check, vp lint and vp fmt --check pass.
• vp test run: 792 test files passed, 1 skipped.

No docs change: the rewrites reference already says the browser URL does not change.

🤖 Generated with Claude Code

[cpojer]

This needs a bit of work as rewrites can remove ordinary query parameters. A form submitted from /source?tab=profile, rewritten to /named?save&tab=profile, produces /source as its page URL. The client then pushes /source into history, losing the filter. protocol.ts:312 strips the first original query parameter using the rewritten request’s action marker. It needs to distinguish which query actually contains the action key.

[karthickeyan-dev]

@cpojer Thanks, fixed in a32774f.

The action key comes from the query of the rewritten request. Page data now strips it from the original query only when the rewrite kept that query (the two queries are equal). A destination with its own query leaves the original query unchanged, so a form on /source?tab=profile rewritten to /named?save&tab=profile reports /source?tab=profile, and the client keeps the filter in history.

The rewrite test now covers this for both c.rewrite() and routing.rewrites rules, plus a GET rewrite to a destination with a query. Both new POST cases fail on the previous commit.

[cpojer]

👍 Thank you.