Using getServerSideProps with Middleware causes all props to be undefined on client-side

[kennsorr]

Summary

I'm trying to do a simple redirect on every page if a certain condition is true using Nextjs middleware.

For some reason, whenever the matcher in middleware.ts matches a page, all props passed from getServerSideProps on that page are undefined when they reach the client side. When I remove pages from the matcher regex, they work as expected, and props are populated.

Example

/middleware.ts:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export default async function middleware(req: NextRequest) {
  return NextResponse.next();
}

export const config = {
  matcher: ['/'],
};

/pages/index.tsx:

export async function getServerSideProps(context) {
  const greeting = 'hello';
  console.log(greeting); // 'hello' in terminal
  return {
    props: {
      greeting,
    },
  };
}

export default function Home({ greeting }) {
  console.log(greeting); // undefined in browser console
   ...

Additional information

getServerSideProps is firing, and I see the correct values in the terminal, but I'm still getting undefined on the client-side specifically is the middleware executes. Is it possible to use both? Or their a better approach to redirecting from all pages than using middleware.ts?

[icyJoseph]

Well that's odd... middleware should not cause this.

Could you add a bit more info.

• do you have _app.tsx?
• next.js version?
• node version?
• example of you do the redirect
• are you also redirecting _next/data requests?

Attempts

I've tried to reproduce your situation with:

import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export default async function middleware(req: NextRequest) {
  if (req.nextUrl.pathname === "/") {
    req.nextUrl.pathname = "/about";
    return NextResponse.redirect(req.nextUrl);
  }
  return NextResponse.next();
}

export const config = {
  matcher: ["/"],
};

And the about page is just:

export const getServerSideProps = () => {
  return { props: { foo: "bar" } };
};

export default function About(props: { foo: string }) {
  return <div>About {props.foo}</div>;
}

No luck.

Somehow I have a hunch that the problem is in the _app file, are you passing along the pageProps?

Like this:

import type { AppProps } from 'next/app'

export default function App({ Component, pageProps }: AppProps) {
  return <Component {...pageProps} />
}

[kennsorr]

Seems like the problem only occurs when I default to the original route with NextResponse.next(). Your example works well for me too since it's doing a redirect on "/" at all times, but in the example below, the issue occurs on "/".

export function middleware(req: NextRequest) {
  if (req.nextUrl.pathname.startsWith("/tag")) {
    req.nextUrl.pathname = "/about";
    return NextResponse.redirect(req.nextUrl);
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/(tag|about)(.)*', '/'],
};

I have _app.tsx:

    <UserProvider>
      <ThemeProvider attribute='class' enableSystem={false}>
        <main className={helvetica.className}>
          <Component {...pageProps} />
        </main>
      </ThemeProvider>
    </UserProvider>

• node - v16.13.0
• next - ^13.1.1

[icyJoseph]

I can't reproduce this. My / has GSSP and I see the props. I used your middleware example exactly, same next and node versions.

I go to /, I see props, I navigate to about, or tags, and click back to /, I see GSSP props every time.

Would you mind setting up a repository where this happens?

[javad7z7]

I can't reproduce this. My / has GSSP and I see the props. I used your middleware example exactly, same next and node versions.

I go to /, I see props, I navigate to about, or tags, and click back to /, I see GSSP props every time.

Would you mind setting up a repository where this happens?

I have the same problem with these samples, when i fetch data in getserversideprops and in prod mode props undefined !
I think this is for next-pwa and stale-while -revalidate strategy

[hoangvu12]

I'm facing the same problem, and it only happens in production. In development enviroment, all the props are working fine.

[AirmanEpic]

I had this issue and fixed it. You need to downgrade to 13.3.1 apparently. It might work for other 13.3.x but 1 was the first and only one I tried. Not really inclined to try any others.

What I did:

1. change my nextjs version to 13.3.1 in package.json
2. run npm i
3. redeploy (I had to fix a problem with crypto but that's irrelevant)

[lopezjurip]

I'm having a similar issue with getServerSideProps + middleware.ts in Next.js 14.1

code: 'MODULE_NOT_FOUND',
requireStack: [
'/var/task/node_modules/next/dist/shared/lib/head.js',
'/var/task/node_modules/next/head.js',
'/var/task/apps/fraccional-web/.next/server/pages/_app.js',
'/var/task/node_modules/next/dist/compiled/next-server/server.runtime.prod.js',
'/var/task/apps/fraccional-web/___next_launcher.cjs'
],
page: '/www/invoice/65/1000000'
}
Error: Cannot find module 'next/dist/server/future/route-modules/pages/vendored/contexts/amp-context'

[javad7z7]

I'm facing the same problem in next 13.4.10, and it only happens in production and i cant redirect in middleware because my next/link not work and show client side error in production!

[25khattab]

is there are any help about this because I honestly have no I dea why this issue happends andI kind of need the middleware in the app

[icyJoseph]

Does you app use next-pwa?

[kiily]

Hi there, we're on Next.js 14.2.25 and do use next-pwa. This is happening for very specific routes and not in others. It is definitely linked to matching those routes in the middleware because the issue re-appears as soon as I match all pages.

Our component expects props but they are undefined which causes the page to break. On reload, they work as expected. This makes it hard to rely on middleware for anything really :/ . The issue only occurs in deployed environments, works fine locally

Any clues if on whether next-pwa could be interefering here?

[icyJoseph]

Yes, next-pwa has a stale-while-revalidate setting by default, which doesn't make sense for pages with GetServerSideProps.

Check this answer: #42405 (comment) it has some code examples, and refers to even more times I've answered this :)

[kiily]

Hey @icyJoseph, thanks for the lightnight fast reply 🙌

Epic! Definitely a potential solution there. I suspect that particular default may be causing other issues with the service worker that I have observed.

Will check this out and report back.

For the time being, ignoring the pages with issues in the middleware works as a patch

[kiily]

Quick one to double-check, but for getStaticProps pages we should still use the default stale-while-revalidate (assuming I understood this correctly) as it would not need to regenerate the page on every request. Is that correct?

[icyJoseph]

Right, cuz, you might be doing revalidate and what not, so you'd likely want it to go check with the network, but server from its cache first. Here's a handy resource https://developer.chrome.com/docs/workbox/modules/workbox-strategies

[kiily]

That article is very helpful, I have a mix on the suggested default with NetworkFirst and targetting specific routes for StaleWhileRevalidate and NetworkOnly strategy