Allow paths in Application Gateway rules to be defined as regular expression
Currently, Application Gateway rules support only path matches with a wildcard at the end of the string.
For us it means to rework our routing strategy as the first part of our route is dynamic /<domain>/<controller> (eg. /sales/process). The controllers are shared among domains. Domains can be dynamically created, what disallow us to directly use the current feature to separate only 'process' controller to standalone backend pool.
We would prefer to be able to define something like '/[a-z]]+/process.*' as a matching criterion.
Emil BM. commented
This is insane. How is this feature not supported? This basically forces users to switch to API Management at 1000x the cost. No service worth a **** only uses fixed routes. As far as I can google, Front Door has the same limitation.
Seems like an obvious thing to focus on, if you want to be a viable service.
Freek van Hezewijk commented
We could surely use this, as we need to route a path containing culturecodes. These vary greatly, and currently we hit the limit of pathing rules due to this. Regular expressions would fix this.
Ryan Adler commented
Is this still planned? any ETA?
Ryan Adler commented
We are trying to move all applications to App Services, but are unable to continue, since we have exhausted all 100 of the allowed path rules. This change would resolve the issue for us, but until then, can you increase that limit? This is a blocker for us.
+1 for this feature as well as an update of when we can expect this.
We are starting the localization effort and marketing wants the language to come before the site. So /es/blog, /es/reviews, where blog and reviews are separate back ends. Each of the 14 languages we want to support needs 2 rules (with and without the trailing slash) so this quickly eats into the 100 rule limit. For us, at this point, even supporting /*/blog in the rules would work, but I'll take full RegEx support :)
Bhushan Gawale commented
@James No its not the same, the regular based expression feature currently is available only while configuring the host headers but not while creating the actual rule.
Any update on this product team? It is highly needed feature specifically when you want to quickly move away from existing proxy or reverse proxy based solutions and use Azure app gateway instead.
James Sturtevant commented
This looks like the it might be available: https://docs.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers#rewrite-conditions
"You use the Perl Compatible Regular Expressions (PCRE) library to set up regular expression pattern matching in the conditions. "
Hey guys, any news?
I´m in the middle of migration and we found a regular expression in our former Netscaler and I would like to reproduce in the Application Gateway.
Aulich Martin (CI/DAD3.2) commented
Same for us, this would be a great feature
Any update on this? This would be really useful for us!
Dynamics Edge commented
We would also really like to see something loosely similar to this implemented in Azure Front Door - you can see our idea request for more details : https://feedback.azure.com/forums/217313-networking/suggestions/38493931-allow-regex-search-patterns-for-url-path-patterns - as well as Application Gateway.
Nathan Field commented
Is there an update on this? We are looking to be able to define one website subdirectory to draw content from a separate pool than the rest of the site (/* except /subdirectory1/*)
Rohan Sharma commented
Any updates on this one please? We need an approach to be able to define multiple backends for a single link.
The regex allow path will definitely work for us but is there any updates when can we expect this?
This is a blocker for us - needed ASAP please.
Andrew Twigg commented
Any update on this one please? Is this likely to deliver soon? thanks
Yup a real issue for me also. I have an API system where I need to block some regex but allow others. This lack of functionality means I can't block at the WAF level.... instead I have to allow 'all' requests through and then block at the application level).
David Nelson commented
This is a blocker for me. I am not going to tie my routing strategy to a tool that does not give me the ability to evolve my backend service structure while maintaining my public API surface.