Since the path rewriting issue mentioned previously wasn’t a BlogEngine-specific problem, I was reluctant to invest a large amount of effort to solve the path problem if it would only fix BlogEngine. As it turns out, I can pull a similar trick “on the way out” as the one being applied on the way in. Instead of modifying hundreds of instances of path concatenations in the BlogEngine code, I wrote an HttpModule that “unwrites” the path that GoDaddy seems to be sending in.
All that the module has to do is attach to the HttpApplication.PreRequestHandlerExecute event and then wrap another layer around HttpResponse.Filter. This give the module a chance to tinker with the values that the page attempts to write to the output stream. BlogEngine.NET itself uses this same method to add compression... which introduces an interesting ordering concern. I’m attempting to “unwrite” text, so my module’s filter needs to be one of the first ones called — so that it doesn’t have to deal with already-compressed text! Since filters are added by wrapping them around any previous filter, my module’s filter must be added last to get it called first. This means that the module’s web.config entry must be one of the last ones listed.
If you look at the links, most seem to be fixed. There are still a few straggling references in the source, though, that will require some more puzzling out. Fortunately, they aren’t as obvious as the page links. Also, the permalinks seem to be getting goofed up, probably because BlogEngine.NET does a redirect, which bypasses my unwriter module. The Unwriter now catches redirects as well! The compression module adds a “/js.axd” reference that my current solution won’t catch, but I think I’ll just live with it. (update on 22 Oct 2009)
I’ll provide the source, but first I have to get syntax highlighting to work. I’m sure it’s just a matter of tweaking the config, but a quick web search shows that this seems to be a common problem. More on that to come...