edits

Author: ktoliver

articles/app-service/app-service-web-configure-tls-mutual-auth.md

@@ -35,7 +35,7 @@ When you enable client certificates for your app, you should select your choice
 To set up your app to require client certificates in the Azure portal:
 
 1. Go to your app management page.
-1. On the resource menu, select **Configuration** > **General Settings**.
+1. On the left menu, select **Configuration** > **General Settings**.
 1. For **Client certificate mode**, select your choice.
 1. Select **Save**.
 
@@ -102,15 +102,15 @@ When you enable mutual auth for your application, all paths under the root of yo
 > [!NOTE]
 > Using any client certificate exclusion path triggers TLS renegotiation for incoming requests to the app.
 
-1. On the resource menu of your app's management pane, select **Configuration** > **General Settings**.
+1. On the left menu of your app's management pane, select **Configuration** > **General Settings**.
 
 1. Next to **Certificate exclusion paths**, select the edit icon.
 
-1. Select **New path**, specify a path, or a list of paths separated by `,` or `;`, and select **OK**.
+1. Select **New path**, specify a path or a list of paths separated by `,` or `;`, and then select **OK**.
 
 1. Select **Save**.
 
-In the following screenshot, any path for your app that starts with `/public` doesn't request a client certificate. Path matching is case-insensitive.
+In the following screenshot, any path for your app that starts with `/public` doesn't request a client certificate. Path matching isn't case specific.
 
 ![Certificate Exclusion Paths][exclusion-paths]
 
@@ -141,13 +141,13 @@ To address the 100-KB limit, consider these alternative solutions:
 1. Send a HEAD request before the PUT/POST request. The HEAD request handles the client certificate.
 1. Add the header `Expect: 100-Continue` to your request. This causes the client to wait until the server responds with a `100 Continue` before sending the request body, which bypasses the buffers.
 
-## Access client certificate
+## Access the client certificate
 
