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

Using xfwd option with http-proxy doesn't remove x-forwarded-* headers #1628

Open
joeymalvinni opened this issue Feb 24, 2023 · 2 comments
Open

Comments

@joeymalvinni
Copy link

joeymalvinni commented Feb 24, 2023

I am making a reverse proxy with node-http-proxy. I have set the xfwd option in the options of createProxyServer, but it doesn't seem to affect the headers.

Here is a snippet of my code:

const proxy = httpProxy.createProxyServer({ 
    agent: httpsAgent,
    secure: true,
    ssl: options,          
    changeOrigin: true,
    xfwd: false // <--- doesnt delete X-Forwarded* headers
});

Can anyone reproduce this? Thanks.

@gergomiklos
Copy link

gergomiklos commented Dec 1, 2023

Same here, with xfwd: false I get this error on production Next.js where req.headers.port is undefined by default:

TypeError [ERR_HTTP_INVALID_HEADER_VALUE]: Invalid value "undefined" for header "x-forwarded-port"
    at ClientRequest.setHeader (node:_http_outgoing:651:3)
    at new ClientRequest (node:_http_client:291:14)
    at request (node:https:358:10)
    at Y.e.request (/var/task/___vc/__launcher/__launcher.js:14:4955)
    at Array.stream (/var/task/node_modules/http-proxy/lib/http-proxy/passes/web-incoming.js:126:74)
    at ProxyServer.<anonymous> (/var/task/node_modules/http-proxy/lib/http-proxy/index.js:81:21)
    at /var/task/node_modules/next-http-proxy-middleware/build/index.js:1:3305
    at new Promise (<anonymous>)
    at /var/task/node_modules/next-http-proxy-middleware/build/index.js:1:2834
    at /var/task/node_modules/next-http-proxy-middleware/build/index.js:1:2052 {
  code: 'ERR_HTTP_INVALID_HEADER_VALUE'
}

So I have to set the header manually before proxying the request:
req.headers['x-forwarded-port'] = req.headers?.['x-forwarded-port'] ?? req.headers?.port ?? req.headers?.proto == 'http' ? 80 : 443

@intellix
Copy link

intellix commented Mar 8, 2024

yep, seeing the same behaviour when trying to create a proxy using vite:

proxy: {
  '/auth': {
    target: 'https://mysite.com',
    changeOrigin: true,
    headers: {
      'x-forwarded-origin-host': 'localhost:4200',
      'x-forwarded-proto': 'http',
    },
  }
}

I'm running locally, so wanted to tell my Staging API Server that we're actually coming from HTTP. It's basically impossible to provide your own x-forwarded-proto. I can disable it and whatever I do, it always sends "https" after my own custom header.

I believe it's because I'm using changeOrigin: true? I don't even understand what's the point of setting x-forwarded automatically to the origin server itself? The whole point of it, is to allow me to tell my origin server where it's actually coming from.

I can't even find a single workaround/hack for it, apart from using patch-package to delete that functionality

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

3 participants