Azure App Services are often placed behind an Application Gateway. Routing is easier to control, your own certificates can be stored centrally and data traffic can be checked and attacks detected. However, if the App Service responds with redirects, the Application Gateway is bypassed in the subsequent call. A rewrite rule helps here.

The Problem – Redirect on App Services

In one project we use the HotChocolate GraphQL Library. The integration is easy, just install the NuGet package and add the following two lines to Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
	services.AddRazorPages();
	services.AddGraphQLServer();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
	...
	app.UseEndpoints(endpoints =>
	{
		endpoints.MapRazorPages();
		endpoints.MapGraphQL();
	});
}

Embedding also makes the Banana Cake Pop Web GUI available. This allows GraphQL requests to be made and the schema to be inspected.

The Banana Cake Pop GUI is called using the URL /graphql. This call responds with a 301 redirect to the URL /graphql/ (with a slash at the end) and contains the URL to the App Service:

The client receives the new URL in the response message under location and executes a new request with this URL.

If the App Service is placed behind an Application Gateway, the behavior is the same. The client calls the App Service via the public IP of the Application Gateway. The Application Gateway forwards the request to the App Service and gets the same 301 response with the URL of the App Service. This response is passed from the Application Gateway to the calling client (red arrow in the title picture) and the client calls the location from the response message directly (lower red arrow in the title picture), bypassing therefore the Application Gateway on the second call.

The Solution – Rewrite Location Header

The solution is to edit the response message before sending it to the client. This can be done directly in the Application Gateway using a rewrite rule.

The rewrite rule checks whether the location in the response header points to an App Service. This is done via checking whether the URL includes azurewebsites.net. The pattern to match also contains expressions in brackets. These can be reused in the action. As described in the article, they are referenced via the variabletype_headertype_header_number naming scheme. The expression in the second bracket is referenced via {http_resp_Location_2} and contains the URL after the azurewebsites.net/.

If the request is a redirect to an App Service, it will be rewritten to http://51.124.208.42/{http_resp_Location_2}. The front part is the gateway IP and the last part reused the target URL. The redirect is now carried out correctly and the Application Gateway is no longer bypassed.

This solution is also necessary if simple authentication is activated for an App Service. Because a redirect to the identity provider is also set up there.