The previous article covered a few errors and resolutions encountered when deploying the Azure Application Gateway. This includes a few more.

First, the redirected path in the redirect configuration is routinely suffixed with a “/” character but this is incorrect when the settings in the same configuration have directives to include the path and the query parameters of the incoming request. With the occurrence of more than one path separators, the url runs the risk of not resolving correctly. Although, this seems trivial, the IaC looks normal with the trailing path separator in the redirect url and often escapes attention until the deployment occurs in the production environment.

Second, the listener must be setup as basic and not multi-site if the backend pool members are not multi-tenant. No matter how many pool members are added this holds true and this is reflected in the hostnames attribute of the listener in the IaC as well. There does not need to be any mention of hostnames because that attribute often marks the listener to be multi-site when the intent might have been to just list the DNS names.

Third, the basic http settings of the application gateway might require the path to be overridden for individual backend targets of the path-based routing. Typically, this value is “/”, the trailing path separator, and it is required to get a non 404 responses from the backend target. But one of the errors cited in the previous article suggests the contrary for its resolution. This calls for creating two http settings with one having the path override and another without so that the application gateway can deploy the default as the one without the path override and individual path-based routing backend targets to utilize the path-based override.

It is important to note that the override works differently depending on the path rule and the override pattern. For example, if the path rule is /fn/* then an override pattern of “/” is required. On the other hand if the path rule is /fn*, then an override pattern of “/” should be avoided unless there is a substitution for “fn” in the path.

Fourth, the rewrite configuration section of the IaC for an application gateway could include a condition-action statement but if care is not taken to exclude unnecessary attributes, it results in an unintended action statement aside from the condition-action statement. This misconfiguration can be caught by reviewing the plan and deploying with just what is needed for the condition-action statement in which case the application gateway will deploy and behave correctly. Common unintended side-effects involve rerouting after the rewrite so that it enters the route evaluation again.

Lastly, the redirects are client facing and rewrites can be backend facing so they must be used appropriately.