404 errors fixed! Goodbye /Glimpse/Config, hello /Glimpse.axd

The short version, is that /Glimpse/Config is being deprecated and being replaced with /Glimpse.axd.

The back story is kind of interesting and we thought we would share what we found with you… needless to say we learn’t a lot about Http Modules/Handlers and how it all comes together.

One of the things I loved so much about Glimpse was the /Glimpse/Config URL. To me this approach seemed so clean and simple, and very web 2.0 ish. However, when we went with this approach we failed to realize some of the gotchas that we ran. The approach we took has led to a number of people experiencing 404 errors in a number of different cases.


I guess when you first start creating something you fail to realize the full extent that something will be used. Our methodology to date has been to not over-engineer, develop for the known with a close eye on the future and to get working code into peoples hands. Given this philosophy and the way Glimpse came about, its not entirety surprising that we didn’t catch every possible case out there.

Problem 1
Specifically the technique we used to register our HttpModule, and thus implement clean URL’s, was by using DynamicModuleUtility (see more here – DynamicModuleUtility – a great article by K. Scott Allen). When we originally saw this we thought that this would be a simple way of wiring Glimpse up. Even though NuGet supply’s support for web.config transforms, we wanted to limit the amount we changed to as little as possible. DynamicModuleUtility offered config free HttpModule wire up.

At the time when we took this approach, we knew that this feature was only made possible by taking a dependency on the Microsoft.Web.Infrastructure assembly. But months later when we wanted to support Web Forms, this dependency is something that we didn’t take into account. During testing this problem never arose, as all our test environments also had ASP.NET MVC installed. This obviously presented a problem for people using Glimpse who didn’t have ASP.NET MVC installed.

Problem 2
Another issue arose as a side effect of using DynamicModuleUtility (even for some people that where running MVC sites and hence had the Microsoft.Web.Infrastructure assembly), was the missing runAllManagedModulesForAllRequests attribute from their config. As it turns out, the DynamicModuleUtility.RegisterModule() method registers the Glimpse module as a managed module. If the runAllManagedModulesForAllRequests isn’t set to true, then the module doesn’t get called for .js requests, which leads to another possible 404.

This is also true for web forms site, as the .NET 4, the ASP.NET Empty Web Application template does not include this setting in the default web.config, and neither did the older 3.5 templates. Hence, there are likely a lot of WebForms apps out there that don’t have that setting enabled in their web.config files.

There are a couple different ways this could be resolved, but it seems like the simplest would be to add the runAllManagedModulesForAllRequests setting to the web.config.transform file. But this isn’t something that we wanted to force on people. Our other option was to simply remove the .js extension, after all given that we have total control over the URL the .js was only there for the sake of convention.

When we did this we had the unfortunate side effect of being picked up by some people’s authentication process. Most people have rules in place to exclude .css, .js, etc from being process by asp.net/asp.net mvc, but since we removed the extension this brought Glimpse up on their radar and meant that additional rules needed to be added especially for Glimpse which is not what we wanted.

Problem 3
ASP.NET 4 has the concept of extensionless URL request-handlers, however when RTM shipped, they only worked for files ending with a dot, not for files with no extension. There is a knowledge base article and Hotfix: 980368. Needless to say we weren’t aware of this issue when we made the decision to go with extensionless URL’s.

After applying this patch, extensionless URL request-handlers do actually work for requests without extensions. Service Pack 1 for Win7 and 2008 R2 includes this hotfix, and it turns out all the environments we are testing had this hotfix.

There is a good post about this here – How ASP.NET MVC Routing Works and its Impact on the Performance of Static Requests.

Resolution and Final Fix
I am hoping that anyone reading this can sympathize with trying to work through these various issues at once. I’m a fan of Dr. House and there is never more than one thing wrong with someone at once, but as it turns out this is does not hold true with software. Trying to make sure that people who were still reporting 404 issues had the right versions of the code, when some people did and some didn’t… Needless to say it took a little bit, but I think we now have a total and permanent solution!

The finial resolution we have settled on is to dump /Glimpse/Config all together and go with the more traditional /Glimpse.axd. To me this is really disappointing as the /Glimpse/Config address seems far more elegant. But when developing a tool like Glimpse and having a situation where people need to install hotfixes or unusual changes to your config or anything else like this isn’t a good thing. The bar to entry should be as low as possible and in this case it means going with a /Glimpse.axd URL.

