freshness review - 8/12

Author: duongau

articles/frontdoor/front-door-url-rewrite.md

@@ -6,7 +6,7 @@ services: front-door
 author: duongau
 ms.service: azure-frontdoor
 ms.topic: conceptual
-ms.date: 06/01/2023
+ms.date: 08/012/2024
 ms.author: duau
 zone_pivot_groups: front-door-tiers
 ---
@@ -15,27 +15,29 @@ zone_pivot_groups: front-door-tiers
 
 ::: zone pivot="front-door-standard-premium"
 
-Azure Front Door supports URL rewrite to change the request path being routed to your origin. URL rewrite allows you to set conditions to make sure the URL or the specified headers gets rewritten only when certain conditions get met. These conditions are based on the request and response information.
+Azure Front Door provides support for URL rewrite, enabling you to modify the request path that is being routed to your origin. This powerful feature allows you to define conditions that determine when the URL or specified headers should be rewritten. These conditions are based on the information present in the request and response.
 
-With this feature, you can redirect your end users to a different origin based on their device types, or the type of file requested. The URL rewrite action can be found in a rule set configuration.
+By using URL rewrite, you have the ability to redirect your end users to different origins based on factors such as their device type or the type of file they're requesting. The URL rewrite action can be easily configured within the rule set, providing you with fine-grained control over your routing behavior.
 
 :::image type="content" source="./media/front-door-url-rewrite/front-door-url-rewrite.png" alt-text="Screenshot of URL rewrite action in a rule set configuration.":::
 
 ## Source pattern
 
-The **source pattern** is the URL path in the initial request you want to replace. Currently, source pattern uses a prefix-based match. To match all URL paths, you can define a forward slash (`/`) as the source pattern value.
+The **source pattern** represents the URL path in the initial request that you wish to replace. Currently, the source pattern utilizes a prefix-based matching approach. To match all URL paths, you can specify a forward slash (`/`) as the value for the source pattern.
 
-For the source pattern in a URL rewrite action, only the path after the *patterns to match* in the route configuration is considered. For example, you have the following incoming URL format `contoso.com/pattern-to-match/source-pattern`, only `/source-pattern` gets considered by the rule set as the source pattern to be rewritten. The format of the out going URL after URL rewrite gets applied is `contoso.com/pattern-to-match/destination`.
+In the context of a URL rewrite action, only the path after the *patterns to match* in the route configuration is taken into consideration for the source pattern. For instance, the rule set considers only `/source-pattern` as the source pattern to be rewritten if you have an incoming URL format of `contoso.com/pattern-to-match/source-pattern`. After the URL rewrite is applied, the outgoing URL format will be `contoso.com/pattern-to-match/destination`.
 
-For situation, when you need to remove the `/pattern-to-match` segment of the URL, set the **origin path** for the origin group in route configuration to `/`.
+In cases where you need to remove the `/pattern-to-match` segment of the URL, you can set the **origin path** for the origin group in the route configuration to `/`.
 
 ## Destination
 
-The destination path used to replace the source pattern. For example, if the request URL path is `contoso.com/foo/1.jpg`, the source pattern is `/foo/`, and the destination is `/bar/`, the content gets served from `contoso.com/bar/1.jpg` from the origin.
+The destination path represents the path that replaces the source pattern. For instance, if the request URL path is `contoso.com/foo/1.jpg`, and the source pattern is `/foo/`, specifying the destination as `/bar/` results in the content being served from `contoso.com/bar/1.jpg` from the origin.
 
 ## Preserve unmatched path
 
-Preserve unmatched path allows you to append the remaining path after the source pattern to the new path. When preserve unmatched path is set to **No** (default), the remaining path after the source pattern gets removed.
+Preserve unmatched path allows you to control how the remaining path after the source pattern is handled. By setting preserve unmatched path to **Yes**, the remaining path is appended to the new path. On the other hand, setting it to **No** (default) will remove the remaining path after the source pattern.
+
+Here's an example showcasing the behavior of preserve unmatched path:
 
 | Preserve unmatched path | Source pattern | Destination | Incoming request | Content served from origin |
 |--|--|--|--|--|
