Rewrites not working on client-side navigation in 12.2+

[luukdv]

Verify canary release

• [X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

Binaries:
  Node: 14.20.0
  npm: 6.14.17
  Yarn: N/A
  pnpm: N/A
Relevant packages:
  next: 13.0.1-canary.0
  react: 18.2.0
  react-dom: 18.2.0

Describe the Bug

When using version 12.2 or higher, rewrites don't work on client-side navigation anymore. It does work when visiting a url directly / refreshing the page. Initially reported in https://github.com/vercel/next.js/issues/38338.

Expected Behavior

Client-side navigations work the same as server-side page loads.

Link to reproduction

https://github.com/luukdv/next-bug

To Reproduce

• Clone https://github.com/luukdv/next-bug
• Run npm i && npm start
• Open http://localhost:3000
• Click "Visit this link"
• Click "Refresh the page"

[vibhor-web-headout]

having same issue here.

I believe it has to do with trailingSlash: true and modification in rewrite redirect's regex match logic.

const matcher = (0, _pathMatch).getPathMatch(rewrite.source + (process.env.__NEXT_TRAILING_SLASH ? '(/)?' : ''), {
    removeUnnamedParams: true,
    strict: true
});

[chrilis]

@luukdv Having the same issue (maybe related to #39638 and #39837) I found that replacing the trailing slash of the source with {/}? does fix the rewrites on client-side navigation.

{
-  source: "/pages/test/",
+  source: "/pages/test{/}?",
   destination: "https://example.com/",
}

I do not know if this is a bug or the documentation should be updated:

If you're using trailingSlash: true, you also need to insert a trailing slash in the source parameter. If the destination server is also expecting a trailing slash it should be included in the destination parameter as well.

[samithaf]

@luukdv Having the same issue (maybe related to #39638 and #39837) I found that replacing the trailing slash of the source with {/}? does fix the rewrites on client-side navigation.

{
-  source: "/pages/test/",
+  source: "/pages/test{/}?",
   destination: "https://example.com/",
}

I do not know if this is a bug or the documentation should be updated:

If you're using trailingSlash: true, you also need to insert a trailing slash in the source parameter. If the destination server is also expecting a trailing slash it should be included in the destination parameter as well.

Yep it's working with your approach! Probably need to update the official documentation?

[TommySorensen]

I'm using rewrites with trailingSlash: false (default) and rewrites still dont work. Going to http://localhost:300/api/proxy/some/page never hits the rewrite rule. If i change the next.config.mjs file to next.config.js everything just works.

{
  source: '/api/proxy/:path*',
  destination: `${apiUrl}/api/:path*`,
}

I tested in 12.3.2-canary.25. Also i am using a [[...slug]].tsx to catch all pages. Right now because the rewrite dont work it will always hit the slug page instead

[luukdv]

@luukdv Having the same issue (maybe related to #39638 and #39837) I found that replacing the trailing slash of the source with {/}? does fix the rewrites on client-side navigation. I do not know if this is a bug or the documentation should be updated

Nice workaround! Does not seem to work for every page though, for example on a home page (/) this error is returned: source does not start with / for route….

Based on the above, this comment and the fact that it's a sudden regression since 12.2 with no alternative solution (and the docs clearly state that the source should include the trailing slash as well), it still seems very much like a bug.

[chrilis]

For the home page we used /{/}?, which worked for us @luukdv. But not sure if that is actually a good idea.

[luukdv]

Updated the reproduction repository to use Next 13.

[goodalex]

I have the same issue in next 13.3.1.

After upgrading from next 12.2.5 to 13.3.1 this issue started to occur - but only when running next dev.

When running next build and next start everything works fine. In next dev all rewriting rules from next.config.js are ignored when the page is called directly. Does anyone have an idea what could be the reason for that?

I am not using trailingSlash options so I can not try the workaround from above.

[will0684]

I have the same issue in next 13.3.1.

After upgrading from next 12.2.5 to 13.3.1 this issue started to occur - but only when running next dev.

When running next build and next start everything works fine. In next dev all rewriting rules from next.config.js are ignored when the page is called directly. Does anyone have an idea what could be the reason for that?

I am not using trailingSlash options so I can not try the workaround from above.

We are having the same issue with Next 13.3.1 when trying to update from 13.2.3. With yarn dev, rewrites are simply not being respected but with yarn build everything works as expected. We are using Next/Link for navigation. We use rewrites to manage internationalization of our paths.

Our repo is here. Ignore the outdated README.

To reproduce it:

Pull the repo and create a .env with the following values:

ADOBE_ANALYTICS_URL= AEM_GRAPHQL_ENDPOINT=https://www.canada.ca/content/_cq_graphql/decd-endc/endpoint.json

yarn install

Upgrade Next to 13.3.1, run yarn dev, go to localhost:3000/fr/accueil (our rewrite destination is /fr/home) and you will see that the page cannot be found, but that /fr/home does work.

Before updating Next, our rewrite config would work as expected.

[ijjk]

@will0684 could you create a fresh issue with your reproduction it looks unrelated to this issue and this one should be resolved. Yours seems specific to i18n and dev handling of rewrites.

I'm gonna close this one out as the original issue from Next.js 12.2 should no longer be relevant and the issue with trailing slashes with rewrites should be handled.

[luukdv]

@ijjk As noted here, this issue still exists using Next.js 13.

Can this please be reopened?

[luukdv]

The reproduction steps outlined here still apply with Next.js 13.4 for example.

[goodalex]

I was also wondering. Although the faulty behavior is not exactly the same, this issue is about rewrites not working as configured. Wouldn't one check whether rewrites work both ways when touching them anyway?

In my case there is no i18n involved.

[github-actions[bot]]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.