This has the advantage that most people already have rules and procedures in place to deal with *.axd’s and its something that people understand. There are also other well established tools such as ELMAH which use this practice, work in almost every case and people are already using. It does mean we will be adding a few more things to your config moving forward, but we since we are doing the exact same thing as ELMAH (from a config transformation perspective) we feel there is already a well established precedence for this.

In the next release of Glimpse /Glimpse/Config will still exist but will inform people of the change and the fact that they should use /Glimpse.axd moving forward.

In addition, we’ve moved away from leveraging DynamicModuleUtility since many users did not have Microsoft.Web.Infrastructure installed on their server.  For users who download Glimpse via NuGet, this has very little impact because we can leverage web.config transforms to register the HttpModule instead.

Please let us know your thoughts and if you have any feedback or thoughts.

7 thoughts on “404 errors fixed! Goodbye /Glimpse/Config, hello /Glimpse.axd

  1. Adam

    Is it not possible to have the url /Glimpse.cfg or something like that? I know that people understand the .axd as a http handler but if .cfg could be done that would be pretty cool.

  2. James

    Hi there,

    On the ELMAH front, although things tend to play very nicely with elmah.axd, there are situations where users end up having issues with that too! We get discussions on Google Groups from users that have installed URL rewriters that play havoc with our handler.

    Also, we’ve come from a world without MVC and elmah.axd doesn’t look so pretty there!!

    There is an interesting post by Alexander Beletsky who creates an ELMAH Controller to wrap up elmah.axd: http://groups.google.com/group/elmah. I having been thinking about how that could be packaged up and rolled out to users via NuGet. I think there are definitely possibilities that could work and I hope to try them out in the ELMAH Sandbox (elmah-sandbox.googlecode.com fairly soon.

    Perhaps this is something that you could consider to offer the best of both worlds?



  3. Carl Taswell

    Encountered previous problems with /glimpse/config/ and reported them in issues some time ago. Was able to eventually resolve them back then but did not continue to use glimpse. Just revisited Glimpse now again and once again encountered new problems with /glimpse/config/ returning 404 error. So I’m glad that you’re finally abandoning this repeatedly problem-prone approach in favor of something more tried and true with the *.axd, but even so, I would recommend that you make it possible to turn on/off Glimpse directly and explicitly in the web.config so that there’s a quick and easy way to verify the correct settings just be viewing the web.config file in an ordinary text editor. Why should we be required to browse to any url of any kind just to turn on Glimpse?!?

  4. Carl Taswell

    Please see this old post from Scott Guthrie at


    on *.ashx versus *.axd re handlers. Do you consider it out of date? Before you make final commitment to .axd over .ashx, it would be helpful to explain compelling benefits especially in view of the recent history with the 404 errors on the /glimpse/config approach. Thanks.

  5. Vitaly Brusentsev

    Great job, guys! This problem prevented us from using Glimpse, as we were relying on extensionless URLs.

    Looks like this update has not been released yet? The v.0.82 still requires /Glimpse/Config to work.

  6. Nik Molnar

    Thanks for the feedback everyone! A few specifics:

    @Adam: Yes is would be possible for us to have Glimpse.cfg, and I agree that it would be more readable. However, introducing new file extensions would require our users to do additional IIS configuration in many cases – we figured that this might prove to be too difficult.

    @James: Thanks for this info on Elmah. We will be looking into this technique for sure!

    @Carl: It is possible to completely turn Glimpse on or off via configuration. The enabled attribute is the overarching kill switch. There is a secret, not really yet supported way to get Glimpse to work without setting the cookie (what turning Glimpse on via Glimpse.axd does), but it has not been documented before. If you’d like to experiment with that, email me nikmd23 at google email service.

    We’ve also looked into .ashx vs .axd and decided on .axd because out of the box MVC projects have an ignore route set for .axd’s.

    @Vitaly: Glimpse 0.83 is not out yet – should only be a few more hours though now out! 😉


Leave a Reply

Your email address will not be published. Required fields are marked *