Fix catch-all router.query corruption with basePath + rewrites#93294
Merged
unstubbable merged 1 commit intoMay 13, 2026
Conversation
github-actions
Bot
added
created-by: Next.js team
Contributor
Tests PassedCommit: 8a064b5 |
unstubbable
force-pushed
the
hl/fix-base-path-middleware-rewrite-router-query
branch
from
8a38ad8 to
651fe55
Compare
In a Pages Router app that combines a `basePath`, `next.config.js` `rewrites`, middleware, and a catch-all dynamic route, a client-side `Link` navigation could land on the page with a corrupted `router.query`. Instead of holding the captured route segments, the catch-all param ended up holding the segments of the internal `_next/data/<buildId>/...` URL. Page code that builds further URLs from `router.query` then produced malformed paths and 404s in production. The corruption originated in `getMiddlewareData`, which was passing `nextConfig: undefined` to `getNextPathnameInfo` whenever `__NEXT_HAS_REWRITES` was true. With basePath set, that meant the basePath prefix was never stripped from the data-source URL, so the `/_next/data/` check never matched and the data prefix was left intact. The resulting pathname flowed back into `routeInfo.resolvedAs`, and on catch-all routes the route regex matched it and overwrote `router.query.<param>` with the data-URL segments. The original ternary at this call site (added in #48753) was there to avoid stripping the locale prefix, since `resolveRewrites` needs `as` to keep its locale prefix to match locale-aware rewrite sources. Disabling all of `nextConfig` was too coarse and broke basePath stripping in the process. The fix passes a partial config with only `basePath` and `trailingSlash`, which keeps the locale prefix intact while still letting `getNextPathnameInfo` strip basePath before the data-prefix check. The new `test/e2e/middleware-dynamic-basepath-matcher-rewrites/` fixture is the catch-all + basePath + rewrites + middleware variant of `test/e2e/middleware-dynamic-basepath-matcher/` (#48753's regression test), and asserts that `router.query.path` is preserved across a client-side `Link` navigation.
unstubbable
force-pushed
the
hl/fix-base-path-middleware-rewrite-router-query
branch
from
651fe55 to
8a064b5
Compare
unstubbable
requested review from
timneutkens and
ztanner
and removed request for
ztanner
5 tasks
timneutkens
approved these changes
May 13, 2026
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.
In a Pages Router app that combines a
basePath,next.config.jsrewrites, middleware, and a catch-all dynamic route, a client-sideLinknavigation could land on the page with a corruptedrouter.query. Instead of holding the captured route segments, the catch-all param ended up holding the segments of the internal_next/data/<buildId>/...URL. Page code that builds further URLs fromrouter.querythen produced malformed paths and 404s in production.The corruption originated in
getMiddlewareData, which was passingnextConfig: undefinedtogetNextPathnameInfowhenever__NEXT_HAS_REWRITESwas true. With basePath set, that meant the basePath prefix was never stripped from the data-source URL, so the/_next/data/check never matched and the data prefix was left intact. The resulting pathname flowed back intorouteInfo.resolvedAs, and on catch-all routes the route regex matched it and overwroterouter.query.<param>with the data-URL segments.The original ternary at this call site (added in #48753) was there to avoid stripping the locale prefix, since
resolveRewritesneedsasto keep its locale prefix to match locale-aware rewrite sources. Disabling all ofnextConfigwas too coarse and broke basePath stripping in the process. The fix passes a partial config with onlybasePathandtrailingSlash, which keeps the locale prefix intact while still lettinggetNextPathnameInfostrip basePath before the data-prefix check.The new
test/e2e/middleware-dynamic-basepath-matcher-rewrites/fixture is the catch-all + basePath + rewrites + middleware variant oftest/e2e/middleware-dynamic-basepath-matcher/(#48753's regression test), and asserts thatrouter.query.pathis preserved across a client-sideLinknavigation.