Apologies to all if you saw a whole bunch of posts appearing and disappearing in the past hour. I’m having – all of a sudden – extreme problems with publishing a blog post from Windows Live Writer to this blog, which is hosted on GoDaddy. This first happened on November 5, but I thought it was a transient issue and ignored it. And then over the weekend I wrote the “adding parentheses” post but it would not publish, no matter what. I finally published it just now with Graffiti’s admin app, which is not nice.

I’m going to be continuing some experiments, trying to narrow this down. In essence, the web server is forcibly closing the connection: “System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host.” This bubbles up and WLW reports:

Network Connection Error
Error attempting to connect to blog at:
http://blog.boyet.com/blahblahblah/metablog.ashx
The underlying connection was closed: An unexpected error occurred on a receive.

(The ASHX file is the MetaWeblog interface to the blog. I can read from the interface, so I can retrieve existing blog posts, get category lists, and all that good stuff, but writing a post causes the aforementioned error.)

photo © 2009 Caitlin Childs | more info (via: Wylio)I was doing a bit of research to try and find some nuggets of information on URL rewriting, especially with regard to GoDaddy’s shared hosting (I run this website (and others) on GoDaddy). I found this article in Google’s cache but the original site (codebeater.com) has gone away (I presume the domain wasn’t renewed). The article was by CodeBeater’s admin.

I didn’t want it to disappear into the ether as I can certainly see me using it in the future. So I copied it here verbatim, just cleaning up some look-n-feel.

[UPDATE 21-Feb-2011: Jeff from the CodeBeater site has revived his blog and has republished this post there.]

Solution for ASP.NET MVC Routing issue on Godaddy shared hosting

This is actually not an issue related to GoDaddy shared hosting at all but an issue with hosting an ASP.NET MVC site in a virtual directory. When you use the shared hosting provided by GoDaddy you get a root folder and limitless subfolders, each of which can be its own domain, by way of virtual directory. Unfortunately, MVC’s routing engine produces URLs that will include the virtual directory name appended to the domain name.

For example, let’s say you have a domain named http://www.example.com and your folder/virtual directory name is /File. If you take the MVC template project without making any modifications and upload it to your folder and then go to your url everything will look fine. You will notice the ‘Home’ and ‘About’ tabs at the top right of the page. When you click on the ‘About’ tab, since it is routed to the Home controller’s About action, you would rightly expect the URL to be www.example.com/Home/About. What you will see, though, is that the URL generated by the ActionLink method includes the name of the virtual directory. Therefore, the URL will be www.example.com/File/Home/About.

If this problem doesn’t bother you then kudos to you. It bothers me and I was really hoping to find a resolution that involved configuration, rather than writing a bunch of custom code for something I felt should work ‘out of the box’. After posting the question here and scouring various forums I found many others having the same problem but not one solution.

Luckily for me, I have a couple of friends and former coworkers that now work at GoDaddy who jumped on this issue when I posted it to their forums. I want to first say thanks to both of them for taking the time to dive into this and finding a configuration-based solution that works perfectly. You know who you are!

So now for the solution, and I probably should have mentioned this at the beginning but hopefully you’re using IIS7 with the URL rewriting module installed (it is installed by default when you use IIS7 on GoDaddy).

Simply add the following into your web.config’s system.webServer element:

<rewrite>
  <rules>
    <rule name="Remove Virtual Directory">
      <match url=".*" />
      <action type="Rewrite" url="{R:0}" />
    </rule>
  </rules>
</rewrite>

All this does is “rewrite” the URL with itself. This causes URL Rewrite to add the original URL (the one with no folder name) to a ServerVariable which is used by ASP.NET MVC to generate other URLs.

Again, this only works when you’re using IIS7 with the url rewriting module installed.

Good luck!

So, last night I was working on my URL shortening website (jmbk.nl) and the application that generates the short URLs and that redirects existing ones to the actual URLs. And for some unknown reason, the redirections just weren’t working on the actual website. I’d get server errors (even “404-Not Found” server errors) and my redirection ASPX page just didn’t seem to get called. It was, to be polite, a mess. And, because it was late at night and I was tired I was flailing around trying stupid stuff to see what stuck and nothing would.

This morning I was more calm and collected and finally worked out what the issue was. Trouble is, when laid out like this, it sounds ruddy obvious and I should not have had a problem in the first place.

