Last Monday I applied a redirect rule to the site. And promptly watched (okay, so it took me 4 hours to notice...) as things went crazy & stuff broke. So, to help avoid that in the future, here's what I did & why I think it broke, and what was done to fix it.

Okay, so basically, there are 4 different domain names that can get visitors to this site. That's nice and all, but it doesn't help the search engine rankings at all. Also, it just seems kind of...repetitive (let's face it; this is probably the real reason I bothered to mess with things; having 4 different paths isn't as elegant as having just one). So I downloaded the URLRewrite add-on for IIS 7.5, installed it and created a simple rule:

   1:  <rewrite>

   2:    <rules>

   3:      <rule name="Redirect to www.ntldr.com" enabled="true" stopProcessing="true">

   4:        <match url=".*" />

   5:        <conditions>

   6:          <add input="{HTTP_HOST}" pattern="^(www.)ntldr.com$" negate="true" />

   7:        </conditions>

   8:        <action type="Redirect" url="http://www.ntldr.com/{R:0}" />

   9:      </rule>

  10:    </rules>

  11:  </rewrite>

The rule looks at every URL used to get to the site, checks to see that the destination server is not www.ntldr.com, and then redirects the request to http://www.ntldr.com/whatever-the-original-request-was. Pretty simple, tested it internally, verified it was working, then applied it to the site and went away for a few hours.

And came back to find that the logs had tens of thousands of entries. Mostly from some computer in Kansas that kept going to / over and over and over and over again. For almost 2 hours. The bots almost universally gave up after just 6 rounds.

Of course I immediately turned off the rewrite rule and frantically began looking at logs & network traces trying to figure out what the heck was going on and how I managed to not catch it in testing. It quickly became apparent that the rule worked internally, but not from outside the Forefront TMG 2010 firewall. Which narrowed down the problem quite a bit, & made me feel less incompetent (yay! the rule worked!), but more stupid (doh! for not testing like an actual user would!).

However, examining the TMG logs didn't really yield anything useful. A request would come in, it would go to the web server, a 301 Permanent Redirect would go back, and then the client would seem to reissue the same request again. Out of desperation, I decided to take a look at the rule and noticed this tab:

At the time, "Apply link translation to this rule" was checked. And one rule is used to make all 4 hosts accessible. Consequently, this is what the Link Translation Mapping looked like:

Public name: ntldr.com

Public name: ntldr.net

Public name: www.ntldr.com

Public name: www.ntldr.net

Oops. Fairly major, mind-numbingly stupid oops.

See, this is what was happening:

1. User visits http://ntldr.net.
2. Request for http://ntldr.net comes into Forefront TMG.
3. Forefront TMG processes the ntldr.com rule and forwards the request to www.ntldr.com (at this point, an internal DNS alias for the actual server, tourmaline.global.ntldr.net).
4. IIS gets the request and applies rewrite rules.
5. Rewrite rules send a reply back saying "no, you really should go to http://www.ntldr.com".
6. Reply reaches Forefront TMG. Forefront TMG applies Link Translation mappings.
7. Link Translation mappings change that to "no, you really should go to http://ntldr.net".
8. User dutifully goes to http://ntldr.net.
9. Repeat 1-8 until the user's browser either gives up (nice browsers), or the user gives up (impatient users), or I disconnect them.

So, the solution: disable link translation in Forefront TMG. Note that I not only had to do that on the rule itself, but also in the Web Filters. That might be just because I was impatient and didn't wait for TMG to fully cycle and disable the rule-level mappings. Not sure though, and haven't had a chance to find out yet.

Now playing: The New Pornographers – Challengers – 07 Unguided