Living with – addendum

by Matt 24. March 2009 18:56

I meant this to a part of the last post, but I forgot. One of the really big things that gets wrong (really wrong) is the lack of any kind of logging, tracing or health monitoring.

This comes as rather a surprise, seeing as there is so much going on in this project – custom HttpHandlers and HttpModules, different data backends (xml or sql), asynchronous processes, etc. The potential for things going wrong is rather large, and there’s no built in way to diagnose the error – or even to know that there was an error.

And no, there isn’t a patch for this one.


Living with

by Matt 23. March 2009 16:46

Last week, I migrated this blog to run on While I haven't posted anything, I have (of course) been tinkering, and here are a couple of things I've noticed:

1. Speed. It's fast. I mean, really fast.

Except when it isn't.

First day after the migration, it was very, very slow. It would take upwards of 30 seconds to display a page. Firebug easily showed the problem, which was a call to retrieve a script from WebResource.axd.

All scripts in are served via an HttpHandler, js.axd. This handler minifies and compresses the files, and sets cache expiry dates. Very useful, at least for any scripts that you add to the page yourself.

Scripts that come from the controls, however, are another kettle of fish. They get served via a different handler, WebResource.axd, which pulls the data from assembly resources. The scripts aren't minified, and they aren't compressed.

So, when the BlogEngine guys wrote the module that compresses responses from the system, they also do a small sleight of hand to redirect any requests for WebResource.axd to go through js.axd. Due to the rather, um, obstinate nature of the WebResource handler, the only way to get this data is by passing the complete url (including domain name) to js.axd, which can then make a web request to go get it.

Unfortunately, and somewhat bizarrely, any request from my server ( to what should be itself ( hang until they timeout. Hence the big pauses.

On the bright side, this interception is configurable (and actually off by default), so it was easy as turning it off in the settings, and we were super-fast again.

2. I made a tweak to only output one feed auto-discovery link. Currently, BlogEngine advertises both the rss and atom version of the feed. From the Windows RSS Platform Publisher's Guide best practices section:

DON'T list the same feed in different formats

Unless you have a really good reason, it's not a good idea to have two links (or three!) that provide the same feed in different formats. It just makes the user have to pick between two things that they are not capable of distinguishing between. Pick your favorite format, and just support that.

So I just advertise a single link using the preferred format (as defined in settings). There's a patch on codeplex (#2635 - direct download) that fixes this for page and comment feeds.

3. There is a small security hole in the implementation of the metaweblog api. Uploading a file does not ensure that the file stays within the App_Data/files folder. This is mitigated by the fact that you can't upload without a username and password, but it could be used to overwrite the users.xml or roles.xml files and allow an editor to become an administrator. OK, not a huge security hole by any means, but it's nice to be fixed. Patch #2636 on codeplex (and direct download)

That patch also urlencodes the identifier used in the url that gets returned, due to point 4...

4. Windows Live Writer uploads files using just an ascii filename. BlogEngine does get enough extra information that it could create a new folder per post (based on post id), but it actually just saves the file using the given filename. Which could cause problems if two posts both use picture.jpg...

Normally, WLW gives a filename that includes a path, guaranteeing unique names for your file uploads. So what's going on?

This happens because WLW recognises out of the box. Check out the BlogProvidersB5.xml file in WindowsLive.Writer.BlogClient.dll resources. It includes this snippet:

<description>A weblog engine on the .Net platform.</description>
<fileUploadNameFormat xpp:if="version gte 12.0.1489.0207">{AsciiFileName}</fileUploadNameFormat>
<fileUploadNameFormat xpp:if="version lt 12.0.1489.0207">{FileName}</fileUploadNameFormat>

Which means that when it downloads the rsd file it matches the “BlogEngine.NET” pattern in the engineName element and applies these settings to the account (which explains the weird backslash you see in the Edit Blog Settings dialog). The pertinent one is fileUploadNameFormat, which gets set to {AsciiFileName}. This is one of a bunch of substitution variables that WLW recognises to build up the filename to send when uploading a file.

Fortunately, this can be overridden in the wlwmanifest.xml file by setting the fileUploadNameFormat element to be empty. This causes WLW to use the default pattern of "{WindowsLiveWriter}/{PostTitle}_{PostRandomizer}/{FileNameWithoutExtension}{FileNameConflictToken:_?}{FileExtension}" which should be fairly deducible. And since we're now saving into folders, and the image and file serving handlers just get passed the path to the file, we really should url encode the path in the returned url.

And yes, there's a patch for the wlwmanifest.xml on codeplex too (#2637 - download link).

It also, in a quick throw away kind of way, specifies the edit url for a post, enabling the "save as draft and edit online" command in WLW. Although, thinking about it, this only supports posts, not pages...

But all in, I'm very pleased. Although I've still got to decide on a theme...

PS. The code formatting extension leaves a bit to be desired, too.

Tags: ,

Shiny new blog

by Matt 10. March 2009 19:46

Ever wiped all the data off a web server and started again? It’s kinda fun, in that cross-your-fingers-and-close-your-eyes kind of way.

I’ve just moved this blog on to, which means I’ve now got to apologise for all those duplicate entries in your feed reader (although if you’ve been reading along in Google Reader, this will be nothing new to you).

Everything seems to have gone smoothly. All the content’s still here, and all existing links, including feed subscriptions should automatically Just Work through the magic of URL rewriting. But if for some reason your feed reader doesn’t update itself, point it to the new feed endpoint –

This has been something that I’ve been meaning to do for ages, but it’s only in the last couple of weeks that I’ve finally pulled all the pieces together to get it working. Turned out to be quite an interesting piece of work, and I think I’ll write a couple of posts about what it takes – migrating content and maintaining links.


Month List


Comment RSS