httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject why mod_gz "now" ? (was: Re: cvs commit: httpd-2.0 STATUS)
Date Mon, 10 Sep 2001 19:34:39 GMT
On Mon, Sep 10, 2001 at 12:26:58PM -0400, wrote:
> If everyone really agrees with Justin/Ian and others that the
> development tree needs a GZIP filter BEFORE the next
> beta and it ( for some reason ) has to become part of the
> core *at this moment* then just go with mod_gz.

For people to easily work with it, test it, fix it, etc, then placing it
into modules/experimental is the way to go. Consider the caching stuff in
there right now. Maybe that stuff works, maybe not. But its presence in
source control means that more than one person can easily work on it. It
means that when somebody makes a change, a commit email is sent out for
review. It means that people can configure it into their server and try it

Living as a [PATCH] on a mailing list doesn't provide for any of those

> Heck... mod_gzip doesn't even use ZLIB so if my conversations
> with Mark Adler about the specifics of you guys using ZLIB
> if you want to doesn't prove we really are just trying to help
> and make sure you have all the information you need to make
> and intelligent decisin then I don't know what would.

We appreciate the information about zlib, but I think it will be easier for
us to work with alternatives and other stuff when we have the stuff in our
CVS repository.

> I am just pointing out that no one has done a really good
> code review of mod_gz even if the 'consensus' is to drop
> it into the core.

Yup. It was posted as a patch. Its potential for addition to the repository
was in question, so why would somebody spend precious time to review a black
sheep? :-)

Consensus is to have it in the core, insofar as modules/experimental can be
called the core.

> I've already pointed out one or two problems
> ( minor ) but a new one I found is that it seems to duplicate
> the addition of the GZIP header at all times ( gets added twice?)
> before the EOS bucket is sent down the pike. Client-side results 
> could be unpredictable. Depends on the browser. It is also completely 
> ignoring the FLUSH bucket when it arrives and has no way to add 
> 'Content-length:' if/when it is necessary.

All good points. There are also a bazillion other things that mod_gzip 1.x
does, which mod_gz can't do (and you've explained that it should). That work
can be done with the module placed into the experimental directory.


Greg Stein,

View raw message