Antwort: Re: Antwort: [Mod_gzip] mod_zip and apache version

[mod_gzip@lists.over.net]

Hi Josep,


>> 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.
> You answered my question.

;-)

> But my "real" question should have been:
> Do you need mod_gzip-1.3.12 for apache-1.3.12 and so on?

The mod_gzip version is just related to the Apache
version that was available when this mod_gzip version
was tested.

> Are mod_gzip version numbers related in any way to apache version
numbers?

Nope - unless you have at least 1.3.<singledigit>,
because of the regular expression support.
Everything more recent is fine - as the Apache 1.3
API is known to be stable.

> By your answer, I understand that they are not related.

That's what I wanted to say. ;-)

>> 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.
> OK. Although Squirrelmail team happily points to mod_zip
> to work with their product, a PHP application.

I think mod_gzip and PHP work together well when con-
figured appropriately (and this depends on how you
embed PHP into Apache - CGI, module, whatever).
But SSL definitely looks like a problem.

>> - 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.
> php-generated files, text only.

Then you can expect a great compression factor.
My guess would be a factor between 3 and 4 for HTTP
content only, and about 60% of the whole TCP/IP traffic.

>> - Do other optimizations as well - like running your
>>   Web content through some stripper that would remove
>>   unnecessary white space and the like.
> Mmmm. Can you provide some pointers about this?

Basically, this is the same idea as the squirrelmail
page you linked to earlier tries to tell you.
Whoever creates HTML pages might well let their source
code be unreadable as only few people want to read it.
Therefore, don't indent (or even comment!) HTML source
code and the like, rather remove each and every white-
space and maybe even line breaks.
Every byte that isn't output doesn't have to be compressed.

>> - Be aware of UserAgents having problems with compressed
>>   content - but don't let that intimidate you using it.
> Mozilla is the corporate-supported browser. Mozilla is
> listed as supported browser. If a users uses a non-supported
> browser, they are on their own. They can always go back to Mozilla.

Life has been nice to you. ;-) Our customers still
include 17% Netscape 4 users, sigh ...

>> - 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:").
> I believe that this doesn't apply. The usage of this webserver
> is webmail.

So every single URL that is accessed will be served by
a CGI-type dynamic output?
And even so, there might be parts that are dynamic but
don't change within seconds, thus might be worth being
cached. (I even have a search engine whose results have
an expiration date of 30 seconds ... I am happy with
each database access that isn't really being performed.)

>> - 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.
> Working with SSL conenctions and email, makes me think that
> a proxy won't really help. Correct me if I'm wrong.

You would at least be able to distribute the load between
two machines, one being a caching front end, the other
being the dataserver backend. Of course, the front end
would then have to understand SSL, and the ratio of pages
of cacheable content shouldn't be too low. So maybe in
your scenario this idea isn't really applicable.


Regards, Michael