[Mod_gzip] gzip vs deflate on Apache

[mod_gzip@lists.over.net]

Hi all,


> mod_deflate actually provided GZIP-encoded content, despite it's name.
> It is native to Apache 2.0.x and must be compiled in to work. mod_gzip
> for Apache 2.0.x is available, and does have more configuration options
> for logging, etc., but, as far as I can tell, is not being actively
> supported; Michael may be better able to describe how active the
> mod_gzip development team has been lately.

okay, then let's see how I feel about the situation right now ...

For Apache 2.x, there is mod_deflate, and the most recent version
can even compress files with a configurable gzip level, while some
earlier versions were only able to do the equivalent of "gzip -1".
Compared to mod_gzip 2.0 versions (which are much older than 1.3.26.1a,
rated by the supported directives) I see little reason why one should
not use mod_deflate, as this one is under active support by the Apache
Group. As for the compression quality, there were already comparison
tests between both modules some months ago, as the mod_gzip mailing
list archive shows - and they have directly led to the latest upgrade
for mod_deflate, providing additional configuration directives.

I believe the Apache Group finally made mod_deflate good enough to
provide basic compression support for Apache 2.x, while still not
supporting some of the mod_gzip configuration directives.
And if my last year of dealing with mod_gzip did nothing else but
help mod_deflate matching the need of the users, then it would still
have been a good investment.
>From the beginning, it was the intention of Kevin Kiley to provide
compression support for Apache - not to have some module to call his
own. This is why he tried to donate the mod_gzip source code to the
Apache Group in the first place. But given the things that happened
back then, I now prefer having a powerful mod_deflate inside the
Apache standard package to insisting on a mod_gzip 3rd party module
for Apache 2.x; in the long run, everyone might be better off this
way. So if any mod_gzip user needs features in Apache 2.x that
mod_deflate doesn't provide yet, then I encourage them to write a
feature request for mod_deflate to the Apache Group about it.

This of course doesn't mean mod_gzip is to be considered obsolete
or dead (just like Apache 1.3 is none of both - they even implement
new directives into Apache 1.3 now and then, just have a look at the
"Compatibility" note for this one:
     http://httpd.apache.org/docs/mod/mod_usertrack.html#cookieformat).
The concept of maintaining its own cache of statically precompressed
files in mod_gzip 1.3.26.1a may stand out as an example what a com-
pression tool might be able to do, and this one is unlikely to become
part of mod_deflate in the near future IMHO (because having an Apache
module writing into user directories might be a question of style;
mod_proxy has the same task but used a different approach, having
some own caching directory outside the URL tree). mod_gzip tried to
provide a solution with minimal effort, using features that were
available already (i. e. its own negotiation feature); a correspon-
ding functionality might well be implemented into mod_deflate in a
very different way (just like gzip_cnc did it, using its own cache
tree outside the URL space - but then it needs to know about this
when doing the negotiation, so Apache's standard content negotiation
mechanism wouldn't be able to provide the required feature).
The implementation of the gzipping code by Kevin Kiley is another
piece of code that isn't covered by mod_deflate (which relies on the
zlib being installed already). I am not enough of a C programmer to
actually compare the quality of both implementations, but I trust
Kevin to have had a sound reason to do this implementation instead
of just going the easy way and simply use the zlib (which is what
mod_gzip 2.0.xy is still doing - thus the huge difference of source
code size between mod_gzip 1.3 and 2.0).
And the logging features of mod_gzip do still provide information
that mod_deflate cannot give you - for statistical evaluations and
for debugging purposes (like the mod_gzip status codes).
On the other hand, it might not be fair to compare the requirements
for logging between an Apache 1.3 module and an Apache 2.0 module,
just because the mechanism of embedding mod_gzip into Apache 1.3 is
so totally different to the filter mechanism of Apache 2.x, and
thus requires much more configuration effort: You can't just blame
mod_deflate for the mere existance of the Apache 2.0 filter concept.

For Apache 2.x, the question seems to be whether any C programmer
needs the additional features of mod_gzip 1.3.26.1a so much that he
would invest the effort of porting the module to the Apache 2.0 API
- or possibly implementing these features into mod_deflate (which
would then require the Apache Group to consider these features to
be important enough).
Another way to go might be writing a guide how do emulate mod_gzip
features by Apache 2.x configuration directives as far as possible.
mod_deflate doesn't have all those include/exclude filter rules, but
Apache has directives like "<FilesMatch>" that allow for very similar
things; mod_deflate doesn't support the flexible creation of "Vary:"
headers, but there is mod_headers to do that in Apache 2.x; and so
on.
Maybe Lance Morrison could be the one who is interested in investing
time into such a project - if so, I'd offer my support for that.
And maybe Ian Holsman, the mod_deflate author, would like to support
such a project as well?

Since Kevin Kiley has been sidelined from mod_gzip development (due
to events beyond control of all of us), there has been only one C
programmer who volunteered to implement new features and bug fixes
to mod_gzip, and that is Christian Kruse. But he is busy in other
projects as well, and he didn't have much time during the better
part of this year anyway.
Open Source development is based on contributions by programmers.
If no C programmer is available to further develop mod_gzip, then
there will not be any further development.
We already were in that situation after mod_gzip 1.3.19.1a; all I
could do then was write a manual, collect and document open issues,
and provide some base which another programmer could start working
from (which is just what Christian did then).
Happily, the to-do list for mod_gzip isn't too long at the moment,
so mod_gzip is usable even without an active C developer right now.

Regards, Michael