Merge pull request #302784 from MicrosoftDocs/main

Auto Publish – main to live - 2025-07-15 22:00 UTC

Author: learn-build-service-prod[bot]

articles/application-gateway/add-http-header-rewrite-rule-powershell.md

@@ -5,51 +5,68 @@ services: application-gateway
 author: mbender-ms
 ms.service: azure-application-gateway
 ms.topic: how-to
-ms.date: 04/12/2019
+ms.date: 07/09/2025
 ms.author: mbender 
 ms.custom: devx-track-azurepowershell
 # Customer intent: "As a cloud administrator, I want to configure HTTP header rewrites using Azure PowerShell, so that I can efficiently modify headers in requests and responses for my Application Gateway."
 ---
 # Rewrite HTTP request and response headers with Azure Application Gateway - Azure PowerShell
 
-This article describes how to use Azure PowerShell to configure an [Application Gateway v2 SKU](./application-gateway-autoscaling-zone-redundant.md) instance to rewrite the HTTP headers in requests and responses.
+This article describes how to use Azure PowerShell to configure an [Application Gateway v2 SKU](./application-gateway-autoscaling-zone-redundant.md) instance to rewrite HTTP headers in requests and responses. Header rewriting enables you to add, remove, or update HTTP headers while the request and response packets move between the client and backend pools.
 
 If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.
 
-## Before you begin
+## Prerequisites
 
-- You need to run Azure PowerShell locally to complete the steps in this article. You also need to have Az module version 1.0.0 or later installed. Run `Import-Module Az` and then `Get-Module Az` to determine the version that you have installed. If you need to upgrade, see [Install Azure PowerShell module](/powershell/azure/install-azure-powershell). After you verify the PowerShell version, run `Login-AzAccount` to create a connection with Azure.
-- You need to have an Application Gateway v2 SKU instance. Rewriting headers isn't supported in the v1 SKU. If you don't have the v2 SKU, create an [Application Gateway v2 SKU](./tutorial-autoscale-ps.md) instance before you begin.
+Before you begin, ensure you have the following requirements:
 
-## Create required objects
+- **Azure PowerShell**: You need Azure PowerShell installed locally or access to Azure Cloud Shell. The Azure PowerShell Az module version 1.0.0 or later is required. To check your version, run `Get-Module -ListAvailable Az`. If you need to upgrade, see [Install Azure PowerShell module](/powershell/azure/install-azure-powershell). 
+- **Azure connection**: After verifying the PowerShell version, run `Connect-AzAccount` to authenticate with Azure.
+- **Application Gateway v2**: You need an existing Application Gateway v2 SKU instance. Header rewriting is only supported in the v2 SKU (Standard_v2 or WAF_v2). If you don't have one, create an [Application Gateway v2 SKU](./tutorial-autoscale-ps.md) instance before you begin.
+- **Proper permissions**: Ensure you have Contributor or Owner permissions on the Application Gateway resource.
 
-To configure HTTP header rewrite, you need to complete these steps.
+> [!IMPORTANT]
+> Header rewrite functionality is only available with Application Gateway v2 SKU. The v1 SKU doesn't support this feature.
 
-1. Create the objects that are required for HTTP header rewrite:
+## Understanding HTTP header rewrite components
 
-   - **RequestHeaderConfiguration**: Used to specify the request header fields that you intend to rewrite and the new value for the headers.
+To configure HTTP header rewrite, you need to understand and create the following components in a specific order:
 
-   - **ResponseHeaderConfiguration**: Used to specify the response header fields that you intend to rewrite and the new value for the headers.
+### Core components
 
-   - **ActionSet**: Contains the configurations of the request and response headers specified previously.
+1. **RequestHeaderConfiguration**: Specifies the request header fields you want to rewrite and their new values. Use this component to modify headers in client requests before they reach the backend servers.
 
-   - **Condition**: An optional configuration. Rewrite conditions evaluate the content of HTTP(S) requests and responses. The rewrite action will occur if the HTTP(S) request or response matches the rewrite condition.
+2. **ResponseHeaderConfiguration**: Specifies the response header fields you want to rewrite and their new values. Use this component to modify headers in server responses before they reach the client.
 
