It's like spot the bug, only the code actually works.
Like everyone else and their dog, I decided to try out Windows Live Writer. But to do that, I needed my blog to support some sort of posting API. My blog software (which, as I'm sure you'll remember, is SubV2) supposedly has support for the MetaWeblog API. There's a file called MetaBlog.ashx, but opening it up in Visual Studio showed the following:
<%@ WebHandler Language="C#" Class="BlueFenix.MetaWeblog.MetaBlog" %>
using System;
using System.Web;
public class MetaBlog : IHttpHandler {
public void ProcessRequest (HttpContext context) {
context.Response.ContentType = "text/plain"
context.Response.Write("Hello World");
}
public bool IsReusable {
get {
return false;
}
}
}
This lead me to add "wire up metaweblog stuff" to my list of things To Do to SubV2 (number 15 of 69, if you're counting). Looks fairly boilerplate and empty, right?
"Hello world". Sheesh.
So, imagine my surprise when I actually navigated to MetaBlog.ashx, and I got a proper page back. How could this "Hello world" http handler actually do anything?
The secret is in the Class attribute on the first line. It's the actual type used for the http handler. Normally, it's named after the class that's also in the body of the ashx file, which gets compiled and then used. Here's it's different. The class in the ashx file gets compiled and thrown away, and the BlueFenix.MetaWeblog.MetaBlog class is used itself. This class happens to be the one that implements IHttpHandler, and the rest of the MetaWeblog API.
The devil really is in the details.
A better solution for this already exists - instead of having a virtually empty MetaBlog.ashx file, add the following into the web.config in the <httpHandlers> element:
<add verb="*" path="MetaBlog.ashx" type="BlueFenix.MetaWeblog.MetaBlog" />
I can now delete the MetaBlog.ashx file. Any requests for MetaBlog.ashx will get mapped from the web.config to the required type.
Subscribe