[Cosmo-dev] Gzipping dojo.js
mde at osafoundation.org
Fri Feb 9 10:50:25 PST 2007
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.
"Internet Explorer (versions 4 through 6) has some more interesting
sometimes incorrectly decompress the resource, or halt compression
halfway through, presenting half a file to the client. If you rely on
1. Content with "Content-Encoding: gzip" Is Always Cached Although You
Use "Cache-Control: no-cache"
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
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
It looks like this stuff is fixed in IE7.
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
More information about the cosmo-dev