Are routes with a '/' match guaranteed to be considered "catch-all" routes? #61547

Deliberate rather than incidental, but the promise that is actually written down is narrower than the one you described, and the difference is worth knowing before you rely on it.

It is intentional, and the intent is on the record

The relocation arrived with #8114 (merged 2018-08-23), whose body states the purpose outright: "This is the rudimentary merge of http routes, pushing the wildcard/catch all routes to the end", fixing #7793 "for Gateways only". So moving catch-alls last is the feature, not a side effect of it.

It is also documented, under Split large virtual services and destination rules into multiple resources:

Although the order of evaluation for rules in any given source VirtualService will be retained, the cross-resource order is UNDEFINED.
There should only be one "catch-all" rule (i.e., a rule without a match field) in the fragments. All such "catch-all" rules will be moved to the end of the list in the merged configuration, but since they catch all requests, whichever is applied first will essentially override and disable any others.

And it is pinned by tests rather than left to chance. TestSortVHostRoutes asserts that a prefix: "/" route moves to the end while the relative order of the rest is preserved, and TestIsCatchAllRoute asserts the classification, including a prefix: "/" case and the negative cases where headers or query parameters are present. Both pass on master today:

--- PASS: TestIsCatchAllRoute (0.00s)
--- PASS: TestSortVHostRoutes (0.00s)
ok      istio.io/istio/pilot/pkg/networking/core/route

Where your reading is broader than the documented contract

Two gaps, and the first is the one that bears on your exact case.

The docs define a catch-all as "a rule without a match field". IsCatchAllRoute is broader: it classifies any route whose path specifier is prefix: "/", PathSeparatedPrefix: "/" or regex .* and which has no header, query parameter or dynamic metadata match. A rule written explicitly as match: [{uri: {prefix: "/"}}] does have a match field, so the documented sentence does not literally cover it, while the implementation and its unit test both do. Your unconstrained uri.prefix: "/" is therefore guaranteed by the code and its test, not by the sentence in the docs.

Second, it is gateway-only, and narrowly so. SortVHostRoutes has exactly one caller in the tree, pilot/pkg/networking/core/gateway.go, applied per virtual host after collapseDuplicateRoutes. That matches both the original PR ("for Gateways only", with a note that doing it in the sidecar "requires a lot of intrusive changes to the RDS code") and the docs line that host merging is not supported in sidecars.

What is still undefined, and why it stayed narrow

The guarantee is only that catch-alls end up after non-catch-alls. It says nothing about ordering among catch-alls, which is why the docs tell you to have only one: with two, whichever lands first swallows everything and disables the other. It also applies no specificity ordering to the remaining routes, so a /foo from one fragment and a /foo/bar from another are still in undefined relative order.

That narrowness is historical rather than accidental. The first attempt at this sorted routes by specificity, and in #10485 a maintainer explains that the implementation "had side effects that were not backward compatible, so the implementation was changed in #8114, before it was released", then closed the issue as working as designed. What survived is the one property that could ship without breaking existing configurations: catch-alls to the end.

So I would treat it as supported behaviour for the case the docs describe, and as an implementation detail for the broader "an explicit prefix: / is guaranteed to follow more specific routes from other resources" reading. If you depend on the latter, the cheapest insurance is to give the catch-all fragment no match field at all, which puts you inside the documented wording as well as the code path.