Corner case in HTTPRouteRule match order when RegularExpression is used

[spacewander]

What would you like to be added:

We need to add test cases to ensure the RegularExpression match happens after the other matches.

Why this is needed:

According to the HTTPRouteRule definition:
https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io%2fv1beta1.HTTPRouteRule

Proxy or Load Balancer routing configuration generated from HTTPRoutes MUST prioritize matches based on the following criteria, continuing on ties. Across all rules specified on applicable Routes, precedence must be given to the match with the largest number of:

Characters in a matching path.
Header matches.
Query param matches.

The routes are sorted by the "Characters in a matching path." first.

However, when the RegularExpression in https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.PathMatchType is involved, the order is ambiguous as the regex can be very specific.

For example, a regex /a/(.*)+ has more characters in a matching path than exact match /a/b, while it is similar to the path prefix /a/. If we strictly sort the route by the path, /a/(.*)+ will be matched before /a/b.

An idea to sort this problem is to ensure the regex match happens after the other matches.

[robscott]

I agree this is an important issue, thanks for catching it! Before we update conformance tests, we should likely work on an update to the spec to clarify the correct order of operations here. It may be sufficient to replace:

* Characters in a matching path.

With:

* Characters in a matching "Exact" path match
* Characters in a matching "Prefix" path match
* Characters in a matching "RegularExpression" path match

[shaneutt]

/help

[sunjayBhatia]

in case we're looking for input on the sorting order/precedence of different match types, in Contour we've historically had:

• exact match gets most precedence, sorted by length (descending)
• regex is next, since it could be more specific than a prefix (again sorted by length)
• prefix match (again sorted by length)

we don't compare length of match string between different match types which is a distinction to point out in the docs if we match this behavior

[pleshakov]

in case we're looking for input on the sorting order/precedence of different match types,

In NGINX, we have the following order:

• exact match gets most precedence
• regex match, which is the first match among the regexes in the order of appearance in the configuration file; In NGINX Kubernetes Gateway, we sort regex matches by their order of appearance in the corresponding HTTPRoutes + by the timestamp and namespace/name of the HTTPRoutes.
• most specific prefix match

https://nginx.org/en/docs/http/ngx_http_core_module.html#location

[Xunzhuo]

/assign
/remove-help