> From: Zvi Har'El [mailto:[EMAIL PROTECTED]] > Sent: 16 February 2002 08:37
> On Fri, 15 Feb 2002 09:44:19 -0800, Ian Holsman wrote about "Re: [PATCH] >mod_deflate": > > > > > > I'm still not very happy about compressing EVERYTHING and excluding > > certain browsers > > as you would have to exclude IE & Netscape. > > > > so > > this is a > > -1 for this patch. > > in order to change this checks need to be there with a directive to > > ignore them (default:off) > > > > IMHO, deflating everything is a waste of the computer resources. HTML files > really compress well. But most of the image files currently supported, e.g., > PNG, GIF, JPEG are already compressed, and deflating them will really do > nothing -- just spend your CPU. I think that compressing text/html for browsers > who send "Accept-Encoding: gzip" is the right approach. A possible enhancement > is to have a directive (DeflateAddMimeType) which will enable deflating more > mime types, e.g., text/plain, but these are really rare! Another type which is > worth compressing is application/postscript, since many viewers (I am not an > expert which - at least those decendents of GhostScript) are capable of > viewing gzipped postscript files. The problem with that is that this is not a > function of the browser, which cannot handle such files, but a function of the > viewer, so the required "Accept-Encoding: gzip" doesn't prove anything about > the ability of the external viewer! > > To summerize, I suggest to deflate only types which can be handled by the > browser itself, and which are not already compressed, which amounts to > text/html or more generally text/* (text/css for instance). It is not a question of browsers. Subversion is also an HTTP client (for details on how subversion works: http://subversion.tigris.org), actually a DAV client, but that's not the point. We want to compress a lot more than what the common browser can handle. And from some preliminary testing, we've seen a big win with compression (traffic size reduced to 10% of the original. Disclaimer: this number is not acurate). I refuse to rule this out by saying: "the common browser doesn't support this". I'd much rather decide on browser and content type, which could be done through configuration. Your DeflateAddMimeType could be an option, but I'd rather see AddOutputFilter take a content type argument: AddOutputFilter <filter> (<content type> | <extention>). Anyhow, it is more about configuration now than to the codes default. > Best, > > Zvi. Sander
