httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: [PATCH] mod_deflate
Date Sat, 16 Feb 2002 09:33:17 GMT
> From: Zvi Har'El [mailto:rl@math.technion.ac.il]
> 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

Mime
View raw message