Azure App Service HTTP/2.0 Disabled: Why It Matters and How to Fix It

HTTP/2 has been a stable, widely supported protocol since 2015, yet plenty of Azure App Services are still defaulting to HTTP/1.1. Lensix raises the App Service HTTP/2.0 Disabled check (appservice_nohttp2) when it finds a web app that has not enabled HTTP/2 support. It's a quick win that improves how clients talk to your app, and there's almost no reason to leave it off.

This post walks through what the check looks at, why HTTP/2 matters, how to flip it on through the portal, CLI, and infrastructure as code, and how to keep new app services from shipping without it.

---

What this check detects

Azure App Service supports HTTP/2 as an opt-in feature. When you create a new web app, the front-end listener defaults to HTTP/1.1 unless you explicitly turn HTTP/2 on. The Lensix check inspects the http20Enabled property in your App Service site configuration. If it is set to false (or never set), the check fails.

The relevant configuration field looks like this when you pull it from the Azure API:

{
  "properties": {
    "siteConfig": {
      "http20Enabled": false
    }
  }
}

---

Why it matters

HTTP/2 is not a security control in the way TLS or authentication is, so this check is mostly about performance, efficiency, and keeping your stack modern. That said, the difference is real and measurable for any app that serves more than a handful of assets per page.

Multiplexing removes head-of-line blocking

Under HTTP/1.1, a browser opens multiple TCP connections and sends requests one after another on each. A slow response can block everything queued behind it. HTTP/2 multiplexes many requests and responses over a single connection, so a slow image doesn't hold up your CSS or JavaScript.

Header compression cuts overhead

HTTP/2 uses HPACK to compress request and response headers. For chatty APIs that send repetitive headers (auth tokens, cookies, content negotiation) on every call, this trims real bytes off the wire and reduces latency.

Fewer connections, less server strain

Collapsing six parallel HTTP/1.1 connections into one HTTP/2 connection reduces the connection setup and teardown overhead on both the client and the App Service front end. On high-traffic apps that adds up.

---

How to fix it

You can enable HTTP/2 from the portal, the Azure CLI, PowerShell, or your IaC of choice. The change takes effect immediately and does not require an app restart.

Option 1: Azure Portal

1. Open the App Service in the Azure portal.
2. Under Settings, select Configuration.
3. Go to the General settings tab.
4. Find HTTP version and set it to 2.0.
5. Click Save.

Option 2: Azure CLI

This is the fastest way to fix a single app or script a fix across many:

az webapp config set \
  --resource-group my-resource-group \
  --name my-app-service \
  --http20-enabled true

Verify the change:

az webapp config show \
  --resource-group my-resource-group \
  --name my-app-service \
  --query "http20Enabled"

You should get back true.

az webapp list --query "[].{name:name, rg:resourceGroup}" -o tsv | \
while read -r name rg; do
  echo "Enabling HTTP/2 on $name in $rg"
  az webapp config set --resource-group "$rg" --name "$name" --http20-enabled true
done

Option 3: PowerShell

Set-AzWebApp `
  -ResourceGroupName "my-resource-group" `
  -Name "my-app-service" `
  -Http20Enabled $true

Option 4: Terraform

If you manage App Services with Terraform, set http2_enabled in the site config. For the azurerm_linux_web_app resource:

resource "azurerm_linux_web_app" "example" {
  name                = "my-app-service"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  service_plan_id     = azurerm_service_plan.example.id

  site_config {
    http2_enabled = true
  }
}

The same http2_enabled attribute applies to azurerm_windows_web_app.

Option 5: Bicep / ARM

resource webApp 'Microsoft.Web/sites@2023-01-01' = {
  name: 'my-app-service'
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      http20Enabled: true
    }
  }
}

---

How to prevent it from happening again

One-time fixes don't stick. The goal is to make HTTP/2 the default for every new App Service so this check never fails again.

Enforce with Azure Policy

Azure Policy can audit or deny App Services that don't have HTTP/2 enabled. Here's a custom policy definition that audits non-compliant apps:

{
  "properties": {
    "displayName": "App Service apps should use HTTP 2.0",
    "policyType": "Custom",
    "mode": "Indexed",
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Web/sites"
          },
          {
            "field": "Microsoft.Web/sites/siteConfig.http20Enabled",
            "notEquals": true
          }
        ]
      },
      "then": {
        "effect": "audit"
      }
    }
  }
}

Assign it at the subscription or management group level. Start with audit to see what's out there, then move to a deployIfNotExists or deny effect once you're confident nothing legitimate depends on HTTP/1.1.

Gate it in CI/CD

If you use Terraform, add a check in your pipeline that fails the plan when http2_enabled is missing or false. A policy-as-code tool like Checkov, tfsec, or Conftest can catch it before merge. A simple Conftest rule with OPA looks like this:

deny[msg] {
  resource := input.resource.azurerm_linux_web_app[name]
  not resource.site_config.http2_enabled
  msg := sprintf("App Service '%s' must enable HTTP/2", [name])
}

Bake it into modules

If your teams provision App Services through a shared Terraform or Bicep module, set http2_enabled = true as the default inside the module. That way every app inherits the right setting without anyone having to remember it.

---

Best practices

• Enable HTTP/2 everywhere by default. There's no downside for clients, and the performance gains are free. Make it the standard, not the exception.
• Pair it with HTTPS-only and a minimum TLS version. HTTP/2 in App Service runs over TLS anyway, so enforce httpsOnly and set the minimum TLS version to 1.2 or higher while you're in the configuration.
• Don't stop at App Service. If traffic flows through Azure Front Door or Application Gateway, confirm HTTP/2 is enabled on those layers too so the benefit reaches the client edge.
• Test before broad rollout on legacy clients. The fallback to HTTP/1.1 is automatic, but if you have unusual server-to-server clients with custom HTTP stacks, give them a quick smoke test.
• Track configuration drift continuously. Settings get changed by hand during incidents and never reverted. Continuous scanning with Lensix catches the regression long before your next audit does.

HTTP/2 on App Service is one of the lowest-effort, highest-confidence fixes in the Azure web tier. Flip it on, enforce it with policy, default it in your modules, and move on to the harder problems.