devServer proxy /api/* is actually /api

[olivercoad]

• Operating System:
• Node Version:
• NPM Version:
• webpack Version:
• webpack-dev-server Version: 3.10.3
• Browser:

• This is a bug
• This is a modification request

Code

When using the 'context': 'target' or 'context': { ...options... } style of proxy, if /* is at the end of the context it is removed.

webpack-dev-server/lib/Server.js

Lines 230 to 233 in 50c09a4

	// For backwards compatibility reasons.
	const correctedContext = context
	.replace(/^\*$/, '**')
	.replace(/\/\*$/, '');

See discussion in #359 for why this was done

So, for a config such as this:

// webpack.config.js
module.exports = {
  //...
  devServer: {
    proxy: {
      '/api/*' : 'http://localhost:3000'
    }
  }
};

Expected Behavior

Proxies everything starting with /api/
i.e. /api/stuff but NOT /apistuff.html

Actual Behavior

Proxies everything starting with /api
including /apistuff.html

For Bugs; How can we reproduce the behavior?

1. Create new project using The SAFE Template: dotnet new SAFE
2. To make it clear when requests are being proxied to the server, replace use_static publicPath with use_router (text "from server") in src/Server/Server.fs
3. Run the project using fake build -t run
4. Observe that localhost:8080/apistuff.html results in from server, because it is being proxied to the server (whereas localhost:8080/notapistuff.html results in Cannot GET /notapistuff.html because it is not being proxied)

For Features; What is the motivation and/or use-case for the feature?

N/A

[alexander-akait]

Bug, thanks for the issue, feel free to send a PR

[olivercoad]

Happy to make a PR. I've got a couple different thoughts of how to approach fixing it.

I think the most important part about this issue that the behaviour is different between the two styles of proxy config.

It would be quite reasonable to expect that changing the config from

devServer: {
    proxy: {
        '/api/*' : 'http://localhost:3000'
    }
}

to

devServer: {
    proxy: [
        {
            context: '/api/*',
            target: 'http://localhost:3000'
        }
    ]
}

would not have an effect on the behaviour.

However, because the latter does not modify the proxyOptions before sending it HPM, it actually has the behaviour of proxying ONLY /api/*, and NOT for example /api or /api/v1/stuff.

Just not altering the context is not really an option because it would break backward compatibility (as seen in #359)

With that in mind, what do you think of the following options.

Instead of removing trailing /*, replace it with /**

This would result in the expected behaviour,

Proxies everything starting with /api/
i.e. /api/stuff but NOT /apistuff.html

but would not fix the discrepency between the two styles and so changing to the array style would still have an unexpected change

Deprecate the use of trailing '/*'

We may as well fix the discrepency with using a single '*' while we're at it.
Deprecate the use of '*' and traling '/*' in the 'context': 'target' style in favour of '**' and '/**'

Deprecate the use of the 'context': 'target' style altogether

Supporting only arrays and not properties would be a simplification of the code base.

Configurations that need extra config need to use the { ...options...} style anyway so may as well use { context: '/api', ...options... }

And for simple proxies that do not need extra configuration, we could add support for https://github.com/chimurai/http-proxy-middleware#shorthand

[alexander-akait]

I think we should use logic as in express

[vtrikoupis]

Hey guys, is there an update on this?
I'm having trouble proxying across federated modules (used to work before beta v4)

[olivercoad]

Not sure. I we can decide which suggested option to take (or something else) I'd still be happy to make a PR.

@vtrikoupis I'd suggest changing any trailing /* with /** or using the array style.

[alexander-akait]

I think we can remove it for the next major release (beta now)

[olivercoad]

What do you mean by "remove it"? Remove what?

[alexander-akait]

backwards compatibility for old package