Update (18-Jan-2011): I uploaded the source for both PathUnwriter.cs and OutgoingStreamFilter.cs in case any one wants it.
As mentioned previously, I wrote an HttpModule to “undo” the path rewriting that GoDaddy seems to do on behalf of a hosted domain. For reference here is the code that does it (PathUnwriter.cs):
/// Clean outgoing path for ISPs that insist on clobbering the incoming path.
/// This module may need to be added *last* so that it's one of the outer-most
/// filters... the filters are created inside-out...
public sealed class PathUnwriter : IHttpModule
//clean-up code here.
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 ... [More]
This makes for an odd first blog, but if I wait until everything’s “just so”, I’ll never get anything posted. In theory, my site should exist at http://blog.jaredreisinger.com. This works, but you may notice that all of the intra-site links start with http://blog.jaredreisinger.com/jaredreisinger-blogengine.web/. This is because GoDaddy’s shared domain hosting (where you have more than one domain hosted from the same account) injects the hosting directory into the incoming URL. My apologies for getting technical; they won’t all be this way...
If you’re familiar with the way that HTTP works, you know that a request for “http://blog.jaredreisinger.com” really means that a connection is made to “blog.jaredreisinger.com”, and a HTTP request is sent that looks something like:
GET / HTTP/1.1
The “Host:” line tells the server that even though it might be hosting ma... [More]