Trouble with root level redirects. How can I debug this?
Answered
Highlander posted this in #help-forum
HighlanderOP
Maybe it's painfully obvious?
I'm trying to add a redirect to an existing site. Uses Page Routing.
Ideally, from root, anything matching
I have read https://nextjs.org/docs/pages/api-reference/next-config-js/redirects multiple times.
I made sure to explicitly set
Here's a relevant portion of my config:
None of these, even
Testing via curl, with
Any ideas how to best debug this? E.g., how to test matchers, etc?
I'm trying to add a redirect to an existing site. Uses Page Routing.
Ideally, from root, anything matching
^/\d{1,5} (non-empty path, beginning with 1 to 5 digits) should be redirected to a given, existing path. I have read https://nextjs.org/docs/pages/api-reference/next-config-js/redirects multiple times.
I made sure to explicitly set
trailingSlashes value. I've also removed any other redirects, removed all rewrites, and turned off any existing middleware. Here's a relevant portion of my config:
{
trailingSlash: false,
async redirects() {
return [
{
source: `/(\\d+)`,
destination: 'https://www.example.com/',
permanent: true,
locale: false, // Avoid `/{lang}/...` prefixes from i18n.
basePath: false, // Destination will not receive prefix.
},
{
source: `/:versionId(\\d+)/:slug`,
destination: '/some/valid/path',
permanent: true,
locale: false,
},
// Invalid case: bare Regex is invalid redirect (app won't start):
// {
// source: `/\\d+`,
// destination: '/some/valid/path',
// permanent: true,
// locale: false,
// },
{
source: `/(\\d{1,5})`,
destination: '/some/valid/path',
permanent: true,
locale: false,
},
{
source: `/:slug(\\d+)`,
destination: '/some/valid/path',
permanent: true,
locale: false,
},
{
source: `/fake/:slug(\\d+)`,
destination: '/some/valid/path',
permanent: true,
locale: false,
},
];
}
}None of these, even
/fake/123 receive a redirect response. Testing via curl, with
curl -I -X GET http://localhost:3000/123, etc. Always receiving a 404.Any ideas how to best debug this? E.g., how to test matchers, etc?
Answered by Highlander
E.g., I think I've determined that capturing
The workaround seems to be... move these kinds of redirects to Middleware, or further out toward ingress. 🤷♂️
/(\\d{1,5} but NEVER capturing /en/(\\d{1,5}) is not possible when i18n is enabled. The workaround seems to be... move these kinds of redirects to Middleware, or further out toward ingress. 🤷♂️
3 Replies
HighlanderOP
More context:
Startup:
Request in alternate terminal:
Extra output in Next terminal/log:
Startup:
❯ yarn run dev
▲ Next.js 14.2.5
- Local: http://localhost:3000
- Environments: .env.development, .env
✓ Starting...
✓ Ready in 791msRequest in alternate terminal:
❯ curl -I -X GET http://localhost:3000/333
HTTP/1.1 404 Not Found
Content-Security-Policy:
Cache-Control: no-store, must-revalidate
x-nextjs-cache: MISS
X-Powered-By: Next.js
ETag: "ap2x2hpwng14of"
Content-Type: text/html; charset=utf-8
Content-Length: 52734
Vary: Accept-Encoding
Date: Fri, 12 Jul 2024 16:12:56 GMT
Connection: keep-alive
Keep-Alive: timeout=5Extra output in Next terminal/log:
Browserslist: caniuse-lite is outdated. Please run:
npx update-browserslist-db@latest
Why you should do it regularly: https://github.com/browserslist/update-db#readme
○ Compiling /404 ...
✓ Compiled /404 in 2.1s (1214 modules)
GET /333 404 in 2725msHighlanderOP
I think I've discovered the issue. While I disagree with the resulting behavior, I'm not sure it's a bug.
If I disable i18n support in the app, these capture as expected.
What I think is happening is based on a misinterpretation from https://nextjs.org/docs/pages/api-reference/next-config-js/redirects#redirects-with-i18n-support
See, I thought (and it seemed intuitive) that if I supplied
Apprently, the correct interpretation is something like
If I disable i18n support in the app, these capture as expected.
What I think is happening is based on a misinterpretation from https://nextjs.org/docs/pages/api-reference/next-config-js/redirects#redirects-with-i18n-support
See, I thought (and it seemed intuitive) that if I supplied
locale: false , then I could capture /something-at-root but NEVER capture /en/something-at-root, which I don't actually want to capture. Apprently, the correct interpretation is something like
"by using locale:false, you are opting in to capture the locale value yourself. But it will always be part of the matched paths"HighlanderOP
E.g., I think I've determined that capturing
The workaround seems to be... move these kinds of redirects to Middleware, or further out toward ingress. 🤷♂️
/(\\d{1,5} but NEVER capturing /en/(\\d{1,5}) is not possible when i18n is enabled. The workaround seems to be... move these kinds of redirects to Middleware, or further out toward ingress. 🤷♂️
Answer