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: ,


Month List


Comment RSS