Chunks on Dynamic Routes 404 when URL is Partially Encoded/Decoded

Link to the code that reproduces this issue

https://github.com/pseudotsuga-fir/static-file-url-encoding-nextgram-example/tree/main

To Reproduce

1. Install dependencies and build the application npm run build
2. Start the application npm run start
3. Locate the chunk for the dynamic route/modal: ls .next/static/chunks/app/@modal/'(.)photos'/'[id]'
4. Make a request for the chunk with the URL encoded and decoded, see that response is 200:
   4.1 curl -I "http://localhost:3000/_next/static/chunks/app/%40modal/(.)photos/%5Bid%5D/{{CHUNK_FILE_HERE}}"
   4.2 curl -I "http://localhost:3000/_next/static/chunks/app/@modal/(.)photos/\[id\]/{{CHUNK_FILE_HERE}}"
5. Make a request for the chunk with the URL partially decoded, see that response is 404:
   5.1 curl -I "http://localhost:3000/_next/static/chunks/app/@modal/(.)photos/%5Bid%5D/{{CHUNK_FILE_HERE}}"

Current vs. Expected behavior

Current Behavior

URL's for chunks that have been partially decoded (for example when deployed through some serverless computing providers) will 404. An example is the chunk: http://localhost:3000/_next/static/chunks/app/@modal/(.)photos/%5Bid%5D/page-123456789.js, which will fail because the at symbol (@) is unencoded while the square brackets ([]) are encoded.

Expected Behavior

The chunks should be able to load when the URL is partially encoded, as how it worked in previous versions of Next (see below for more detail on versions). The chunk: http://localhost:3000/_next/static/chunks/app/@modal/(.)photos/%5Bid%5D/page-123456789.js should load the same as http://localhost:3000/_next/static/chunks/app/%40modal/(.)photos/%5Bid%5D/page-123456789.js.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:02:45 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T8112
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 22.14.0
  npm: 10.9.2
  Yarn: N/A
  pnpm: 8.15.9
Relevant Packages:
  next: 15.2.5 // Latest available version is detected (15.2.5).
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.3
Next.js Config:
  output: N/A

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

Dynamic Routes, Parallel & Intercepting Routes

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

Other (Deployed)

Additional context

Issue is present on latest canary version as of writing: 15.3.0-canary.46. Last working version was 15.0.0-canary.160. This issue becomes present in the following canary version, 161, as a result of PR #70256

This issue will affect all Next apps deployed on Google's cloud run, as cloud run instances partially decode URL's before they are passed through. This is a known issue in the Google Cloud documentation. This also affects other deploys such as certain AWS serverless options.

This issue appears to have been present for Vercel deploys around February:

I’m having exactly the same issue when upgrading from Next 14 to 15.1.6, only when deployed to Vercel as well.

Route is set up as /site/[host]/[[...path]] and await props.params on my layout returns { host: '%5Bhost%5D' }.

Originally posted by @hernansartorio in #74532

Issue mentioned above (#74532) appears to be partially related or entirely the same.

This is no longer the case for Vercel deploys and appears to have been patched there, as can be seen when reproducing the issue via the steps above on the same app deployed to Vercel: https://static-file-url-encoding-nextgram-example.vercel.app

_NEXT-4495

Start with the linked static-file-url-encoding-nextgram-example reproduction: run npm run build and npm run start, then compare the encoded and partially decoded curl requests. Use the regression introduced by PR #70256 as the code reference; done when the partially decoded dynamic-route chunk returns 200 like the other URL forms.