Next.js Discord

Discord Forum

Trouble with root level redirects. How can I debug this?

Answered
Highlander posted this in #help-forum
Open in Discord
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 ^/\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 /(\\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. 🤷‍♂️
View full answer

3 Replies

HighlanderOP
More context:

Startup:

❯ yarn run dev
  ▲ Next.js 14.2.5
  - Local:        http://localhost:3000
  - Environments: .env.development, .env

 ✓ Starting...
 ✓ Ready in 791ms


Request 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=5


Extra 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 2725ms
HighlanderOP
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 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 /(\\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