After much messing around trying to get the
dasBlog CAPTCHA to work when my blog was running under a .NET 2.0 application, I finally gave up and moved it out to it's own sub-domain (blog.davebouwman.net). This way both sites can happily coexist - one in 1.1 and the other in 2.0, and CAPTCHA will reliably work.
The main feed is via FeedBurner, so it has been updated. The other problem was avoiding 404 errors for people who have bookmarks to the site, or who come in from Google. The basic problem was how to redirect all requests to the old Url to the new Url.
The pattern looks like this:
www.davebouwman.net/blog/SomeContent.aspx --> over to blog.davebouwman.net/SomeContent.aspx
This is just the place for a
HttpHandler. The handler itself simply intercepts requests, and transforms the Url as noted above, and then redirects the client browser to the new location. Since the main site runs in .NET 2.0, I created a class in App_Code, and had it implement IHttpHandler.
The redirection code for the handler is super simple:
public void ProcessRequest(HttpContext context)
{
context.Response.Cache.SetCacheability(HttpCacheability.Public);
//re-map the Url
string inputUrl = context.Request.Url.AbsoluteUri;
string redirUrl = "";
if (inputUrl.Contains("http://www.")) {
//drop the /blog
redirUrl = inputUrl.Replace("/blog", "");
//repoint the subdomain
redirUrl = redirUrl.Replace("http://www.", "http://blog.");
}
context.Response.Redirect(redirUrl, true);
}
Next is register the handler in web.config. The syntax for adding the handler into Web.Config is not exactly clear: Depending on where you handler is implemented, there are two ways to specify the type:
1) If the implementation is in another assembly, then you must put the assembly name after the type. This is what I most commonly found whe Googling, and is standard practice for .NET 1.1
<httpHandlers>
<add verb="*" path="~/blog/*.*" type="SomeNamespace.SomeHandler,SomeAssembly" />
</httpHandlers>
2) If the implementation is in App_Code (ie it's in the running assembly), you do not need to specify the assembly name. This makes sense as in ASP.NET 2.0, there is no assembly name! But this is not exactly clear.
<httpHandlers>
<add verb="*" path="~/blog/*.*" type="BlogRedirectHandler" />
</httpHandlers>
After I got this sorted out, everything was working smoothly on my home system. However, when I moved the code to my hosting provider (www.webhost4life.com), the handler would not work.
SolutionI'll jump to the conclusion, and if you're having strange problems with web.config & HttpHandlers, read the Details section below.
The underlying issue was the in order to have
dasBlog live inside a .NET 2.0 web site, I had to create a separate .NET application at www.davebouwman.net/blog. Even though I removed the folder, IIS was still thinking that the application existed. Since it's a hosted system, and I did not have direct access to the IIS manager, I had to muddle around in their ".NET Application" tool - where I finally saw that the application was still mapped in IIS. Once I deleted this application, everything worked.
More Details...I had moved the /blog folder out of my main site, and did not intend to have a /blog folder at all - the HttpHandler would match the Url pattern, and handle the request without needed a real folder. Only when I made a request, I got an ASP.NET Error stating that the requested folder does not exist. While technically accurate, this seemed like an odd error because I did not get it on my home system.
I then re-created the /blog folder, when I got a "Could not create type" error, which would show the handlers section from web.config. No matter how I setup the handler - in App_Code or external assembly, it would not load the handler.
So, I suspected that this was somehow related to the fact I used to have an application in /blog, so I changed the path in the handler to /junk/*.* and fired off a request. And it worked. This narrowed it down to something related to the /blog folder. From there I just banged around in the site manager tools that I have access to, and finally was able to delete the ".NET Application".
So - if you are having issues with httpHandlers, getting "Could not Create Type" or "could not create assembly" errors, make sure the path you are trying to handle is not registered as it's own application.