Merge pull request #312109 from riturajc/riturajc/appgw-pace-updates-feb2026

Application Gateway and WAF documentation improvements (7 PACE items)

Author: ttorble

articles/application-gateway/application-gateway-autoscaling-zone-redundant.md

@@ -35,10 +35,12 @@ However, it’s important to note that provisioning a new instance may take appr
 
 For scale-in events, Application Gateway drains existing connections for 5 minutes on the instance that is subject for removal. After 5 minutes, existing connections are closed and the instance removed. Any new connections during or after the 5 minute scale-in time is established to other existing instances on the same gateway.
 
+> [!NOTE]
+> During autoscaling events, brief dips in availability metrics may be observed. This behavior is expected during scaling transitions and typically resolves within seconds.
+
 ## Next steps
 
 - Learn more about zone redundancy in [Reliability for Application Gateway v2](/azure/reliability/reliability-application-gateway-v2)
 - Learn how to [Schedule autoscaling for Application Gateway](application-gateway-externally-managed-scheduled-autoscaling.md)
 - Learn more about [Application Gateway v2](overview-v2.md)
 - [Create an autoscaling, zone redundant application gateway with a reserved virtual IP address using Azure PowerShell](tutorial-autoscale-ps.md)
-

articles/application-gateway/application-gateway-components.md

@@ -131,7 +131,7 @@ A backend pool routes request to backend servers, which serve the request. Backe
 - Public IP addresses
 - Internal IP addresses
 - FQDN (fully qualified domain names) or short names (single-label domain names), provided your DNS server can resolve them
-- Multitenant backends (such as App Service)
+- Multitenant backends such as Azure App Service and Azure Container Apps. See [Protect Container Apps with Application Gateway and WAF](../container-apps/waf-app-gateway.md) for implementation guidance.
 
 Application Gateway backend pool members aren't tied to an availability set. An application gateway can communicate with instances outside of the virtual network that it's in. As a result, the members of the backend pools can be across clusters, across datacenters, or outside Azure, as long as there's IP connectivity.
 

articles/application-gateway/application-gateway-probe-overview.md

@@ -82,6 +82,10 @@ The following table provides definitions for the properties of a custom health p
 | Interval |Probe interval in seconds. This value is the time interval between two consecutive probes |
 | Time-out |Probe time-out in seconds. If a valid response isn't received within this time-out period, the probe is marked as failed  |
 | Unhealthy threshold |Probe retry count. The backend server is marked down after the consecutive probe failure count reaches the unhealthy threshold |
+| MinServers |Minimum number of servers that are always marked healthy. Default value is 0, which means health probe results determine the health status of all backend servers. When set to a value greater than 0, the specified number of servers are always marked as healthy regardless of probe results. This property is only configurable via PowerShell, Azure CLI, or ARM templates (not available in Azure portal).|
+
+> [!WARNING]
+> Use the **MinServers** parameter with caution. When MinServers is set to a value greater than 0, Application Gateway always marks that minimum number of backend servers as healthy, even if their health probes are failing. This can result in traffic being sent to unhealthy servers, potentially causing 502 Bad Gateway errors or other connectivity issues for clients. Only configure MinServers if you have specific availability requirements and understand the implications of overriding health probe results.
 
 ### Probe matching
 

articles/application-gateway/application-gateway-secure-flag-session-affinity.md

