IE does not particularly like compressed CSS and JS and exhibits exactly the behaviour you describe when you download a compressed CSS or a compressed JS which compressed size is less than 5 KB (?? not sure about the number, but if memory serves me right it corresponds to some Windows registry setting). Compressing plain text or HTML works well.
In my view you have several choices: 1. If you really need to compress CSS and JS responses because most are big, but you have a few that are below the limit, you can pad those that are known to cause the problem. 2. If most CSS and JS are small, you can choose not to compress this kind of contents. 3. You can use mod_filter to execute the DEFLATE output-filter, you can create conditions on the types of contents you want to compress, and even on the size of each content. You can for example choose to compress CSS and JS only if the size exceeds a certain value. mod_filter is an Apache 2.1/2.2 module but can relatively easily be compiled for Apache 2.0 You state that you have the problem even though you do not compress JS. I do not however know about any other issue with IE that would cause the problem you describe, and the problem is definitely not in Apache. I have been using compression a little in 2.0.47, and heavily in 2.0.49 and 2.0.54, and never seen the exact problem you describe caused by anything else that IE/CSS/JS. Of course there may be other problems related to timing, scripts expecting certain variables to exist that are defined in another java script that has not yet initialised etc., but I doubt it is in your case. -ascs -----Original Message----- From: Simon Werner [mailto:[EMAIL PROTECTED] Sent: Friday, April 14, 2006 7:55 AM To: users@httpd.apache.org Subject: [EMAIL PROTECTED] Problems with JS, IE 6.0 and mod_deflate We are encountering a problem with IE 6.0 SP1 where it seems to have problems with compressed data being served from the IBM HTTP Server 2.0.47 (Apache). Using the mod_deflate option to compress static and dynamic data on the run. The problem is that the client side will "hang" and do nothing, we are not sure what it could be but it looks like it is related to the javascript files not being decompressed properly. The strange thing is that the problem appears semi-randomly on one client. We have tested it on about 5 clients. When the problem occurred we discovered that the last line of a javascript file is missing, this line only contains a closing bracket, }. However, this file downloads correctly on other clients and when mod_deflate is OFF. So when using the built-in script debugging tool provided with IE (or MS Office?) the execution works correctly until the last executable point in the file (which is not the last line), then the client application hangs, although IE is responding correctly. This leads me to the assumption that the file is not decompressed properly on the client or not compressed properly on the server (unlikely since it only occurs for one client). Even IBM, the providers of this Apache server are unable to solve the problem, see http://publib.boulder.ibm.com/httpserv/ihsdiag/deflate_diag.html . They reference an Apache module called mod_net_trace, but there are no other references to it on the web. On the Apache server we have enabled SSL (mod_ssl), client-side caching (mod_expires) and compression (mod_deflate). When we disable mod_deflate the client will run correctly. We have not tried disabling mod_ssl or mod_expires. Even when we disable compression for HTML and JS files the problem still occurs. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
