Hey there,
in 1.14.1 the following rewrite function worked
proxy: {
'/api/**': {
target: 'http://localhost:9001',
rewrite: function(req) {
req.url = req.url.replace(/^\/api(.+)$/, '$1');
return req.url;
},
ignorePath: false,
changeOrigin: true,
secure: false
}
}
As of 1.15.0 The rewrite function doesn't get called anymore.
Was there a breaking change with how the rewrite function works? I understand there was a switch in how proxy works but I figured I would have to update to 2.x.x for those changes to manifest.
Thoughts?
Confirmed that this is happening. Could you try if the fix in #567 works for you? The fastest way to check is to copy/paste the contents of the PR in node_modules/webpack-dev-server/lib/Server.js.
@SpaceK33z I gave this a quick shot and it didn't seem to fix the problem.
I probably won't be able to fool around with it any further until tomorrow morning.
@SpaceK33z @jdkrebs
This line in http-proxy-middleware kind of ignores/reverts the rewritten path in your fix. (source)
// http-proxy-middleware
req.url = (req.originalUrl || req.url);
Not sure what the best approach would be to make it backwards compatible.
As alternative, you could use the .pathRewrite option offered by HPM.
The syntax is slightly different...
proxy: {
'/api/**': {
target: 'http://localhost:9001',
pathRewrite: function (path, req) {
return path.replace('/api/foo', '/api/bar');
}
}
}
For more info on pathRewrite: http-proxy-middleware/recipes/pathRewrite.md
@SpaceK33z
I noticed a sudden surge in downloads since v1.15.0 got released and with it also a number of proxy related issues. Feel free to _cc_ me if you need any assistance.
@chimurai, thanks for your help, really appreciate it!
Maybe I could override req.originalUrl with the value of req.url (very very hacky)? Or do something like req.originalUrl = null? We could only use this for 1.15.0, and make 2.0.0 use the new pathRewrite, which makes much more sense to me.
Nice, your package was introduced to us by a PR, but that PR also simply removed or broke other proxy functionality. I like the extra options though.
Think nullifying the originalUrl with req.originalUrl = null would be the best option to make it backwards compatible, without too much hacking.
A side note:
There is tiny change in pathRewrite behavior as of HPM v0.17.1:
https://github.com/chimurai/http-proxy-middleware/pull/98
Path rewrites will only be done for paths which will be proxied.
Not sure what the behavior is of rewrite in WDS... Maybe something to doublecheck / keep an eye on.
@jdkrebs, I updated PR #567, could you try if it works for you now?
@chimurai, thanks for the extra info!
@SpaceK33z The good news is with that change the rewrite function gets called again. The bad news is now the request hangs. It looks like next is never called in the conditional that calls the rewrite function. would just calling next() after calling the rewrite fix the issue?
UPDATE: I tried just throwing in the next() call but that then doesn't proxy the rewritten url to the correct host. I'll maybe dig a little deeper here.
After looking at the code, I also tried adding
return proxyMiddleware(req, res, next); which seems to not proxy the request either.
@jdkrebs, updated PR, can you try again? Made a small mistake.
@SpaceK33z I gave it a shot and I got the same result from my above comment. Essentially the request ultimately ends up getting handled by express rather than proxying (Cannot GET /someurl)
So although the rewrite works and the request doesn't hang, the request ultimately doesn't get proxied.
@jdkrebs, hmm, is the pathRewrite method also good enough for you (see @chimurai's example above)?
I'll update the wiki that pathRewrite is the way to go then.
@SpaceK33z Yeap, I have no problem changing it to use that. Thanks for the help and wiki updates.
Closing this. This breaking change was not intended to be released in a minor release, but to completely revert this we'd need to revert the whole PR that introduced http-proxy-middleware. This also brought us websocket proxy support, and a lot of other nice options. Also, not that many people seem to use rewrite. Documentation for the dev-server is updated to reflect this.
Thanks for your help @jdkrebs and @chimurai
TL;DR - use pathRewrite, as documented in http-proxy-middleware.
Most helpful comment
@SpaceK33z @jdkrebs
This line in
http-proxy-middlewarekind of ignores/reverts the rewritten path in your fix. (source)Not sure what the best approach would be to make it backwards compatible.
As alternative, you could use the
.pathRewriteoption offered by HPM.The syntax is slightly different...
For more info on
pathRewrite: http-proxy-middleware/recipes/pathRewrite.md@SpaceK33z
I noticed a sudden surge in downloads since v1.15.0 got released and with it also a number of proxy related issues. Feel free to _cc_ me if you need any assistance.