Let’s briefly explain how it all works. The application has a routine that converts a long URL (such as http://blog.boyet.com/blog/pcplus/pcplus-285-calculating-pi/) and converts it to a short URL (like http://jmbk.nl/d3T7A) and stores it in a database. That bit is easy. Now the fun stuff: the short URL does not actually exist. When you click on it, magic happens, a 404 error is raised and my redirection page is supposed to gain control, work out what short URL was used, and convert it back to the long URL (it just looks it up in the database essentially). It then does a Response.Redirect to that URL. To the end-user, it was as if he just clicked on a short URL and he got the actual web page.

The problem is in that phrase “magic happens”. I was assuming one thing and some entirely different other thing was happening.

This is what I was assuming. I had a section in my web.config that said:

<customErrors mode="On">
	<error statusCode="404" redirect="Redirection.aspx" />
</customErrors>    

(This is in the system.web section.) I was reading this as “Got a 404? Go to Redirection.aspx”. Right? Wrong. All right, it’s partially correct but the bit I was assuming was correct was hopelessly wrong.

The other thing to point out is that the jmbk.nl website is being run on GoDaddy. It is hosted on a Windows server running IIS7 and ASP.NET 3.5. I’d also set the “404 Error Behavior” option on the hosting dashboard to the same ASPX page, although part of me was wondering why. Surely my web.config setting was enough?

Therein lies the rub. No, it isn’t. You see, there are two different ways a 404 error could be generated. My issue was I thought that there was only one.

First things first: when you try and follow a link to your domain, it is IIS that will get the request and decide what to do. (I’m assuming my case here, obviously I should say “the web server” to be more generic.) Part of IIS’ configuration is a list of file extensions and what to do with those extensions. GoDaddy have got their IIS set up such that if you request an ASPX page (or ASHX, ASMX, etc, etc), IIS will just pass the whole request over to ASP.NET and let it do with it what it will.

So, if I request http://jmbk.nl/DoesNotExist.aspx, IIS will pass it on to ASP.NET, and ASP.NET will work out that that ASPX page is bogus; it does not exist. It’s a 404. ASP.NET then goes to the web.config file, finds out what I wanted it to do with 404 errors and then redirects the request to http://jmbk.nl/Redirection.aspx?aspxerrorpath=http://jmbk.nl/DoesNotExist.aspx. My redirection page gains control, works out the original URL (using Request.QueryString["aspxerrorpath"]) and can do some valuable work with it.

But what if the original request was not for an obvious ASP.NET page? Say, for a short URL like http://jmbk.nl/d3T7A? In this case, IIS will not pass the request onto ASP.NET. Instead it tries to find that page itself. If it can’t find the page, it’s a 404 again, but this time generated by IIS itself. IIS looks to its own custom error page list to see what to do with a 404. The way I’ve set up the hosting of this website with GoDaddy, the custom error page is the same Redirection.aspx page. IIS redirects the request (and, yes, it gets transferred to ASP.NET). This time however, the redirected request is very different: http://jmbk.nl/Redirection.aspx?404;http://jmbk.nl:80/d3T7A.

Notice a couple of things: there is no aspxerrorpath key, and in fact the query string (the bit after the question mark) is not even a name/value dictionary. There’s no key=value pairs to be seen anywhere; Request.QueryString[...] is going to get you nothing.

The solution is to either have two different redirection pages, one for ASP.NET 404s and one for IIS 404s with different processing, or to use a different way to get at the query string. In the end, I went for the second option and used Request.ServerVariables["QUERY_STRING"] to get the entire query string. Once I had that it was pretty easy to extract the non-existing URL, no matter how the query string had been created.

As I said, it all sounds very obvious describing it like this, but I was seriously confused about it all last night. My research showed me that I’m not the only person so confused.

Nearly two weeks ago, I converted this site to use SQL Server as the database engine. Without a doubt, having the database on another server separate from the main web server has helped the speed of this site dramatically, so much so that I've added features like the "top five most popular posts" gadget to the first sidebar and "other similar posts" to each blog post (when they're displayed on their own).

The only problem that I've had is that my backups of the site have reduced in frequency equally dramatically. Why? Just the sheer number of steps I have to go through to perform a database backup on GoDaddy. For fun, here's the full process:

Step 1 Go to the GoDaddy home page and log in:

Step 2 Click on the My Hosting Account menu item