-     If you associate more than one condition with an action, the action occurs only when all the conditions are met. In other words, the operation is a  logical AND operation.
+3. **ActionSet**: Contains the configurations of the request and response headers specified. Each action set represents a collection of header modifications to perform.
+   
+   - **Condition**: An optional configuration. Rewrite conditions evaluate the content of HTTP(S) requests and responses. The rewrite action occurs if the HTTP(S) request or response matches the rewrite condition.
 
-   - **RewriteRule**: Contains multiple rewrite action / rewrite condition combinations.
+   > [!NOTE]
+   > Multiple conditions associated with an action use logical AND operation - all conditions must be met for the action to execute.
 
-   - **RuleSequence**: An optional configuration that helps determine the order in which rewrite rules execute. This configuration is helpful when you have multiple rewrite rules in a rewrite set. A rewrite rule that has a lower rule sequence value runs first. If you assign the same rule sequence value to two rewrite rules, the order of execution is non-deterministic.
+5. **RewriteRule**: Combines multiple rewrite actions and rewrite conditions. Each rule defines when and how to modify headers.
 
-     If you don't specify the RuleSequence explicitly, a default value of 100 is set.
+6. **RuleSequence** (Optional): Determines the execution order when you have multiple rewrite rules in a rewrite set. Rules with lower sequence values execute first. If you don't specify a value, the default is 100.
 
-   - **RewriteRuleSet**: Contains multiple rewrite rules that will be associated to a request routing rule.
+   > [!WARNING]
+   > If you assign the same sequence value to multiple rules, the execution order becomes non-deterministic.
 
-2. Attach the RewriteRuleSet to a routing rule. The rewrite configuration is attached to the source listener via the routing rule. When you use a basic routing rule, the header rewrite configuration is associated with a source listener and is a global header rewrite. When you use a path-based routing rule, the header rewrite configuration is defined on the URL path map. In that case, it applies only to the specific path area of a site.
+7. **RewriteRuleSet**: Contains multiple rewritten rules that are associated with a request routing rule.
 
-You can create multiple HTTP header rewrite sets and apply each rewrite set to multiple listeners. But you can apply only one rewrite set to a specific listener.
+### Application scope
 
-## Sign in to Azure
+The rewrite configuration scope depends on the routing rule type:
+
+- **Basic routing rule**: Header rewrite configuration applies globally to all requests for the associated listener
+- **Path-based routing rule**: Header rewrite configuration applies only to requests matching specific URL path patterns defined in the URL path map
+
+> [!IMPORTANT]
+> You can create multiple HTTP header rewrite sets and apply each set to multiple listeners, but only one rewrite set can be applied to a specific listener.
+
+## Authenticate with Azure
+
+Before configuring header rewrite rules, authenticate with Azure and select your subscription:
 
 ```azurepowershell
 Connect-AzAccount
@@ -58,12 +75,12 @@ Select-AzSubscription -Subscription "<sub name>"
 
 ## Specify the HTTP header rewrite rule configuration
 
-In this example, we'll modify a redirection URL by rewriting the location header in the HTTP response whenever the location header contains a reference to azurewebsites.net. To do this, we'll add a condition to evaluate whether the location header in the response contains azurewebsites.net. We'll use the pattern `(https?)://.*azurewebsites.net(.*)$`. And we'll use `{http_resp_Location_1}://contoso.com{http_resp_Location_2}` as the header value. This value will replace *azurewebsites.net* with *contoso.com* in the location header.
+In this example, we modify a redirection URL by rewriting the location header in the HTTP response whenever the location header contains a reference to azurewebsite.net. To do this modification, we add a condition to evaluate whether the location header in the response contains azurewebsite.net. We use the pattern `(https?)://.*azurewebsite.net(.*)$`. And we use `{http_resp_Location_1}://contoso.com{http_resp_Location_2}` as the header value. This value replaces *azurewebsite.net* with *contoso.com* in the location header.
 
 ```azurepowershell
 $responseHeaderConfiguration = New-AzApplicationGatewayRewriteRuleHeaderConfiguration -HeaderName "Location" -HeaderValue "{http_resp_Location_1}://contoso.com{http_resp_Location_2}"
 $actionSet = New-AzApplicationGatewayRewriteRuleActionSet -ResponseHeaderConfiguration $responseHeaderConfiguration
-$condition = New-AzApplicationGatewayRewriteRuleCondition -Variable "http_resp_Location" -Pattern "(https?):\/\/.*azurewebsites\.net(.*)$" -IgnoreCase
+$condition = New-AzApplicationGatewayRewriteRuleCondition -Variable "http_resp_Location" -Pattern "(https?):\/\/.*azurewebsite\.net(.*)$" -IgnoreCase
 $rewriteRule = New-AzApplicationGatewayRewriteRule -Name LocationHeader -ActionSet $actionSet -Condition $condition
 $rewriteRuleSet = New-AzApplicationGatewayRewriteRuleSet -Name LocationHeaderRewrite -RewriteRule $rewriteRule
 ```
