Thursday, June 6, 2013

GoDaddy, ASP.NET, and Junk Characters in Your URL

Originally written for eImagine Technology Group (

The Problem
If I am being completely honest, I first noticed the problem a few years ago. Years. That's right, I noticed it, but it never really caused me any problems so I figured, "If it ain't broke..."

The issue, so to speak, is indicated as such: You run you ASP.NET web application (or web site) locally or perhaps on any other server and it behaves normally. So, after debugging, you FTP the system to your GoDaddy Windows shared hosting account. Once complete, you hit the URL in your browser and... hmm, that's weird, isn't it?

The URL changed from:

Where the hell did those extra characters come from?

Now, even in this particular case, I might have shrugged and went about my business, but the problem was that this particular URL and web page was an ASMX file that was receiving a very simple JSON post via stream. In posting, via jQuery's $.ajax() call, the 302 redirect message that normally sends browsers on to this modified URL could not be followed by the posting call and was causing it to "succeed" without really succeeding due to the changing and seemingly-random characters added. Sure, I could hard-code one set, but after a few calls from different clients, the actual URL was always different and always issued a 302 redirect.

If this is happening to you and you just want the answer so you can move about your business, feel free to jump to the solution now.

My Pain
I searched. I Googled. I did my due diligence. I finally found an article on the GoDaddy forums that seemed to answer this, but the consensus in the post was that you should call their support to turn it off. So, knowing the futility of any phone call of this technical magnitude, I called GoDaddy support anyway.

After a ten minute wait, and being put on hold to escalate the issue, I was told it was likely a name server issue. I repeat, a name server issue. Forget that my site pulled up just fine and was executing correctly - why should that matter in this diagnosis? Seeing I wasn't getting any further I agreed to resolve the "issue" myself and hung up.

The Answer
And then it happened. Something in the deep recesses of memory fired and I realized I had seen characters like this before and noted that the characters changed only between sessions...

I searched around for how the web.config can set the particular way that session state is supposed to be conducted (cookie, SQL, etc). Sure enough, it turns out that in-URL is one way that the unique id for a session can be conducted from one page to the next.

What is worth noting here is that I am not nor was not using sessioning at all and there was no mention of sessions or such in my web.config.

The Solution
On a frustrated whim, I decided to add the ASP.NET sessionState XML tag with the mode set to "off" to my web.config. The final and very simple solution looked like this:

     <sessionState mode="Off">  
    <compilation debug="true" strict="false" explicit="true" targetFramework="4.5" />  
    <httpRuntime targetFramework="4.5" />  
I re-built (mostly out of habit) and uploaded via FTP and anxiously hit the refresh button. Bingo! No more crazy characters.

Even though they don't tell you so and certainly aren't aware of it as a general FAQ in support, GoDaddy shared hosting must have a machine-level configuration that not only turns on sessionState, but specifically uses the in-URL mode. This makes sense since you are likely on a VM as part of their "grid" and, form one moment to the next, may not even be operating on the same semi-physical "machine".

If you need sessionState yet don't want the id located in your URL via 302 redirects, follow one of the many tutorials on switching to database-stored sessions or another scheme. Heck, you can even "roll your own" if you are rambunctious.

Hope this helps!

No comments:

Voice Comments