@@ -19,6 +19,9 @@ In this guide you learn to create a Rewrite set for your Application Gateway and
 * You must have an Azure subscription. You can create a [free account](https://azure.microsoft.com/pricing/purchase-options/azure-account?cid=msft_learn) before you begin.
 * An existing Application Gateway resource configured with at least one Listener, Rule, Backend Setting and Backend Pool configuration. If you don't have one, you can create one by following the [QuickStart guide](quick-create-portal.md).
 
+> [!IMPORTANT]
+> If your backend application returns multiple Set-Cookie headers (for example, application cookies in addition to the ApplicationGatewayCookie), the simple pattern matching approach shown in this article will apply the rewrite to all Set-Cookie headers. To target only the ApplicationGatewayCookie specifically, use the HeaderValueMatcher pattern matching feature. For more information, see [Pattern matching for Set-Cookie headers](rewrite-http-headers-url.md#pattern-matching).
+
 ## Creating a Rewrite set
 
 1. Sign in to the Azure portal.
@@ -41,6 +44,8 @@ In this guide you learn to create a Rewrite set for your Application Gateway and
     1. Case-sensitive - No
     1. Operator - equal (=)
     1. Pattern to match - (.*)
+        > [!NOTE]
+        > This pattern `(.*)` matches all Set-Cookie headers. If you need to target only the ApplicationGatewayCookie and preserve other Set-Cookie headers, see [Pattern matching for Set-Cookie headers](rewrite-http-headers-url.md#pattern-matching) to use the HeaderValueMatcher feature.
     1. To save these details, select **OK**.
 1. Go to the **Then** box to specify action details.
     1. Rewrite type - Response header
@@ -53,4 +58,5 @@ In this guide you learn to create a Rewrite set for your Application Gateway and
 
 
 ## Next steps
-[Visit other configurations of a Backend Setting](configuration-http-settings.md)
+- [Visit other configurations of a Backend Setting](configuration-http-settings.md)
+- [Learn about pattern matching for Set-Cookie headers](rewrite-http-headers-url.md#pattern-matching)

articles/application-gateway/configuration-listeners.md

@@ -95,7 +95,9 @@ Set-AzApplicationGateway -ApplicationGateway $gw
 > When creating an application gateway resource through the Azure portal, the default option for **HTTP2** is set as enabled. You can choose **Disabled** during creation, and re-enabled HTTP2 support using the Azure portal by selecting **Enabled** under **HTTP2** in **Application gateway > Configuration**.
 >
 > In instances where HTTP2 isn't supported by a client, HTTP1.1 will be used. Enabling HTTP2 doesn't disable HTTP1.1; it allows support for both.
->
+
+> [!NOTE]
+> Application Gateway only supports HTTP/2 over TLS (HTTPS listeners). HTTP/2 Cleartext (h2c) protocol upgrade attempts from HTTP/1.1 are not supported and will result in a 403 Forbidden error. Clients attempting h2c upgrades should use native HTTP/2 connections over HTTPS or remain on HTTP/1.1.
 
 ### WebSocket support
 

articles/application-gateway/http-response-codes.md

@@ -55,16 +55,16 @@ HTTP 400 response codes are commonly observed when:
 Some common reasons for the request to be non-compliant to RFC are: 
 
 | Category | Examples |
-| ---------- | ---------- | 
-| Invalid Host in request line  | Host containing two colons (example.com:**8090:8080**) |
+| ---------- | ---------- |
+| Invalid Host in request line | Host containing two colons (example.com:**8090:8080**) |
 | Missing Host Header | Request doesn't have Host Header |
 | Presence of malformed or illegal character | Reserved characters are **&,!.** The workaround is to code it as a percentage. For example: %& |
 | Invalid HTTP version | Get /content.css HTTP/**0.3** |
-| Header field name and URI contain non-ASCII Character | GET /**«úü¡»¿**.doc HTTP/1.1  |
+| Header field name and URI contain non-ASCII Character | GET /**«úü¡»¿**.doc HTTP/1.1 |
 | Missing Content Length header for POST request | Self Explanatory |
 | Invalid HTTP Method | **GET123** /index.html HTTP/1.1 |
 | Duplicate Headers | Authorization:\<base64 encoded content\>, Authorization: \<base64 encoded content\> |
-| Invalid value in Content-Length | Content-Length: **abc**,Content-Length: **-10**|
+| Invalid value in Content-Length | Content-Length: **abc**,Content-Length: **-10** |
 
 For cases when mutual authentication is configured, several scenarios can lead to an HTTP 400 response being returned the client, such as:
 - Mutual authentication is enabled but the Client certificate wasn't presented. 
@@ -93,6 +93,7 @@ An HTTP 401 unauthorized response can be returned to AppGW probe request if the
 HTTP 403 Forbidden is presented when customers are utilizing WAF (Web Application Firewall) skus and have WAF configured in Prevention mode.  If enabled WAF rulesets or custom deny WAF rules match the characteristics of an inbound request, the client is presented a 403 forbidden response.
 
 Other reasons for clients receiving 403 responses include:
+- **h2c protocol upgrade attempts**: Application Gateway returns 403 errors when clients attempt to upgrade from HTTP/1.1 to HTTP/2.0 using the h2c protocol (HTTP/2 Cleartext). Application Gateway only supports HTTP/2 over TLS (HTTPS listeners); h2c protocol upgrades over HTTP listeners are not supported. This behavior occurs regardless of WAF mode. Clients should use native HTTP/2 connections over HTTPS or remain on HTTP/1.1 without upgrade attempts.
 - You're using App Service as backend and it's configured to allow access only from Application Gateway. This can return a 403 error by App Services. This typically happens due to redirects/href links that point directly to App Services instead of pointing at the Application Gateway's IP address. 
 - If you're accessing a storage blog and the Application Gateway and storage endpoint is in different region, then a 403 error is returned if the Application Gateway's public IP address isn't allow-listed. See [Grant access from an internet IP range](/azure/storage/common/storage-network-security?tabs=azure-portal#grant-access-from-an-internet-ip-range).
 

articles/application-gateway/key-vault-certs.md

@@ -77,7 +77,8 @@ Define access policies to use the user-assigned managed identity with your Key V
 3. If you're using the permission model **Vault access policy**: Select **Access Policies**, select **+ Add Access Policy**, select **Get** for **Secret permissions**, and choose your user-assigned managed identity for **Select principal**. Then select **Save**.
 
    If you're using **Azure role-based access control** follow the article [Assign a managed identity access to a resource](/entra/identity/managed-identities-azure-resources/how-to-assign-access-azure-resource) and assign the user-assigned managed identity the **Key Vault Secrets User** role to the Azure Key Vault.
-
+   > [!NOTE]
+   > When using Azure RBAC with Key Vault, if you're configuring the Application Gateway integration using PowerShell, Azure CLI, or REST API (for example, using `Get-AzKeyVaultSecret` or `az keyvault secret show`), the **user or service principal** performing these operations also needs the **Key Vault Secrets User** role (or equivalent permissions) on the Key Vault. This is because these management operations run in your security context, not the Application Gateway's managed identity context. The managed identity is used by Application Gateway at runtime to retrieve certificates.
 ### Verify Firewall Permissions to Key Vault
 
 As of March 15, 2021, Key Vault recognizes Application Gateway as a trusted service by leveraging User Managed Identities for authentication to Azure Key Vault.  With the use of service endpoints and enabling the trusted services option for Key Vault's firewall, you can build a secure network boundary in Azure. You can deny access to traffic from all networks (including internet traffic) to Key Vault but still make Key Vault accessible for an Application Gateway resource under your subscription.

articles/application-gateway/toc.yml

@@ -209,6 +209,8 @@
       href: ingress-controller-expose-websocket-server.md
     - name: Autoscale AKS pods with Application Gateway metrics
       href: ingress-controller-autoscale-pods.md
+  - name: Integration with Container Apps
+    href: ../container-apps/waf-app-gateway.md?toc=/azure/application-gateway/toc.json&bc=/azure/application-gateway/breadcrumb/toc.json
   - name: Route by URL
     items:
     - name: Azure PowerShell

articles/web-application-firewall/ag/upgrade-ruleset-version.md

@@ -53,8 +53,7 @@ When upgrading your Azure WAF ruleset version, make sure to:
     -Name $wafPolicyName ` 
     -ResourceGroupName $resourceGroupName 
     $currentExclusions = $wafPolicy.ManagedRules.Exclusions 
-    $currentManagedRuleset = $wafPolicy.ManagedRules.ManagedRuleSets 
-    | Where-Object { $_.RuleSetType -eq "OWASP" } 
+    $currentManagedRuleset = $wafPolicy.ManagedRules.ManagedRuleSets | Where-Object { $_.RuleSetType -eq "OWASP" } 
     $currentVersion = $currentManagedRuleset.RuleSetVersion
     ```
 
@@ -121,14 +120,15 @@ groups:
         foreach ($existingRule in $group.Rules) { 
     if (-not (Test-RuleIsRemovedFromDRS21 $existingRule.RuleId $currentVersion)) 
       { 
-       `$existingGroup = $groupOverrides | 
-    Where-Object { $_.RuleGroupName -eq $mappedGroupName } 
+       $existingGroup = $groupOverrides | Where-Object { $_.RuleGroupName -eq $mappedGroupName } 
     if ($existingGroup) { 
-    if (-not ($existingGroup.Rules | 
-    Where-Object { $_.RuleId -eq $existingRule.RuleId })) { 
+    if (-not ($existingGroup.Rules | Where-Object { $_.RuleId -eq $existingRule.RuleId })) { 
     $existingGroup.Rules.Add($existingRule) } } 
     else { 
-      $newGroup = New-AzApplicationGatewayFirewallPolicyManagedRuleGroupOverride ` -RuleGroupName $mappedGroupName ` -Rule @($existingRule) $groupOverrides += $newGroup } } } }
+      $newGroup = New-AzApplicationGatewayFirewallPolicyManagedRuleGroupOverride ` 
+        -RuleGroupName $mappedGroupName ` 
+        -Rule @($existingRule) 
+      $groupOverrides += $newGroup } } } }
 
     ```