date and acrolinx fix

Author: madsd

articles/app-service/overview-access-restrictions.md

@@ -3,7 +3,7 @@ title: App Service Access restrictions
 description: This article provides an overview of the access restriction features in App Service
 author: madsd
 ms.topic: overview
-ms.date: 03/01/2024
+ms.date: 01/03/2024
 ms.author: madsd
 ms.custom: UpdateFrequency3
 ---
@@ -14,7 +14,7 @@ Access restrictions in App Service are equivalent to a firewall allowing you to
 
 ## How it works
 
-When traffic reaches App Service, it first evaluates if the traffic originates from a private endpoint or is coming through the default endpoint. If the traffic is sent through a private endpoint, it's sent directly to the site without any restrictions. Restrictions to private endpoints are configured using network security groups.
+When traffic reaches App Service, it first evaluates if the traffic originates from a private endpoint or is coming through the default endpoint. If the traffic is sent through a private endpoint, it sends directly to the site without any restrictions. Restrictions to private endpoints are configured using network security groups.
 
 If you send traffic through the default endpoint (often a public endpoint), the traffic is first evaluated at the app access level. Here you can either enable or disable access. If you enable app access, the traffic is evaluated at the site access level. For any app, you have both the main site and the advanced tools site (also known as scm or kudu site).
 
@@ -24,7 +24,7 @@ You have the option of configuring a set of access restriction rules for each si
 
 ## App access
 
-App access allows you to configure if access is available through the default (public) endpoint. If you've never configured the setting, the default behavior is to enable access unless a private endpoint exists after which it's implicitly disabled. You have the ability to explicitly configure this behavior to either enabled or disabled even if private endpoints exist.
+App access allows you to configure if access is available through the default (public) endpoint. If the setting isn't configured, the default behavior is to enable access unless a private endpoint exists which changes the implicit behavior to disable access. You have the ability to explicitly configure this behavior to either enabled or disabled even if private endpoints exist.
 
 :::image type="content" source="media/overview-access-restrictions/app-access-portal.png" alt-text="Screenshot of app access option in Azure portal.":::
 
@@ -40,7 +40,7 @@ Site access restriction has several types of rules that you can apply:
 
 ### Unmatched rule
 
-You can configure the behavior when no rules are matched (the default action). It's a special rule that always appears as the last rule of the rules collection. If the setting has never been configured, the unmatched rule behavior is to allow all access unless one or more rules exists after which it's implicitly changed to deny all access. You can explicitly configure this behavior to either allow or deny access regardless of defined rules.
+You can configure the behavior when no rules are matched (the default action). It's a special rule that always appears as the last rule of the rules collection. If the setting isn't configured, the unmatched rule behavior depends on configured rules. If there are no rules, the unmatched rule behavior is to allow all access, but if one or more rules exists it implicitly changes to deny all access. You can explicitly configure this behavior to either allow or deny access regardless of defined rules.
 
 ### IP-based access restriction rules
 
@@ -65,7 +65,7 @@ To learn more about configuring service endpoints with your app, see [Azure App
 
 #### Any service endpoint source
 
-For testing or in specific scenarios, you may want to allow traffic from any service endpoint enabled subnet. You can do that by defining an IP-based rule with the text "AnyVnets" instead of an IP range. You can't create these rules in the portal, but you can modify an existing IP-based rule and replace the IP address with the "AnyVnets" string.
+For testing or in specific scenarios, you can allow traffic from any service endpoint enabled subnet. You can do that by defining an IP-based rule with the text "AnyVnets" instead of an IP range. You can't create these rules in the portal, but you can modify an existing IP-based rule and replace the IP address with the "AnyVnets" string.
 
 ### Access restriction rules based on service tags
 
@@ -89,16 +89,16 @@ For any rule, regardless of type, you can add http header filtering. Http header
 
 * **X-Forwarded-For**. [Standard header](https://developer.mozilla.org/docs/Web/HTTP/Headers/X-Forwarded-For) for identifying the originating IP address of a client connecting through a proxy server. Accepts valid CIDR values.
 * **X-Forwarded-Host**. [Standard header](https://developer.mozilla.org/docs/Web/HTTP/Headers/X-Forwarded-Host) for identifying the original host requested by the client. Accepts any string up to 64 characters in length.
-* **X-Azure-FDID**. [Custom header](../frontdoor/front-door-http-headers-protocol.md#from-the-front-door-to-the-backend) for identifying the reverse proxy instance. Azure Front Door sends a guid identifying the instance, but it can for third party proxies be used to identify the specific instance. Accepts any string up to 64 characters in length.
-* **X-FD-HealthProbe**. [Custom header](../frontdoor/front-door-http-headers-protocol.md#from-the-front-door-to-the-backend) for identifying the health probe of the reverse proxy. Azure Front Door sends "1" to uniquely identify a health probe request. The header can for third party proxies be used to identify health probes. Accepts any string up to 64 characters in length.
+* **X-Azure-FDID**. [Custom header](../frontdoor/front-door-http-headers-protocol.md#from-the-front-door-to-the-backend) for identifying the reverse proxy instance. Azure Front Door sends a guid identifying the instance, but it can also be used for non-Microsoft proxies to identify the specific instance. Accepts any string up to 64 characters in length.
+* **X-FD-HealthProbe**. [Custom header](../frontdoor/front-door-http-headers-protocol.md#from-the-front-door-to-the-backend) for identifying the health probe of the reverse proxy. Azure Front Door sends "1" to uniquely identify a health probe request. The header can also be used for non-Microsoft proxies to identify health probes. Accepts any string up to 64 characters in length.
 
 Some use cases for http header filtering are:
 * Restrict access to traffic from proxy servers forwarding the host name
 * Restrict access to a specific Azure Front Door instance with a service tag rule and X-Azure-FDID header restriction
 
 ## Diagnostic logging
 
-App Service provides the ability to [send various logging categories to Azure Monitor](./troubleshoot-diagnostic-logs.md#send-logs-to-azure-monitor). One of those categories is called *IPSecurity Audit logs* and represent the activities in access restrictions. All requests that match a rule (except the unmatched rule), both allow and deny, will be logged and can be used to validate configuration of access restrictions. The logging capability is also a powerful tool when troubleshooting rules configuration.
+App Service can [send various logging categories to Azure Monitor](./troubleshoot-diagnostic-logs.md#send-logs-to-azure-monitor). One of those categories is called *IPSecurity Audit logs* and represent the activities in access restrictions. All requests that match a rule (except the unmatched rule), both allow and deny, is logged and can be used to validate configuration of access restrictions. The logging capability is also a powerful tool when troubleshooting rules configuration.
 
 ## Advanced use cases
 
@@ -118,7 +118,7 @@ You might have a site that is publicly accessible, but your deployment system is
 
 ### Allow external partner access to private endpoint protected site
 
-In this scenario, you're accessing your site through a private endpoint and are deploying through a private endpoint. You may want to temporarily invite an external partner to test the site. You can do that by enabling public app access. Add a rule (IP-based) to identify the client of the partner. Configure unmatched rules action to deny for both main and advanced tools site. 
+In this scenario, you're accessing your site through a private endpoint and are deploying through a private endpoint. You can temporarily invite an external partner to test the site. You can do that by enabling public app access. Add a rule (IP-based) to identify the client of the partner. Configure unmatched rules action to deny for both main and advanced tools site. 
 
 ### Restrict access to a specific Azure Front Door instance