Merge pull request #302477 from reyjordi/config-overview

Azure Doc-a-thon

Author: prmerger-automator[bot]

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
 

articles/application-gateway/ssl-overview.md

@@ -61,7 +61,7 @@ You may not want unencrypted communication to the backend servers. You may have
 
 End-to-end TLS allows you to encrypt and securely transmit sensitive data to the backend while you use Application Gateway's Layer-7 load-balancing features. These features include cookie-based session affinity, URL-based routing, support for routing based on sites, the ability to rewrite or inject X-Forwarded-* headers, and so on.
 
-When configured with end-to-end TLS communication mode, Application Gateway terminates the TLS sessions at the gateway and decrypts user traffic. It then applies the configured rules to select an appropriate backend pool instance to route traffic to. Application Gateway then initiates a new TLS connection to the backend server and re-encrypts data using the backend server's public key certificate before transmitting the request to the backend. Any response from the web server goes through the same process back to the end user. End-to-end TLS is enabled by setting protocol setting in [Backend HTTP Setting](./configuration-overview.md#http-settings) to HTTPS, which is then applied to a backend pool.
+When configured with end-to-end TLS communication mode, Application Gateway terminates the TLS sessions at the gateway and decrypts user traffic. It then applies the configured rules to select an appropriate backend pool instance to route traffic to. Application Gateway then initiates a new TLS connection to the backend server and re-encrypts data using the backend server's public key certificate before transmitting the request to the backend. Any response from the web server goes through the same process back to the end user. End-to-end TLS is enabled by setting protocol setting in [Backend HTTP Setting](./configuration-overview.md#backend-settings) to HTTPS, which is then applied to a backend pool.
 
 In Application Gateway v1 SKU gateways, [TLS policy](./application-gateway-ssl-policy-overview.md) applies the TLS version only to frontend traffic and the defined ciphers to both frontend and backend targets.  In Application Gateway v2 SKU gateways, TLS policy only applies to frontend traffic, backend TLS connections will always be negotiated via TLS 1.0 to TLS 1.2 versions.