Allow RegEx Search Patterns for URL Path Patterns in Front Door Rules, and Multiple Wildcards
Right now, Azure Front Door URL Path Patterns support matching through only one wildcard (asterisk)
that currently must be preceded by a slash and must appear at the very end of the URL Path Pattern.
This is still true as of September 1, 2019.
For some use cases, it is crucial to have much more control over each URL path pattern, than the current existing functionality in Azure Front Door.
We would like to see the possibility to have more versatile rules in Azure Front Door, including both of the following:
1) The ability to place more than one wildcard (asterisk) in the same URL path pattern,
and for multiple wildcards to be able to appear in other parts of the rule other than the very end preceded by a slash,
and with no absolute requirement for a wildcard to be preceded by a slash
and no absolute requirement for the wildcard to appear as the final character of the URL Path Pattern.
2) We would like to see support for RegEx ( Regular Expression ) search patterns,
and for there to be allowed to be more than one RegEx search pattern in the same URL path pattern,
and for RegEx to be able to appear in multiple parts of the URL Path Pattern.
This #2 may also be the preferred way to implement both #1 and #2 at the same time.
The reason #1 is mentioned, is because perhaps for those Azure users not familiar with Regular Expressions who may still want more versatility, maybe at least the ability to use more than one wildcard in the same URL Path Pattern, and not just at the very end preceded by a slash, could be helpful for some use cases as well.
The mention of #1 is also intended to clarify that the desired functionality for #2 is for there to be more than one RegEx search pattern supported in the same URL Path Pattern,
and for there not to be any obligation for it to appear only once at the very end of the string preceded by a slash.
something like //route//123/* cannot be done right now, which if it were implemented,
should match the example routes of:
We would like the above to be possible.
Also, it is not possible right now to use RegEx search patterns to define something like:
which if implemented would match the example routes of
We would like something like the above to be possible as well.
It could alternatively be no longer allowed to use wildcards, and use RegEx only.
The above example
would then instead have to be defined as something like:
This example above presumes that an asterisk wildcard in the current functionality would be roughly equivalent to a RegEx catch-all greedy capture of .+?
in the current model, that may or may not actually be the case.
Since the current Azure Front Door asterisk only can appear at the end of the URL path pattern and always must be preceded by a slash (/), the current matching engine cannot actually be presumed to be equivalent to a RegEx, the presumptions are only for purposes of illustrating the requested functionality.
To make the engine still user friendly for people who may want more versatile rules but do not want to use RegEx, perhaps the current wildcard asterisk * could still be supported, and would be interpreted as .+? if it were RegEx
However, remember that a wildcard also means "zero or more of the matched element" in RegEx.
~~Option 1 to deal with asterisk: RegEx Parenthetical Capture~~
Perhaps it may be a desirable option to require parenthetical capture groups for RegEx, to distinguish between the user-friendly asterisk * , and the intention to say "zero or more" as in .+?
For instance, this example (.) could mean zero or more of anything. Whereas . would actually be equivalent to a literal period, followed by the RegEx of (.+?)
, and more like expected behavior for people who just want to use one or more wildcards.
/a./route - this would match /a.example/route but not /a/something/route or /a/route
/a(.)/route - this would match /a/route as well as /a/something/route and /a/example/route
And then if someone wants to use a literal parenthetical for some reason either in the URL with no RegEx. or inside a RegEx, perhaps the parenthetical must be escaped with \ (and this would be specified in the instructions). Literal parentheses inside URL’s may not be that common, but they are technically still possible.
All content enclosed in non-escaped closed sequences of parentheticals could be interpreted as RegEx search patterns. All literal parentheses, asterisks, or dots (and certain other characters) inside capture groups would need to be escaped with \ or it would become invalid RegEx.
Or something like the above.
~~Option 2 to deal with asterisk: RegEx Only~~
A potentially easy solution is that all literal characters are not enclosed in parentheses, and all RegEx must be enclosed in parentheses.
The existing wildcard would then be literally an asterisk, unless inside a RegEx capture group such as (.*)
Similar to #1, parentheses must be escaped with \
The only downside is it is not as user friendly for people who want non-RegEx Wildcards as Option #1.
There are other options, they won't be enumerated here for now.
Although this could be out of scope for this one request,
the mention of capture groups (Options 1 and 2 above) here is because:
if RegEx capture groups became part of the functionality,
then it is possible that capture groups can become usable for the "Forward - Rewrite" and "Redirect - Destinations" components of Azure Front Door.
For example, perhaps capture groups can be mentioned in the destination fragment or custom forwarding path as $1, $2 etc. - making even some interesting advanced use cases possible.
We would definitely like to see this supported too if possible, although we expect the use of capture groups inside forward rewrites or redirect destinations to be probably a separate scope, because even just supporting RegEx matching alone (and multiple instances in same URL Path) is plenty for one feature request.
By the way, there may be a loosely similar feature request to this one started by someone else in Feb. 2018, here:
but that request is specifically for Application Gateway,.
This request here is for Azure Front Door.
This request also goes into detail on the requested functionality and therefore may not be identical to the other request.
This request is for the above functionality to be implemented in Azure Front Door.
We happen to also want to see this same kind of functionality rolled out for Application Gateway as well, if possible, but this feature request is being filed for Azure Front Door.
Shakeel osmani commented
This is a must have I do not understand how Azure cannot support this. The alternative left in Azure native is have a function app do proxy-ing that is just a horrible idea. This is a simple use case for multiple situations increasingly with single page applications that have path location routes, you will always generate unnecessary errors or weird redirects. God forbid you to want host multiple different types of applications under a custom domain with custom routing rules.
Lars Kemmann commented
A related, but not identical, need is the ability to *turn off* the automatic appending of whatever the wildcard matched to the end of the forwarding URL. This is needed for single-page apps with client-side routes, e.g. example.com/app/* where all matching requests should simply be forwarded (not redirected) to example.com/static/index.html.
This turned out to be a blocker for us today.
Need to be able to capture one or more segments matched from the request URL and use them when rewriting the replacement URL.
Here's a typical sample, easily achieved with IIS URL Rewrite, Traefik, NGiNX, etc. so there are plenty of reference solutions / formats.
A very powerful and simple solution (albeit technical) is support for Regex with capture groups that can be referenced in the replacement pattern. Should cover most if not all scenarios.
Ultimately a simpler implementation to achieve the below would be awesome!
The above would map from this:
We would also like to see this available in Application Gateway. We want the ability to route requests to specific instances based on wildcards _within_ the URL path:
This would allow us to route to specific instances where we host these operations. This is key for micro service architecture.