Proxy with '**' suppresses URLs with parameters

[Kyrodan]

Expected behavior

apiProxy1 should match:
/something/myapp/api?param=value => should match to http://www.example.org/otherapi?param=value

apiProxy2 should not be necessary.

Actual behavior

apiProxy1:
/something/myapp/api => matches to http://www.example.org/otherapi
/something/myapp/api?param=value => does not match

apiProxy2:
/something/myapp/api => matches to http://www.example.org/otherapi
/something/myapp/api?param=value => matches to http://www.example.org/otherapi?param=value

Setup

• http-proxy-middleware: 0.16.0
• server: connect 2.30.0

proxy middleware configuration

var apiProxy1 = proxy('/**/myapp/api', {target:'http://www.example.org/otherapi', changeOrigin:true});
var apiProxy2 = proxy('/**/myapp/api*', {target:'http://www.example.org/otherapi', changeOrigin:true});

[chimurai]

Hi @Kyrodan ,

Once you use wildcards for context matching, micromatch is used internally to handle wildcard matching.

The behavior you described is the default behavior of micromatch.

var mm = require("micromatch");

console.log(mm('/something/myapp/api', '/**/myapp/api').length > 0); // true
console.log(mm('/something/myapp/api?param=value', '/**/myapp/api').length > 0); // false

console.log(mm('/something/myapp/api', '/**/myapp/api*').length > 0); // true
console.log(mm('/something/myapp/api?param=value', '/**/myapp/api*').length > 0); // true

Please check the following resources for more info on glob patterns:

• https://www.npmjs.com/package/micromatch
• https://www.npmjs.com/package/glob

Alternatively if you want to customize the matching behavior; you can provide your own function to do the matching:

var filter = function (path, req) {
    return (/\/myapp\/api/.test(path));
};

var apiProxy = proxy(filter, {target:'http://www.example.org/otherapi', changeOrigin:true});

Please let me know if the documentation can be improved to clear up this confusion.

[Kyrodan]

Thanks @chimurai,

for me it was completely unclear that the pattern "/something/myapp/api" matches my URL with paramaters, but "/**/myapp/api" didn't. For me the use case for http-proxy-middleware is to "redirect" url paths to another location. Parameters and Fragments should not be part of the matching because they never should be "rewritten" - this would mean an API call itself gets manipulated.

By the way: Fragments/Hashes are already excluded, see context-matcher.js, function getUrlPath:

url.parse(uri).path

Regarding to https://www.npmjs.com/package/url path returns the "Concatenation of pathname and search". To unify these different behaviors, maybe it's better to use pathname (= "The path section of the URL, that comes after the host and before the query, including the initial slash if present.").

Here are some other examples that may lead to confusion (excluding the parameters-part mentioned above):

var apiProxy1 = proxy('/**/myapp/api', {target:'http://www.example.org/otherapi', changeOrigin:true});
// /something/myapp/apiExtended => no match
// Result: expected behavior)

var apiProxy2 = proxy('/**/myapp/api*', {target:'http://www.example.org/otherapi', changeOrigin:true});
// /something/myapp/apiExtended => matches to http://www.example.org/otherapiExtended 
// Result: unexpected behavior, should match to http://www.example.org/otherapi)

var apiProxy3 = proxy('/**/myapp/apiExtended', {target:'http://www.example.org/extendedapi', changeOrigin:true});
// /something/myapp/apiExtended => matches to http://www.example.org/extendedapi
// Result: expected bahavior

After looking into documentation I maybe could have guessed this issue. At least this could be clarified in documentation adding additional samples. But in my opinion this is a bug.

Regards,
Daniel

[chimurai]

Thanks for explaining. I think you might be right.

There is a little history to this.
When I was implementing the wildcard functionality I did stumble upon this issue; Decided to provide as much data (including the url query parameters) allowing the developer discriminate on query parameters.

With the introduction of the custom context match function (v0.13.0), the wildcard behavior can be corrected like you described, without loosing the ability to discriminate on query parameters.

I"ll create a fix to restrict matching to the .pathname (RFC 3986 path)

[chimurai]

@Kyrodan

I just published version 0.17.0-beta to npm.
Let me know if this fixed the issue for you.

[Kyrodan]

Thank you, this works for me now.