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.
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.
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.
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.