Application Gateway HTTP settings configuration

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.

Cookie-based affinity

Azure Application Gateway uses gateway-managed cookies for maintaining user sessions. When a user sends the first request to Application Gateway, it sets an affinity cookie in the response with a hash value which contains the session details, so that the subsequent requests carrying the affinity cookie are routed to the same backend server for maintaining stickiness.

This feature is useful when you want to keep a user session on the same server and when session state is saved locally on the server for a user session. If the application can't handle cookie-based affinity, you can't use this feature. To use it, make sure that the clients support cookies.

The Chromium browser v80 update brought a mandate where HTTP cookies without SameSite attribute have to be treated as SameSite=Lax. For CORS (Cross-Origin Resource Sharing) requests, if the cookie has to be sent in a third-party context, it has to use SameSite=None; Secure attributes and it should be sent over HTTPS only. Otherwise, in an HTTP only scenario, the browser doesn't send the cookies in the third-party context. The goal of this update from Chrome is to enhance security and to avoid Cross-Site Request Forgery (CSRF) attacks.

To support this change, starting February 17 2020, Application Gateway (all the SKU types) will inject another cookie called ApplicationGatewayAffinityCORS in addition to the existing ApplicationGatewayAffinity cookie. The ApplicationGatewayAffinityCORS cookie has two more attributes added to it ("SameSite=None; Secure") so that sticky sessions are maintained even for cross-origin requests.

Note that the default affinity cookie name is ApplicationGatewayAffinity and you can change it. If in your network topology, you deploy multiple application gateways in line, you must set unique cookie names for each resource. If you're using a custom affinity cookie name, an additional cookie is added with CORS as suffix. For example: CustomCookieNameCORS.

Connection draining

Connection draining helps you gracefully remove backend pool members during planned service updates. It applies to backend instances that are

• explicitly removed from the backend pool, or
• reported as unhealthy by the health probes.

You can apply this setting to all backend pool members by enabling Connection Draining in the Backend Setting. It ensures that all deregistering instances in a backend pool don't receive any new requests/connections while maintaining the existing connections until the configured timeout value. This is also true for WebSocket connections.

Configuration Type	Value
Default value when Connection Draining is not enabled in Backend Setting	30 seconds
User-defined value when Connection Draining is enabled in Backend Setting	1 to 3600 seconds

The only exception to this are requests bound for deregistering instances because of gateway-managed session affinity. These requests continue to be forwarded to the deregistering instances.

Protocol

Application Gateway supports both HTTP and HTTPS for routing requests to the backend servers. If you choose HTTP, traffic to the backend servers is unencrypted. If unencrypted communication isn't acceptable, choose HTTPS.

This setting combined with HTTPS in the listener supports end-to-end TLS. This allows you to securely transmit sensitive data encrypted to the back end. Each backend server in the backend pool that has end-to-end TLS enabled must be configured with a certificate to allow secure communication.

Port

This setting specifies the port where the backend servers listen to traffic from the application gateway. You can configure ports ranging from 1 to 65535.

Trusted root certificate

If you select HTTPS as the backend protocol, the Application Gateway requires a trusted root certificate to trust the backend pool for end-to-end SSL. By default, the Use well known CA certificate option is set to No. If you plan to use a self-signed certificate, or a certificate signed by an internal Certificate Authority, then you must provide the Application Gateway the matching public certificate used by the backend pool. This certificate must be uploaded directly to the Application Gateway in .CER format.

If you plan to use a certificate on the backend pool that is signed by a trusted public Certificate Authority, then you can set the Use well known CA certificate option to Yes and skip uploading a public certificate.

Request timeout

This setting is the number of seconds that the application gateway waits to receive a response from the backend server.

Override backend path

This setting lets you configure an optional custom forwarding path to use when the request is forwarded to the back end. Any part of the incoming path that matches the custom path in the override backend path field is copied to the forwarded path. The following table shows how this feature works:

• When the HTTP setting is attached to a basic request-routing rule:

  Original request	Override backend path	Request forwarded to back end
  /home/	/override/	/override/home/
  /home/secondhome/	/override/	/override/home/secondhome/

• When the HTTP setting is attached to a path-based request-routing rule:

  Original request	Path rule	Override backend path	Request forwarded to back end
  /pathrule/home/	/pathrule*	/override/	/override/home/
  /pathrule/home/secondhome/	/pathrule*	/override/	/override/home/secondhome/
  /home/	/pathrule*	/override/	/override/home/
  /home/secondhome/	/pathrule*	/override/	/override/home/secondhome/
  /pathrule/home/	/pathrule/home*	/override/	/override/
  /pathrule/home/secondhome/	/pathrule/home*	/override/	/override/secondhome/
  /pathrule/	/pathrule/	/override/	/override/

Use custom probe

This setting associates a custom probe with an HTTP setting. You can associate only one custom probe with an HTTP setting. If you don't explicitly associate a custom probe, the default probe is used to monitor the health of the back end. We recommend that you create a custom probe for greater control over the health monitoring of your back ends.

Configuring the host name

Application Gateway allows for the connection established to the backend to use a different hostname than the one used by the client to connect to Application Gateway. While this configuration can be useful in some cases, exercise caution when overriding the hostname such that it is different between the application gateway and the client compared to the backend target.

In production, it is recommended to keep the hostname used by the client towards the application gateway as the same hostname used by the application gateway to the backend target. This avoids potential issues with absolute URLs, redirect URLs, and host-bound cookies.

Before setting up Application Gateway that deviates from this, please review the implications of such configuration as discussed in more detail in Architecture Center: Preserve the original HTTP host name between a reverse proxy and its backend web application

There are two aspects of an HTTP setting that influence the Host HTTP header that is used by Application Gateway to connect to the backend:

• "Pick host name from backend-address"
• "Host name override"

Pick host name from backend address

This capability dynamically sets the host header in the request to the host name of the backend pool. It uses an IP address or FQDN.

This feature helps when the domain name of the back end is different from the DNS name of the application gateway, and the back end relies on a specific host header to resolve to the correct endpoint.

An example case is multi-tenant services as the back end. An app service is a multi-tenant service that uses a shared space with a single IP address. So, an app service can only be accessed through the hostnames that are configured in the custom domain settings.

By default, the custom domain name is example.chinacloudsites.cn. To access your app service by using an application gateway through a hostname that's not explicitly registered in the app service or through the application gateway's FQDN, you can override the hostname in the original request to the app service's hostname. To do this, enable the pick host name from backend address setting.

For a custom domain whose existing custom DNS name is mapped to the app service, the recommended configuration is not to enable the pick host name from backend address.

Host name override

This capability replaces the host header in the incoming request on the application gateway with the host name that you specify.

For example, if www.contoso.com is specified in the Host name setting, the original request *https://appgw.chinanorth2.chinacloudapp.cn/path1 is changed to *https://www.contoso.com/path1 when the request is forwarded to the backend server.

Next steps

• Learn about the backend pool