Step 3 When your accounts are displayed, click on the Manage Account link for the account that has the SQL Server database:

Step 4 Click on the Databases menu and select SQL Server:

Step 5 When the list of databases is then displayed, click on the pencil icon to view the database details:

Step 6 Click on the Backup icon:

Step 7 Finally, it's time to initiate the actual backup by clicking OK on the resulting pane:

Note, though, that I have no way to specify the backup file name, so that, perhaps, I can take a daily backup and have the ability to go back to a particular day; that therefore the old backup file is going to get overwritten; that I won't know or get notified that the backup is complete (apart from the rather wishy-washy "up to 2 hours" text).

Final step (number 8) Of course, now I have to download the resulting backup file using FTP onto my local machine.

To be brutally honest, this is way too many steps. Creating backups that I can download are just not going to get done with any regularity. Since I do have remote access to the SQL Server instance, another way of doing this might have been to use SQL Server Management Studio, but that seems to want to backup to a folder on the same machine as the server instance, and I don't have such access.

I know that GoDaddy back up their own servers (well, all right, I assume that they are), but as Jeff Atwood said today on Twitter after suffering a complete server crash which wiped out Coding Horror: "for the record, I blame 50% hosting provider, 50% myself (don't trust the hosting provider, make your OWN offsite backups, too!)". To be faced with that possibility is the stuff of nightmares…

Is that SEO-specific enough, do you think? Heh. Anyway, here's the situation. I started this blog using GraffitiCMS about a year ago, previously having used static web pages created with CityDesk. All my sites are hosted on GoDaddy: I went with a Deluxe hosting option which means I can host pretty much as many sites as I want to in the same single folder tree.

At the time — can't remember why — I decided to stick with the default VistaDB as the database instead of opting to go to SQL Server. Throughout the year, things have been good, no issues whatsoever, so my decision seemed sane. Until about two weeks ago that is, when everything went to hell in a handcart in a hurry. Essentially, for a whole week, this blog went offline:

I still don't know what was up. I uploaded a blog post the day before, then, blam, November 15th was a black hole that lasted 6 days. As detailed here, I tried to fix it once I was back home from PDC — thought I'd had, but ever since it's been acting weird. Every now and then, for no discernable reason I can see, some process (obviously an ASP.NET IIS process) locks some section of the VistaDB database file and it's curtains for the blog until the process resets, several hours later. I'm guessing that it's some bug in GraffitiCMS and one request is hanging, causing everything else to hang. Or it's because something is timing out from taking too long. At any rate the log slowly starts to fill up with errors, since every three minutes or so some process kicks off to clean out deleted records:

Plus the site has suddenly been acting as if it's very tired. It's just been plain slow. Just nasty to use (I was counting something like 7 seconds for a blog post to come up).

Finally yesterday I'd had enough. The site locked up again (for about 5 hours this time), so it was just time to move to SQL Server. At least with that I have some diagnostic tools and the like to find out what's going on.

With my GoDaddy hosting plan I have the ability to have up to 2 SQL Server databases. Not many, Benny, but then again I only need one. First problem is that, by default, GoDaddy does not expose your SQL Server database for remote access. They provide a nice web-based tool to manage your database, but it seemed a little limiting to me: I wanted to use SQL Server Management Studio to manage my database. Plus, the only way I was going to be able to get all my data into the database was to do it via a remote connection.

So I fired off an email to support asking for the right to access my database remotely. I got a reply back after three hours saying that I should delete my current databases (after backing them up of course). Also they had to move my whole domain onto another hosting server in order to allow remote access to the database. No problem (I only had a test database to try out the standard GoDaddy tools and this was soon dropped), so I quickly replied that my domain was ready to be moved. Four hours later, I got a reply saying, in effect, that "due to its complex nature, your issue has been relayed to our Advanced Technical Support Team". OK, I let support take their course and went to bed.

This morning, I had a slew of messages saying that the move had been successful and that I could now access SQL Server remotely. Amazingly the whole site was much more responsive than before: I reckon the previous hosting server was a bit overloaded (perhaps this was also part of my problem?). This evening, then, was the time for the Big Conversion.

1. I logged into my hosting account on GoDaddy and created a new database. On the database creation page was a radio button to state whether this database could be connected to remotely or not, something that had been missing before:

I made sure that the button was set to Yes. 5 minutes or so later, the database had been created.

