Edit

Share via

How requests get matched to a route configuration

  • Article

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.

Important

Azure Front Door (classic) will be retired on March 31, 2027. To avoid any service disruption, it is important that you migrate your Azure Front Door (classic) profiles to Azure Front Door Standard or Premium tier by March 2027. For more information, see Azure Front Door (classic) retirement.

When a request arrives at the Azure Front Door (classic) edge, one of the first steps is to determine how to route the matching request to a backend resource and then take a defined action in the routing configuration. This document explains how Front Door determines which route configuration to use when processing a request.

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.

Note

  • Paths without a wildcard are considered exact-match paths. A path ending with a / is also an exact match.
  • Path patterns are case insensitive. For example, /FOO and /foo are treated as duplicates and are not allowed in the Patterns to match setting.

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.

If Azure Front Door (classic) doesn't have a cached response, it checks for a URL rewrite configuration. If no custom forwarding path is defined, the request is forwarded to the appropriate backend in the configured backend pool. If a custom forwarding path is defined, the request path is updated accordingly and then forwarded to the backend.

Next steps