How requests get matched to a route configuration

A route in Azure Front Door defines how traffic is handled when an incoming request arrives at the Azure Front Door edge. The route settings establish an association between a domain and an origin group. By using advanced features such as Pattern to Match and Rule sets, you can have granular control over traffic to your backend resources.

Note

When you use the Front Door rule sets, you can configure a rule to override the origin group for a request. The origin group set by the rule set overrides the routing process described in this article.

Structure of a Front Door route configuration

A Front Door routing rule consists of two major parts: the "left-hand side" and the "right-hand side". Front Door matches the incoming request to the left-hand side of the route, while the right-hand side defines how the request is processed.

Incoming match (left-hand side)

The following properties determine whether the incoming request matches the routing rule (left-hand side):

  • HTTP Protocols - HTTP or HTTPS
  • Domain - For example: www.foo.com, *.bar.com
  • Paths - For example: /*, /users/*, /file.gif

These properties are expanded internally so that every combination of Protocol/Domain/Path is a potential match set.

Routing decision (right-hand side)

The decision on how to process the request depends on whether caching is enabled for the route. If a cached response isn't available, the request is forwarded to the appropriate origin.

Route matching

This section explains how Front Door matches requests to routing rules. The basic principle is that Front Door always matches to the most-specific request by evaluating the "left-hand side" properties: protocol, domain, and path, in that order.

Frontend host matching

Azure Front Door uses the following steps to match frontend hosts:

  1. Check for routes with an exact match on the frontend host.
  2. If no exact match is found, the request is rejected with a 404: Bad Request error.

The following tables illustrate three different routing rules with their frontend hosts and paths:

Routing rule Frontend hosts Path
A foo.contoso.com /*
B foo.contoso.com /users/*
C www.fabrikam.com, foo.adventure-works.com /*, /images/*

The following table shows the matching results for the routing rules in the previous table:

Incoming frontend host Matched routing rules
foo.contoso.com A, B
www.fabrikam.com C
images.fabrikam.com Error 404: Bad Request
foo.adventure-works.com C
contoso.com Error 404: Bad Request
www.adventure-works.com Error 404: Bad Request
www.northwindtraders.com Error 404: Bad Request

Path matching

After Azure Front Door determine the specific frontend host and filtering possible routing rules, it selects the routing rules based on the request path. The following logic is used:

  1. Check for routing rules with an exact match to the request path.
  2. If no exact match is found, look for a routing rule with a wildcard path that matches.
  3. If no matching path is found, the request is rejected with a 404: Bad Request error.

Note

The wildcard character * is only valid for paths that don't have any other characters after it. Additionally, the wildcard character * must be preceded by a slash /. Paths without a wildcard are considered exact-match paths. A path that ends in a slash / is also an exact-match path. Ensure that your paths follow these rules to avoid errors.

The following table lists routing rules with their frontend host and path combinations:

Routing rule Frontend host Path
A www.contoso.com /
B www.contoso.com /*
C www.contoso.com /ab
D www.contoso.com /abc
E www.contoso.com /abc/
F www.contoso.com /abc/*
G www.contoso.com /abc/def
H www.contoso.com /path/

The following table shows which routing rule matches an incoming request at the Azure Front Door edge:

Incoming Request Matched Route
www.contoso.com/ A
www.contoso.com/a B
www.contoso.com/ab C
www.contoso.com/abc D
www.contoso.com/abzzz B
www.contoso.com/abc/ E
www.contoso.com/abc/d F
www.contoso.com/abc/def G
www.contoso.com/abc/defzzz F
www.contoso.com/abc/def/ghi F
www.contoso.com/path B
www.contoso.com/path/ H
www.contoso.com/path/zzz B

Warning

If there are no routing rules for an exact-match frontend host without a catch-all route path (/*), no routing rule will be matched.

Example configuration:

Route Host Path
A profile.contoso.com /api/*

Matching table:

Incoming request Matched Route
profile.domain.com/other None. Error 404: Bad Request

Routing decision

Once Azure Front Door matches a routing rule, it decides how to process the request. If a cached response is available, it gets served back to the client.

If a rule set is configured for the matched routing rule, it gets processed in order. Rule sets can override a route by directing traffic to a specific origin group. If no rule set is defined, the request is forwarded to the origin group without changes.

Next steps