Today I was asked “what is StrongWildcard and WeakWildcard, and which one should I use?”. The piece of object model that my co-worker is asking about is:

Most bindings have a HostNameComparisonMode property on them. This property is used for service-side endpoints (IChannelListener), in conjunction with the ListenUri of that endpoint. The values are semantics similar to + and * for http.sys registrations. “Wildcard” vs. “Exact” refers to how we match the authority (hostname+port) piece of an incoming Uri. For “Wildcard”, anything matches. For “Exact”, we perform a case-insensitive string comparison to determine equality.

“Strong” vs. “Weak” has to do with the relative priorities of endpoints. We use three longest-prefix-match tables, one each for StrongWildcard, Exact, and WeakWildcard. When a Message comes into the system, we first try to match the Uri against our Strong table (which uses a wildcard comparison on hostname+port). If nothing matches, we try the Exact table (using a case-insensitive exact comparison on hostname+port). Lastly, if there was no match on Strong or Exact, we check the Weak table (again using a wildcard match for hostname+port).

For example, let’s say you have the following endpoints registered on your machine:

1. (http://foo.com/a/b/c/, StrongWildcard)
2. (http://foo.com/a/b/, Exact)
3. (http://bar.com/, Exact)
4. (http://foo.com/a/, WeakWildcard)

A request coming in for http://foo.com/a/b/c/d/ will match (1).

A request for http://foo.com/a/b/ will match (2) since the strong comparison fails (/a/b/c/ is not a prefix of /a/b/).

A request for http://foo.com/a/d/ will match (4). Even though “/” is a prefix match of “/a/d/” for (3), the hostnames differ and so the Exact match will fail.

Lastly, a request for http://bar.com/a/b/ will match (3). (2) is a prefix match but the hostnames differ, and (3) takes precedence over (4) in priority order.

Hopfully this helps demystify our endpoint URI matching process!