next.js: Dynamic Router - url decoded parameter results in javascript 404

This bug also applies when deploying to an IIS web server using iisnode as an intermediary. Running the same app via “npm run start” without iisnode makes the error go away. Presumably because as the OP indicates, the brackets are getting needlessly URL decoded in the middle.

I agree that the resolution needs to be Next.js’s production router accepting either encoded or decoded brackets in URLs. But I found an interim solution that works in the iisnode case at least. The solution involved editing the server.js file iisnode is configured to bootstrap with. The solution replaces any brackets found in req.url with their URL-encoded equivalents. This is a laser-focused hack for dealing specifically with this problem and not others that may arise from URL transformation like this. Partly because I want to minimize URL hacking security risks. Partly because this should be a short-term patch and not the final solution. Worked for us though. Here’s our server.js file:

const { createServer } = require('http');
const { parse } = require('url');
const next = require('next');

const dev = process.env.NODE_ENV !== 'production';
const hostname = 'localhost';
const port = process.env.PORT || 3000;

// when using middleware `hostname` and `port` must be provided below
const app = next({ dev, hostname, port });
const handle = app.getRequestHandler();

app.prepare().then(() => {
    createServer(async (req, res) => {

        // Emergent bug in Next.js: doesn't deal wll with brackets in 
        // URL when iisnode or other reverse proxy is in the middle.
        // See https://github.com/vercel/next.js/issues/54325
        let reqUrl = req.url
            .replace(/\[/g, '%5B')
            .replace(/\]/g, '%5D');
        //console.log(`>>> ` + reqUrl);

        try {
            // Be sure to pass `true` as the second argument to `url.parse`.
            // This tells it to parse the query portion of the URL.
            const parsedUrl = parse(reqUrl, true);

            await handle(req, res, parsedUrl);

        } catch (err) {
            console.error('Error occurred handling', reqUrl, err);
            res.statusCode = 500;
            res.end('internal server error');
        }
    })
        .listen(port, (err) => {
            if (err) throw err;
            console.log(`> Ready on http://${hostname}:${port}`);
        });
});

Same problem here on production, when using dynamic routes. I downgraded to 13.4.12 now.

@navivanuva that version is outdated, please upgrade to latest version 13.5.4

Anyone able to test this PR for iisnode too? If we can confirm it fixes this scenario as well as nginx, then I can link both issues to the PR as a fix.

#56187

This bug also applies when deploying to an IIS web server using iisnode as an intermediary. Running the same app via “npm run start” without iisnode makes the error go away. Presumably because as the OP indicates, the brackets are getting needlessly URL decoded in the middle.

I agree that the resolution needs to be Next.js’s production router accepting either encoded or decoded brackets in URLs. But I found an interim solution that works in the iisnode case at least. The solution involved editing the server.js file iisnode is configured to bootstrap with. The solution replaces any brackets found in req.url with their URL-encoded equivalents. This is a laser-focused hack for dealing specifically with this problem and not others that may arise from URL transformation like this. Partly because I want to minimize URL hacking security risks. Partly because this should be a short-term patch and not the final solution. Worked for us though. Here’s our server.js file:

const { createServer } = require('http');
const { parse } = require('url');
const next = require('next');

const dev = process.env.NODE_ENV !== 'production';
const hostname = 'localhost';
const port = process.env.PORT || 3000;

// when using middleware `hostname` and `port` must be provided below
const app = next({ dev, hostname, port });
const handle = app.getRequestHandler();

app.prepare().then(() => {
    createServer(async (req, res) => {

        // Emergent bug in Next.js: doesn't deal wll with brackets in 
        // URL when iisnode or other reverse proxy is in the middle.
        // See https://github.com/vercel/next.js/issues/54325
        let reqUrl = req.url
            .replace(/\[/g, '%5B')
            .replace(/\]/g, '%5D');
        //console.log(`>>> ` + reqUrl);

        try {
            // Be sure to pass `true` as the second argument to `url.parse`.
            // This tells it to parse the query portion of the URL.
            const parsedUrl = parse(reqUrl, true);

            await handle(req, res, parsedUrl);

        } catch (err) {
            console.error('Error occurred handling', reqUrl, err);
            res.statusCode = 500;
            res.end('internal server error');
        }
    })
        .listen(port, (err) => {
            if (err) throw err;
            console.log(`> Ready on http://${hostname}:${port}`);
        });
});

This solves a bug that I’ve been struggling with for several weeks and therefore couldn’t update. Regardless, I hope the Next.js team fixes the bug. But in any case a great fallback, thank you very much.

We also stumbled upon this today. reverting to 13.4.12 for now…

Same with nginx 1.25.2 (reverse proxy) & Next.js containing dynamic routes. However, if I start the server locally with npm run build followed by npm run start, there are no problems to report. It’s very strange

Downgrade to 13.4.12 solve the issue 😕