Using xfwd option with http-proxy doesn't remove x-forwarded-* headers
joeymalvinni opened this issue · 2 comments
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.
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
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