@@ -74,32 +91,51 @@ $rewriteRuleSet = New-AzApplicationGatewayRewriteRuleSet -Name LocationHeaderRew
 $appgw = Get-AzApplicationGateway -Name "AutoscalingAppGw" -ResourceGroupName "<rg name>"
 ```
 
-## Retrieve the configuration of your request routing rule
+## Retrieve request routing rule configuration
+
+Get the specific request routing rule where you want to apply the header rewrite configuration:
 
 ```azurepowershell
 $reqRoutingRule = Get-AzApplicationGatewayRequestRoutingRule -Name rule1 -ApplicationGateway $appgw
 ```
 
 ## Update the application gateway with the configuration for rewriting HTTP headers
 
-In this example, the rewrite set would be associated instantly against a basic routing rule. In case of a path based routing rule, the association would not be enabled by default. The rewrite set can be enabled either via checking the paths on which it needs to be applied via portal or by providing a URL path map config specifying the RewriteRuleSet against each path option.  
+In this example, the rewrite set would be associated instantly against a basic routing rule. In a path based routing rule, the association wouldn't be enabled by default. The rewrite set can be enabled either via -- checking the paths on which it needs to be applied via portal or by providing a URL path map config specifying the RewriteRuleSet against each path option.  
 
 ```azurepowershell
 Add-AzApplicationGatewayRewriteRuleSet -ApplicationGateway $appgw -Name $rewriteRuleSet.Name  -RewriteRule $rewriteRuleSet.RewriteRules
 Set-AzApplicationGatewayRequestRoutingRule -ApplicationGateway $appgw -Name $reqRoutingRule.Name -RuleType $reqRoutingRule.RuleType -BackendHttpSettingsId $reqRoutingRule.BackendHttpSettings.Id -HttpListenerId $reqRoutingRule.HttpListener.Id -BackendAddressPoolId $reqRoutingRule.BackendAddressPool.Id -RewriteRuleSetId $rewriteRuleSet.Id
 Set-AzApplicationGateway -ApplicationGateway $appgw
 ```
 
-## Delete a rewrite rule
+## Remove a rewrite rule (Optional)
 
-```azurepowershell
+If you need to remove a rewrite rule set from your Application Gateway, use the following steps:
+
+```azurepowershell-interactive
+# Retrieve the current Application Gateway configuration
 $appgw = Get-AzApplicationGateway -Name "AutoscalingAppGw" -ResourceGroupName "<rg name>"
+
+# Remove the rewrite rule set association from the routing rule first
+$requestRoutingRule = Get-AzApplicationGatewayRequestRoutingRule -Name "rule1" -ApplicationGateway $appgw
+
+# Clear the rewrite rule set reference
+$requestRoutingRule.RewriteRuleSet = $null
+
+# Remove the rewrite rule set from the Application Gateway
 Remove-AzApplicationGatewayRewriteRuleSet -Name "LocationHeaderRewrite" -ApplicationGateway $appgw
-$requestroutingrule= Get-AzApplicationGatewayRequestRoutingRule -Name "rule1" -ApplicationGateway $appgw
-$requestroutingrule.RewriteRuleSet= $null
-set-AzApplicationGateway -ApplicationGateway $appgw
+
+# Apply the changes
+Set-AzApplicationGateway -ApplicationGateway $appgw
+
+Write-Output "Rewrite rule set removed successfully"
 ```
 
 ## Next steps
 
