Posterous theme by Cory Watilo

Domain URL redirection, mojoPortal default site handling, URL rewriting and ASP.NET 4 extensionless URLs

Check out this website I found at vanadiumtech.com

Hold on, this one's twisty.

One of my managers recently informed me that when you go to our website with "sitename.com", you were redirected to "support.sitename.com", not "www.sitename.com". This wasn't the desired behavior.

I thought I could solve this using mojoPortals "Preferred Site Name" feature. The preferred site name tells the server to redirect to another URL, one which contains the full site name, when a request comes in without a hostname tacked on the domain, as above. Sounds perfect, right?

Well, not quite. First of all, kiddies, don't mess with this setting unless you know what you are doing. Unfortunately for me, I frequently think I know what I'm doing when I, in fact, do not. Twice I locked myself out of my support site by forcing it to redirect me elsewhere. There's a way to fix this mistake by logging onto the server and using SQL Management Studio to find the right field in the database and erase it. You can find the field in the mojoPortal docs, I believe thanks to me reporting it to them after the first time I messed it up.

So what happens when you use the setting? Well, if you have my setup, nothing. See, first you go into the admin interface. This has to be done on the default site in order for you to see the preferred hostname setting. So first you go to the default site, support.sitename.com in my case, and then login to the admin interface.

Now here's the rub. If I set the preferred hostname to "www.sitename.com" on the default site, I lock myself out. Why? Because now when I go either to "sitename.com" *or* "support.sitename.com", I get redirected to "www.sitename.com". Which is the desired behavior for "sitename.com" but *not* for "support.sitename.com", which you can no longer reach at all and, by the way, is *not* the default site and therefore cannot undo the setting. Why? Because you can only access that setting when you're logged into the admin interface on the *default* site.

SQL Management Studio to the rescue. Fortunately the fix takes effect immediately and doesn't require any restarting of services.

Scratch head. Maybe it'll work if I set it on the other site, the non-default one? So I try this, and nothing. Of course, if you visit the other site "www.sitename.com", there's no need to use the preferred hostname because you're already at it. If that site had another name, then this might be useful, but it doesn't in our case. Why doesn't it do anything for the "sitename.com" case? Well, that's because the preferred hostname is on the non-default site, which never sees that request. mojoPortal *always* routes the non-specific domain request to the default site. The only way to change that particular host request is to use the preferred site name on the site that handles the request, which is the default site. As we've seen, that's impossible here.

More head scratching. Clearly I'm going to have to turn to another feature or technology to get me out of this.

I didn't really consider trying to put a manual redirect into mojoPortal's redirect handler (had enough of it's model) and IIS 6 itself can only do redirects on urls that exist as files in the filesystem. No dice.

However, I was already using another tool that is more powerful and could handle arbitrary redirects: URL rewriting via IIRF 2.1.

I had IIRF already installed on the server to handle reverse proxying to a web application server. I just needed to allow the same install to work for my mojoPortal site and to write the rules for it.

I was able to succeed with this approach, but it took a bit of wrangling. The first problem was that IIRF is an ISAPI filter, and for some reason it didn't want to load on the mojoPortal site in IIS manager. This may have been an issue with some of my security software, so I turned the security off and also ended up approaching things a little bit differently, so I'm not sure which it was that solved it.

Instead of installing IIRF as a filter on the mojoPortal site, I installed it once for all of the sites at the top level, removing it from the web application site. This worked fine for the web application site when I restarted IIS, but wasn't working for mojoPortal.

I first made a basic iirf.ini for the mojoPortal site that just enabled IIRF and logging and nothing else. I was checking the iirfstatus url to get a report from the module, which worked on the web app but not mojo. What gives.

Then I remembered. The web app is on an older ASP.NET worker group because ASP.NET 4 (for mojo) was messing with its URLs. ASP.NET 4 magically mangles any extensionless URL (basically anything not ending in ".aspx" or ".html", although that's simplifying). The same was happening with the iirfstatus url, so IIRF was never seeing the request.

The article linked above talks about that in more detail and offers a couple different solutions, one by disabling extensionless URL handling (something I had been trying to avoid so I might use it in the future) and another by doing some crazy rewriting. Valuing my sanity, I chose to disable extensionless URLs through the DWORD: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0\EnableExtensionlessUrls = 0

Once I did that and restarted IIS, I could get to the status page and see IIRF was working on the mojoPortal site. I used the rewrite rules from the article mentioned above and it worked like a charm after that.

Whew!