Static asset requests to next.js trigger url slugs

[Chrischuck]

I have an application that uses multiple url slugged routes i.e. localhost:3000/[id] and localhost:3000/[id]/[otherId] for example.

I take these url slugs and make requests to my server with them. I'm getting a ton of server requests where the slugs are static assets so id for example will be static and otherId will be favicon.ico.

Logs in _app.js:

Console output:

I apologize in advance for the limited info, this is a closed source project but please let me know if you need more information

[willemliu]

I'm afraid that when you've set your dynamic routing up to catch all then the only thing to do is to discard the request if the [id] matches static.

[Chrischuck]

I feared I'd end up having to do this unfortunately, while I know this will work, i want it to be the last ditch effort...Also, does this mean that the static assets are triggering renders on the server?

[ijjk]

Hi, what version of Next.js are you on? I'm not able to reproduce this on the latest version of Next.js v9.2.2 as we check for static files before rendering any pages.

If a static file doesn't exist and it is at the same depth as your dynamic route then this is the expected behavior as we don't restrict what paths you are allowed to use with dynamic routes

[Chrischuck]

Here are two prod logs of the behavior

I've also seen static get plucked in prod as well

[ijjk]

So no static assets are being requested since they don't actually exist right? If are wanting to prevent this page from receiving specific requests you can test out the new experimental rewrites feature and rewrite them to a non-existent page so it 404s e.g.

module.exports = {
  experimental: {
    async rewrites() {
      return [
        {
          source: '/static/:path*',
          destination: '/_404'
        },
      ]
  }
}

Note: the above rewrite will only work correctly on the latest canaries of Next.js since it is an experimental feature and it will only 404 for non-existing assets

[Chrischuck]

What about in the case of the favicon.ico where I would like that to be served? Also is it possible to ignore rather than send the request to a page? I'd like to avoid an unnecessary render on the server

[ijjk]

If the favicon.ico is in your public folder it will be served before the rewrite is hit along. On the latest canaries of Next.js the 404 page is static which means you aren't doing additional renders on the server using this strategy

[Chrischuck]

I see, thank you for the help! One last thing before I try this route. But if I visit http://localhost:8081/favicon.ico in my browser, I don't get the favicon at all but I get the page for that route. my public folder is public/favicon.ico and that's it. Is there any possible way for next.js to overwrite? I'm trying to make a repro this on another app but haven't been able to...

[Chrischuck]

Thanks for the help @ijjk and @willemliu

The first part of the problem: I had my public directory inside my src folder so next wasn't looking in the right spot...

For the other issues like index.html showing up, I'll probably opt for the rewrite approach.

Thanks again for your help/time!

[jesstelford]

I ran into this same issue but in a slightly different situation, which I think might be a bug in the next.js deployment preset on now(?):

My project has a monorepo* structure like so:

.
├── package.json
├── api           (my backend server)
│   └── ...
└── www           (next.js site)
    ├── package.json
    ├── next.config.js
    ├── pages
    │   └── ...
    └── public
        └── ...

Note the next.js site is in a sub-folder: ./www.

I have now deployment options setup like so:

• Build command: yarn --cwd www next build (equivalent to cd www && next build)
• Output directory: www/.next
• Root directory: ./

When I deploy this, the next.js site runs successfully, but none of the files from ./www/public/* are included in the Output of the deployment.

However, if I move the ./www/public folder up into the root to ./public:

 .
 ├── package.json
 ├── api
 │   └── ...
+├── public        (moved ./www/public to ./public)
+│   └── ...
 └── www
     ├── package.json
     ├── next.config.js
     ├── pages
     │   └── ...
-    └── public
-        └── ...

Everything then works; the next.js site renders correctly, and all the files in ./public/* are now accessible.

This hints at there possibly being an issue with where the now next.js preset looks for the public folder?

My assumption was; it would be moved to <outputDir>/static/public (or similar) during build, and so would pick up the Output directory config and all work as expected.

It appears this assumption is incorrect and instead it looks for it at <rootDir>/public.

Is this a bug, or expected behaviour?

---

* The monorepo is setup using yarn workspaces, so the deployment needs to run yarn in the root directory, not in ./www or things break.