UrlRewritingNet default redirects

We were using UrlRewritingNet on one our site that hosts marketing landing pages. Our marketing URLs are in the format "http://mydomain/campaign/123456" where the "123456" is a PIN associated with a particular user. Since we can't create a seperate landing page for each user, we setup a redirect rule like this:

With the above rule in place, any page with a PIN at the end of the URL will be rewritten as http://mydomain/campaign/default.aspx?PIN= . So one page can handle an entire campaign without the need to create a seperate page for each user. This worked very well and we were doing multiple campaigns successfully.

Note here that the campaign URLs do not have a file extension and so we had setup IIS to send all web requests to ASP.Net as detailed in the URLRewritingNet documentation. Since IIS was sending all web requests to ASP.Net, we have to set up the defaultPage property in the URLRewritingNet configuration to "default.aspx".

One issue we faced here is that we couldn't access the home page of the web site. When we try http://mydomain/ our request would time out after a long wait. But if we type http://mydomain/default.aspx it renders just fine. This happens only on our QA and PROD web sites. Our DEV site with the same setting worked without a glitch. The difference between these environment is that the dev server was a standalone server and the QA and PROD servers were load balanced with a BigIP(f5).

Our QA and PROD web servers in the DMZ were using a non standard http port (for security reasons) for communications between the f5 and the individual servers. Later, we found out that when we try to access http://mydomain/ the URLRewritingNet was redirecting the request either to http://mydomain01:45555/default.aspx or http://mydomain02:45555/default.aspx depending on which server received the request. Since the server specific URL is only accessible inside our DMZ, the request to the default pages were failing.

After trying different settings with URLRewritingNet config and some other, we figured out that by setting the defaultpage property to "", we resolved the issue.