Page chunk for catch-all page at root level is evaluated/rendered on the server

[Yegair]

Page chunk for catch-all page at root level is evaluated/rendered on the server

[mraerino]

In fact, the URL only gets shadowed/rewritten when the square brackets are URI encoded: https://example.com/%5B%5B...any%5D%5D.js. On the other hand, the request for https://example.com/[[...any]].js works totally fine. So that led us to suspect that perhaps the netlify.app logic for checking if a local file exists may not correctly decode URIs.

thank you for pointing out that detail. seems to be something we'd want to fix in the future. i'll make sure to open an internal issue.

would there be a way to publish that file without special characters for now?

[lindsaylevine]

#77 re-addresses this :)

[FinnWoelm]

Hi @Yegair,

Thank you for your kind words and for this detailed issue report! I think you are absolutely right — it's probably related to issue #41.

@lindsaylevine is already in touch with the team that manages the Netlify redirects/rewrites feature, to see if they can dig into the issue. We will keep you and everyone else posted here!

For now, it's best to use the "no-op redirect" you mentioned.

Stay tuned and thanks again for the report & repo to reproduce the issue! 🔥

[mraerino]

@FinnWoelm i'm curious: why wouldn't you add that /_next/* /_next/:splat 200 rule to the redirects file in the build process of next-on-netlify?
it seems to always be a good idea right?

[FinnWoelm]

Hi @mraerino, thanks for checking this out! Really appreciate your help!

All redirects generated by next-on-netlify are non-force redirects, so they should not shadow existing files. This always works correctly, except in the case where the asset has a square bracket in its filename. Then the URL gets shadowed even though a local file exists!

In fact, the URL only gets shadowed/rewritten when the square brackets are URI encoded: https://example.com/%5B%5B...any%5D%5D.js. On the other hand, the request for https://example.com/[[...any]].js works totally fine. So that led us to suspect that perhaps the netlify.app logic for checking if a local file exists may not correctly decode URIs.

Adding to that suspicion is the fact that this issue only occurs when a catch-all redirect is present, such as: /* /myfile.html 200. Without that redirect, the URL with encoded square brackets yields the correct file. With that redirect, the same URL with encoded square brackets incorrectly gets rewritten to myfile.html.

Please correct me if I'm wrong, but doesn't the fact, that a redirect with /_next/* /_next/:splat 200 solves this issue, further add to the suggestion that there is an issue with decoding the URI? The redirect should not be necessary thanks to Netlify's shadowing rules (unless, of course, we had some forced redirects in our _redirects file, but there aren't any).

We wanted to raise this issue (rather than locally fix it with /_next/* /_next/:splat 200), in case there is actually an issue with the shadowing logic. Because if so, it might affect others using SPA with catch-all redirects (.e.g., a React app with /* /index.html 200) and local files with square brackets in their names (admittedly, it's not super common to have these in your file names).

Does that make sense? Am I mistaken in my understanding of how things should work? Happy to chat more at any time, if it would be helpful!

[FinnWoelm]

Hey @mraerino, that's awesome to hear!! 🙌 😊

We can't publish it without special characters (it's created that way by the framework and there are a lot of internal references to those files with square brackets), but I think we will do the /_next/* /_next/:splat 200 thing as you have suggested!

Thank you again for looking into this :)

[afzalsayed96]

Hi @FinnWoelm,

I'm facing this issue when I have something like pages/index.js & pages/[...rest].js.

The temporary /_next/* /_next/:splat 200 fix does not get applied in this case as it is not considered root level catch-all route.

The redirects generated are

/:rest/*  /.netlify/functions/next_rest  200

[lindsaylevine]

@afzalsayed96 looking into this, thanks for reporting!