Add support for query param forwarding in getStaticProps redirect

[benkingcode]

Describe the feature you'd like to request

In our app, we have pages that use getStaticProps, ISR and fallback: blocking. The route param accepts a slug in the format of [id]-[friendlyName].

If the user visits a URL with a correct id, but an incorrect friendlyName, we want to redirect them to the canonical URL. For example, a request comes in to /event/123-my-first-event. We find the event with ID 123, but notice that the friendlyName in the database is actually my-second-event. Therefore the canonical URL is /event/123-my-second-event. In getStaticProps we perform a permanent redirect.

However, during these redirect all query parameters are lost. This is critical as analytics tracking params are frequently appended, and if the user gets redirected we lose all the tracking.

We would like the ability to optionally opt-in to forward the original request's query parameters onto the supplied destination.

Describe the solution you'd like

A new option in redirect to be added, for example;

return {
  redirect: {
    destination: '/event/123-my-second-event',
    permanent: true,
    forwardQueryParams: true
  }
}

When this is supplied, the Next router takes the destination and appends the query parameters from the original request. For example, a request to /event/123-my-first-event?foo=bar becomes /event/123-my-second-event?foo=bar

An implementation of this has been developed in a fork and is ready to be submitted as a PR if this idea is approved.

Describe alternatives you've considered

The only possible alternatives currently would be either;

1. Use getServerSideProps, but we lose the caching benefits of getStaticProps
2. Create a middleware in front of the page to check for the canonical URL in advance, however this would run on every request and essentially negate the caching benefits

[benkingcode]

Who is available to look into this? We have a PR that is ready to go. It's a critical blocker for us.

[icyJoseph]

I most definitely don't have any power deciding which features come through or not, but have you considered using an api/route as bouncing-off platform?

// api/redirect.ts

import type { NextApiRequest, NextApiResponse } from "next";

async function redirectHandler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method !== "GET")
    return res.status(404).json({ message: "Not Found" });
  try {
    const referer = req.headers["referer"];

    if (!referer) return res.status(404).json({ message: "Not Found" });

    const url = new URL(referer);

    const query = url.searchParams.toString();

    return res.redirect(303, `https://somewhere-else?${query}`);
  } catch (e) {
    return res.status(500).json({ message: "Internal Server Error" });
  }
}

export default redirectHandler;

It does depend on the referer header, but it does allow you to do the same. From getStaticProps you'd redirect to destination: "/api/redirect" and from there, forward to the next resource, with queries included.

I guess, for completeness, sake, this is also another way to handle this right?

[J-Gonzalez]

This is an exact usecase we're looking for. On our platform, "friendlyName" is user generated content, and the pages/content/title are able to be changed. The permanent link is based on the ID, with the friendlyName being the latest/correct version (which we redirect to).

However, any UTM params or other query params are lost on this redirect as mentioned above and we need a way to keep them. API routes or middleware essentially removes the caching feature and we might as well do getServerSideProps instead unless static + keeping params is able to work.

[J-Gonzalez]

@benkingcode - Curious to see your PR for this. It's also a critical blocker for us - with the alternative being we use getServerSideProps and forget ISR/SSR

The idea and approach seems simple enough. The getStaticProps function doesn't need to "know" and do logic on the query params (which wouldn't be possible as it's pre-generated), it just needs to append them to the redirect (which it should fully have access to the full path anyways)