Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Next.js App Router can't handle proxied requests #932

Open
2 tasks done
Smolya opened this issue Sep 2, 2023 · 21 comments
Open
2 tasks done

Next.js App Router can't handle proxied requests #932

Smolya opened this issue Sep 2, 2023 · 21 comments

Comments

@Smolya
Copy link

Smolya commented Sep 2, 2023

Checks

Describe the bug (be clear and concise)

I'm using App Router (next 13) and trying to proxy requests on another server via createProxyMiddleware. But I've got an error by doing this. I use example from https://github.com/chimurai/http-proxy-middleware/blob/master/recipes/servers.md#nextjs, but fitted to a new App Routes with GET and POST handlers
Error:

TypeError: Cannot set property url of #<NextRequest> which has only a getter
    at Object.set (webpack-internal:///(sc_server)/./node_modules/next/dist/server/future/route-modules/app-route/helpers/proxy-request.js:117:26)
    at HttpProxyMiddleware.applyPathRewrite (webpack-internal:///(sc_server)/./node_modules/http-proxy-middleware/dist/http-proxy-middleware.js:113:29)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async HttpProxyMiddleware.prepareProxyRequest (webpack-internal:///(sc_server)/./node_modules/http-proxy-middleware/dist/http-proxy-middleware.js:93:13)
    at async HttpProxyMiddleware.middleware (webpack-internal:///(sc_server)/./node_modules/http-proxy-middleware/dist/http-proxy-middleware.js:23:48)
    at async eval (webpack-internal:///(sc_server)/./node_modules/next/dist/server/future/route-modules/app-route/module.js:265:37)

Step-by-step reproduction instructions

- api/internal/[...path]/route.ts

import type { NextApiRequest, NextApiResponse } from 'next';
import {
    createProxyMiddleware,
} from 'http-proxy-middleware';

const proxy = createProxyMiddleware<NextApiRequest, NextApiResponse>({
    target: process.env.BACKEND_URL,
    pathRewrite: {
        '^/api/internal': '',
    },
}) as any;

function handler(req: NextApiRequest, res: NextApiResponse) {
    return proxy(req, res, (err) => {
        if (err) {
            console.log(err);
        }

        return res;
    });
}

export {
    handler as GET,
    handler as POST,
};

Client call:

const users = await fetch('/api/internal/users');

Expected behavior (be clear and concise)

Handle proxied requests via Next 13 (App Router)

How is http-proxy-middleware used in your project?

@demo/[email protected] /Users/sergey.samoylov/WebstormProjects/demo/web
└── [email protected]

What http-proxy-middleware configuration are you using?

const proxy = createProxyMiddleware<NextApiRequest, NextApiResponse>({
    target: process.env.BACKEND_URL,
    pathRewrite: {
        '^/api/internal': '',
    },
})

What OS/version and node/version are you seeing the problem?

System:
    OS: macOS 13.3
    CPU: (10) arm64 Apple M1 Pro
    Memory: 130.45 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 16.10.0 - ~/.nvm/versions/node/v16.10.0/bin/node
    Yarn: 1.22.17 - ~/.nvm/versions/node/v16.10.0/bin/yarn
    npm: 7.24.0 - ~/.nvm/versions/node/v16.10.0/bin/npm
    pnpm: 6.35.1 - ~/.nvm/versions/node/v16.10.0/bin/pnpm
  Managers:
    Homebrew: 4.1.4 - /opt/homebrew/bin/brew
    pip3: 23.1 - /Library/Frameworks/Python.framework/Versions/3.10/bin/pip3
    RubyGems: 3.0.3.1 - /usr/bin/gem
  Utilities:
    Make: 3.81 - /usr/bin/make
    GCC: 14.0.3 - /usr/bin/gcc
    Git: 2.39.2 - /usr/bin/git
    Clang: 14.0.3 - /usr/bin/clang
    Curl: 7.87.0 - /usr/bin/curl
  Servers:
    Apache: 2.4.54 - /usr/sbin/apachectl
  Virtualization:
    Docker: 20.10.12 - /usr/local/bin/docker
  IDEs:
    Vim: 9.0 - /usr/bin/vim
    WebStorm: 2021.3.3
    Xcode: /undefined - /usr/bin/xcodebuild
  Languages:
    Bash: 3.2.57 - /bin/bash
    Go: 1.20.3 - /usr/local/go/bin/go
    Perl: 5.30.3 - /usr/bin/perl
    Protoc: 3.21.12 - /opt/homebrew/bin/protoc
    Python3: 3.10.11 - /Library/Frameworks/Python.framework/Versions/3.10/bin/python3
    Ruby: 2.6.10 - /usr/bin/ruby
  Databases:
    MongoDB: 5.0.6 - /opt/homebrew/bin/mongo
    PostgreSQL: 14.9 - /opt/homebrew/bin/postgres
    SQLite: 3.41.2 - /opt/local/bin/sqlite3
  Browsers:
    Chrome: 116.0.5845.140
    Safari: 16.4
@gciluffo
Copy link

Same issue here. Had to work around by creating a /pages/api directory adjacent to my app directory in order to get api proxies working.

@jtomaszewski
Copy link

I've tried handcrafting it but also failed.

I created app/[...all]/router.ts file with following contents:

import httpProxy from "http-proxy";

export async function GET(request: Request) {
  const proxy: httpProxy = httpProxy.createProxy();
  const response = new Response();

  return new Promise((resolve, reject) => {
    proxy
      .once("proxyRes", resolve)
      .once("error", reject)
      .web(request, response, {
        target: "https://napiachu.pl",
        secure: false,
        changeOrigin: true,
        autoRewrite: true,
        cookieDomainRewrite: "",
      });
  });
}

But it just doesn't work, it raises TypeError: req.on is not a function error.

That's probably because the interface of request & response object is now completely different in app router (request is a node fetch "request" object, not a IncomingMessage class object coming from node http library; and response is simply not existing).

So http-proxy nor http-proxy-middleware can't be used "as is", unless we find some way how we can make it work on top of the new request & response interfaces.

@newbeea

This comment was marked as spam.

@timmyg

This comment was marked as spam.

@BhaskaranR

This comment was marked as spam.

8 similar comments
@stoompa

This comment was marked as spam.

@tsunamiShi

This comment was marked as spam.

@aaman123

This comment was marked as spam.

@tomasguerreiro

This comment was marked as spam.

@childbamboo

This comment was marked as spam.

@hmvmpire

This comment was marked as spam.

@dannydeut

This comment was marked as spam.

@villqrd

This comment was marked as spam.

@liambowers
Copy link

If you're about to add a 'I have this issue too, +1' kind of comment, I'd suggest giving the first post a thumbs-up which communicates the same and doesn't spam subscribed users unnecessarily.

@karbica
Copy link

karbica commented Feb 15, 2024

Same. I wish the route segment config, e.g. const runtime = 'nodejs'; (the default btw), would actually pass the supported request and response interfaces. Instead we get the interfaces that would run on the edge and inside the browser which are incompatible with other third-party proxy implementations.

@KakkoiDev
Copy link

KakkoiDev commented Apr 18, 2024

I've tried handcrafting it but also failed.

I created app/[...all]/router.ts file with following contents:

import httpProxy from "http-proxy";

export async function GET(request: Request) {
  const proxy: httpProxy = httpProxy.createProxy();
  const response = new Response();

  return new Promise((resolve, reject) => {
    proxy
      .once("proxyRes", resolve)
      .once("error", reject)
      .web(request, response, {
        target: "https://napiachu.pl",
        secure: false,
        changeOrigin: true,
        autoRewrite: true,
        cookieDomainRewrite: "",
      });
  });
}

But it just doesn't work, it raises TypeError: req.on is not a function error.

That's probably because the interface of request & response object is now completely different in app router (request is a node fetch "request" object, not a IncomingMessage class object coming from node http library; and response is simply not existing).

So http-proxy nor http-proxy-middleware can't be used "as is", unless we find some way how we can make it work on top of the new request & response interfaces.

After trying for a while I was still getting the TypeError: req.on is not a function error. So I finally dropped http-proxy-middleware in favor of a more "native" NextJS solution: with a middleware and rewrites.

The logic is as follow: Every time a request starting with /api is made, the middleware will update it as needed and then the rewrites will proxy it to the desired destination.

middleware.ts

// imports...

export async function middleware(request: NextRequest) {
  // your other middleware actions...

  if (/^\/api/.test(path)) { // if sending a request to /api/...
    const newResponse = NextResponse.next(); // prepare a new response

    // modify your response if needed
    const bearerToken = await getBearerToken();
    newResponse.headers.set("Authorization", "Bearer " + bearerToken);
    // ...

    return newResponse; // return the modified response
  }
}

next.config.js

module.exports = {
  // your other config...
  async rewrites() {
    return [
      {
        source: "/api/:path*", // get everything after /api/
        destination: `${process.env.NEXT_PUBLIC_API_URL}/:path*`, // send it to your API
      },
    ];
  },
}

For more information:

@asadkhalid305
Copy link

asadkhalid305 commented Jun 2, 2024

I've tried handcrafting it but also failed.
I created app/[...all]/router.ts file with following contents:

import httpProxy from "http-proxy";

export async function GET(request: Request) {
  const proxy: httpProxy = httpProxy.createProxy();
  const response = new Response();

  return new Promise((resolve, reject) => {
    proxy
      .once("proxyRes", resolve)
      .once("error", reject)
      .web(request, response, {
        target: "https://napiachu.pl",
        secure: false,
        changeOrigin: true,
        autoRewrite: true,
        cookieDomainRewrite: "",
      });
  });
}

But it just doesn't work, it raises TypeError: req.on is not a function error.
That's probably because the interface of request & response object is now completely different in app router (request is a node fetch "request" object, not a IncomingMessage class object coming from node http library; and response is simply not existing).
So http-proxy nor http-proxy-middleware can't be used "as is", unless we find some way how we can make it work on top of the new request & response interfaces.

After trying for a while I was still getting the TypeError: req.on is not a function error. So I finally dropped http-proxy-middleware in favor of a more "native" NextJS solution: with a middleware and rewrites.

The logic is as follow: Every time a request starting with /api is made, the middleware will update it as needed and then the rewrites will proxy it to the desired destination.

middleware.ts

// imports...

export async function middleware(request: NextRequest) {
  // your other middleware actions...

  if (/^\/api/.test(path)) { // if sending a request to /api/...
    const newResponse = NextResponse.next(); // prepare a new response

    // modify your response if needed
    const bearerToken = await getBearerToken();
    newResponse.headers.set("Authorization", "Bearer " + bearerToken);
    // ...

    return newResponse; // return the modified response
  }
}

next.config.js

module.exports = {
  // your other config...
  async rewrites() {
    return [
      {
        source: "/api/:path*", // get everything after /api/
        destination: `${process.env.NEXT_PUBLIC_API_URL}/:path*`, // send it to your API
      },
    ];
  },
}

For more information:

I am also getting the same error.

If we do this then source: "/api/:path*", will replace every route. What if I want it to behave exactly like a catch-all route e.g. if some x path does not match then rewrites happen? Would appreciate your response.

@polesapart
Copy link

I am also getting the same error.

If we do this then source: "/api/:path*", will replace every route. What if I want it to behave exactly like a catch-all route e.g. if some x path does not match then rewrites happen? Would appreciate your response.

Check the link above (nextjs rewrites) for the fallback option

@rayrapetyan
Copy link

rewrites doesn't work for everything (e.g. websockets).

@dbjpanda
Copy link

Any update on this issue?

@mdylan2
Copy link

mdylan2 commented Nov 19, 2024

Bump

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests