Uncategorized

ASP.NET 2.0 application running in Firefox and not running in IE

Every now and then we get calls from a customer who decided to migrate his application from ASP.NET 1.1 to 2.0 (and sometimes those are mission-critical ones…) just changing the relevant mappings in IIS console, to then discover that the application is no longer working, or has some quite weird behavior which gives them headaches…

Luckily that was not the case of the call I’ll now talk about; to test if the application could work against ASP.NET 2.0 the customer made the very quick test described above: they simply changed the mappings through IIS console and immediately notice that something was going wrong inside the app. They started troubleshooting the problem themselves and have then been able to repro the same problematic behavior inside a minimized application, just a simple .aspx page with some very basics functionalities in there (just a page with a command button and a GridView to fill with some data coming from Sql Server). This minimized repro was working fine on the dev machine with Cassini, but once installed in the target web server (Windows 2003 with IIS 6.0); when browsing with IE, the resulting HTML lacks completely the client-side Javascript to trigger the postback (while this code is present in Firefox). They were accessing the web server through a proxy, but the same was true also when using Firefox…

We checked the basics (event log, IIS configuration, web.config etc…) but everything looked fine; we then captured a network trace to monitor the communication between the client and the web server, and here we found that the User-Agent string was a bit different from the one we excepted (and this was also confirmed enabling Tracing for the test .aspx page):

    • IE User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; server; domain|user; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1)
  • Modified User-Agent: Jaguar Application Client/4.1,Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; server; domain|user; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1)

The User-Agent string was modified by the procy of the customer.

After some more investigation we found that the User-Agent string was not matching anymore the one described in “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers\ie.browser”, which contains the definition of IE browser capabilities; ASP.NET relies on that file (there are more, for other kind of browsers) to know the level of the browser issuing the request and produce an HTML output which can be understood by that browser. Due to the modified User-Agent, ASP.NET was no longer able to recognize the IE capabilities, and it considered it as a downlevel browser (capable of understanding just plain HTML), therefore it produces just that, simple HTML. Interestingly, this did not apply to Firefox because its User-Agent string (even if modified) matched against a .browser file with Javascript capabilities, therefore ASP.NET always included client-side scripts and the test page worked as expected.

As a colleague of mine told at the Lisbon off-site a couple of weeks ago: “Now that we understand what’s going wrong, we can fix it” 😊. We created a new .broser file (we called it jaguar.browser) and modified the regular expression to match your custom User-Agent string; we preferred to create a new file instead of modifying the IE one because those files are not granted to be immutable, and future hotfixes or Service Packs could modify them, thus invalidating our changes (and the customer would have all of a sudden the problem back). By the way, after you create or modify a .browser file, the new changes are not immediately available for the runtime, so you must run the following command:

aspnet_regbrowsers -i

The command creates the runtime browser capabilities assembly and installs it in the global assembly cache; so in this case the problem was not IE itself, but rather the non matching User-Agent string.

Here are a couple of links which may be of interests regarding this issue:

Carlo

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.