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

[Josep L. Guallar-Esteve]

On Wednesday 15 January 2003 01:05 pm, Michael.Schroepl@telekurs.de wrote:
> Hi Josep,

Hi Michael

> >> 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.

I've tried recompiling the mod_gzip srpm (source rpm) package from Mandrake 
8.2 at a RedHat 7.3 system. It didn't work! mod_gzip doesn't like apache 
version:
# rpm -bb mod_gzip.spec
error: failed build dependencies:
        apache = 1.3.26 is needed by mod_gzip-1.3.19.1a-12rh73
        apache-devel = 1.3.26 is needed by mod_gzip-1.3.19.1a-12rh73
# rpm -q apache
apache-1.3.27-2

... I modify spec file with
(...)
%define apache_version 1.3.27
(...)
%define name mod_gzip
%define version 1.3.19.1a
%define release 12rh73
(...)
BuildRequires: apache = 1.3.27
BuildRequires: apache-devel = 1.3.27
(...)

I build the package:

# rpm -bb mod_gzip.spec
(...)
Wrote: /usr/src/redhat/RPMS/i386/mod_gzip-1.3.19.1a-12rh73.i386.rpm
(...)

# rpm -q apache
apache-1.3.27-2

# rpm -ivh mod_gzip-1.3.19.1a-12rh73i386.rpm
error: failed dependencies:
        apache = 1.3.26 is needed by mod_gzip-1.3.19.1a-12rh73
        apache-common = 1.3.26 is needed by mod_gzip-1.3.19.1a-12rh73
        apache-conf = 1.3.26 is needed by mod_gzip-1.3.19.1a-12rh73

I've tried to change the requirements in the spec file fom "=" to ">=". But 
still complains :(

Any idea?

> >> 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).

It is PHP

> 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.

Excellent.

> >> - 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.

I'll have to look into this.

> >> - 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 ...

We have a sensible CIO. Some users decide to use IExplorer, version 5.5. But 
they are on their own.

> >> - 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?

Yes, it's dynamic. PHP builds on-the-fly html pages.

> 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.)

My "problem" is because this dynamic content is delivered through SSL, so I 
assume that the PHP pages have a very limited life.

> >> - 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.

Yet another machine? Ufff! I don't think we could possibly add yet another 
server.

> Regards, Michael


Salut,
Josep
-- 
Josep L. Guallar-Esteve		Eastern Radiologists, Inc.
Systems and Network Administration  http://www.easternrad.com