IIS URL Rewrite – Hosting multiple domains under one site

In a shared hosting environment, it's a common desire to have a single IIS website that handles multiple sites with different domain names.  This saves the cost of setting up additional sites with the hoster. 

At ORCS Web, we've supported this situation for many years using ISAPI Rewrite.  Now, with URL Rewrite for IIS 7, it's easier and it's integrated right into web.config.  In this blog post I'll set out to cover the essentials for hosting multiple domain names under a single account using URL Rewrite.

This post assumes that you are using URL Rewrite 1.0, 1.1 or 2.0.  I'll follow-up in a later post on more advanced ways to take this further yet, using the new features of URL Rewrite 2.0.

Part II will cover the outgoing rules available in URL Rewrite 2.0 to take this a step further.

First, the file structure

Let's lay out the directory structure for this example.  Assume that you have 3 domain names.  They are: masterdomain.com, site2.com and hawaiivisit.site2.com.  You've created your directory structure like this:

Let's assume that masterdomain.com was already in the root of the site and can't easily be moved.  However, site2.com and hawaiivisit.site.com need to be set up.  Each of these folders have a website within them.

Directing the domain name to the server

First, make sure that when you browse to the website by domain name, that it resolves to the correct IP address.  This is handled at the DNS level.  Your DNS entry for site2.com and hawaiivisit.site2.com will often be identical to masterdomain.com and are managed through your DNS provider.

Catching the site when on the server

If you host with a web hosting company then they will take care of this.  If you host yourself, make sure to set a site binding so that the expected site processes the domain name.  If you use host headers, be sure to add the extra bindings for them.

Redirecting the site to a subfolder

Now that you have the domain name directed to the server and site, URL Rewrite comes in to direct it to a subfolder.

First, make sure that your web host supports URL Rewrite on the server that you're hosted on.  The following assumes that it's installed and supported.

You can use IIS 7 Manager which gives a friendly interface for creating rules.  If you prefer to write them directly in web.config, I'll include the rules below.

First, open up URL Rewrite:

I've come to prefer RegEx rules instead of wildcard rules.  I find that wildcard rules reach their limit pretty quickly.  Regular expressions can be daunting at first but it's pretty easy to pick up the basics.  Here's an excellent reference to get started: http://www.regular-expressions.info/reference.html

To create the rule click on "Add Rules…".

Select the "Blank Rule" template and click OK.

For the name, enter your domain name, or whatever makes the most sense to you.

Match URL section

In the Match URL Section, leave the defaults to match the pattern and Regular Expressions.  For the pattern, enter (.*) without the parentheses.  The "URL" is the part after the domain name.  i.e. www.ThisIsTheDomain.com/ThisIsTheURL.  It's the domain that we're interested in now, not the URL.

Conditions

The Conditions section is where we'll do most of the work.  Expand that section if it's collapsed and click "Add". 

The domain name is contained within the HTTP header called {HTTP_HOST}.  Here's where the fun comes.  The regular expression pattern that will match www.site2.com or site2.com (without the www) looks like this: ^(www.)?site2.com$. 

Here's what that means. 

• The ^ is the character that signifies the start of the string.  That ensures that something.www.site2.com doesn't also get included with this rule.
  
• The $ is the character that marks the end of the string.
  
• ( ) parentheses are used to create section groups. 
  
• ? means that something is optional.
  
• Therefore, (www.)? means that with www. or without, either are accepted.

After filling in these fields you should have something like the following:

Now, here's the part that many people wouldn't guess at first.  Since URL Rewrite works on the URL only, while most code (ASP.NET, ASP, PHP, etc) works at the server level, they aren't aware of each other.  Just because you rewrite the URL doesn't mean that the code has any clue of the change.  As a result, any time that ASP.NET automatically creates the path, it will likely clash with the URL Rewrite rule.  For example, Response.Redirect("~/") will redirect to the root of the application.  That means that it can create a path like www.site2.com/site2.  Notice the extra site2 in the path.  The login page for ASP.NET will mess with you too.

A future blog post will cover how to hide the /site2 using URL Rewrite 2.0, but the easy solution is to ensure that www.site2.com and www.site2.com/site2 both go to the same place.  Both should be served from …\masterdomain.com\site2.  It means that the URL can be longer than you may prefer, but it allows the site to continue to function.

To achieve this, add an exclusion condition so that this rule doesn't redirect at all if the URL starts with /site2/.

There are 2 ways to achieve this.  You could go back to the URL section where we previously entered .* and update that section.  There isn't anything wrong with that at all.  For no particular reason that I can think of right now, I prefer to do this from the conditions section.  Here's how to do it:

Add another condition where the condition input is {PATH_INFO}, and set the dropdown to "Does Not Match the Pattern", and set the Pattern to ^/site2/.  That means that the PATH_INFO must start with /site2/.  Note that you shouldn't end with the $ this time because you want sub-sub folders to work too.  It should look like this:

Action Section

We're nearly done.  In the Action section, first set the "Action Type" to Rewrite.  Then set the Rewrite URL to \site2\{R:0} and ensure that the "Append query string" checkbox is checked.  The {R:0} is a back reference to the URL.  It will allow the URL to be carried through dynamically in the request.  The Append query string ensures that the query string itself will carry through.

The complete rule should look like this:

That's it.  Save and test.

Using a Text Editor

You may prefer to use a text editor or to see the config directly.  The rule generated for web.config looks like this:

<rewrite>

    <rules>

        <rule name="site2.com" stopProcessing="true">

            <match url=".*" />

            <conditions>

                <add input="{HTTP_HOST}" pattern="^(www.)?site2.com" />

                <add input="{PATH_INFO}" pattern="^/site2/" negate="true" />

            </conditions>

            <action type="Rewrite" url="\site2\{R:0}" />

        </rule>

    </rules>

</rewrite>

And, the rule for hawaiivisit.site2.com is similar.  It looks like this:

<rewrite>

    <rules>

        <rule name="hawaiivisit.site2.com" stopProcessing="true">

            <match url=".*" />

            <conditions>

                <add input="{HTTP_HOST}" pattern="^hawaiivisit.site2.com$" />

                <add input="{PATH_INFO}" pattern="^/hawaiivisit/" negate="true" />

            </conditions>

            <action type="Rewrite" url="\hawaiivisit\{R:0}" />

        </rule>

    </rules>

</rewrite>

The other things

I wanted to briefly mention what isn't covered in this blog post that you may want to consider. 

• DNS. The 'how to' for your domain name purchase and directing isn't covered here.
  
• Statistics. If you use  a client-side option like Google Analytics then this will work just as well under a single account.  However, if you are using a log based statistics program like SmarterStats then it's up to you to set rules in SmarterStats to filter out or sub-divide the statistics into useful sections i.e. 1 per site.
  
• Email. You will likely need to setup another mail account with your host, or add the new domain as a domain alias to your existing account.
  
• ASP.NET inheritance. web.config inherits down the entire path but the ASP.NET folders do not inherit past application boundaries.  More on that here.  One workaround if ASP.NET inheritance fights with you is to not have a site in the website root.  Instead, place all sites in their own subfolder.
  
• You'll likely need to mark the folder as an application so that it is an ASP.NET application.  (assuming ASP.NET of course)