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? smile_wink) 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:

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

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

Comments (6)

  1. One of my client’s customers was really upset because Internet Explorer 6 would often hang on opening

  2. Kevin says:

    Is there a general solution to this problem?

  3. Well, if you’re in a controlled environment (your company’s Intranet) the easiest thing to do is likely upgrate to IE7, which does not have this problem. If yoou can’t, and installing the fixes above does not help, then I think you shoud try to change your application to specify the appropriate ClientTarget (see the last paragraph in the post above).

    I’m not sure at the moment if and when will be released a fix for IE6, it depends on how hard and "dangerous" is to change that part of the browser…

    HTH

  4. Again on the Ajax-compression subject (see here and here ), here’s another error I got recently: Sys.WebForms.PageRequestManagerParserErrorException:

  5. Http compression with client-side scripting should be handled with care. The problem can have different

  6. Kunal Kamboj says:

    Hi I am getting a similar error but in my mo dule i am not using any kind of compression. I wanted to implement some kind of security in my module but still i am getting error on the pages having ajax controls. Is there any work around for this….

    Pleas Help

Skip to main content