RFC: Returning redirects from getServerSideProps / getStaticProps

[timneutkens]

This has been released:

• https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation
• https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering

---

Original RFC

• Related discussions
  • Redirect issue with getserversideprops #13871
  • Redirect 404 errors #13813
  • Always redirect from page A to page B #13662
  • Return redirect from getServerSideProps #11281
  • How to Redirect in getStaticProps #11346
  • How to use getServerSideProps in a HOC for authentication #10925
  • Want to use getServerProps instead of getInitialProps, but how to implement server side redirect? #13635
  • No refresh when redirecting to the current url #12939
  • Can't find a way to properly redirect in 9.3 #11072
  • How to protect routes #13610
• Related issues
  • Docs: Missing information about redirecting #11797
• RFC

  • After getServerSideProps and getStaticProps were introduced there was a lot of feedback of users trying to do redirects (see list of discussions below mentioning redirects). Even with getInitialProps this issue has come up quite a bit given that you had to manually detect the server/client-side using either res and ending the response or Router.push (using the client-side Next.js router)

  • This would generally looks something like this:

    function HomePage() {
      return Hello World
    }
    
    HomePage.getInitialProps({res}) {
      if(res) {
        res.setHeader('Location', '/somewhere-else')
        // Next.js would auto-detect the response being finished and stops it's own process
        res.end()
        return {}
      }
      
      Router.push('/somewhere-else')
      return {}
    }
    
    export default HomePage

    • A major downfall with this approach is that data can not be prefetched, as it was not a pure function and could trigger a navigation simply by scrolling or hovering.

  • Some people wrote helper libraries and articles for this behavior

    • https://www.npmjs.com/package/nextjs-redirect
    • https://www.npmjs.com/package/next-redirect
    • https://stackoverflow.com/questions/58173809/next-js-redirect-from-to-another-page
    • How to redirect? #4931
    • https://linguinecode.com/post/how-to-redirect-on-the-server-side-with-next-js

  • Proposal

    • Ideally we'd provide a behavior to allow redirection as it'll avoid code duplication is user code and make it significantly easier to do a server-side or client-side redirect to a page. This could be driven by getStaticProps / getServerSideProps through returning an extra redirect key in both methods.

    • The redirect key would allow for setting permanent to true or false which will use the 308 and 307 status code respectively (they're the new equivalent of 301 / 302)

    • The redirect key would allow for setting the destination of where you want to go

    • An example of how this would look:

      javascript
      export default function HomePage() {
        return Hello World
      }
      
      export async function getServerSideProps({params}) {
        const item = await getData(params.id)
        if(!item) {
          return {
            redirect: {
              permanent: false,
              destination: '/somewhere-else'
            }
          }
        }
        
        return {
          props: {
            item
          }
        }
      }

    • When using static generation with the fallback: true behavior you might also want to redirect to another page when the page does not exists, hence why redirect might be useful there also:

      export default function HomePage() {
        return Hello World
      }
      
      export async function getStaticProps({params}) {
        const item = await getData(params.id)
        if(!item) {
          return {
            redirect: {
              permanent: false,
              destination: '/somewhere-else'
            }
          }
        }
        
        return {
          props: {
            item
          }
        }
      }

    • When moving between pages using next/router and next/link and a destination matches a route in the Next.js application a client-side transition happens. If it did not match a full transition happens.

[aralroca]

Love it!

[mrlaseptima]

I loveeeee it toooo . thanks you

[tomaszferens]

Not sure if it's possible, but could we somehow get an access to the request in getStaticProps? It would be useful for redirecting (or setting initial state) based on a cookie existence.

I'm referring to this comment: #11346 (comment)

[timneutkens]

When using static generation with the fallback: true behavior you might also want to redirect to another page when the page does not exists, hence why redirect might be useful there also:

This is already covered in the RFC. It can only be used together with fallback: true given that static pages are served from a CDN automatically (e.g. on https://vercel.com)

[jamesknelson]

Does this mean it won't be possible to cache redirects, or set redirects on pages statically generated due to paths returned from getStaticPaths?

I know with S3/Cloudfront at least, it's possible to set redirect headers for CDN URLs. For Navi's static generation, the way I did this was to generate a .headers file alongside each statically generated .html file, and include any headers there.

[kachkaev]

It's important to make sure the solution is TypeScript compatible. Looks like it can, assuming this change:

next.js/packages/next/types/index.d.ts

Lines 117 to 126 in 38bd1a0

	export type GetServerSidePropsResult<P> = {
	props: P
	}
	export type GetServerSideProps<
	P extends { [key: string]: any } = { [key: string]: any },
	Q extends ParsedUrlQuery = ParsedUrlQuery
	> = (
	context: GetServerSidePropsContext<Q>
	) => Promise<GetServerSidePropsResult<P>>

⬇️

+ type SomeStandardRedirectConfigType = {...}

 export type GetServerSidePropsResult<P> = {
   props: P
+ } | {
+  redirect: SomeStandardRedirectConfigType
 }

So when the result includes redirect, it cannot contain props. And when there are props, adding redirect is not allowed. Am I missing anything?

BTW what will Next do when it sees both fields returned from getServerSideProps / getStaticProps in runtime?

[nahtnam]

Just wondering, why 307/308? It seems like there isn't that much support in the older versions of Chrome and Firefox: https://caniuse.com/#search=308

[timneutkens]

You can still support older browsers with the HTML redirect approach, which Next.js will automatically handle.

[nfantone]

Are we contemplating the possibility of allowing cookies to be forwarded from redirects? That would be pretty useful for keeping authentication alive, for instance.

[nahtnam]

This is a good point actually. What about adding additional headers, cookies, etc? The ctx way allows you to attach it to the res (when rendered on the server)

[timneutkens]

What about adding additional headers, cookies, etc?

You can already achieve this in getServerSideProps if you really have to.

[arunoda]

@timneutkens this is great.
Are we going to support a case like this?

{
  redirect: {
    permanent: false,
    destination: 'https://someother.website/path'
  }
}

[timneutkens]

When a destination matches a route in the Next.js application a client-side transition happens. If it did not match a full transition happens.

Yep!

[Janpot]

This would make it easy for developers to accidentally write open redirects. Would it make sense that this behavior should be explicitly enabled through an external: true or allowExternal: true flag?

edit:

I mean code like

async function getServerSideProps ({ query }) {
  // ...
  return {
    permanent: false,
    destination: query.destination
  }
}

with the intention of only being used for internal links. a malicious actor could use this to construct a link that looks trustworthy, but redirects to a bad origin. I've also seen these sorts of redirects being used to exploit vulnerabilities that are otherwise harder to exploit.

[timneutkens]

Yeah I think that would make sense 👍 Though the Location could still be affected without absolute urls if the values are not encoded properly

[rokinsky]

@timneutkens this feature looks nice and useful, thank you. I have a question about

When a destination matches a route in the Next.js application a client-side transition happens. If it did not match a full transition happens.

Could you explain more what do you mean? A client-side transition (changing a route on the client-side) doesn't look SEO-friendly. Let me know if I'm wrong.

[timneutkens]

When moving between pages using next/router and next/link and a destination matches a route in the Next.js application a client-side transition happens. If it did not match a full transition happens.

Updated the message. It only relates to client-side routing.

[iammarkps]

How Vercel redirect login to dashboard without showing any part of login page? It’s seem to me that they use server side redirect but I’m not sure.

If it’s really server sided how can that page be so fast like it is static page?

I’ve also opened discussion here on swr repo

[timneutkens]

It was answered by someone already here: vercel/swr#514 (comment)

[iammarkps]

@timneutkens Thank you!

[Vadorequest]

I'm interested in this RFC to automatically opt-in to preview mode by redirecting to my /api/preview endpoint if the current stage of the application is staging, in order to enforce a publication workflow where production is fully static (SSG) but staging is fully dynamic (SSG with preview mode always on).

It feels like this would be possible with the current proposal. Is there any ETA?

My only workaround for now is to perform this from the client side, which isn't optimal UX-wise.

I had opened a question about that but didn't get much feedback so far. But after reading this RFC and #11346 I came to the conclusion it can only be done from the browser, until proper redirects can be done from getStaticProps. Is that correct?

[revolunet]

Hi, i think these bugs may be related too; these happens on Edge and Safari and when you try route to a new url that return a 30X from getServerSideProps. Either with <Link/> or Router.push.

• fetchNextData error handling fails with TypeError: Attempted to assign to readonly property. #11608
• Using writeHead to redirect in getServerSideProps fails on Safari #12409

[kylemcd]

Is there any movement on this outside of this discussion? Been running into some breaking issues surrounding this in Safari. Happy to jump in and help if there's already a branch started somewhere!

[timneutkens]

Not yet, we focused on shipping Next.js 9.5 first and are solving some issues related to it currently, we'll focus on it after that.

[FarazPatankar]

Is there a suggested solution for this in the meantime? Something that isn't super hacky, doesn't involve creating a custom server and works on both the client and the server?

Another question I had was, if I add getServerSideProps to a page I want to achieve the redirection on, and then handle my redirection within my getServerSideProps method, can I be sure that that piece of code will always run? Even if the user navigates to it from a client-side Link tag or a Router.push() call?

[NateRadebaugh]

There is also a res.redirect method in Next.js 9.4.5+:

// Only for Next.js 9.4.5+
export async function getServerSideProps(context) {
  context.res.redirect('/login');
}

[simonuvarov]

I was told that it works only for API routes for now

[NateRadebaugh]

Ah OK. I'm using something like this in my own project at the moment:

import Router from "next/router";

export default function redirectTo(
  destination,
  { res, asPath } = {}
) {
  if (destination === asPath) {
    return;
  }

  if (res) {
    res.writeHead(302, { Location: destination });
    res.end();
  } else {
    if (destination[0] === "/" && destination[1] !== "/") {
      Router.push(destination);
    } else {
      window.location = destination;
    }
  }
}

redirectTo(loginPath, ctx);

[FarazPatankar]

@timneutkens I'd really appreciate it if you could take a minute to answer my queries. I can't quite find a way that works across both the server and the client and doesn't involve the UI flickering when handled using a useEffect.

Is there a method that is recommended by the Next team that we could use until this RFC is implemented?

[jnv]

I wonder, would that somehow allow us to return 404 status code from getStaticProps (with fallback: 'blocking') or is that for another RFC?

[jstcki]

I also wonder if this RFC would cover triggering a render of the static prebuilt pages/404.js (e.g. by returning statusCode: 404 from gSSP) without having to implement error page rendering on each page or redirecting to a 404 page?

[timneutkens]

I also wonder if this RFC would cover triggering a render of the static prebuilt pages/404.js (e.g. by returning statusCode: 404 from gSSP) without having to implement error page rendering on each page or redirecting to a 404 page?

Not this RFC, but that's the follow-up to this work indeed.

[AlexZeDim]

@timneutkens it's just RFC, right? Will Next.js provide an announcement when this feature becomes available live and what about docs? Do you have any plans to cover with it examples?

[Danetag]

Any update on the 404 status for pages generated using fallback: unstable_blocking|true ? Thanks!

[LotharVM]

@timneutkens, as you mentioned returning a 404 is part of the follow-up to this RFC, do you have any update about it? Feels like it's the last missing piece of SSG 🙏

[bartlangelaan]

How about throwing errors instead of returning objects?

For example:

import { RedirectResponse, ErrorResponse, NotFoundResponse } from 'next';

export default function HomePage() {
  return <>Hello World</>
}

export async function getServerSideProps({params}) {
  const item = await getData(params.id)

  if(!item) {
    throw new NotFoundResponse();
  }
  
  if(item.slug) {
    throw new RedirectResponse('/somewhere-else', { permanent: false });
  }

  if(item.published === false) {
    throw new ErrorResponse(403);
  }
  
  return {
    props: {
      item
    }
  }
}

This makes it also possible to throw these errors in nested functions, like in the 'getData' function for example.

Furthermore, TypeScript can probably autocomplete a lot more using these kind of classes.

[timneutkens]

It's not an error so throwing wouldn't make sense.

[warent]

Agree. A redirect and an error are two different things.

[mjr]

What do you think of Next provide an shortcut function just to make the code cleaner?

function redirect(to, permanent = false) {
  return {
    redirect: {
      permanent,
      destination: to,
    },
  }
}

or

function redirect(to, options = { permanent: false }) {
  const { permanent } = options
  return {
    redirect: {
      permanent,
      destination: to,
    },
  }
}

export async function getServerSideProps({ params }) {
  const item = await getData(params.id)
  if (!item) {
    return redirect("/somewhere-else", true)
  }

  return {
    props: {
      item,
    },
  }
}

or

export async function getServerSideProps({ params }) {
  const item = await getData(params.id)
  if (!item) {
    return redirect("/somewhere-else", { permanent: true })
  }

  return {
    props: {
      item,
    },
  }
}

export async function getStaticProps({ params }) {
  const item = await getData(params.id)
  if (!item) {
    return redirect("/somewhere-else")
  }

  return {
    props: {
      item,
    },
  }
}

[timneutkens]

What would be the benefit over returning the exact same in the object, it doesn't save characters / doesn't make it immediately clear if it's a temporary/permanent redirect.

[blujedis]

@timneutkens I know this has been asked a lot here's how I'm handling the redirect issues. Disclosure I've not sorted out all the ramifications just yet but this seems to work for now. There are three components. A base wrapper component, a wrapper component that is the Guard, what protects the view and finally a simple Redirect component.

Essentially you pass in a function that is called in getServerSideProps it should return a statusCode like say 401 or an object containing the statusCode. The object if it contains additional data gets passed to props.

(FYI) posting links instead of source as it's verbose for all three

Here's the guard.

https://github.com/blujedis/nextjs-typescript/blob/main/src/components/with/withGuard.tsx

Here's an example Implementation which is commented fairly well.

https://github.com/blujedis/nextjs-typescript/blob/main/src/pages/examples/secured.tsx

Hope it saves someone some time :)

[timneutkens]

Main downside with that approach is that it can't be tree-shaken, you'd probably want to expose separate exports

[blujedis]

Yeah that's true, prolly better to just use static implementations for the specific use case, good point! Other than that that was the best I could come up with for now. Seems to work just fine, thought I'd share that as it's the complete picture or whatever, thx Tim 👍

[dolie]

It seems difficult to implement it when API calls are chained...
Check the return on every line is really redundant. And surround everything with a try catch do not seems to be granular enough.

export async function getServerSideProps({query}){

  const documents = await getDocuments(query.id)
  const users = await getUsers(documents)
  const kittens = await getKittens(users)

  return ({
    props : {
      documents,
      users,
      kittens
    }
  })

A method to implement server side (e.g. Axios interceptors) would be more convenient !

import {Redirect} from 'next/server-side'
// maybe : {Router} from 'next/server-side' 
import {LOGIN} from '@constants/routes'

// [...]

// Axios interceptor
static responseError(error) {

    if (error?.response?.status === 401){
      Redirect(LOGIN)
    }
}

[SylvainGarrigues]

This has been implemented right?
bc80fb4

Which version of next.js does this ship into?

Also, in the initial proposal in this discussion, what did you mean by:
"A major downfall with this approach [using res.setHeader('Location', '/somewhere-else')] is that data can not be prefetched, as it was not a pure function and could trigger a navigation simply by scrolling or hovering."

[karlhorky]

Next.js 9.5.4 has unstable support for it: https://github.com/vercel/next.js/releases/tag/v9.5.4

See how to use it now: https://github.com/vercel/next.js/pull/16642/files#diff-318f35e639c875557159a9297bd3415458e884208be91285a622f9484395aa83R28-R33

Once stable support is released, I guess it will be written about on the Next.js Blog: https://nextjs.org/blog

[gunar]

Canary has stable support now: #18282

…

On Mon, Oct 26, 2020 at 9:28 PM Karl Horky ***@***.***> wrote: Next.js 9.5.4 has *unstable* support for it: https://github.com/vercel/next.js/releases/tag/v9.5.4 See how to use it now: https://github.com/vercel/next.js/pull/16642/files#diff-318f35e639c875557159a9297bd3415458e884208be91285a622f9484395aa83R28-R33 Once stable support is released, I guess it will be written about on the Next.js Blog: https://nextjs.org/blog — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14890 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2UDXSJQASJTBZ62WTJF7LSMXSW3ANCNFSM4ORVK2AQ> .

[dolie]

Ok, so I opened up an Issue.

[PolMrt]

Open PR to add this to documentation #18626

[gamegee]

With next.js v10 it is now possible to use redirect with getServerSideProps. 🔥

But even with this feature it seems that next.js lacks routes middlewares (or route guards) to handle authentication abstraction.

Does someone has an example of route auth in next.js, I'm new to next.js and I've seen a lot of different patterns and I can't figure out which one are good or bad.

For now the best option I found is to duplicate code in each route:

// /app/dashboard.tsx
... 
export async function getServerSideProps() {
  const isAuth = auth({ roles: ['user'] })
  if (!isAuth) {
    return {
      redirect: {
        permanent: false,
        destination: '/login',
      },
    }
  }
}

// /app/settings/user.tsx
... 
export async function getServerSideProps() {
  const isAuth = auth({ roles: ['user', 'admin'] })
  if (!isAuth) {
    return {
      redirect: {
        permanent: false,
        destination: '/login',
      },
    }
  }
}

// /app/settings/account.tsx
... 
export async function getServerSideProps() {
  const isAuth = auth({ roles: ['admin'] })
  if (!isAuth) {
    return {
      redirect: {
        permanent: false,
        destination: '/login',
      },
    }
  }
}

Would be nice to have middleware system so I could just compose middleware based on route paths, (as @StarpTech said in #11822)

E.g.:

Router.guards.add('/app/*, [authMiddleware({ roles: ['user']) }]);
Router.guards.add('/app/settings/*, [authMiddleware({ roles: ['admin']) }]);

[ljosberinn]

how is it duplication if the code is defined only once? 🤔

[gamegee]

@ljosberinn I was answering to @mohux 😬
Thx for your answer, but still with your function withServerSideProps you have to duplicate the call on each defined route.

More than just code duplication, having middleware composition scales better.

Here is a more advanced example:

/**
 * To access "/app/*" you need to be auth as a user
 * If auth pass, it fetch the core data needed in app (e.g. currentUser, currentAccount, ...)
 */
Router.guards.add('/app/*', [authMiddleware({ roles: ['user']) }, fetchCoreDataMiddleware]);

/**
 * To access "/app/settings/*" you need to be auth as an admin
 * It will fetch the core data needed in all admin pages
 */
Router.guards.add('/app/settings/*', [authMiddleware({ roles: ['admin']) }, fetchAdminDataMiddleware]);

/**
 * The "/app/settings/*/integrations/*" routes access are already check in other route guard
 * So here you only need to fetch integration datas
 */
Router.guards.add('/app/settings/*/integrations/*', [fetchIntegrationsDataMiddleware]);

Given that example the routes:

• /app/hello
  • require auth user
  • fetch core data

---

• /app/settings/123
  • require auth user
  • require auth admin
  • fetch core data
  • fetch admin data

---

• /app/settings/123/integration
  • require auth user
  • require auth admin
  • fetch core data
  • fetch admin data
  • fetch integration data

Doing that without routes guards and for hundreds of routes is way harder to maintain.
But since it's not supported yet I am going to use withServerSideProps on each route anyway.

[numToStr]

+1 for route gaurds w/ wildcard path matching

[kachkaev]

Guards are a yet another abstraction, which can complicate things and lead to bugs. Imagine you have a super secret page and decide you change its route, but forget about the guard that is declared elsewhere 💣💥

Function composition is a safer way here.

[ghost]

I didnt know you could do a redirect in getServerSideProps() until reading this. This helped me alot. Thanks!!

[Meemaw]

Trying to migrate to SSR redirects we're facing some issues. We have a "auth" middleware that will redirect users to /login like this:

context.res.writeHead(302, { Location: '/login', 'set-cookie': 'some-value-that-clears-session' });
context.res.end();

With this, we are also clearing user's session cookie by adding the set-cookie header. Is there any plan to support this in SSR redirects?

[timneutkens]

You can already set headers on res using https://nodejs.org/api/http.html#http_response_setheader_name_value, no need to res.writeHead in that way.

[Meemaw]

So the following should work with getServerSideProps @timneutkens ?

context.res.setHeader('set-cookie', 'value');
return {
  redirect: {
    destination: '/login',
    statusCode: 302,
  },
};

[warent]

For anyone interested in consistent authentication "middleware" using the new redirect, here's a pattern that I've adopted. Not entirely sure how I feel about this abstraction for the long term but it works okay for what I need at the moment.

utils.ts

export const withAuthentication = (getServerSidePropsFn: GetServerSidePropsFn) => ctx => {
  const token = cookies(ctx)?.token;
  if (!token) {
    return {
      redirect: {
        permanent: false,
        destination: "/log-in"
      }
    }
  }

  return getServerSidePropsFn({ token });
}

my-page.ts

export const getServerSideProps = withAuthentication(async ({ token }) => {
    return {
      props: {
          // ...
      }
    }
})

If you want, you could get fancy and create a function to chain these together to be more like true middleware. e.g. (untested code, just a general idea that comes to mind)

const middleware = chain => ctx => {
  chain[0](ctx, () => {
    if (chain.length > 1) {
      middleware(chain.slice(1))(ctx);
    }
  })
}

const withAuthentication = (ctx, next) => {
  // do something with context
  next();
};

export const getServerSideProps = middleware([withAuthentication, withSomethingElse, finalGetServerSideProps]);

In any case, in my opinion this is just a utility that Next.js is not responsible for supporting and does not belong in the Next.js library.

(edited for clarity)

[karlhorky]

Looks like const token = cookies(ctx)?.token; can also be simplified to just const token = ctx.req.cookies?.token; now with Next.js 10.0.4. No more cookie function 🎉

More details in the PR: #19724

[cristianrodri]

I added types and generics in withAuthentication

export const withAuthentication =
  <P, Q extends ParsedUrlQuery = ParsedUrlQuery>(
    getServerSidePropsFn: GetServerSideProps<P, Q>
  ): GetServerSideProps<P, Q> =>
  async ctx => {
    const token = ctx.req.cookies?.token

    if (!token) {
      return {
        redirect: {
          permanent: false,
          destination: '/login'
        }
      }
    }

    return getServerSidePropsFn(ctx)
  }

export const getServerSideProps = withAuthentication<Props>(async ({ req }) => {
  const { token } = req.cookies

  return {
    props: {
      ...
    }
  }
})

[karlhorky]

@cristianrodri nice! Maybe would also be cool to have a returnTo query parameter, for returning to the location that the user was trying to access upon successful login

return {
  redirect: {
    permanent: false,
    destination: `/login?returnTo=${path}`
  }
}

[slevy85]

What about rewrites ?
Would it be possible to return { rewrite : { destination: '/other/page' } } from getServerSideProps ?

My use case is with slugs :

• My canonical pages are statically generated without slugs : /posts/1, /posts/2
• I would like to let the user go to /posts/1/slug1 and still get the content of /posts/1
• I would like the user to be redirected to the correct slug if the slug is not correct: /posts/1/wrong-slug -> /posts/1/slug1

I wish I could do it like this :

// In /posts/[reference]/[slug].js
export const getServerSideProps = async (context) => {
  const { params } = context;
  const { reference, slug } = params;

  const post = await fetchPost({ reference });

  if(post.slug === slug) {
      return {rewrite: {destination : '/posts/1'}}
  }
  return {redirect:{destination: `/posts/1/${post.slug}`}}
}

[marklindsay24]

I'm currently using next v10.0.4 and trying the new getServerSideProps with returning a redirect as shown below. It was my understanding that this would automatically do a redirect to a route in my app called /somewhere-else. But instead, this is calling my custom 404 page. Did I miss something? Do I need to handle inside my 404 page? If so, what do I use to know what caused 404?

return {
   redirect: {
       permanent: false,
       destination: '/somewhere-else'
  }
}

[karlhorky]

Do you have the file /pages/somewhere-else.js? That's where the redirect will send users.

[marklindsay24]

yes, such route/file exists in my app.

[marklindsay24]

I determined this works in a single next without zones. But i was using a monorepo with multiple zones and micro-proxy. Maybe micro-proxy is messing this up. Any good boilerplates for zones and micro-proxy. Is that outdates now? if so, what can I use? I tried rewrites.

[panoslympe]

I don't know in what version Vercel added this...but..

if all you want is to redirect to a 404 page....you can simply do this..

export async function getServerSideProps() {
if (!data) {
return { notFound: true }
}
}

it doesn't redirect... you don't get a 302 (redirect status)...you just render 404 page, with original url and all! 🎉🥳

[pedroramon]

It would be nice if this redirect was also verified in '_app.js' getInitialProps. Some global redirects (like authorization) can enjoy this!

[bsmith-self]

Hard to tell from the discussion; what's the current status of this feature?

My usecase is that I've got a blog:

/blog
/blog/[post-name]

I'm statically-rendering these posts with getStaticPaths. This works, and 404's when the user visits a post that doesn't exist (/blog/fakepost), but what I'd like to do is redirect to /blog when they visit a post that doesn't exist. I'm on Next 10.2.3, and this doesn't seem to work:

  // return { notFound: true }  old way; this works but 404's
  return { redirect: { destination: '/blog', permanent: false } }

I've tried with both fallback: false and fallback: true

[Vadorequest]

@bsmith-self You can do that from _app.

getStaticProps is only executed at build time, so it won't help you achieving this. But _app is gonna be executed at runtime on the browser, it can detect the 404 too, and you can simply use a browser redirect.

[leerob]

This has been released, sorry! I forgot to post back and close this discussion 👍

https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation
https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering