Dealing with Azure’s Application Gateway when your app depends on the Host header

This post assumes you know what Application Gateway is and what its used for. If not, go here: https://azure.microsoft.com/en-us/services/application-gateway/.

We recently ran into an issue with this tool when attempting to deploy a Sitefinity site using Multisite. Multisite allows you to have a single Sitefinity instance (one App Service in Azure) which dynamically loads up different content based on the host name (or sub directory, if you with). Unfortunately, if you are using Application Gateway to its full benefit, then your host name will not be what you expect… For example, let’s assume you have this setup:

mysite.azurewebsites.net (default Azure url)
www.sitea.com (default site for Multisite)
www.siteb.com (additional site for Multisite)
www.sitec.com (additional site for Multisite)

You wouldn’t route the *.azurewebsites.net host name through the gateway. But the other hosts above would be. If you made a request to www.siteb.com, here is how that request is received once it reaches the Sitefinity application:

Host: mysite.azurewebsites.net
X-Original-Host: www.siteb.com

Azure’s Application Gateway took the original host header and dropped it into an X-Original-Host header. And the new Host header is set to the default App Service host name. Unfortunately, this breaks Sitefinity’s Multisite tool because it is unable to determine the site to load up – because the information for determining that is now in a different header. In this case, Sitefinity would attempt to load up the default site (www.sitea.com). This is because mysite.azurewebsites.net is the Host record, which still routes to our App Service. But it isn’t defined in Multisite, so Sitefinity attempts to load the configured default site.

This issue is not specific to Sitefinity. It will affect any application that depends on the Host header for different things in the application. I’ve slapped together a extension for Azure App Services which handles two things:

  1. Unlock the Host and X-Original-Host headers so that you can use rewrites on them. By default, Azure blocks these.
  2. Rewrite the Host header with the value from the X-Original-Host header. We do this for only the App Service we’ve installed the extension to.

Sources:
https://blog.frankfu.com.au/2018/11/13/correcting-host-headers-with-azure-websites-when-using-it-behind-an-application-gateway-or-reverse-proxy/
https://github.com/projectkudu/kudu/wiki/Azure-Site-Extensions#understanding-what-could-go-wrong-with-xdt-transforms

You can access the source code for this extension here:
https://github.com/avisra/AppGatewayHostRewrite

This has not been heavily tested. If you notice issues, please let me know, or submit a pull request to git repo 🙂

The extension itself is available on Nuget and is published to Azure kudu extension gallery (https://www.nuget.org/packages/AppGatewayHostRewrite). This is accessible from your App Service’s SCM site under “Site Extensions”

Big thanks go out to Frank Fu for doing most of the hard work.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.