add related content section

Author: halkazwini

articles/frontdoor/rules-engine-scenarios.md

@@ -33,7 +33,7 @@ You can define various rule [actions](front-door-rules-engine-actions.md) based
 
 This article covers common use cases supported by the rules engine, and how to configure these rules to meet your needs. It also includes Azure Resource Manager (ARM) template examples to help automate deployment of these capabilities.
 
-### Scenario 1: Redirect using query string, URL path segments, or incoming hostname captures
+## Scenario 1: Redirect using query string, URL path segments, or incoming hostname captures
 
 Managing redirects is critical for search engine optimization (SEO), user experience, and the proper functioning of a website. Azure Front Door's rules engine and server variables allow you to efficiently manage batch redirects based on various parameters.
 
@@ -75,7 +75,7 @@ Managing redirects is critical for search engine optimization (SEO), user experi
 
 - **Redirect based on fixed-length URL path segments:** You can redirect requests to different origins based on fixed-length URL path segment by capturing the URL segments using `{variable:offset:length}`. For more information, see [Server variable format](/azure/frontdoor/rule-set-server-variables#server-variable-format).
 
-    For example, consider a scenario where the tenant ID is embedded in the URL segment and is always 6 characters long, such as: `https://api.contoso.com/{tenantId}/xyz`. To extract `{tenantId}` from the URL and decide the correct redirect to use in the format of `tenantId.backend.com/xyz`.
+    For example, consider a scenario where the tenant ID is embedded in the URL segment and is always six characters long, such as: `https://api.contoso.com/{tenantId}/xyz`. To extract `{tenantId}` from the URL and decide the correct redirect to use in the format of `tenantId.backend.com/xyz`.
 
     This approach eliminates the need to create a separate rule for each tenant ID, allowing you to handle dynamic routing with fewer rules.
 
@@ -194,9 +194,9 @@ Managing redirects is critical for search engine optimization (SEO), user experi
     }
     ```
 
-### Scenario 2: Populate or modify a response header based on a request header value
+## Scenario 2: Populate or modify a response header based on a request header value
 
-In some scenarios, you may need to populate or modify a response header based on a request header value.
+In some scenarios, you might need to populate or modify a response header based on a request header value.
 
 For example, you can add CORS header where needed to serve scripts on multiple origins from the same CDN domain, and response must contain the same FQDN in `Access-Control-Allow-Origin` header as the request origin header, rather than a wildcard allowing all domains (*) to enhance security. You can achieve it by using the `{http_req_header_Origin}` server variable to set the response header.
 
@@ -245,7 +245,7 @@ For example, you can add CORS header where needed to serve scripts on multiple o
 }
 ```
 
-### Scenario 3: Rename a response header to a brand-specific one 
+## Scenario 3: Rename a response header to a brand-specific one 
 
 You can rename a response header generated by a cloud provider by adding a new custom response header and deleting the original.
 
@@ -289,11 +289,11 @@ For example, you can replace the response header `X-Azure-Backend-ID` with a bra
 }
 ```
 
-### Scenario 4: A/B testing (experimentation)
+## Scenario 4: A/B testing (experimentation)
 
 Splitting incoming traffic into two origin groups can be is useful in A/B testing, rolling deployments, or load balancing without complex backend logic.
 
-For example, you can split incoming traffic based on the client port number. A rule can match client ports that end in 1, 3, 5, 7, or 9 and forward those requests to an *experiment-origin-group*. All other traffic continues to the default origin group per route settings. The previous regex is just an example, You can explore and test your own expressions using tools like [regex101](https://regex101.com/).
+For example, you can split incoming traffic based on the client port number. A rule can match client ports that end in 1, 3, 5, 7, or 9 and forward those requests to an *experiment-origin-group*. All other traffic continues to the default origin group per route settings. The previous regex is just an example. You can explore and test your own expressions using tools like [regex101](https://regex101.com/).
 
 > [!NOTE]
 > Since client ports are random, this method typically results in an approximate 50/50 traffic split. However, the presence of any proxies or load balancers between clients and the Front Door might affect this assumption due to factors like connection reuse or source port rewriting. Use logs or metrics to validate the actual behavior in your environment.
@@ -345,7 +345,7 @@ For example, you can split incoming traffic based on the client port number. A r
 }
 ```
 
-### Scenario 5: Redirect with URL path modification and preserve capability
+## Scenario 5: Redirect with URL path modification and preserve capability
 
 In some scenarios, you might need to add new segments or remove some segments while preserving the rest of the URL path.
 
@@ -384,7 +384,7 @@ For example, if you want to redirect `https://domain.com/seg0/seg1/seg2/seg3` to
 }
 ```
 
-### Scenario 6: Redirect by removing fixed parts of a URL path
+## Scenario 6: Redirect by removing fixed parts of a URL path
 
 You can remove fixed segments of known size from a URL path, such as country codes (us) or locales (en-us), while preserving the rest of the URL path.
 
@@ -439,7 +439,7 @@ To achieve this, use `{variable:offset} `, which includes the server variable af
 }
 ```
 
-### Scenario 7: URL rewrite by removing one or more segments of URL path
+## Scenario 7: URL rewrite by removing one or more segments of URL path
 
 You can remove one or more segments from a URL path, such as country codes (us) or locales (en-us), while preserving the rest of the URL path.
 