-To learn more about how to set up some common use cases, see [common header rewrite scenarios](./rewrite-http-headers-url.md).
+Now that you learned how to configure HTTP header rewrite rules, explore these related articles:
+
+- **Common scenarios**: Learn about [common header rewrite scenarios](./rewrite-http-headers-url.md) including security headers, custom routing, and backend server integration patterns.
+
+- **Monitoring and troubleshooting**: Set up [Application Gateway diagnostics](./application-gateway-diagnostics.md) to monitor header rewrite operations and troubleshoot issues.

articles/application-gateway/configuration-overview.md

@@ -20,35 +20,35 @@ This image illustrates an application that has three listeners. The first two ar
 
 ## Infrastructure
 
-The Application Gateway infrastructure includes the virtual network, subnets, network security groups, and user defined routes.
+The Application Gateway infrastructure includes the virtual network, subnets, network security groups, and user-defined routes.
 
 For more information, see [Application Gateway infrastructure configuration](configuration-infrastructure.md).
 
 
 
 ## Frontend IP address
 
-You can configure the application gateway to have a public IP address, a private IP address, or both. A public IP is required when you host a back end that clients must access over the Internet via an Internet-facing virtual IP (VIP).
+You can configure the application gateway to have a public IP address, a private IP address, or both. A public IP is required when you host a backend that clients must access over the Internet via an Internet-facing virtual IP (VIP).
 
 For more information, see [Application Gateway frontend IP address configuration](configuration-frontend-ip.md).
 
 ## Listeners
 
-A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address. When you configure the listener, you must enter values for these that match the corresponding values in the incoming request on the gateway.
+A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address. When you configure the listener, you must enter values for these entities that match the corresponding values in the incoming request on the gateway.
 
 For more information, see [Application Gateway listener configuration](configuration-listeners.md).
 
 ## Request routing rules
 
-When you create an application gateway by using the Azure portal, you create a default rule (*rule1*). This rule binds the default listener (*appGatewayHttpListener*) with the default backend pool (*appGatewayBackendPool*) and the default backend HTTP settings (*appGatewayBackendHttpSettings*). After you create the  gateway, you can edit the settings of the default rule or create new rules.
+When you create an application gateway by using the Azure portal, you create a default rule (*rule1*). This rule binds the default listener (*appGatewayHttpListener*) with the default backend pool (*appGatewayBackendPool*) and the default backend HTTP settings (*appGatewayBackendHttpSettings*). After you create the gateway, you can edit the settings of the default rule or create new rules.
 
 For more information, see [Application Gateway request routing rules](configuration-request-routing-rules.md).
 
-## HTTP settings
+## Backend settings
 
-The application gateway routes traffic to the backend servers by using the configuration that you specify here. After you create an HTTP setting, you must associate it with one or more request-routing rules.
+The application gateway routes traffic to the backend servers by using the configuration that you specify here. After you create a backend setting, you must associate it with one or more request-routing rules.
 
-For more information, see [Application Gateway HTTP settings configuration](configuration-http-settings.md).
+For more information, see [Application Gateway backend settings configuration](configuration-http-settings.md).
 
 ## Backend pool
 
@@ -58,10 +58,10 @@ After you create a backend pool, you must associate it with one or more request-
 
 ## Health probes
 
-An application gateway monitors the health of all resources in its back end by default. But we strongly recommend that you create a custom probe for each backend HTTP setting to get greater control over health monitoring. To learn how to configure a custom probe, see [Custom health probe settings](application-gateway-probe-overview.md#custom-health-probe-settings).
+An application gateway monitors the health of all resources in its backend by default. But we strongly recommend that you create a custom probe for each backend HTTP setting to get greater control over health monitoring. To learn how to configure a custom probe, see [Custom health probe settings](application-gateway-probe-overview.md#custom-health-probe-settings).
 
 > [!NOTE]
-> After you create a custom health probe, you need to associate it to a backend HTTP setting. A custom probe won't monitor the health of the backend pool unless the corresponding HTTP setting is explicitly associated with a listener using a rule.
+> After you create a custom health probe, you need to associate it to a backend HTTP setting. A custom probe doesn't monitor the health of the backend pool unless the corresponding HTTP setting is explicitly associated with a listener using a rule.
 
 ## Next steps