Webpack-dev-server: Proxy rewrite function no longer called in 1.15.0

Created on 24 Aug 2016  路  12Comments  路  Source: webpack/webpack-dev-server

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?

2 (urgent)

Most helpful comment

@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.

All 12 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mischkl picture mischkl  路  3Comments

wojtekmaj picture wojtekmaj  路  3Comments

antoinerousseau picture antoinerousseau  路  3Comments

StephanBijzitter picture StephanBijzitter  路  3Comments

adiachenko picture adiachenko  路  3Comments