-
Notifications
You must be signed in to change notification settings - Fork 825
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
proxy needs to be last middleware #248
Comments
Currently http-proxy-middleware/lib/index.js Line 43 in 66396d4
Can you patch it locally to call I'll have to investigate what kind of side-effects this changes might have. |
@chimurai doing so does work for me. That said, my other middlewares don't modify request headers, which I imagine is where making this change could be tricky. I absolutely understand if guaranteeing |
@chimurai do you know why |
Why not return a promise or directly next()? It would make other middleware to work abnormally. |
Middleware doesn't call |
It will call |
Just hit this also with the following use case:
But the proxy middleware doesn’t call Thoughts? |
@aral using the onProxyRes: (proxyRes, req, res) => {
if (proxyRes.statusCode === 200) {
// don't do anything if response successful
return;
}
if (proxyRes.path.includes('VX') {
// don't do anything if we're already returning from version fallback
return;
}
// otherwise, redirect to versioned instance
res.redirect('/VX/...');
}, ... or something like that? |
@leveneg Thanks, Grant. I did try fiddling with |
I have another case, I want to add cache layer on top of proxy. edit: |
Been a while! Any updates on this. I too was a bit surprised to see that my subsequent middleware suddenly failed. Would be nice to at least have the argument available in the case of option.selfHandleResponse. Closing by pending issue provided that there might be more progress here.. One dirty workaround that might work for some is to create a separate express instance which only handles proxying. This instance can then be called in the middleware of the outer instance. My usecase simply being response validation. |
@aral @hpl002 Hi guys, I'm pretty sure it should work: app.use((req, res, next) => {
createProxyMiddleware(path, {
selfHandleResponse: true,
onProxyRes(proxyRes, req, res) {
if (proxyRes.statusCode === 404) {
return next();
} else {
let body = new Buffer('');
proxyRes.on('data', (data) => body = Buffer.concat([body, data]));
proxyRes.on('end', () => res.end(body));
}
}
})(req, res, next);
}); What do you think about this solution? The weak point is that HPM will be created on each request. |
Riffing on @PaulMaly's solution, and through some indirection with a const app = express();
app.use(proxyWithFallthrough(address1));
app.use(proxyWithFallthrough(address2));
app.listen(PORT);
function proxyWithFallthrough(address) {
// makes it possible to call the `next()` function from `onProxyRes()`
const reqNextMap = new WeakMap();
const proxyHandle = createProxyMiddleware({
target: address,
selfHandleResponse: true,
onProxyRes(proxyRes, req, res) {
if (proxyRes.statusCode === 404) {
const next = reqNextMap.get(req);
return next();
} else {
proxyRes.pipe(res);
}
},
});
return function handle(req, res, next) {
reqNextMap.set(req, next);
return proxyHandle(req, res, next);
};
} |
Perhaps I'm using the library incorrectly, or unaware of its limitations- but I recently found that I've had to put http-proxy-middleware as the last middleware in my express config.
Expected behavior
If possible, http-proxy-middleware should call the
next()
middleware. If not, the behavior should be documented.Actual behavior
middlewares that follow http-proxy-middleware are not executed
Setup
proxy middleware configuration
server mounting
The text was updated successfully, but these errors were encountered: