Some weeks ago I wrote how to minify and compress the WebResource.axd handler. In the comments of that post someone asked how to do the same with ScriptResource.axd. I thought about it and realized it could be done much smarter.

If you take a look at the HTML source at the CodePlex Issue Tracker page, you’ll see it references 13 WebResource.axd and ScriptResource.axd. That’s 13 different web requests on each page load. The ScriptResource.axd is using HTTP compression but WebResource.axd does not. None of them minifies the scripts.

Therefore it would be cool to create a plug ‘n play HttpModule that combines all resource.axd scripts into one single web request and then minify and compress them. It would result in smaller HTML, fewer web requests and optimized JavaScript code. If you’re a YSlow nazi like me, this is a must-have.

How it works

To make it work, we need both an HttpModule and an HttpHandler.

The module

The module looks for resource scripts in the HTML code and collects all the references from the src tag. It then constructs a new script tag containing all the references and points it to the HttpHandler. The new script tag is injected into the HTML where the first resource script was found. It keeps the order of the scripts intact.

All the original scripts are now removed and a single new script pointing to the handler is injected.

The handler

When the handler is requested by the browser it looks for a URL parameter containing the references to the original resource script. They are separated by a comma in the URL parameter. It then retrieves the content of each script using a HTTP request. Then content is then aggregated into a single string which then get’s minified. Minifying means that all comments and whitespace is removed from the script.

The string is then being cached so the handler only has to do it once per application life cycle. The output is then compressed and the appropriate header set so the browser will cache the file for 30 days. You can easily set the number of days in cache to whatever you see fit.

Implementation

Download the ScriptCompressor.cs file below and put it in your App_Code folder. Then add the following lines to your web.config:

<httpModules>
  <add type="ScriptCompressorModule" name="ScriptCompressorModule" />
</httpModules>
<httpHandlers>
  <add verb="*" path="*js.axd" type="ScriptCompressorHandler" />
</httpHandlers>

Download

ScriptCompressor.zip (3.43 kb)

My pride takes a hit every time I read the title of this post. At least it contains the word “fix”.

People have reported a memory leak on a few occasions, but I’ve never been able to find it and neither have anyone else. I just left it because it has never bothered me. It might be because of a very forgiving hosting partner that just adds more RAM if necessary and never tell me.

Yesterday evening I found myself in the right mood for tracking down this leak and it only took me 6 hours to find it. The fix took about 8 seconds, but what jolly 8 seconds that was.

The problem

After six hours I found that the leak was in the Related Posts server control. The constructor registered an event handler for the Post.Saved event, but the constructor wasn’t static like all the other controls. It was public which means that at every page view the event handler would be registered. That resulted in that the control never got disposed because of the reference to the event. So for each page view, an equal number of controls got stuck in memory and couldn't be garbage collected.

The fix

Make the constructor and event handler static so they only run once in the application life cycle. Let this be a lesson to all, remember to unhook your event handlers. The fix works for BlogEngine.NET 1.3, 1.3.1 and 1.4 and you just have to replace one file in the App_Code folder.

Download the memory leak fix at CodePlex and follow the instructions in the readme.txt.

I’m sorry it took so long to find this fix. I hope it hasn’t caused you too much trouble.

BlogEngine.NEXT

In the light of this and other bugs, we have decided to do a service release in a couple of weeks. Beside the memory leak fix, it will include many other tweaks, fixes and a few new minor features. It will be 100% backwards compatible with the current 1.4 release. If you have found some issues with 1.4 that you want fixed in the next release, please add them to the issue tracker.