Ajax resource intermittently not accessible (http compression)

A few days before Christmas I had a case where the customer was intermittently getting troubles with his javascript/Ajax resource; as usual everything was working fine on the development machine, but when moved on the production server the application started throwing some client side javascript exceptions like “myVar is undefined” which means that the Ajax resource was not accessible by the browser.

After some of the usual checks and discussions with the customer we found out that the production server was using HTTP Compression which is an old friend of mine (I already rambled about it here); they developed a custom HTTP Module to implement the .NET Framework compression classes and mechanism and disabling it was not an option, since their resource were quite large were affecting the applications’ performance.

Then I had a couple of weeks off for Christmas and my colleague Gunnar took over the case (isn’t nice when you go on holiday and someone else takes care of the job for you? ?) and with some further debugging they found this interesting method:

private static bool IsCompressionEnabled(HttpContext context) { 
    return ScriptingScriptResourceHandlerSection.ApplicationSettings.EnableCompression && 
        ((context == null) || 
        !context.Request.Browser.IsBrowser("IE") || 
        (context.Request.Browser.MajorVersion > 6)); 
}

This means that Ajax does support compression for Internet Explorer 7 but it does not support compression for Internet Explorer 6. Why?

Well, the fact is that IE6 has some serious troubles with compressed content, and those issues have been resolved in IE7:

• Internet Explorer may not decompress HTTP content when you visit a web site (scheduled for IE6 SP2)
• Internet Explorer does not correctly decompress data that uses the GZIP data compression method (scheduled for IE6 SP2)
• FIX: Internet Explorer 6 does not display the previous Web page when you browse an ASP.NET Web application and then click the Back button (scheduled for Windows XP SP3)

Another release containing several fixes is in the latest Windows Script 5.7 which contains updates for jscript parser:

• You may experience slow performance when you view a Web page that uses JScript in Internet Explorer 6 (scheduled for WinXP SP3)

The problem for a public Internet side is that you don’t know if advance if your users will have all those updated installed, and of course you cannot force them to update their systems; moreover there are some security updates released through Windows Update for IE6 have also updated the management for compressed resources. After some testing we found that customer’s application was finally working with IE6 but HTTP compression was  not used by the runtime, so we decided to create an alias for IE7 (see clientTarget element) and then set Request.ClientTarget by code to one of those aliases to force the runtime consider the request as if it were coming from IE7 even if it was actually IE6; this enables both HTTP compression for Ajax resources and partial compressed postbacks.

Carlo

Quote of the day:

The wages of sin are death, but by the time taxes are taken out, it’s just sort of a tired feeling. – Paula Poundstone