[Cosmo-dev] Gzipping dojo.js

Adam Christian adam at osafoundation.org
Fri Feb 9 11:08:25 PST 2007


This may just be oversimplified but can't you have a small piece of  
logic that grabs the gzipped for everything other than ie6? And we  
can make a note in the "known issues" saying yes we know ie6 is way  
slower and explain why

This is what I did in Windmill and it worked fine.

<script type="text/javascript">
		if (browser.isIE){
			url = 'lib/ieController.js';
		}
		else {
			url = 'lib/Controller.js.gzip';
		}
		document.write('<script src="', url, '" type="text/javascript"><\/ 
script>');
</script>

Adam

On Feb 9, 2007, at 10:50 AM, Matthew Eernisse wrote:

> It's our old friend, IE6 again -- IE6 is known not to work reliably  
> with gzipped content, despite the fact that it's supposed to  
> support it.
>
> From the "Serving JavaScript Fast" article:
>
> http://www.thinkvitamin.com/features/webapps/serving-javascript-fast
>
> "Internet Explorer (versions 4 through 6) has some more interesting  
> issues. When loading gzipped JavaScript, Internet Explorer will  
> sometimes incorrectly decompress the resource, or halt compression  
> halfway through, presenting half a file to the client. If you rely  
> on your JavaScript working, you need to avoid sending gzipped  
> content to Internet Explorer."
>
> From MS:
>
> 1. Content with "Content-Encoding: gzip" Is Always Cached Although  
> You Use "Cache-Control: no-cache"
>
> http://support.microsoft.com/kb/321722/EN-US/
>
> This one is not so much of an issue for us, since IE has such a  
> screwy caching mechanism in the first place -- we're now versioning  
> the js directory, and we have to use the query string hack anyway  
> when we want to make sure IE gets updated content.
>
> 2. Internet Explorer May Lose the First 2,048 Bytes of Data That  
> Are Sent Back from a Web Server That Uses HTTP Compression
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496
>
> This is the biggie that you hear about the most.
>
> It looks like a Service Pack was supposed to have fixed this, but I  
> don't know if our supported browser configurations specify the  
> latest Service Pack -- or if that's even feasible to require.
>
> The 'workaround' for this problem is stated as "Disable HTTP  
> compression by changing the Web server's configuration." :)  
> (Although I think I also remember hearing someone mention adding 2K  
> of blank space at the beginning of the file for IE to throw away.)
>
> Bottom line is that we need to be able to ensure that IE6 always  
> gets the unzipped file -- regardless of what type of content it  
> purports to accept.
>
> It looks like this stuff is fixed in IE7.
>
>
> M.
>
>
> Travis Vachon wrote:
>>>
>>> The compiled dojo.js added in 0.6.0 is 444Kb.  When gzipped (with  
>>> regular compression), the size is 114Kb.
>> !!!!!!
>> :-D :-D
>> !!!!!!!
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev



More information about the cosmo-dev mailing list