Remember the routing if you want to reverse-proxy on a Sitecore site

Ever been asked to set up a Reverse Proxy to allow a particular URL on your website to fetch its content from a site somewhere else? It’s not an uncommon requirement, but it seems to cause some configuration challenges too. Having been drafted in to solve some issues with just such a setup recently, here’s a quick description of the stuff I need to remember next time I get this job:

Dependencies

To rewrite requests generally, you need to have installed the “URL Rewrite” module for IIS. (Which you can get from the Web Platform Installer pretty easily) But to enable a reverse-proxy rule in IIS, it will tell you that you need to have the Application Request Routing extensions installed. You can add that via WPI too, or it can be downloaded from: https://www.iis.net/downloads/microsoft/application-request-routing and installed as a standard MSI package.

The rewrite rule

Next up, you need to make sure that IIS is configured to do your rewriting for you. While there is a “reverse proxy” rule template, it doesn’t actually add that much, so you can start from a blank rule if you prefer:

The key fields you need to configure are:

• Pattern This is the incoming URL that you want to match and re-write. The default is for your matching pattern to be a regular expression, so you can use groups to split it up into the parts you need. By default you get “(.*)” which just matches anything. Chances are you have some sort of base url you need to match for this sort of reverse proxy – so you might have a rule like “the-url-you-want-to-reverse-proxy/(.*)” to match your prefix, and squirrel away everything else for use later. (Also, note that this process matches just the URL’s path by default – you don’t need to account for domain names)
• Rewrite URL This is the expression that describes what you want the incomming URL rewritten to. It takes whatever static data you provide, and can mix it with captured groups from the Pattern above and other data to get the resulting URL. And if that URL isn’t hosted by this server, it can fetch it externally. Commonly you end up with a pattern that looks like “https://MyOtherDomain.com/SomePath/{R:1}” to take whatever was left at the end of your Pattern and put add it to your rewritten domain.

But if you have more complex rewriting requirements, your rules will look more complex too. If you do, you’ll likely end up filling in extra conditions in the details of your rule:

Don’t forget to make Sitecore play nice!

A key thing that gets forgotten here is that you need to make sure Sitecore doesn’t attempt to handle the URL you want to be reverse-proxied. If it does get involved, then you’re going to end up with Sitecore’s 404 page, because whatever the path you’re trying to rewrite with your proxy url, it’s almost certainly not going to map to a valid Sitecore content item that can be rendered…

There are two ways you can go about this. First, you can write some code to customise routing, and explicitly tell the routing engine to ignore the path(s) you want to reverse-proxy for. Depending on the version of Sitecore, you might add some routing config to the initialise pipeline to do this:

public static void RegisterRoutes(RouteCollection routes)
{
  routes.IgnoreRoute("some-reverse-proxied-path/{*pathInfo}");
}

(See documentation for details)

Or alternatively you can patch Sitecore’s pre-existing setting for what URLs it should ignore. While this isn’t one of the easiest settings to patch (Because by default it’s just a big string – though there are approaches you can use to make this easier if you want), it is probably the quickest way to make Sitecore ignore a url, and doesn’t involve deploying code:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
      <setting name="IgnoreUrlPrefixes" value="/the-url-you-want-to-reverse-proxy|/sitecore/default.aspx|/trace.axd|/webresource.axd|/sitecore/shell/Controls/Rich Text Editor/Telerik.Web.UI.DialogHandler.aspx|/sitecore/shell/applications/content manager/telerik.web.ui.dialoghandler.aspx|/sitecore/shell/Controls/Rich Text Editor/Telerik.Web.UI.SpellCheckHandler.axd|/Telerik.Web.UI.WebResource.axd|/sitecore/admin/upgrade/|/layouts/testing|/sitecore/service/xdb/disabled.aspx" />
    </settings>
  </sitecore>
</configuration>

OTB it’s just a pipe-separated list of URL prefixes, without domain names – so you can just stick your required URL onto the beginning…

And once you’ve sorted those three settings you should find that your reverse-proxy urls start to work.