A fun gotcha with Azure Front Door Premium

I bumped into an interesting redirect-loop issue with a Sitecore instance sitting behind Azure Front Door recently. It's not a product I know a great deal about, so this seemed worth writing down in case I come across it again, or others bump into the same challenge. Turns out it wasn't a Sitecore-specific issue, but its definitely something which could affect other Sitecore sites...

The issue

The site in question was a Sitecore instance running in PaaS on Azure. It happened to be the UAT instance of the site, but this could equally affect production I suspect. It wasn't a site my team had built - we'd taken it on from another agency - and it had been running fine for some time. But for business reasons the client was in the process of moving from using a "standard" instance of Front Door to using a Premium instance. That involved a chunk of setup, and binding the DNS names / SSL certificates etc for this site's various endpoints to the new Front Door instance. But it didn't involve any changes to Sitecore itself.

After the change to Premium Front Door had been made for this UAT instance, trying to browse to the site in question failed. Azure said the App Service was up, The logs were showing it responding to things like health check messages with 200 OK. But when you pointed your browser at the public url of the site, the request failed with a redirect loop error in the browser.

Looking at the browser's network trace, this was odd. We were seeing something along the lines of:

sequenceDiagram
  Web Browser-->>Server: Request: GET https://www.mysite.com/
  loop Repeats until browser gives up
     Server-->>Web Browser: Response: REDIRECT TO https://www.mysite.com/
     Web Browser-->>Server: Request: GET https://www.mysite.com/
  end

					

The redirect was instructing the client to request exactly the url it originally asked for. That was definitely a reason for a loop, but an odd one...

Finding the cause

There was quite a lot of digging about, focused on "what did we change recently" initially. But the thing which gave away the underlying cause was the IIS logs. While you can get at these via FTP or the debug console in Azure, the "easiest" view is the Log Stream UI:

When I spent some time looking at these logs while the issue was happening I noticed an important thing: The requests which were succeeding were coming in with the public name of the site as the requested host. But the requests which were being redirected were coming in with the private DNS name of the App Service as the requested host.

Digging into the config of the App Service, there was a redirect for this hiding in web.config:

<rule name="Redirect from Azure Websites" stopProcessing="true">
  <match url="(.*)"/>
  <conditions>
    <add input="{HTTP_HOST}" pattern="^my-app-service-cd.azurewebsites.net$"/>
  </conditions>
  <action type="Redirect" url="https://uat-www.mysite.com/{R:1}" appendQueryString="true" redirectType="Permanent"/>
</rule>

					

It looks like that was put into the site some time back to make sure that things like the CSP always worked. If you were able to request the private URL of the site, that name would need to be included in the CSP as well, or things like JavaScript would break. This can be a Sitecore-specific thing in sites which need to be configured with absolute URLs from the LinkManager too - you can configure a single site to respond to multiple URLs, but it only generates these URLs with one configured DNS name. So I've found a few sites over the years with this sort of redirect because of this.

So thinking about this for a config while, I realised what was happening under the surface was:

sequenceDiagram
  Web Browser-->>Front Door: Request: GET https://www.mysite.com/
  loop Repeats until browser gives up
    Front Door-->>Server: Rewrite request to: GET https://my-app-service-cd.azurewebsites.net/
    Server-->>Front Door: Response: REDIRECT TO https://www.mysite.com/
    Front Door-->>Web Browser: Response: REDIRECT TO https://www.mysite.com/
    Web Browser-->>Front Door: Request: GET https://www.mysite.com/
  end

					

So the key to my problem was that Premium Front Door was rewriting requests, and in the past the Standard Front Door wasn't doing that.

Fixing the issue

My experience wasn't good enough to work out why this rewrite was happening on my own. But with some advice from helpful Azure experts at Rackspace (Thanks Andrew!), the fix turned out to be simple.

In the Premium Front Door instance you have to configure an "origin" for the sites you're providing services for. The setup for that includes a "Host name" field where you pick your app service's name, and picking a value for this sets a default value for the following field "Origin host header" to be the private name of your site too.

When both of these are set, Front Door will rewrite requests from the public name to the private name. I expect for a lot of situations this default makes sense, but here it was causing the problem. So to fix the rewriting issue, you have to manually change this "Origin host header" field to be blank:

Once you save the change to remove that value, Front Door stops doing the rewriting. And that fixed my redirect loop issue.

↑ Back to top