DevDisasters

Take It to the Limit

Adam's employer was able to reclaim the company URL from a cyber squatter. Now it should be easy to make sure its site resolves to the new name, right?

• By Mark Bowytz
• 08/06/2015

Hardly anyone noticed when the e-mail landed in everyone's inboxes from marketing group. There was a lot of fanfare accompanying the message body, but for a small company like Bantam Software Corp. (not the real company's name), being able to use bantamsoft.com instead of mybantamsoft.com was a pretty big deal. Rumor had it that someone had squatted the domain name several years ago and had been holding it "hostage" for some incredulous sum ever since.

Not long after the URL announcement, the CEO sent an e-mail of much greater importance -- Bantam had just picked up a new client, effectively doubling Bantam's annual revenue.

At least everybody now knew how Bantam was able to purchase the domain name.

After receiving the official "all clear" to proceed, Adam logged into the Bantam Software Web hosting services provider and thought about how he could best transfer over its external Web site to the new domain (e-mail would be handled by a different group, thank goodness).

After some contemplation, he decided to go with what he felt was a fairly safe and low-risk approach that could be accomplished in a couple of hours: He decided to copy the existing site's code to a new directory that the new domain would point to. When it was time to officially use the new domain name, he could redirect the old URL to the new one.

Now it wasn't that he doubted his abilities. Instead, he didn't trust the hosting provider who, often regrettably, only fit into the monetary portion of the "fast, cheap, good -- pick two" adage.

Entering the base URL worked fine. The company's landing page loaded in an expected amount of time and all the images and expected scripts loaded, but any attempts to view anything beyond the main page resulted in an error: "HTTP 500 - CANNOT LOAD, NUMBER FIELD NOT FOUND."

Adam knee-jerked and reached out to the host's support site. But mid-way through drafting a ticket Adam thought it might be wise to dig into the code a little bit first. After all, with the new URL not being live yet, he had the luxury of at least a little time.

Having found the code that dutifully parses out parameters passed via the URL, he noticed something peculiar: The logic parsed out URL parameters based on the length of the URL passed:

protected void Page_Load(object sender, EventArgs e)
{
  if (!IsPostBack)
  {           
    // ...
    string strUrl = HttpContext.Current.Request.Url.AbsoluteUri;
    string strNumber = "";

    if (strUrl.Contains("?") == true)
    {
      strNumber = strUrl.Substring(25, strUrl.Length - 25);         
    }

    // ...
}

"Oh, so that's why the external sites can only have a single URL," he wondered aloud. The changing of the URL to drop the "my" had shortened each URL's length and resulted in broken logic. Whoops!

Adam made a mental note to change this section of code to use something more sane like Request.QueryString["number"]; but to continue with his testing in the near term, he changed the substring length value to 23 and did some more poking. Hooray! The URLs off the main page worked again.

Adam returned to the draft of the ticket that he had started on the hosting company's support page and deleted the subject line. He had found and fixed one thing ... and he still had a lot of testing to do.