Update ingress-controller-annotations.md

Author: ShawnJackson

articles/application-gateway/ingress-controller-annotations.md

@@ -11,7 +11,7 @@ ms.author: greglin
 
 # Annotations for Application Gateway Ingress Controller
 
-You can annotate the Kubernetes ingress resource with arbitrary key/value pairs. Application Gateway Ingress Controller (AGIC) relies on annotations to program Azure Application Gateway features that aren't configurable via the ingress YAML. Ingress annotations are applied to all HTTP settings, back-end pools, and listeners derived from an ingress resource.
+You can annotate the Kubernetes ingress resource with arbitrary key/value pairs. Application Gateway Ingress Controller (AGIC) relies on annotations to program Azure Application Gateway features that aren't configurable via the ingress YAML. Ingress annotations are applied to all HTTP settings, backend pools, and listeners derived from an ingress resource.
 
 ## List of supported annotations
 
@@ -48,7 +48,7 @@ For AGIC to observe an ingress resource, the resource *must be annotated* with `
 
 ## Backend Path Prefix
 
-The following annotation allows the back-end path specified in an ingress resource to be rewritten with the specified prefix. Use it to expose services whose endpoints are different from the endpoint names that you use to expose a service in an ingress resource.
+The following annotation allows the backend path specified in an ingress resource to be rewritten with the specified prefix. Use it to expose services whose endpoints are different from the endpoint names that you use to expose a service in an ingress resource.
 
 ### Usage
 
@@ -82,11 +82,11 @@ spec:
 
 The preceding example defines an ingress resource named `go-server-ingress-bkprefix` with an annotation named `appgw.ingress.kubernetes.io/backend-path-prefix: "/test/"`. The annotation tells Application Gateway to create an HTTP setting that has a path prefix override for the path `/hello` to `/test/`.
 
-The example defines only one rule. However, the annotations apply to the entire ingress resource. So if you define multiple rules, you set up the back-end path prefix for each of the specified paths. If you want different rules with different path prefixes (even for the same service), you need to define different ingress resources.
+The example defines only one rule. However, the annotations apply to the entire ingress resource. So if you define multiple rules, you set up the backend path prefix for each of the specified paths. If you want different rules with different path prefixes (even for the same service), you need to define different ingress resources.
 
 ## Backend Hostname
 
-Use the following annotation to specify the host name that Application Gateway should use while talking to the pods.
+Use the following annotation to specify the hostname that Application Gateway should use while talking to the pods.
 
 ### Usage
 
@@ -120,15 +120,15 @@ spec:
 
 ## Custom Health Probe
 
-You can [configure Application Gateway](./application-gateway-probe-overview.md) to send custom health probes to the backend address pool. When the following annotations are present, the Kubernetes ingress controller [creates a custom probe](./application-gateway-create-probe-portal.md) to monitor the back-end application. The controller then applies the changes to Application Gateway.
+You can [configure Application Gateway](./application-gateway-probe-overview.md) to send custom health probes to the backend address pool. When the following annotations are present, the Kubernetes ingress controller [creates a custom probe](./application-gateway-create-probe-portal.md) to monitor the backend application. The controller then applies the changes to Application Gateway.
 
-- `health-probe-hostname`: This annotation allows a custom host name on the health probe.
+- `health-probe-hostname`: This annotation allows a custom hostname on the health probe.
 - `health-probe-port`: This annotation configures a custom port for the health probe.
 - `health-probe-path`: This annotation defines a path for the health probe.
 - `health-probe-status-code`: This annotation allows the health probe to accept different HTTP status codes.
 - `health-probe-interval`: This annotation defines the interval at which the health probe runs.
 - `health-probe-timeout`: This annotation defines how long the health probe waits for a response before failing the probe.
-- `health-probe-unhealthy-threshold`: This annotation defines how many health probes must fail for the back end to be marked as unhealthy.
+- `health-probe-unhealthy-threshold`: This annotation defines how many health probes must fail for the backend to be marked as unhealthy.
 
 ### Usage
 
@@ -214,7 +214,7 @@ spec:
 Use the following annotations if you want to use connection draining:
 
 - `connection-draining`: This annotation specifies whether to enable connection draining.
-- `connection-draining-timeout`: This annotation specifies a timeout, after which Application Gateway terminates the requests to the draining back-end endpoint.
+- `connection-draining-timeout`: This annotation specifies a timeout, after which Application Gateway terminates the requests to the draining backend endpoint.
 
 ### Usage
 
@@ -354,7 +354,7 @@ spec:
 
 ## Override Frontend Port
 
-Use the following annotation to configure a front-end listener to use ports other than 80 for HTTP and 443 for HTTPS.
+Use the following annotation to configure a frontend listener to use ports other than 80 for HTTP and 443 for HTTPS.
 
 If the port is within the Application Gateway authorized range (1 to 64999), the listener is created on this specific port. If you set an invalid port or no port in the annotation, the configuration uses the default of 80 or 443.
 
@@ -432,7 +432,7 @@ spec:
 
 ## Hostname Extension
 
-You can configure Application Gateway to accept multiple host names. Use the `hostname-extension` annotation to define multiple host names, including wildcard host names. This action appends the host names onto the FQDN that's defined in the ingress `spec.rules.host` information on the front-end listener, so it's [configured as a multisite listener](./multiple-site-overview.md).
+You can configure Application Gateway to accept multiple hostnames. Use the `hostname-extension` annotation to define multiple hostnames, including wildcard hostnames. This action appends the hostnames onto the FQDN that's defined in the ingress `spec.rules.host` information on the frontend listener, so it's [configured as a multisite listener](./multiple-site-overview.md).
 
 ### Usage
 
@@ -465,7 +465,7 @@ spec:
               number: 443
 ```
 
-The preceding example configures the listener to accept traffic for the host names `hostname1.contoso.com` and `hostname2.contoso.com`.
+The preceding example configures the listener to accept traffic for the hostnames `hostname1.contoso.com` and `hostname2.contoso.com`.
 
 ## WAF Policy for Path
 
@@ -663,7 +663,7 @@ HTTP headers allow a client and server to pass additional information with a req
 
 With the URL rewrite capability, you can:
 
-- Rewrite the host name, path, and query string of the request URL.
+- Rewrite the hostname, path, and query string of the request URL.
 - Choose to rewrite the URL of all requests or only requests that match one or more of the conditions that you set. These conditions are based on the request and response properties (request header, response header, and server variables).
 - Choose to route the request based on either the original URL or the rewritten URL.