TypeError: s is not a function occurs when api routes do not match.

[skyddyyu]

Link to the code that reproduces this issue

https://github.com/skyddyyu/api-route-mismatch

To Reproduce

1.There is an api route /api/rest/upload in the project for file upload. When I accidentally enter the wrong routing address, such as api/ant/upload, an error message appears: TypeError: s is not a function.

Current vs. Expected behavior

There is an api route /api/rest/upload in the project for file upload. When I accidentally enter the wrong routing address, such as api/ant/upload, an error message appears: TypeError: s is not a function. This is not true. Expected to happen. At the same time, if the route cannot be recruited, there should be a friendly response. The request status and code should be 404. At the same time, different response information should be returned under different data type requests to provide a friendly reminder to the developer.

Verify canary release

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

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
Binaries:
  Node: 18.18.2
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.0.4
  eslint-config-next: 14.0.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A

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

App Router, Middleware / Edge (API routes, runtime)

Additional context

No response

[jupapios]

I was able to reproduce this bug on my production app (in practice it can be reproduced against any production app),

To add more context, the problem happens when you send a multipart/form-data (it does NOT happen with x-www-form-urlencoded) to a non-existent route.

ie,

POST /404-route HTTP/1.1
Host: localhost:3000
Content-Length: 128
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="hi"

hi
------WebKitFormBoundary7MA4YWxkTrZu0gW--

returns a 500 instead of 404.

[codebackup91]

I have a couple of logs with the same error on a webhook I exposed.
To elaborate on the repro steps, if you see a 405 error you probably have a middleware on top (ie next-auth or next-intl's middlewares), so just make sure the route you're testing against doesn't have one.

Here's a one line repro curl https://demo.vercel.store/api --form foo="bar"

[huozhi]

Fixed by #60526

[github-actions]

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