@@ -480,7 +480,7 @@ To achieve this, use the `{url_path:seg#:length}` server variable format to capt
 }
 ```
 
-### Scenario 8: Use regex to reduce the number of rule conditions and avoid hitting limits
+## Scenario 8: Use regex to reduce the number of rule conditions and avoid hitting limits
 
 Using regex in rule conditions can significantly reduce the number of rules required, which helps avoid rule limits that can be a blocker for customers who need conditions or actions for hundreds of clients.
 
@@ -539,9 +539,9 @@ Instead of creating individual rules for each possible client ID, you can use a
 }
 ```
 
-### Scenario 9: Modify origin redirects using response header captures
+## Scenario 9: Modify origin redirects using response header captures
 
-You can make action fields dynamic by using response header values as server variables. This is particularly useful when origin servers issue redirects that reference their own domain names.
+You can make action fields dynamic by using response header values as server variables. This is useful when origin servers issue redirects that reference their own domain names.
 
 **The Problem:** Origin servers like Azure App Service commonly issue redirect URLs that reference their own domain name (for example, `contoso.azurewebsites.net`). If these URLs reach the client unmodified, the next request bypasses Azure Front Door, which disrupts the user's navigation experience.
 
@@ -606,9 +606,9 @@ For more information, see [Preserve the original HTTP host name between a revers
 }
 ```
 
-### Scenario 10: If-elseif-else rules
+## Scenario 10: If-elseif-else rules
 
-The Azure Front Door rules engine doesn't natively support traditional conditional logic with "if-elseif-else" structures. By default, all rules are independently evaluated as "if condition1 then action1," "if condition2 then action2," and so forth. When multiple conditions are met simultaneously, multiple corresponding actions are executed.
+The Azure Front Door rules engine doesn't natively support traditional conditional logic with "if-elseif-else" structures. By default, all rules are independently evaluated as "if condition1 then action1", "if condition2 then action2", and so forth. When multiple conditions are met simultaneously, multiple corresponding actions are executed.
 
 However, you can emulate "if-elseif-else" logic by using the **Stop evaluating remaining rules** feature to create conditional branching that resembles:
 
@@ -632,7 +632,7 @@ However, you can emulate "if-elseif-else" logic by using the **Stop evaluating r
 
 :::image type="content" source="./media/rules-engine-scenarios/if-elseif-else-rules-final.png" alt-text="Screenshot that shows how to place if-elseif-else rules as the final ruleset for the route." lightbox="./media/rules-engine-scenarios/if-elseif-else-rules-final.png":::
 
-### Scenario 11: Removing query strings from incoming URLs using URL redirects
+## Scenario 11: Removing query strings from incoming URLs using URL redirects
 
 You can remove query strings from incoming URLs by implementing a 3xx URL redirect that guides users back to the Azure Front Door endpoint with the query strings removed.
 
@@ -684,7 +684,7 @@ The following example demonstrates how to remove the entire query string from in
 }
 ```
 
-### Scenario 12: Append SAS token in query string to authenticate Azure Front Door to Azure Storage
+## Scenario 12: Append SAS token in query string to authenticate Azure Front Door to Azure Storage
 
 You can protect files in your storage account by changing the access to your storage containers from public to private and using Shared Access Signatures (SAS) to grant restricted access rights to your Azure Storage resources from Azure Front Door without exposing your account key. You can also accomplish this using Managed Identity. For more information, see [Use managed identities to authenticate to origins](/azure/frontdoor/origin-authentication-with-managed-identities).
 
@@ -757,11 +757,11 @@ The rule configuration redirects all HTTPS requests that don't already contain t
 }
 ```
 
-### Scenario 13: Add security headers with rules engine
+## Scenario 13: Add security headers with rules engine
 
 You can use the Azure Front Door rules engine to add security headers that help prevent browser-based vulnerabilities, such as HTTP Strict-Transport-Security (HSTS), X-XSS-Protection, Content-Security-Policy, and X-Frame-Options.
 
-For example, you can add a *Content-Security-Policy* header to all incoming requests that match the path defined in the route associated with your rules engine configuration. In this configuration, use `script-src 'self' https://apiphany.portal.azure-api.net`as the header value to only allow scripts from the trusted site `https://apiphany.portal.azure-api.net` to run on the application. 
+For example, you can add a *Content-Security-Policy* header to all incoming requests that match the path defined in the route associated with your rules engine configuration. In this configuration, use `script-src 'self' https://apiphany.portal.azure-api.net` as the header value to only allow scripts from the trusted site `https://apiphany.portal.azure-api.net` to run on the application. 
 
 :::image type="content" source="./media/rules-engine-scenarios/add-security-headers.png" alt-text="Screenshot that shows how to add security headers with rules engine." lightbox="./media/rules-engine-scenarios/add-security-headers.png":::
 
@@ -792,3 +792,9 @@ For example, you can add a *Content-Security-Policy* header to all incoming requ
     }
 }
 ```
+
+## Related content
+
+- [What is a rule set in Azure Front Door?](/azure/frontdoor/front-door-rules-engine)
+- [Rule set actions](/azure/frontdoor/front-door-rules-engine-actions)
+- [Configure rule sets in Azure Front Door](/azure/frontdoor/standard-premium/how-to-configure-rule-set)