Apache::Compress - any caveats?
I had developed Apache module mod_deflate that allow to gzip or deflate content: ftp://ftp.lexa.ru/pub/apache-rus/contrib/mod_deflate-1.0.7.tar.gz This module tested at one of the loaded Russian sites - www.rambler.ru and several other small Russian sites. Documentation in Russion only but basic configuration is very simple: DeflateEnable on mod_deflate encodes 'text/*' content type. By default mod_deflate allows encoding if request is HTTP/1.1 and request is not proxied (it can be changed). So Netscape 4 requests is not encoded by default. During testing I found some browser bugs with gzip: MSIE 4.x can't handle gzipped content if length of URL string without 'http://' prefix is bigger then 253 characters. Mozilla 0.9.1 and Netscape 6.1b1 don't understand encoding if header line has tralling spaces - "Content-Encoding: gzip ". Macromedia FlashPlayer 4.x-5.x doesn't understand gzipped content recieved by browser via getVariables() function. Igor Sysoev
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.
Apache::Compress - any caveats?
I'm using Apache::Compress with Apache::Filter successfully and have modified it to only compress text/html (due to a bug in netscape 4.7). It's working fine with all version of the following browsers: Konqueror, Netscape, IE, Opera, Lynx and AOL. I was wondering if anyone has had any bad experiences with it or knows of any caveats? 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 (besides a bit of extra CPU usage on the server side)?
