Rewrites redirect instead of rewriting

[JohnAllen]

Maybe I misunderstand how redirects are supposed to work (not middleware ones, next.config.js ones).

I'm trying to host a blog on WP and have an app run on Vercel. So in my next config I am rewriting any requests to /blog to my actual hosted blog url.

(my primary URL let's just call it myapp.com

My config is like this:

async rewrites() {
    return {
      beforeFiles: [
        {
          source: '/blog/:slug',
          destination: 'https://blog.url.com/blog/:slug',
        },
      ],
    };
  },

But when I do this, the final URL is just https://blog.url.com/blog/somepost and not myapp.com/blog/somepost.

Does this make sense?

I would appreciate any help understanding how rewrites are supposed to work.

[icyJoseph]

I am a bit confused here:

• Vercel app lives at A.com
• WP blog lives at B.com

async rewrites() {
    return {
      beforeFiles: [
        {
          source: '/blog/:slug',
          destination: 'https://B.com/blog/:slug',
        },
      ],
    };
  },

I notice that the docs, do not use beforeFiles for external rewrites, could you try with that?

However, I don't follow what's the issue you are seeing, is the not browser showing A.com/blug/:slug with the contents of B.com/blug/:slug?

[icyJoseph]

It looks like things are setup fine.

However, there's a quite a bit going on, with all of the config plugins.

I'd just try out to move the config like this:

[withExpo, {
    projectRoot: __dirname + '/../..',
    async rewrites() {
    return [
      {
        source: '/blog/:slug',
        destination: 'https://lingospring.dreamhosters.com/blog/:slug',
      },
    ];
  }
}]], {
/*  rest of config */  
}

Plugin composition must be the issue, some plugins misbehave or pass the configs around in odd ways.

I don't think that the next version is an issue, though I'd recommend to upgrade.

[JohnAllen]

Thanks @icyJoseph. I will give this a try.

[JohnAllen]

I can't get it to work. Tried a bunch of different options. Was going to email you about it...

[icyJoseph]

Hi,

Yeah, I tried a few things:

• Your repo I couldn't get started so I couldn't do much more there, but I wanted to try this answer https://stackoverflow.com/questions/67570519/redirect-destination-nextjs-and-react-native-expo-web
• I followed this guide https://docs.expo.dev/guides/using-nextjs/, and there I saw that it used next 9.1.3 which didn't support redirects, or rewrites, so I upgraded to 11.1.2. However, with this projects, the rewrites don't even work at all.

I think, you can try a couple of things:

• Remove plugins, one by one, to try and see if one of them has a bug.
• Try to get the rewrites working using the https://docs.expo.dev/guides/using-nextjs/ this guide, and take your learnings to the expo app.
• Ask on the expo adapter Github page, https://github.com/expo/expo-cli/tree/main/packages/next-adapter, I have a feeling, they haven't seen this before, and it is a bit scary that the adapter is labeled as experimental.

[JohnAllen]

Thanks @icyJoseph. I will try these things. Good suggestions.

[ericvillemure]

I have the same problem here. It looks like it works when it is a simple GET query but for POST I also get 307 Temporary Redirect. I am not 100% sure but could it be because the server side fetch crashes?

This is my next.config.js

module.exports = {
    async rewrites() {
        return {
            beforeFiles: [
                {
                    source: "/api/v1/search",
                    destination: `${process.env.MLSERVICE_URL}/api/v1/search`
                },
                {
                    source: "/health",
                    destination: `${process.env.MLSERVICE_URL}/health`
                },
            ]
        };
    },
}

This is the output in Chrome for /health

This is the output for /api/v1/search

[MisterJimson]

I'm also having the same problem. Trying to use rewrites but see 301 redirect instead.

[sbennettmarqeta]

I had the same issue and I was able to resolve it. The server I was proxying to enforced a trailing slash so if /A was going to /B it would redirect to /B/

I fixed it by doing updating it from this:

{
          source: '/main/:path*',
          destination: 'https://external-service.com/main/:path*'
}

to this:

{
          source: '/main/:path*',
          destination: 'https://external-service.com/main/:path*/'
}

[arndom]

I'm having the same issue in a regular nextjs app, it redirects only in production, any insight @JohnAllen pls?

[JohnAllen]

No. Sorry

[alexmojaki]

I think I've figured this out. Like @sbennettmarqeta said, part of the problem is the backend server enforcing a trailing slash. So nextjs really was proxying rather than redirecting, but the proxied response was itself a redirect, which told the client to request directly from the backend rather than the nextjs server. @ericvillemure's example looks the same as what I was getting: 307 is probably from the backend.

In addition to that, nextjs itself will redirect requests that don't end in a trailing slash by default. That particular redirect is a 308 rather than a 307. So the client will make the request again without the trailing slash, which leads back to the first problem above. The combination makes this really confusing to debug.

The good news is that the docs actually cover all this under https://nextjs.org/docs/api-reference/next.config.js/rewrites#rewriting-to-an-external-url, it's just so far down it's hard to notice. In that example code:

module.exports = {
  trailingSlash: true,
  async rewrites() {
    return [
      {
        source: '/blog/',
        destination: 'https://example.com/blog/',
      },
      {
        source: '/blog/:path*/',
        destination: 'https://example.com/blog/:path*/',
      },
    ]
  },
}

there are two fixes:

1. trailingSlash: true prevents the second problem of 308 from nextjs.
2. The source and destination both end in /, e.g. /:path*/.

[v36u]

Thank you! I was encountering the same problem and after adding a trailing / at the end of both the source and the destination, the rewrite worked again. Indeed, this also catches the case when the source does not have a trailing slash because Next.js auto redirects (thanks to trailingSlash: true), and then the path matches.

[pencilcheck]

I noticed that if you have a backend that uses nextjs sometimes if you use middleware like clerk, they will respond with 307/308 and it will mess things up, so the best thing is to limit the paths clerk will respond with 307/308