RE: Apache::Compress - any caveats?
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?
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?
Re: Apache::Compress - any caveats?
Ged Haywood wrote: > > > > I think because many browsers claim to accept gzip encoding and then > > > fail to cope with it. > > > > Such as? > > It's second hand information - Josh had some trouble last year when we > were working on the same project, and I think he eventually gave up > with gzip because of it. He doesn't read the mod_perl list all the > time (being a busy chap:) so I've copied him in on this and maybe > he'll give us the benefit of his experience. Maybe he'll tell you I'm > talking through my hat too... > 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. 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. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
RE: Apache::Compress - any caveats?
Hi Matt, On Mon, 29 Oct 2001, Matt Sergeant wrote: > > -Original Message- > > From: Ged Haywood [mailto:[EMAIL PROTECTED]] > > > > On Wed, 24 Oct 2001, Mark Maunder wrote: > > > I noticed that there are very few sites out there using > > > Content-Encoding: gzip - in fact yahoo was the only one I could find. > > > > I think because many browsers claim to accept gzip encoding and then > > fail to cope with it. > > Such as? It's second hand information - Josh had some trouble last year when we were working on the same project, and I think he eventually gave up with gzip because of it. He doesn't read the mod_perl list all the time (being a busy chap:) so I've copied him in on this and maybe he'll give us the benefit of his experience. Maybe he'll tell you I'm talking through my hat too... 73, Ged.
RE: Apache::Compress - any caveats?
> -Original Message- > From: Ged Haywood [mailto:[EMAIL PROTECTED]] > > Hi there, > > On Wed, 24 Oct 2001, Mark Maunder wrote: > > > I noticed that there are very few sites out there using > > Content-Encoding: gzip - in fact yahoo was the only one I could > > find. Is there a reason for this > > I think because many browsers claim to accept gzip encoding and then > fail to cope with it. Such as? I've been delivering gzip from axkit.org and take23.org for nearly a year now, and had only one complaint (a Netscape 3 user on Solaris who didn't have a /usr/bin/gunzip installed), so I'm curious. (Admittedly I don't exactly have a large number of users). _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Re: Apache::Compress - any caveats?
Ged Haywood wrote: > Hi there, > > On Wed, 24 Oct 2001, Mark Maunder wrote: > > > I noticed that there are very few sites out there using > > Content-Encoding: gzip - in fact yahoo was the only one I could > > find. Is there a reason for this > > I think because many browsers claim to accept gzip encoding and then > fail to cope with it. The only bug I have noticed is Netscape 4.7 which does not like anything other than HTML to be compressed. So the only thing I'm compressing is text/html. I dont know of any browsers that wont accept compressed html (so far).
Re: Apache::Compress - any caveats?
Hi there, On Wed, 24 Oct 2001, Mark Maunder wrote: > I noticed that there are very few sites out there using > Content-Encoding: gzip - in fact yahoo was the only one I could > find. Is there a reason for this I think because many browsers claim to accept gzip encoding and then fail to cope with it. 73, Ged.