Replies: 4 comments
-
Hi @glenjamin . Glad you're pointing this out. Some use cases: app.use("/api", proxy({target:'http://www.example.org'}));
// https://localhost:3000/api/foo/bar -> // http://www.example.org/foo/bar
app.use("/api", proxy({target:'http://www.example.org/api'}));
// https://localhost:3000/api/foo/bar -> // http://www.example.org/api/foo/bar
app.use(proxy({target:'http://www.example.org'}));
// https://localhost:3000/foo/bar -> // http://www.example.org/foo/bar
app.use(proxy({target:'http://www.example.org/api'}));
// https://localhost:3000/foo/bar -> // http://www.example.org/api/foo/bar Unfortunately this'll introduce a breaking change. I've been thinking what the best strategy is...
or
Some investigation is needed how this might affect the Popular libs shouldn't be affected to much when they use the path-less express mounting :
Some libs can benefit from this change probably:
Please let me know what you think. |
Beta Was this translation helpful? Give feedback.
-
My initial instinct is that that's being a little bit too clever. A single new option called something like My experience with breaking changes has been that it can cause large knock on effects onto the ecosystem which are hard to predict when making them. Introducing a new off-by-default option might not be as good for discoverability, but adding a prominent example into the README may help there. |
Beta Was this translation helpful? Give feedback.
-
The examples are actually the default behavior of http-proxy. (Which I later found out) Together with these two
Thought it was a bug (#17) :) and "fixed" it with this line of code: http-proxy-middleware/lib/index.js Line 96 in 73e0e0a Like you said; Probably bit too clever. Or maybe insufficiently documented. The original behavior is actually in line with nginx's proxy_pass behavior: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass Seen quite some issues when devs configure it the same way like in nginx... With the current implementation, it will be proxied like: Will have to think how this can be implemented smoothly... |
Beta Was this translation helpful? Give feedback.
-
I'm having an similar problem import express, { Router } from 'express'
import proxyMiddleware from 'http-proxy-middleware'
import httpProxy from 'http-proxy' // used in solution B)
//Create proxy instance for solution B)
const proxy = httpProxy.createProxyServer({ secure: false })
// The Express APP
const app = express()
// An express router
const apiRouter = Router()
// my custom proxy middleware
function myProxyMiddleware(url){
const proxyRouter= Router()
// A)Not working solution
router.use('/',proxyMiddleware({ target: url, changeOrigin: true }))
// B)Working as expected solution
router.all('*', (req, res) => {
return proxy.web(req, res, { target: url, changeOrigin: true)
})
return router
}
// api router using middleware
api.use('/endpoint', myProxyMiddleware('http://example.org/api'))
// app using api router
app.use('/myapi/v1', api)
app.server.listen(8080); Where i'm trying to apply the solution A, for better integration
The middleware is using an solution that seems to work is router.use('/',(req, res, next) => {
req.originalUrl = req.path
next()
},proxyMiddleware({ target: url, changeOrigin: true })) |
Beta Was this translation helpful? Give feedback.
-
Setup
proxy middleware configuration
server mounting
Suggested behavior
Whenever I use this module, I tend to end up with the config roughly like the above. The webserver is proxying API requests back to some other origin, normally adding some authentication headers on the way past.
In this setup, I generally want the express mountpoint to be stripped away, which can be done via
pathRewrite
, but only by giving the middleware knowledge of where it is mounted.Ideally I want the proxy to not need to know where it is mounted, and just strip the mountpoint away. I have found a way to do this inside onProxyReq:
Would you be open to making this a built-in option?
Beta Was this translation helpful? Give feedback.
All reactions