Middleware rewrites do not automatically handle i18n

Verify canary release

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

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000
Binaries:
  Node: 16.13.0
  npm: 8.1.0
  Yarn: 1.22.17
  pnpm: 6.30.1
Relevant packages:
  next: 12.1.6-canary.14
  react: 18.1.0
  react-dom: 18.1.0

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

Vercel

Describe the Bug

Server side renders are return 404s for paths adjusted by rewrites in our _middleware.js. Client side routing worked fine for this paths, which meant these 404s weren’t immediately apparent in QA.

This took quite a while to debug this; When i18n is provided in next.config.js middleware rewrites break.

Expected Behavior

Next.js generally does an amazing job of reconciling the default locale automatically. It’d be great if this would be extended to the middleware as well (i.e. prepend the pathname with the default locale, if is doesn’t start with a locale).

It’s also possible that this is by design. If so, I would suggest calling this out clearly in the documentation (i.e. Caveats).

To Reproduce

Clone this repo and deploy to Vercel.

Both host1.testingwebsite.co and host2.testingwebsite.co that are configured in the middleware are pointing to cname.vercel-dns.com for your convenience.

[javivelasco]

@joshuabaker I’ve just tried to reproduce with the most recent canary but I didn’t use the hostnames but instead used a query parameter to decide how to rewrite. In practical terms it works exactly in the same way if I’m not missing anything. To update to the latest canary you need to move your middleware file from pages/_middleware.js to /middleware.js in the root folder. All APIs you are using are compatible with the latest version so my testing code looks like this:

import { NextResponse } from "next/server";

export default function middleware(req) {
  const url = req.nextUrl.clone();
  const siteId = req.nextUrl.searchParams.get("site") || "0";
  if (!["0", "1", "2"].includes(siteId)) {
    return new Response(null, { status: 404 });
  }

  if (
    url.pathname.includes(".") || // exclude file paths (e.g. public folder)
    url.pathname.startsWith("/api") || // exclude all API routes
    req.headers.has("x-prerender-revalidate") // exclude revalidate requests
  ) {
    return undefined; // Do nothing
  }

  if (url.pathname.startsWith(`/_sites`) || !siteId) {
    return new Response(null, { status: 404 });
  }

  if (url.pathname === "/blog") {
    url.pathname += "/page/1";
  }

  url.pathname = `/_sites/${siteId}${url.pathname}`;
  return NextResponse.rewrite(url);
}

First I tested the app exactly as in your repository and indeed visiting the root page you get a 404. I did reproduce it. After updating I deployed again and it all works as expected. If you change the query parameter to be a different site rewrites will work just fine.

About NextURL indeed it does. For example, if you have a basePath say /root and support es locale and you have a request to https://test.vercel.app/root/es/about then NextURL will be:

request.nextUrl.locale // 'es'
request.nextUrl.basePath // '/root'
request.nextUrl.pathname // '/about'
String(request.nextUrl) // https://test.vercel.app/root/es/about

Since it all seems to be working fine, I’m closing this issue! Thanks for reporting and for the feedback 🙏

[github-actions[bot]]

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