Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into gh32740

Author: KumudD

articles/application-gateway/application-gateway-components.md

@@ -48,7 +48,7 @@ Application Gateway supports four protocols: HTTP, HTTPS, HTTP/2, and WebSocket:
 >HTTP/2 protocol support is available to clients connecting to application gateway listeners only. The communication to backend server pools is always over HTTP/1.1. By default, HTTP/2 support is disabled. You can choose to enable it.
 
 - Specify between the HTTP and HTTPS protocols in the listener configuration.
-- Support for [WebSockets and HTTP/2 protocols](overview.md#websocket-and-http2-traffic) is provided natively, and [WebSocket support](application-gateway-websocket.md) is enabled by default. There's no user-configurable setting to selectively enable or disable WebSocket support. Use WebSockets with both HTTP and HTTPS listeners.
+- Support for [WebSockets and HTTP/2 protocols](features.md#websocket-and-http2-traffic) is provided natively, and [WebSocket support](application-gateway-websocket.md) is enabled by default. There's no user-configurable setting to selectively enable or disable WebSocket support. Use WebSockets with both HTTP and HTTPS listeners.
 
 Use an HTTPS listener for SSL termination. An HTTPS listener offloads the encryption and decryption work to your application gateway, so your web servers aren't burdened by the overhead.
 
@@ -110,9 +110,9 @@ The port and protocol used in the HTTP settings determine whether the traffic be
 
 This component is also used to:
 
-- Determine whether a user session is to be kept on the same server by using the [cookie-based session affinity](overview.md#session-affinity).
+- Determine whether a user session is to be kept on the same server by using the [cookie-based session affinity](features.md#session-affinity).
 
-- Gracefully remove backend pool members by using [connection draining](overview.md#connection-draining).
+- Gracefully remove backend pool members by using [connection draining](features.md#connection-draining).
 
 - Associate a custom probe to monitor the backend health, set the request timeout interval, override host name and path in the request, and provide one-click ease to specify settings for the App Service backend.
 

articles/application-gateway/application-gateway-faq.md

@@ -125,7 +125,7 @@ No. Instances are distributed across upgrade domains and fault domains.
 
 ### Does Application Gateway support connection draining?
 
-Yes. You can set up connection draining to change members within a backend pool without disruption. For more information, see [connection draining section of Application Gateway](overview.md#connection-draining).
+Yes. You can set up connection draining to change members within a backend pool without disruption. For more information, see [connection draining section of Application Gateway](features.md#connection-draining).
 
 ### Can I change instance size from medium to large without disruption?
 
@@ -406,7 +406,7 @@ Sample NSG configuration for private IP only access:
 ![Application Gateway V2 NSG Configuration for private IP access only](./media/application-gateway-faq/appgw-privip-nsg.png)
 
 ### Does Application Gateway affinity cookie support SameSite attribute?
-Yes, the [Chromium browser](https://www.chromium.org/Home) [v80 update](https://chromiumdash.appspot.com/schedule) introduced a mandate on HTTP cookies without SameSite attribute to be treated as SameSite=Lax. This means that the Application Gateway affinity cookie won't be sent by the browser in a third-pary context. 
+Yes, the [Chromium browser](https://www.chromium.org/Home) [v80 update](https://chromiumdash.appspot.com/schedule) introduced a mandate on HTTP cookies without SameSite attribute to be treated as SameSite=Lax. This means that the Application Gateway affinity cookie won't be sent by the browser in a third-party context. 
 To support this scenario, Application Gateway injects another cookie called *ApplicationGatewayAffinityCORS* in addition to the existing *ApplicationGatewayAffinity* cookie.  These cookies are similar, but the *ApplicationGatewayAffinityCORS* cookie has two more attributes added to it: *SameSite=None; Secure*. These attributes maintain sticky sessions even for cross-origin requests. See the [cookie based affinity section](configuration-overview.md#cookie-based-affinity) for more information.
 
 ## Next steps

articles/application-gateway/features.md

@@ -0,0 +1,162 @@
+---
+title: Azure Application Gateway features
+description: Learn about Azure Application Gateway features
+services: application-gateway
+author: vhorne
+ms.service: application-gateway
+ms.topic: conceptual
+ms.date: 03/04/2020
+ms.author: victorh
+---
+
+# Azure Application Gateway features
+
+[Azure Application Gateway](overview.md) is a web traffic load balancer that enables you to manage traffic to your web applications.
+
+![Application Gateway conceptual](media/overview/figure1-720.png)
+
+Application Gateway includes the following features:
+
+- [Secure Sockets Layer (SSL/TLS) termination](#secure-sockets-layer-ssltls-termination)
+- [Autoscaling](#autoscaling)
+- [Zone redundancy](#zone-redundancy)
+- [Static VIP](#static-vip)
+- [Web Application Firewall](#web-application-firewall)
+- [Ingress Controller for AKS](#ingress-controller-for-aks)
+- [URL-based routing](#url-based-routing)
+- [Multiple-site hosting](#multiple-site-hosting)
+- [Redirection](#redirection)
+- [Session affinity](#session-affinity)
+- [Websocket and HTTP/2 traffic](#websocket-and-http2-traffic)
+- [Connection draining](#connection-draining)
+- [Custom error pages](#custom-error-pages)
+- [Rewrite HTTP headers](#rewrite-http-headers)
+- [Sizing](#sizing)
+
+## Secure Sockets Layer (SSL/TLS) termination
+
+Application gateway supports SSL/TLS termination at the gateway, after which traffic typically flows unencrypted to the backend servers. This feature allows web servers to be unburdened from costly encryption and decryption overhead. But sometimes unencrypted communication to the servers isn't an acceptable option. This can be because of security requirements, compliance requirements, or the application may only accept a secure connection. For these applications, application gateway supports end to end SSL/TLS encryption.
+
+For more information, see [Overview of SSL termination and end to end SSL with Application Gateway](ssl-overview.md)
+
+## Autoscaling
+
+Application Gateway Standard_v2 supports autoscaling and can scale up or down based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning. 
+
+For more information about the Application Gateway Standard_v2 features, see [Autoscaling v2 SKU](application-gateway-autoscaling-zone-redundant.md).
+
+## Zone redundancy
+
+A Standard_v2 Application Gateway  can span multiple Availability Zones, offering better fault resiliency and removing the need to provision separate Application Gateways in each zone.
+
+## Static VIP
+
+The application gateway Standard_v2 SKU supports static VIP type exclusively. This ensures that the VIP associated with application gateway doesn't change even over the lifetime of the Application Gateway.
+
+## Web Application Firewall
+
+Web Application Firewall (WAF) is a service that provides centralized protection of your web applications from common exploits and vulnerabilities. WAF is based on rules from the [OWASP (Open Web Application Security Project) core rule sets](https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project) 3.1 (WAF_v2 only), 3.0, and 2.2.9. 
+
+Web applications are increasingly targets of malicious attacks that exploit common known vulnerabilities. Common among these exploits are SQL injection attacks, cross site scripting attacks to name a few. Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching and monitoring at many layers of the application topology. A centralized web application firewall helps make security management much simpler and gives better assurance to application administrators against threats or intrusions. A WAF solution can also react to a security threat faster by patching a known vulnerability at a central location versus securing each of individual web applications. Existing application gateways can be converted to a Web Application Firewall enabled application gateway easily.
+
+For more information, see [What is Azure Web Application Firewall?](../web-application-firewall/overview.md).
+
+## Ingress Controller for AKS
+Application Gateway Ingress Controller (AGIC) allows you to use Application Gateway as the ingress for an [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/services/kubernetes-service/) cluster. 
+
+The ingress controller runs as a pod within the AKS cluster and consumes [Kubernetes Ingress Resources](https://kubernetes.io/docs/concepts/services-networking/ingress/) and converts them to an Application Gateway configuration, which allows the gateway to load-balance traffic to the Kubernetes pods. The ingress controller only supports Application Gateway Standard_v2 and WAF_v2 SKUs. 
+
+For more information, see [Application Gateway Ingress Controller (AGIC)](ingress-controller-overview.md).
+
+## URL-based routing
+
+URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request. 
+One of the scenarios is to route requests for different content types to different pool.
+
+For example, requests for `http://contoso.com/video/*` are routed to VideoServerPool, and `http://contoso.com/images/*` are routed to ImageServerPool. DefaultServerPool is selected if none of the path patterns match.
+
+For more information, see [URL Path Based Routing overview](url-route-overview.md).
+
+## Multiple-site hosting
+
+Multiple-site hosting enables you to configure more than one web site on the same application gateway instance. This feature allows you to configure a more efficient topology for your deployments by adding up to 100 web sites to one Application Gateway (for optimal performance). Each web site can be directed to its own pool. For example, application gateway can serve traffic for `contoso.com` and `fabrikam.com` from two server pools called ContosoServerPool and FabrikamServerPool.
+
+Requests for `http://contoso.com` are routed to ContosoServerPool, and `http://fabrikam.com` are routed to FabrikamServerPool.
+
+Similarly, two subdomains of the same parent domain can be hosted on the same application gateway deployment. Examples of using subdomains could include `http://blog.contoso.com` and `http://app.contoso.com` hosted on a single application gateway deployment.
+
+For more information, see [Application Gateway multiple site hosting](multiple-site-overview.md).
+
+## Redirection
+
+A common scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure all communication between an application and its users occurs over an encrypted path.
+
+In the past, you may have used techniques such as dedicated pool creation whose sole purpose is to redirect requests it receives on HTTP to HTTPS. Application gateway supports the ability to redirect traffic on the Application Gateway. This simplifies application configuration, optimizes the resource usage, and supports new redirection scenarios, including global and path-based redirection. Application Gateway redirection support isn't limited to HTTP to HTTPS redirection alone. This is a generic redirection mechanism, so you can redirect from and to any port you define using rules. It also supports redirection to an external site as well.
+
+Application Gateway redirection support offers the following capabilities:
+
+- Global redirection from one port to another port on the Gateway. This enables HTTP to HTTPS redirection on a site.
+- Path-based redirection. This type of redirection enables HTTP to HTTPS redirection only on a specific site area, for example a shopping cart area denoted by `/cart/*`.
+- Redirect to an external site.
+
+For more information, see [Application Gateway redirect overview](redirect-overview.md).
+
+## Session affinity
+
+The cookie-based session affinity feature is useful when you want to keep a user session on the same server. By using gateway-managed cookies, the Application Gateway can direct subsequent traffic from a user session to the same server for processing. This is important in cases where session state is saved locally on the server for a user session.
+
+For more information, see [How an application gateway works](how-application-gateway-works.md#modifications-to-the-request).
+
+## Websocket and HTTP/2 traffic
+
+Application Gateway provides native support for the WebSocket and HTTP/2 protocols. There's no user-configurable setting to selectively enable or disable WebSocket support.
+
+The WebSocket and HTTP/2 protocols enable full duplex communication between a server and a client over a long running TCP connection. This allows for a more interactive communication between the web server and the client, which can be bidirectional without the need for polling as required in HTTP-based implementations. These protocols have low overhead, unlike HTTP, and can reuse the same TCP connection for multiple request/responses resulting in a more efficient resource utilization. These protocols are designed to work over traditional HTTP ports of 80 and 443.
+
+For more information, see [WebSocket support](application-gateway-websocket.md) and [HTTP/2 support](configuration-overview.md#http2-support).
+
+## Connection draining
+
+Connection draining helps you achieve graceful removal of backend pool members during planned service updates. This setting is enabled via the backend http setting and can be applied to all members of a backend pool during rule creation. Once enabled, Application Gateway ensures all deregistering instances of a backend pool don't receive any new request while allowing existing requests to complete within a configured time limit. This applies to both backend instances that are explicitly removed from the backend pool by a user configuration change, and backend instances that are reported as unhealthy as determined by the health probes. The only exception to this are requests bound for deregistering instances, which have been deregistered explicitly, because of gateway-managed session affinity and continues to be proxied to the deregistering instances.
+
+For more information, see [Application Gateway Configuration Overview](configuration-overview.md#connection-draining).
+
+## Custom error pages
+
+Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page.
+
+For more information, see [Custom Errors](custom-error.md).
+
+## Rewrite HTTP headers
+
+HTTP headers allow the client and server to pass additional information with the request or the response. Rewriting these HTTP headers helps you accomplish several important scenarios, such as:
+
+- Adding security-related header fields like HSTS/ X-XSS-Protection.
+- Removing response header fields that can reveal sensitive information.
+- Stripping port information from X-Forwarded-For headers.
+
+Application Gateway supports the capability to add, remove, or update HTTP request and response headers, while the request and response packets move between the client and back-end pools. It also provides you with the capability to add conditions to ensure the specified headers are rewritten only when certain conditions are met.
+
+For more information, see [Rewrite HTTP headers](rewrite-http-headers.md).
+
+## Sizing
+
+Application Gateway Standard_v2 can be configured for autoscaling or fixed size deployments. This SKU doesn't offer different instance sizes. For more information on v2 performance and pricing, see [Autoscaling v2 SKU](application-gateway-autoscaling-zone-redundant.md#pricing).
+
+The Application Gateway Standard is offered in three sizes: **Small**, **Medium**, and **Large**. Small instance sizes are intended for development and testing scenarios.
+
+For a complete list of application gateway limits, see [Application Gateway service limits](../azure-resource-manager/management/azure-subscription-service-limits.md?toc=%2fazure%2fapplication-gateway%2ftoc.json#application-gateway-limits).
+
+The following table shows an average performance throughput for each application gateway v1 instance with SSL offload enabled:
+
+| Average back-end page response size | Small | Medium | Large |
+| --- | --- | --- | --- |
+| 6 KB |7.5 Mbps |13 Mbps |50 Mbps |
+| 100 KB |35 Mbps |100 Mbps |200 Mbps |
+
+> [!NOTE]
+> These values are approximate values for an application gateway throughput. The actual throughput depends on various environment details, such as average page size, location of back-end instances, and processing time to serve a page. For exact performance numbers, you should run your own tests. These values are only provided for capacity planning guidance.
+
+## Next steps
+
+- Learn how Application Gateway works - [How an application gateway works](how-application-gateway-works.md)