...

• All instances of Application Gateway probe the backend independent of each other.

• The same probe configuration applies to each Application Gateway instance.

• If there are multiple listeners, then each listener probes the backend independent of each other.

• Custom probes give you more granular control over the health monitoring.

  • When using custom probes, you can configure a custom hostname, URL path, probe interval, and how many failed responses to accept before marking the back-end pool instance as unhealthy

• By default, an HTTP(S) response with status code between 200 and 399 is considered healthy.

• Custom health probes additionally support two matching criteria.

  • HTTP response status code match - Probe matching criterion for accepting user specified http response code or response code ranges.

    • Individual comma-separated response status codes or a range of status code is supported.

  • HTTP response body match - Probe matching criterion that looks at HTTP response body and matches with a user specified string.

    • The match only looks for presence of user specified string in response body and isn't a full regular expression match.

  • Match criteria can be specified using the New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.

    
    

...

Configure 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 a listener, you must enter values that match the corresponding values in the incoming request on the gateway.

• After you create the application gateway, you can edit the settings of that default listener (appGatewayHttpListener) or create new listeners.

  • Basic: All requests for any domain will be accepted and forwarded to backend pools.

  • Multi-site: Forward requests to different backend pools based on the host header or host names.

    • You must specify a host name that matches with the incoming request.

    • This is because Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port.

• For the v2 SKU, multi-site listeners are processed before basic listeners.

• Choose the front-end IP address that you plan to associate with this listener

• Choose the front-end port.

• HTTPS: enables TLS termination or end-to-end TLS encryption.

  • The TLS connection terminates at the application gateway.

  • Traffic between the client and the application gateway is encrypted.

  • If you want end-to-end TLS encryption, you must choose HTTPS and configure the back-end HTTP setting.

    • This ensures that traffic is re-encrypted when it travels from the application gateway to the back end.

• To configure TLS termination and end-to-end TLS encryption, you must add a certificate to the listener to enable the application gateway to derive a symmetric key.

  • This is dictated by the TLS protocol specification.

  • The symmetric key is used to encrypt and decrypt the traffic that's sent to the gateway.

  • The gateway certificate must be in Personal Information Exchange (PFX) format.

    • This format lets you export the private key that the gateway uses to encrypt and decrypt traffic.

...

Redirection overview

• You can use application gateway to redirect traffic.

• It has a generic redirection mechanism which allows for redirecting traffic received at one listener to another listener or to an external site.

• A common redirection scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure all communication between application and its users occurs over an encrypted path.

• The following types of redirection are supported:

  • 301 Permanent Redirect

  • 302 Found

  • 303 See Other

  • 307 Temporary Redirect
    

• see URL path-based redirection using PowerShell - Azure Application Gateway | Microsoft Docs.

...

Application Gateway request routing rules

• When you create an application gateway using the Azure portal, you create a default rule (rule1).

  • This rule binds the default listener (appGatewayHttpListener) with the default back-end pool (appGatewayBackendPool) and the default back-end HTTP settings (appGatewayBackendHttpSettings).

• For a basic rule, only one back-end pool is allowed.

  • All requests on the associated listener are forwarded to that back-end pool.

• For a path-based rule, add multiple back-end pools that correspond to each URL path.

  • The requests that match the URL path that's entered are forwarded to the corresponding back-end pool.

• Add a back-end HTTP setting for each rule.

  • Requests are routed from the application gateway to the back-end targets by using the port number, protocol, and other information that's specified in this setting.

...

Rewrite HTTP headers and URL

• By using rewrite rules, you can add, remove, or update HTTP(S) request and response headers as well as URL path and query string parameters as the request and response packets move between the client and backend pools via the application gateway.

• The headers and URL parameters can be set to static values or to other headers and server variables.

• HTTP header and URL rewrite features are only available for the Application Gateway v2 SKU.

• By rewriting these headers, you can accomplish important tasks, such as adding security-related header fields like HSTS/ X-XSS-Protection, removing response header fields that might reveal sensitive information, and removing port information from X-Forwarded-For headers.

• Rewrite the host name, path, and query string of the request URL

Image Added

The value of a URL or a new or existing header can be set to these types of values:

• Text

• Request header. To specify a request header, you need to use the syntax {http_req_headerName}

• Response header. To specify a response header, you need to use the syntax {http_resp_headerName}

• Server variable. To specify a server variable, you need to use the syntax {var_serverVariable}. See the list of supported server variables

...

UrlPathMap configuration element

• UrlPathMap configuration element

"urlPathMaps": [{

 "name": "{urlpathMapName}",

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMapName}",

 "properties": {

 "defaultBackendAddressPool": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName1}"

 },

 "defaultBackendHttpSettings": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpSettingsList/{settingname1}"

 },

 "pathRules": [{

 "name": "{pathRuleName}",

 "properties": {

 "paths": [

 "{pathPattern}"

 ],

 "backendAddressPool": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName2}"

 },

 "backendHttpsettings": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpsettingsList/{settingName2}"

 }

 }

 }]

 }

}]

• PathPattern is a list of path patterns to match. Each must start with / and the only place a "*" is allowed is at the end following a "/."