Support regex based path rewrites

[arkodg]

What would you like to be added: Tracks support for regex based path substitution mentioned in the GEP https://gateway-api.sigs.k8s.io/geps/gep-726/#future-extension

Why this is needed: Automate path rewrites that have a common pattern e.g.

/auth/v1/{pattern} -> /self-service/{pattern}/browser

/auth/v1/login -> /self-service/login/browser
/auth/v1/recovery -> /self-service/recovery/browser
/auth/v1/settings -> /self-service/settings/browser

Related

• Thoughts from users and maintainers regarding supporting this - https://github.com/kubernetes-sigs/gateway-api/issues/726#issuecomment-984430631
• Supported in Istio - https://github.com/istio/istio/issues/22290 / https://github.com/istio/istio/pull/45398

[shaneutt]

Sounds like a good one to have:

/triage accepted

However, we don't expect this to be something we need for v1 so we're not necessarily ready for anyone to jump in on this one (unless this is the ONLY thing you want to work on).

[plnordquist]

Something that would also be useful in this same sort of rewrite would be matching parts of the hostname to put in the path. An example of this is mapping a sub-domain to a sub path of a backend application.

Some example nginx configuration:

server_name ~(?<sub>.+)\.example.com
if ( $sub != "" ) {
  rewrite ^/(v1|v2)/(.*) /app/$sub/$1/$2 break;
}

[youngnick]

The biggest reason why this is not done yet is about regular expression compatibility. An GEP that addresses this will need also to address:

• what flavors of regexes are supported across most if not all Gateway API implementations
• what flavor of regex is chosen as the Gateway API flavor. Ideally we should only be choosing one.
• why that particular flavor has been chosen. Note that any flavor that's not supported by all implementations will need some pretty significant justification here.

Since doing regex path rewrites means supporting a regex path match and then using regex matched details in the rewrite filter, this GEP also covers adding regex match support to the base matches stanza.

Other concerns I'd like to see addressed in this GEP that aren't regex compatibility:

• How do regexes get sorted in a list of matches? What happens when a regex also matches a Prefix or Exact match? ( I suspect the answer should be "Exact beats Prefix beats Regex beats /", but we will need to specify this precisely). Also note that the discussion about cascading matches is very relevant here too (what happens if cascading matches are enabled? Will that be hard to reason about or produce surprising results?)
• How do we also allow the use of regex capture groups inside rewrite filters? (That is, can you match on /api/{path} and then use $1 or something to represent the matched path in a rewrite filter? If so, how does that syntax work?).
• Using regex path matching basically precludes also doing any sort of path-based route delegation (which we haven't discussed for a long time, but we have discussed previously). What should we do here?
• As raised by @plnordquist, what's the support for using other data inside a regex match, like hostname, port, etc?

For the last two items, we don't need to answer those in the GEP, but if we aren't going to, we need to explicitly put them in as "reserved for future work", so the discussion doesn't get derailed. The regex flavor discussions has all the hallmarks of one that could be contentious to me, which is concerning.

[arkodg]

Envoy Gateway just added support for this using a filter in v1.2, here's an example