I believe I have it … I’ve been meaning to put together
the ultimate outgoing rule for hosting multiple domains under one
site. I finally sat down this week and setup a few test cases, and created one rule to rule them all. In Part I of this two part series, I covered
the incoming rule necessary to host a
site in a subfolder of a website, while making it appear as if it’s in
the root of
the site. Part II won’t work without applying Part I first, so if you haven’t read it, I encourage you to read it now. However,
the incoming rule by itself doesn’t address everything. Here’s
the problem … Let’s say that we host www.site2.com in a subfolder called site2, off of masterdomain.com. This is
the same example I used in Part I. Using an incoming rewrite rule, we are able to make a request to www.site2.com even though
the site is really in
the /site2 folder.
The gotcha comes with any type of path that ASP.NET generates (I’m sure other scripting technologies could do
the same too). ASP.NET thinks that
the path to
the root of
the site is /site2, but
the URL is /. See
the issue? If ASP.NET generates a path or a redirect for us, it will always add /site2 to
the URL. That results in a path that looks something like www.site2.com/site2. In Part I, I mentioned that you should add a condition where “{PATH_INFO} ‘does not match’ /site2”. That allows www.site2.com/site2 and www.site2.com to both function
the same. This allows
the site to always work, but if you want to hide /site2 in
the URL, you need to take it one step further. One way to address this is in your code. Ultimately this is
the best bet. Ruslan Yakushev has a great article on a few considerations that you can address in code. I recommend giving that serious consideration. Additionally, if you have upgraded to ASP.NET 3.5 SP1 or greater, it takes care of some of
the references automatically for you. However, what if you inherit an existing application? Or you can’t easily go through your existing
site and make
the code changes? If this applies to you, read on. That’s where URL Rewrite 2.0 comes in. With URL Rewrite 2.0, you can create an outgoing rule that will remove
the /site2 before
the page is sent back to
the user. This means that you can take an existing application, host it in a subfolder of your
site, and ensure that
the URL never reveals that it’s in a subfolder. Performance Considerations Performance overhead is something to be mindful of. These outbound rules aren’t simply changing
the server variables.
The first rule I’ll cover below needs to parse
the HTML body and pull out
the path (i.e. /site2) on
the way through. This will add overhead, possibly significant if you have large pages and a busy
site. In other words, your mileage may vary and you may need to test to see
the impact that these rules have. Don’t worry too much though. For many sites,
the performance impact is negligible. So, how do we do it? Creating
the Outgoing Rule There are really two things to keep in mind. First, ASP.NET applications frequently generate a URL that adds
the /site2 back into
the URL. In addition to URLs, they can be in form elements, img elements and
the like.
The goal is to find all of those situations and rewrite it on
the way out. Let’s call this
the ‘URL problem’. Second, and similarly, ASP.NET can send a LOCATION redirect that causes a redirect back to another page. Again, ASP.NET isn’t aware of
the different URL and it will add
the /site2 to
the redirect. Form Authentication is a good example on when this occurs. Try to password protect a
site running from a subfolder using forms auth and you’ll quickly find that
the URL becomes www.site2.com/site2 again. Let’s term this
the ‘redirect problem’. Solving
the URL Problem – Outgoing Rule #1 Let’s create a rule that removes
the /site2 from any URL. We want to remove it from relative URLs like /site2/something, or absolute URLs like http://www.site2.com/site2/something. Most URLs that ASP.NET creates will be relative URLs, but I figure that there may be some applications that piece together a full URL, so we might as well expect that situation. Let’s get started. First, create a new outbound rule. You can create
the rule within
the /site2 folder which will reduce
the performance impact of
the rule. Just a reminder that incoming rules for this situation won’t work in a subfolder … but outgoing rules will. Give it a name that makes sense to you, for example “Outgoing – URL paths”. Precondition. If you place
the rule in
the subfolder, it will only run for that
site and folder, so there isn’t need for a precondition. Run it for all requests. If you place it in
the root of
the site, you may want to create a precondition for HTTP_HOST = ^(www\.)?site2\.com$. For
the Match section, there are a few things to consider. For performance reasons, it’s best to match
the least amount of elements that you need to accomplish
the task. For my test cases, I just needed to rewrite
the <a /> tag, but you may need to rewrite any number of HTML elements. Note that as long as you have
the exclude /site2 rule in your incoming rule as I described in Part I, some elements that don’t show their URL—like your images—will work without removing
the /site2 from them. That reduces
the processing needed for this rule. Leave
the “matching scope” at “Response” and choose
the elements that you want to change. Set
the pattern to “^(?:site2|(.*//[_a-zA-Z0-9-\.]*)?/site2)(.*)”. Make sure to replace ‘site2’ with your subfolder name in both places. Yes, I realize this is a pretty messy looking rule, but it handles a few situations. This rule will handle
the following situations correctly: Original Rewritten using {R:1}{R:2} http://www.site2.com/site2/default.aspx http://www.site2.com/default.aspx http://www.site2.com/folder1/site2/default.aspx Won’t rewrite since it’s a sub-sub folder /site2/default.aspx /default.aspx site2/default.aspx /default.aspx /folder1/site2/default.aspx Won’t rewrite since it’s a sub-sub folder. For
the conditions section, you can leave that be. Finally, for
the rule, set
the Action Type to “Rewrite” and set
the Value to “{R:1}{R:2}”.
The {R:1} and {R:2} are back references to
the sections within parentheses. In other words, in http://domain.com/site2/something, {R:1} will be http://domain.com and {R:2} will be /something. If you view your rule from your web.config file (or applicationHost.config if it’s a global rule), it should look like this: <rule name="Outgoing - URL paths" enabled="true">
<match filterByTags="A" pattern="^(?:site2|(.*//[_a-zA-Z0-9-\.]*)?/site2)(.*)" />
<action type="Rewrite" value="{R:1}{R:2}" />
</rule>
Solving
the Redirect Problem
Outgoing Rule #2
The second issue that we can run into is with a client-side redirect. This is triggered by a LOCATION response header that is sent to
the client. Forms authentication is a common example. To reproduce this, password protect your subfolder and watch how it redirects and adds
the subfolder path back in.
Notice in my test case
the extra paths:
http://site2.com/site2/login.aspx?ReturnUrl=%2fsite2%2fdefault.aspx
I want to remove /site2 from both
the URL and
the ReturnUrl querystring value. For semi-readability, let’s do this in 2 separate rules, one for
the URL and one for
the querystring.
Create a second rule. As with
the previous rule, it can be created in
the /site2 subfolder. In
the URL Rewrite wizard, select Outbound rules –> “Blank Rule”.
Fill in
the following information:
Name
response_location URL
Precondition
Don’t set
Match: Matching Scope
Server Variable
Match: Variable Name
RESPONSE_LOCATION
Match: Pattern
^(?:site2|(.*//[_a-zA-Z0-9-\.]*)?/site2)(.*)
Conditions
Don’t set
Action Type
Rewrite
Action Properties
{R:1}{R:2}
It should end up like so:
<rule name="response_location URL">
<match serverVariable="RESPONSE_LOCATION" pattern="^(?:site2|(.*//[_a-zA-Z0-9-\.]*)?/site2)(.*)" />
<action type="Rewrite" value="{R:1}{R:2}" />
</rule>
Outgoing Rule #3
Outgoing Rule #2 only takes care of
the URL path, and not
the querystring path. Let’s create one final rule to take care of
the path in
the querystring to ensure that ReturnUrl=%2fsite2%2fdefault.aspx gets rewritten to ReturnUrl=%2fdefault.aspx.
The %2f is
the HTML encoding for forward slash (/).
Create a rule like
the previous one, but with
the following settings:
Name
response_location querystring
Precondition
Don’t set
Match: Matching Scope
Server Variable
Match: Variable Name
RESPONSE_LOCATION
Match: Pattern
(.*)%2fsite2(.*)
Conditions
Don’t set
Action Type
Rewrite
Action Properties
{R:1}{R:2}
The config should look like this:
<rule name="response_location querystring">
<match serverVariable="RESPONSE_LOCATION" pattern="(.*)%2fsite2(.*)" />
<action type="Rewrite" value="{R:1}{R:2}" />
</rule>
It’s possible to squeeze
the last two rules into one, but it gets kind of confusing so I felt that it’s better to show it as two separate rules.
Summary
With
the rules covered in these two parts, we’re able to have a
site in a subfolder and make it appear as if it’s in
the root of
the site. Not only that, we can overcome automatic redirecting that is caused by ASP.NET, other scripting technologies, and especially existing applications.
Following is an example of
the incoming and outgoing rules necessary for a
site called www.site2.com hosted in a subfolder called /site2. Remember that
the outgoing rules can be placed in
the /site2 folder instead of
the in
the root of
the site.
<rewrite>
<rules>
<rule name="site2.com in a subfolder" enabled="true" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<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>
<outboundRules>
<rule name="Outgoing - URL paths" enabled="true">
<match filterByTags="A" pattern="^(?:site2|(.*//[_a-zA-Z0-9-\.]*)?/site2)(.*)" />
<action type="Rewrite" value="{R:1}{R:2}" />
</rule>
<rule name="response_location URL">
<match serverVariable="RESPONSE_LOCATION" pattern="^(?:site2|(.*//[_a-zA-Z0-9-\.]*)?/site2)(.*)" />
<action type="Rewrite" value="{R:1}{R:2}" />
</rule>
<rule name="response_location querystring">
<match serverVariable="RESPONSE_LOCATION" pattern="(.*)%2fsite2(.*)" />
<action type="Rewrite" value="{R:1}{R:2}" />
</rule>
</outboundRules>
</rewrite>
If you run into any situations that aren’t caught by these rules, please let me know so I can update this to be as complete as possible.
Happy URL Rewriting!
