Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/vigorous-wilson-25ycfg

To Reproduce

1. Start the application
2. Click the 2 links
3. Observe the console output

Current vs. Expected behavior

Current: always returns pathname /foo
Expected: returns /foo or /foo/ depending on the link

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 15.0.0-canary.25 // Latest available version is detected (15.0.0-canary.25).
  eslint-config-next: N/A
  react: 19.0.0-beta-04b058868c-20240508
  react-dom: 19.0.0-beta-04b058868c-20240508
  typescript: 5.1.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Middleware, Pages Router

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed), Other (Deployed)

Additional context

The issue turns up in conjunction with config.skipTrailingSlashRedirect being set to true.

The issue leads to all client-side navigation locking up in an infinite redirect loop when using middleware to redirect to trailing slash variants of the same url, e.g. from /foo to /foo/. In the middleware the pathname is still /foo even after the redirect, which starts the loop.

The issue (most likely) stems from the URL normalization that Next.js applies to /_next/data/* urls. The respective .json URLs are always normalized to whatever config.trailingSlash is set to, disregarding the setting of config.skipTrailingSlashRedirect.

This seems related, but not identical, to #66738. The source of the error could be close to the source of #58320 as well.

From the looks of it, this doesn't affect the app router. Here the pathname looked correct in both cases in a quick sandbox repro.