2. I fired up SQL Server Management Studio (SSMS) 2008 and connected to the SQL Server URL given by the database configuration page, providing the user name and password I'd set up for the database. It connected just fine.

3. However, when I tried to open the Databases node in the Object Explorer, I got SQL Server error 916. My credentials were not able to access another database I'd never heard of. I went back to the SSMS server login dialog, and added my database name. Same error. I googled for the answer and found this article by Clay Burt that described the same issue. It made reference to this Microsoft Connect post about how to fix the problem. Once I did this and refreshed, I saw a huge long list of the databases on the server, of which mine was one. (Of course, the only database I was able to open was my own.)

4. I opened my database in SSMS and then ran the Graffiti_SQL_Schema.sql script (it's in the top level \Data folder of the GraffitiCMS install). This created the database schema that Graffiti uses. Then it was time for the data.

5. I copied my whole GraffitiCMS site from GoDaddy onto my local disk. I normally do this for backups every couple of days anyway, but this time I wanted to make sure I had the latest, most-up-to-date Vista VDB3 database file. I was going to be using the DataMover utility to copy the data over to SQL Server. I set an "under repair" default.html file in the root folder so that visitors would know something was going on.

6. Now it was time for DataMover. This utility is found in the \Data\Utility\Migrations folder of the GraffitiCMS install. It requires two databases: the source and the destination. For the source, I browsed to the folder containing the VDB3 file I'd just downloaded, and for the target, I entered in the .NET connection string that pointed to the GoDaddy SQL Server instance that was hosting my database. (GoDaddy provide this in their database control panel. Open the database control panel, click on the pencil icon next to your database, then click on Configuration. Find the one that says .NET, it's just a case of selecting it all, copy-and-pasting it, and then overwriting the dummy password with the real one). I clicked Copy Data and then started to write this blog post about how I did it all.

7. Once all the data had been copied to the SQL Server database, it was time to fix the web.config file that I'd downloaded. First of all, I located the current connection string. It looked like this for me:

<add name="Graffiti" connectionString="Data Source=|DATADIRECTORY|\boyetblog.vdb3" />

I changed it to look like this (with certain values changed to protect the innocent, namely, me):

<add name="Graffiti" connectionString="Data Source=boyetblog.db.999999999.hostedresource.com;Initial Catalog=BoyetBlog;Persist Security Info=True;User ID=userid;Password=password;" />

Now I had to change the data provider. Further down web.config, there's a line that said:

<add key="DataBuddy::Provider" value="DataBuddy.VistaDBProvider, DataBuddy"/>

And I changed it to look like this:

<add key="DataBuddy::Provider" value="DataBuddy.SQL2K5DataProvider, DataBuddy"/>

I then uploaded the changed web.config file to the root of my blog site.

8. Time to test. I played around with as many features of the site that I could, especially the admin pages, including reporting. All seemed to work just fine. In fact, better than that, it is rip-roaringly fast. Having the database engine on a separate machine from the hosted web server is just slick like skates on ice.

I noticed this a couple of weeks ago, but couldn't pin it down to anything. All of a sudden, the Graffiti application used to run this blog suddenly stopped working, throwing up its generic error page. After a little bit of investigation why, I found out that the write permissions on the blog root folder had been cleared.

So I set them back, and promptly forgot about it.

Well, it happened again yesterday afternoon and the only thing that I had done with regard to my website configuration was to create a new subdomain of boyet.com: acting.boyet.com. This is a convenient place to hold my acting résumé (I had an audition yesterday afternoon, and I thought this would be an ideal short URL to write down on the audition form — no slashes or other weird characters).

It seems that adding the new subdomain to boyet.com did two things. First, it added the target folder for the subdomain to my IIS settings. Don't know why, but I removed it. And then, second, it cleared the write permissions to my blog subdomain and without write permissions, Graffiti can't run and throws up the error page.

And then I remembered what had happened last time this had happened: I'd just registered imetjulian.com and added it to my hosting account.

So, bear this in mind when you have a hosting account with GoDaddy: if you are configuring your domains in your hosting account (either adding new ones, or adding a subdomain, or possibly removing some), the domain configuration application may reset any write permissions you may have set on folders. If you have one of these folders as an application root — and, really, there's no other reason to have write permissions set — then the application probably won't run properly. After you've finished configuring your domains, check any write permissions you may have set.