-In App Service, TLS termination of the request happens at the frontend load balancer. When App Service forwards the request to your app code with [client certificates enabled](#enable-client-certificates), it injects an `X-ARR-ClientCert` request header with the client certificate. App Service doesn't do anything with this client certificate other than forwarding it to your app. Your app code is responsible for validating the client certificate.
+In App Service, TLS termination of the request happens at the front-end load balancer. When App Service forwards the request to your app code with [client certificates enabled](#enable-client-certificates), it injects an `X-ARR-ClientCert` request header with the client certificate. App Service doesn't do anything with this client certificate other than forward it to your app. Your app code is responsible for validating the client certificate.
 
 For ASP.NET, the client certificate is available through the `HttpRequest.ClientCertificate` property.
 
-For other application stacks (Node.js, PHP, etc.), the client cert is available in your app through a base64-encoded value in the `X-ARR-ClientCert` request header.
+For other application stacks (Node.js, PHP), the client cert is available in your app through a base64-encoded value in the `X-ARR-ClientCert` request header.
 
 ## ASP.NET Core sample
 
@@ -387,7 +387,7 @@ export class AuthorizationHandler {
 
 ## Java sample
 
-The following Java class encodes the certificate from `X-ARR-ClientCert` to an `X509Certificate` instance. `certificateIsValid()` validates that the certificate's thumbprint matches the one given in the constructor and that certificate isn't expired.
+The following Java class encodes the certificate from `X-ARR-ClientCert` to an `X509Certificate` instance. `certificateIsValid()` validates that the certificate's thumbprint matches the one given in the constructor and that the certificate isn't expired.
 
 ```java
 import java.io.ByteArrayInputStream;

articles/app-service/configure-authentication-oauth-tokens.md

@@ -14,15 +14,16 @@ This article shows you how to work with OAuth tokens when you use the built-in [
 
 ## Retrieve tokens in app code
 
-From your server code, the provider-specific tokens are injected into the request header so that you can easily access them. The following table shows possible token header names:
+From your server code, the provider-specific tokens are injected into the request header so that you can easily access them.
+
+The following table lists possible token header names:
 
 | Provider | Header names |
 |-|-|
 | Microsoft Entra | `X-MS-TOKEN-AAD-ID-TOKEN` <br/> `X-MS-TOKEN-AAD-ACCESS-TOKEN` <br/> `X-MS-TOKEN-AAD-EXPIRES-ON`  <br/> `X-MS-TOKEN-AAD-REFRESH-TOKEN` |
 | Facebook Token | `X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN` <br/> `X-MS-TOKEN-FACEBOOK-EXPIRES-ON` |
 | Google | `X-MS-TOKEN-GOOGLE-ID-TOKEN` <br/> `X-MS-TOKEN-GOOGLE-ACCESS-TOKEN` <br/> `X-MS-TOKEN-GOOGLE-EXPIRES-ON` <br/> `X-MS-TOKEN-GOOGLE-REFRESH-TOKEN` |
 | X | `X-MS-TOKEN-TWITTER-ACCESS-TOKEN` <br/> `X-MS-TOKEN-TWITTER-ACCESS-TOKEN-SECRET` |
-|||
 
 > [!NOTE]
 > Different language frameworks might present these headers to the app code in different formats, such as in lowercase or by using title case.
@@ -58,7 +59,7 @@ When your provider's access token (not the [session token](#extend-session-token
     1. Select **Put**.
 
     > [!NOTE]
-    > The scope that gives you a refresh token is [offline_access](../active-directory/develop/v2-permissions-and-consent.md#offline_access). See how it's used in [Tutorial: Authenticate and authorize users end-to-end in Azure App Service](tutorial-auth-aad.md). The other scopes are requested by default by App Service already. For information on these default scopes, see [OpenID Connect Scopes](../active-directory/develop/v2-permissions-and-consent.md#openid-connect-scopes).
+    > The scope that gives you a refresh token is [offline_access](../active-directory/develop/v2-permissions-and-consent.md#offline_access). See how it's used in [Tutorial: Authenticate and authorize users end-to-end in Azure App Service](tutorial-auth-aad.md). The other scopes are already requested by App Service by default. For information on these default scopes, see [OpenID Connect Scopes](../active-directory/develop/v2-permissions-and-consent.md#openid-connect-scopes).
 
 After your provider is configured, you can [find the refresh token and the expiration time for the access token](#retrieve-tokens-in-app-code) in the token store.
 
@@ -90,7 +91,7 @@ az webapp auth update --resource-group <group_name> --name <app_name> --token-re
 ```
 
 > [!NOTE]
-> The grace period only applies to the App Service authenticated session, not the tokens from the identity providers. No grace period exists for expired provider tokens.
+> The grace period only applies to the App Service authenticated session, not to the tokens from the identity providers. No grace period exists for expired provider tokens.
 >
 
 ## Related content

articles/app-service/configure-authentication-user-identities.md

@@ -20,7 +20,7 @@ Some example headers are described in the following table:
 
 | Header                       | Description                                                           |
 |------------------------------|-----------------------------------------------------------------------|
-| `X-MS-CLIENT-PRINCIPAL`      | A Base64-encoded JSON representation of available claims. For more information, see [Decode the client principal header](#decode-the-client-principal-header).   |
+| `X-MS-CLIENT-PRINCIPAL`      | A base64-encoded JSON representation of available claims. For more information, see [Decode the client principal header](#decode-the-client-principal-header).   |
 | `X-MS-CLIENT-PRINCIPAL-ID`   | An identifier for the caller, which the identity provider sets.            |
 | `X-MS-CLIENT-PRINCIPAL-NAME` | A human-readable name for the caller, set by the identity provider, such as an email address or a user principal name.   |
 | `X-MS-CLIENT-PRINCIPAL-IDP`  | The name of the identity provider that App Service authentication uses. |
@@ -34,9 +34,9 @@ Code that is written in any language or framework can get the information that i
 
 ### Decode the client principal header
 
-`X-MS-CLIENT-PRINCIPAL` contains the full set of available claims as Base64-encoded JSON. These claims go through a default claims-mapping process, so some might have different names than you would see if you processed the token directly.
+`X-MS-CLIENT-PRINCIPAL` contains the full set of available claims as base64-encoded JSON. These claims go through a default claims-mapping process, so some might have different names than you would see if you processed the token directly.
 
-Here's the decoded payload is structured:
+Here's how the decoded payload is structured:
 
 ```json
 {
@@ -127,7 +127,7 @@ public static class ClaimsPrincipalParser
 
 ### Framework-specific alternatives
 
-For ASP.NET 4.6 apps, App Service populates [ClaimsPrincipal.Current](/dotnet/api/system.security.claims.claimsprincipal.current) with the authenticated user's claims, so you can follow the standard .NET code pattern, including the `[Authorize]` attribute. Similarly, for PHP apps, App Service populates the `_SERVER['REMOTE_USER']` variable. For Java apps, the claims are [accessible from the Tomcat servlet](configure-language-java-security.md#authenticate-users-easy-auth).
+For ASP.NET 4.6 apps, App Service populates [ClaimsPrincipal.Current](/dotnet/api/system.security.claims.claimsprincipal.current) with the authenticated user's claims. You can follow the standard .NET code pattern, including the `[Authorize]` attribute. Similarly, for PHP apps, App Service populates the `_SERVER['REMOTE_USER']` variable. For Java apps, the claims are [accessible from the Tomcat servlet](configure-language-java-security.md#authenticate-users-easy-auth).
 
 For [Azure Functions](../azure-functions/functions-overview.md), `ClaimsPrincipal.Current` isn't populated for .NET code, but you can still find the user claims in the request headers, or get the `ClaimsPrincipal` object from the request context or even through a binding parameter. For more information, see [Work with client identities in Azure Functions](../azure-functions/functions-bindings-http-webhook-trigger.md#working-with-client-identities).
 

articles/app-service/deploy-local-git.md

@@ -8,12 +8,12 @@ ms.custom: devx-track-azurecli, devx-track-azurepowershell
 author: cephalin
 ms.author: cephalin
 ---
-# Deploy to Azure App Service by using local Git
+# Deploy to Azure App Service by using Git locally
 
 This article shows you how to deploy your app to [Azure App Service](overview.md) from a Git repository on your local computer.
 
 > [!NOTE]
-> This deployment method requires [SCM basic authentication](configure-basic-auth-disable.md), which is less secure than [other deployment methods](deploy-authentication-types.md). When local Git deployment doesn't work, you can't configure local Git deployment in the app Deployment Center.
+> This deployment method requires [Source Control Manager (SCM) basic authentication](configure-basic-auth-disable.md), which is less secure than [other deployment methods](deploy-authentication-types.md). If local Git deployment doesn't work, you can't configure local Git deployment in the app Deployment Center.
 
 ## Prerequisites
 
@@ -37,7 +37,7 @@ Learn how to [configure deployment credentials for Azure App Service](deploy-con
 
 ## Create a Git-enabled app
 
-If you already have an App Service app and you want to configure a local Git deployment for it, see [Configure an existing app](#configure-an-existing-app) instead.
+If you already have an App Service app and you want to configure a local Git deployment for the app, see [Configure an existing app](#configure-an-existing-app) instead.
 
 # [Azure CLI](#tab/cli)
 

articles/app-service/language-support-policy.md

@@ -14,7 +14,7 @@ This article describes the language runtime support policy for updating existing
 
 ## Updates to existing stacks
 
-App Service updates existing stacks from each community after they become available. App Service updates major versions of stacks but can't guarantee any specific minor versions or patch versions. The platform controls minor and patch versions. For example, App Service updates Node 18 but doesn't guarantee a specific Node 18.x.x version. If you need a specific minor or patch version, you can use a [custom container](quickstart-custom-container.md).
+App Service updates existing stacks after they become available from each community. App Service updates major versions of stacks but can't guarantee any specific minor versions or patch versions. The platform controls minor and patch versions. For example, App Service updates Node 18 but doesn't guarantee a specific Node 18.x.x version. If you need a specific minor or patch version, use a [custom container](quickstart-custom-container.md).
 
 ## Retirements
 
@@ -127,7 +127,7 @@ Microsoft and Adoptium builds of OpenJDK are provided and supported on App Servi
 
 If you're [pinned](configure-language-java-deploy-run.md#choosing-a-java-runtime-version) to an earlier minor version of Java, your app might be using the deprecated [Azul Zulu for Azure](https://devblogs.microsoft.com/java/end-of-updates-support-and-availability-of-zulu-for-azure/) binaries that are provided through [Azul Systems](https://www.azul.com/). You can keep using these binaries for your app, but any security patches or improvements are available only in more recent versions of OpenJDK. In this scenario, we recommend that you periodically update your web apps to a more recent version of Java.
 
-Major version updates are provided through new runtime options in Azure App Service. Update to these later versions of Java by configuring your App Service deployment. You are responsible for testing and ensuring the major update meets your needs.
+Major version updates are provided through new runtime options in Azure App Service. Update to these later versions of Java by configuring your App Service deployment. You're responsible for testing and ensuring the major update meets your needs.
 
 Supported JDKs are automatically patched on a quarterly basis in January, April, July, and October of each year. For more information, see [Java on Azure](/azure/developer/java/fundamentals/java-support-on-azure).