Redirect Path Selection Algorithm

SiteDetour supports a flexible and robust algorithm for matching your preferred redirect rule based on the requested URL.

On this page:

Overview

The following documentation outlines how SiteDetour matches request URIs and selects the appropriate path-based redirection rule when serving a redirect.

Path Selection Logic

SiteDetour begins the path selection process by sanitizing the requested URL - all query-string parameters are removed, as well as the domain name and scheme for the purposes of matching a candidate path. For example, http://example.com/foo?key=value will be reduced to "/foo" for the purposes of selecting the best matching path-rule within your redirect.

SiteDetour supports two types of matching operators for specifying how a given path should be matched against a request URI:

  1. Exact Match: The path entered must be identical to the requested URI.
  2. Starts With Match: The requested URI must start with the path entered within your path-rule. For example, /blog is a prefix within /blog/article.

The algorithm used for selecting the "best matching path" uses the following logic:

  1. For each path rule entered within SiteDetour:
  1. If the path matches the requested URI exactly, this path-rule is selected for building the redirect target URL.
  2. Otherwise, if the path-rule uses "starts with" matching, SiteDetour will check if the requested URI starts with the path entered.
  1. If so, the length of the path is determined by taking the number of characters within the path.
  2. If not, the path-rule is skipped over.
  1. Once all paths have been analyzed, the longest matching path-rule will be selected. For example, a rule for "/foo/bar" is longer than "/foo" and will therefore be selected.
  2. If no path-rules were matched, the "Default Base Path" rule will be selected. The default base path is always represented as the first path-rule within your redirect.

Examples

Consider the following path-rule configuration:

  1. Any request for "/my/path" (including URL variations with query-string parameters) would be matched by the first path-rule.
  2. A request for "/blog/article" would be matched for the second rule in the above image. This is because the rule uses the "Starts With" operator for it's matching.
  3. A request for "/blog/2022/example" would be matched by the third rule in the above image. This is because it is the longest matching path-rule, and is therefore selected over the less specific "/blog" path-rule.