Regex for path matching: RegularExpression

[omegion]

Hi,

It seems NGF does not yet support RegularExpression for path matching. I wonder if there is any way for me to move this NGINX location to HTTPRoute with the current features:

location ~* ^/foo-service/workspaces/\w+(-\w+)?/environments/ {
  //
}

I could not figure out how I could match this path with HTTPRoute. Do you have any ideas?

[sjberman]

Hi @omegion, unfortunately there is no workaround at this point for adding in regex path matching. We'll need to implement the Gateway API feature in order for this to work.

Thanks for your interest in this! It helps us with our priorities.

[sjberman]

For when this gets implemented, something to keep in mind is that this needs to play well with Rewrites and Redirects, which could be the challenging part. If conformance tests do not exist, then we should implement functional tests for all of these cases.

[fabian4]

I can help with this feature, can I just take it?

Is there any other thing I should pay attention to about the Rewrites and Redirects parts?

BTW I don't think conformance test has covered the RegularExpression right now, we might have to handle it on our own.

[fabian4]

As mentioned in https://gateway-api.sigs.k8s.io/reference/spec/?h=replaceprefixmatch#httppathmodifier

ReplacePrefixMatch is only compatible with a PathPrefix HTTPRouteMatch.
Using any other HTTPRouteMatch type on the same HTTPRouteRule will result in
the implementation setting the Accepted Condition for the Route to status: False.

So all the combination is as follow

PathMatch	Rewrite/Redirect	Support	Example
Exact	ReplaceFullPath	✅	/foo → /bar
Exact	ReplacePrefixMatch	❌	-
Prefix	ReplaceFullPath	✅	/api/v1/users → /api/v2
Prefix	ReplacePrefixMatch	✅	/api/v1/users/123 → /api/v2/users/123
Regex	ReplaceFullPath	✅	/foo/book/bar → /items/book
Regex	ReplacePrefixMatch	❌	-

Also for more example with Regex + ReplaceFullPath

Regex Pattern	Request Path	Named Capture	ReplaceFullPath	Result Path
^/foo/bar$	/foo/bar	None	/items/default	/items/default
^/foo/(?<id>\w+)/bar$	/foo/book/bar	id=book	/items/$id	/items/book
^/shop/(?<cat>\w+)/item/(?<itemid>\d+)$	/shop/electronics/item/123	cat=electronics, itemid=123	/products/$cat/$itemid	/products/electronics/123
^/api/v1/(?<res>\w+)/(?<id>\d+)$	/api/v1/users/42	res=users, id=42	/v2/$res/$id	/v2/users/42
^/old/(?<path>.*)$	/old/foo/bar	path=foo/bar	/new/$path	/new/foo/bar
^/prefix/(?<tail>.*)$	/prefix/a/b/c	tail=a/b/c	/newprefix/$tail	/newprefix/a/b/c

Please correct me if anything above is wrong

[sjberman]

Hi @fabian4, you are certainly welcome at taking a stab at this, though I do have a feeling it may be a bit more complex than it seems at face value. There are some intricacies with the way we handle some internal routing in the nginx conf (and through use of NJS) when more complex HTTP matching conditions are configured, in addition to how we handle rewrites and redirects (which use some regex) with regard to internal locations. It does require a bit of nginx knowledge. Having regex-based paths makes this ever more complicated. We have to ensure things like rewriting/redirecting a regex path to another path properly preserves any query args or additional path segments, especially when routing to another internal location block.