My bad experience was with Netscape 4.7. The problem was if the *first* compressed thing it saw was *not* html, e.g. if it was Javascript when the corresponding html file was not compressed.
Once it saw compressed html, though, it could then reliably uncompress Javascript as long as you kept the browser open. -P -----Original Message----- From: Mark Maunder [mailto:[EMAIL PROTECTED]] Sent: Monday, October 29, 2001 2:20 PM To: Joshua Chamas Cc: Ged Haywood; Matt Sergeant; [EMAIL PROTECTED] Subject: Re: Apache::Compress - any caveats? > Ged Haywood wrote: > There was one odd browser that didn't seem to deal with gzip encoding > for type text/html, it was an IE not sure 4.x or 5.x, and when set > with a proxy but not really using a proxy, it would render garbage > to the screen. This was well over a year ago at this point when this > was seen by QA. The compression technique was the same used as > Apache::Compress, where all of the data is compressed at once. > Apparently, if one tries to compress in chunks instead, that will > also result in problems with IE browsers. We've been testing with Opera, Konqueror, NS 4.7 and 6 and IE 5, 5.5 and 6, AOL and Lynx and haven't had any probs. (haven't tested IE below version 5 though *gulp*) The only real problem was NS 4.7 which freaked out when you compressed the style sheet and the HTML (it wouldn't load the style sheet) so we're just compressing text/html. > Note that it wasn't I that gave up on compression for the project, > but a lack of management understanding the value of squeezing 40K > of HTML down to 5K !! I would compress text/html output to > netscape browsers fearlessly, and approach IE browsers more > carefully. I differ in that NS instils fear and IE seems to cause less migranes. Agree on your point about management ignorance though. Isn't bandwidth e-commerce's biggest expense?
