Wildcard matching inner domain. Either a doc discrepancy, or unclear.

[jamesastrang]

Existing documentation URL(s)

• https://developers.cloudflare.com/workers/configuration/routing/routes/

What changes are you suggesting?

On the Routes page, in the "Hostnames may optionally begin with *" section, the example table contains an internal contradiction that I'd like clarified or corrected.

The table states:

Request URL	*example.com/*
https://myexample.com/	Matches
https://not-example.com/	Does not match

Based on the rule stated earlier on the same page — "The only supported operator is the wildcard (*), which matches zero or more of any character" — I cannot see why these two cases would behave differently. In both URLs, the * prefix would match the characters preceding example.com ("my" in one case, "not-" in the other), and the trailing /* would match the empty path. By the documented rule, both should match.

This is also reinforced by the warning immediately above the table, which states that *example.com "will also match hostnames that are not subdomains of example.com" and recommends using two separate routes (example.com/* and *.example.com/*) to avoid this. That warning agrees with the interpretation that not-example.com should match — which makes the last row of the table the outlier.

There are two possibilities, and either would require a documentation change:

1. The table is wrong. If the wildcard truly matches zero or more of any character, then https://not-example.com/ should say "Matches." The row should be corrected.
2. The table is correct, but the rule is incompletely described. If there is some additional constraint in the matching implementation — for example, that certain characters (hyphens, non-alphanumerics, etc.) terminate the wildcard match at a hostname boundary — that constraint needs to be documented. As written, the rule does not explain why "my" is an acceptable wildcard match but "not-" is not.

I have not purchased domains to empirically verify which case is true, so I'm raising this as a consistency issue rather than asserting which side is incorrect.

What is the expected outcome?

Either:

1. The not-example.com row in the table is updated to "Matches" to align with the stated wildcard semantics and the warning above the table, or
2. The rule description is expanded to document the actual matching behavior — specifically, what additional constraints apply to the * wildcard in the hostname position that cause myexample.com to match but not-example.com not to.

Additional information