Antwort: [Mod_gzip] mod_zip and apache version

[mod_gzip@lists.over.net]

Hi Josep,


> 1.-  Which version of mod_gzip should I use for my system?

Of course I suggest using the most recent one suitable
for your Apache server.
For Apache 1.3.x, this is mod_gzip 1.3.26.1a at the moment.

> > Are mod_gzip versions related in anyway with apache versions?

Apache 1.3 and Apache 2.0 are very different products,
so mod_gzip has to be written to fit the architecture
of the Apache product.
But then, the Apache 1.3 architecture hasn't changed for
a long time, so you would be able to use any mod_gzip
version from about 1.3.14. on with any Apache version
from about 1.3.<singledigit> on - mod_gzip relies on some
Apache regular expression handling that has been intro-
duced in some early Apache 1.3 version, thus it would
not work with Apache 1.2. (Not that I would suggest
using such an olde Apache anyway ... ;-)

> 2.- Where can I find a fine manual so I can RTFM?

The document that I would consider to be closest to a
"manual" is on my website. It is part of the download
package of mod_gzip 1.3.26.1a.
If you have any questions not covered there, feel free
to ask (and help me improve the documentation by your
questions).
Actually, your questions already made me start adding
some of the corresponding information to these pages.

> 3.- Does anyone has mod_gzip used in production servers?
> I'd like to know what "gotchas" have you found on produc-
> tion environments.

Sure. I am using it for about a year now.
Any known bugs should be documented at the project's
bug list:
   http://sourceforge.net/tracker/?group_id=54975&atid=475503

> (mail, http or similar).

I don't understand what you mean with "mail" here.
mod_gzip is an Apache module, and is used for HTTP
traffic only.
The HTTP protocol (RFC2616) supports "encoding" the
content, which _may_ include applying a compression.
I am not familiar with the mail protocols and whether
they allow for any compression.

> I would like to use with our main webmail (https-squirrelmail)
> server.

It was a good idea that you mentioned "HTTPS" because
this alone will pose a problem, due to the architecture
of Apache 1.3 and the way mod_ssl operates.
I suggest you to read the "mod_gzip and SSL mini howto"
     http://lists.over.net/pipermail/mod_gzip/2002-February/005911.html
(and today I finally managed to remember putting this
 one on the link list of the mod_gzip docs, sigh ...
 maybe I should even make it part of the documentation.)

PHP seems to be a tricky issue as well, just because
there are so many ways you can use PHP in combination
with an Apache server.
You will have to find out which one applies to your con-
figuration, and then tell mod_gzip exactly what to do.

And then, there have been reports about problems using
mod_gzip with some web servers that claim to be Apaches
but have been modified internally by anyone.
I never heard about your "Squirrelmail" package - so I
cannot tell you whether you will experience any specific
problems there. But from the SourceForge project page,
this looks to be just a PHP application and no modifi-
cation of Apache itself.

> 4.- Any extra advice from mod_gzip users?

- Be aware of what you want to get. Simply compressing
  each and every HTTP output isn't a cure for everything.

- Use file formats that are free of redundancies (optimi-
  zed GIF/PNG images) so that you won't have to compress
  their content again and again.

- Do other optimizations as well - like running your
  Web content through some stripper that would remove
  unnecessary white space and the like.

- Think about keeping static pages in precompressed form
  cached on your Apache server; mod_gzip 1.3.26.1a will
  help you a lot with this, and this may save a lot of
  CPU power.

- Be aware of UserAgents having problems with compressed
  content - but don't let that intimidate you using it.

- Encourage the HTTP clients to not request the same con-
  tent again and again, by sending them expiration dates
  via HTTP headers ("Expires:", "Cache-Control:").

- As a front end for your Apache server, use a good proxy
  cache that is able to hold variants of negotiated
  (compressed/uncompressed) content, like Squid 2.5.

Regards, Michael