Fixing path-based routing in Application Gateways:

The Azure Application Gateway is a resource that can consolidate web traffic to diverse set of resources such as App Services and Function Apps. When there are multiple resources, it is possible to route the traffic independently to each resource. Typically, a custom probe is created to test these independent traffic flow to different resources. When a custom probe is created, the most frequent and sometimes frustrating error response to get is 404 not found http status code even when the direct request to the response returns a successful 200 http status code. This article explains how to configure the listener, the routing rules, the backend pool members, and the backend http setting to get a successful http response from each of the resources just like they would have given when reached directly.

One of the hard to visualize concepts is that the traffic that flows to a backend pool member through the gateway is not pass-through traffic even when TLS is configured as end-to-end. The portion of the flow between the client and the gateway and the gateway and the backend pool member are initiated differently. The clients initiate the first part, and the gateway initiates the second part even when the request body and certain parameters remain the same to keep the data propagated through the gateway to the backend pool member. Throughout this article, we will assume that this break in flow to a resource is seamless and invisible to the user and that it occurs over https to cover the more general case of targeting a resource via the gateway as if it were targeted directly. Add a certificate, self-signed or signed, to enable the client to connect over https.

The first step is configuring the listener properly. A listener listens to a specific combination of IP address and port. There can be only as many probes as there are listeners. So, we can start with one listener that listens to https traffic at the front-end public ip address of the gateway. Since each app service and function app will have a default public endpoint, it is important that the listener be configured as multi-site rather than basic. Since all app services and function have endpoints with “azurewebsites.net” suffix, the at least one hostname that the listener must listen to is “*.azurewebsites.net”.

The next step is to configure the back-end pool members. Path-based routing can route the traffic consolidated by the listener to various back-end pool members. Note that we use the word instead of redirect because while http/s redirection is possible, here we are merely assigning the traffic to go to different destinations based on the relative paths mentioned in a route that we will configure next. The prerequisite to differentiating different targets for that purpose, is to separate out multiple backend pools, preferably one for each target if they are hosted on different endpoints.

The step after that is to configure the backend setting. This setting will specify the port and it is best to pick the hostname from the backend pool. It will require a cert for the data transfer between the gateway and the backend target, so it can take a public key certificate that can be downloaded from the trusted publisher of azurewebsites.net certificates.

The step after that is to configure the route. This step will ask for the listener as well as the target. When we specify the path-based routing, every relative path will have its target and http setting. Since the http setting is specific to the port and all backend pool members in this case leverage the same https port, they can use the same backend setting while the target differ for each path based route. There will be a default case to specify as well.

With these configuration, when the probe is created to reach the listener at the root path, each flow to a  target will be independently routed. This is demonstrated as shown below.

Reference: https://gw-temp-2.booksonsoftware.com

curl -i -k -H "Host: fn-app-temp-1.azurewebsites.net" "https://gw-temp-2.booksonsoftware.com/api/HttpExample/?name=Ravi"  > root.htmlcurl -i -k -H "Host: web-app-temp-1.azurewebsites.net/web/" "https://gw-temp

-2.booksonsoftware.com/"  > root.html

C:\Users\ravib.DESKTOP-1K6OB4E>curl -i -k -H "Host: fn-app-temp-1.azurewebsites.net" "https://gw-temp-2.booksonsoftware.com/api/HttpExample/?name=Ravi"

HTTP/1.1 200 OK

Date: Tue, 04 Jul 2023 02:18:13 GMT

Content-Type: text/plain; charset=utf-8

Transfer-Encoding: chunked

Connection: keep-alive

Request-Context: appId=cid-v1:78e72797-a318-46f1-8401-29719dbd5478

 

Hello, Ravi. This HTTP triggered function executed successfully.