@@ -49,11 +51,9 @@ Preserve unmatched path allows you to append the remaining path after the source
 
 [!INCLUDE [Azure Front Door (classic) retirement notice](../../includes/front-door-classic-retirement.md)]
 
-Azure Front Door (classic) supports URL rewrite by configuring a **Custom forwarding path** when configuring the forward routing type rule. By default, if only a forward slash (`/*`) is defined, Front Door copies the incoming URL path to the URL used in the forwarded request. The host header used in the forwarded request is as configured for the selected backend. For more information, see [Backend host header](origin.md#origin-host-header).
-
-The robust part of URL rewrite is the custom forwarding path copies any part of the incoming path that matches the wildcard path to the forwarded path.
+Azure Front Door (classic) provides support for URL rewrite by configuring a **Custom forwarding path** when setting up the forward routing type rule. By default, if only a forward slash (`/*`) is defined, Front Door replicates the incoming URL path in the forwarded request. The host header used in the forwarded request is based on the configuration of the selected backend. For more detailed information, see the [Backend host header](origin.md#origin-host-header) documentation.
 
-The following table shows an example of an incoming request and the corresponding forwarded path when using a custom forwarding path of `/fwd/` for a match path with a wildcard. The **a/b/c** part of the path represents the portion replacing the wildcard.
+The key aspect of URL rewrite lies in the ability to copy any matching part of the incoming path to the forwarded path when using a custom forwarding path with a wildcard match. The following table illustrates an example of an incoming request and the corresponding forwarded path when utilizing a custom forwarding path of `/fwd/`. The section denoted as **a/b/c** represents the portion that replaces the wildcard match.
 
 | Incoming URL path | Match path | Custom forwarding path | Forwarded path |
 |--|--|--|--|
@@ -70,9 +70,10 @@ Consider a routing rule with the following combination of frontend hosts and pat
 |  | /foo/\* |
 |  | /foo/bar/\* |
 
-The first column in the following table shows examples of incoming requests and the second column shows what would be the **most-specific** matching route defined. The next three columns in the table are examples of *Custom forwarding paths*.
+The following table illustrates examples of incoming requests and their corresponding most-specific matching routes. It also provides examples of custom forwarding paths and the resulting forwarded paths.
+
+For instance, consider the second row of the table. If the incoming request is `www.contoso.com/sub`, and the custom forwarding path is set to `/`, then the forwarded path would be `/sub`. However, if the custom forwarding path is set to `/fwd/`, then the forwarded path would be `/fwd/sub`. The emphasized parts of the paths indicate the portions that are part of the wildcard match.
 
-For example, the second row reads, for an incoming request of `www.contoso.com/sub`, if the custom forwarding path is `/`, then the forwarded path would be `/sub`. If the custom forwarding path was `/fwd/`, then the forwarded path is `/fwd/sub`. The **emphasized** parts of the paths represent the portions that are part of the wildcard match.
 
 | Incoming request | Most-specific match path | / | /fwd/ | /foo/ | /foo/bar/ |
 |--|--|--|--|--|--|
@@ -89,9 +90,7 @@ For example, the second row reads, for an incoming request of `www.contoso.com/s
 
 ## Optional settings
 
-There are extra optional settings you can also specify for any given routing rule settings:
-
-* **Cache configuration** - If disabled or not specified, requests that match to this routing rule doesn't attempt to use cached content and instead always fetch from the backend. For more information, see [caching with Azure Front Door](front-door-caching.md).
+**Cache configuration** - If disabled or not specified, requests that match to this routing rule doesn't attempt to use cached content and instead always fetch from the backend. For more information, see [caching with Azure Front Door](front-door-caching.md).
 
 ::: zone-end