Uhm? Also ich habe aus diversen Quellen gelesen, dass mod_gzip und mod_ssl sich nicht vertragen. Bin mir auch sehr sicher, dass es nicht ging.
Ich rede von Apache 1.x, vielleicht ist das der Grund? :o)
Die 2.xer sind mir noch ein wenig suspekt.
Und hier noch der Beweis:
* SHORT ANSWER
The situation has not changed. It is still not possible for
the Apache 1.x code to load a standard module in conjunction with
mod_ssl that can directly compress the data before
it is encrypted. It's never been possible.
* WHY NOT? ( THE LONG ANSWER )
mod_ssl is not a 'standard' Apache module and it
doesn't install and/or load the way all the others do.
mod_ssl for the Apache 1.3.x series is, and always
has been, a 'hack' on Apache that enables it to
do encryption.
What mod_ssl really does is the following...
When you INSTALL mod_ssl you are basically
giving it permission to REWRITE your Apache code.
That's why you have to re-compile Apache when
installing mod_ssl. It does not use the 'standard'
module methods and has to rewrite significant
portions of Apache in order to have any chance
at working.
It may not SEEM like this is what is happening if
you are just getting Apache + mod_ssl binary
distributions from some RPM or tarball but I assure
you that whoever is putting together that package
had to do the 'recompile' step and let mod_ssl
rewrite the Apache Server code.
mod_ssl rewrites Apache so that it can STEAL the
low level connection interface in order to have a
chance at doing the SSL handshakes. Apache
was not desgined for this and so this feature had
to be 'hacked' into Apache.
The mod_ssl folks actually applied some design
concepts in order to pull this off and they came up
with something for Apache called the EAPI ( Extended
API ) which was 'designed' to allow modules to take
over parts of Apache that were not possible using
the standard Apache module interface.
What they intended Apache to do was to ADOPT their
EAPI interface and code so that they would not have
to ask users to REWRITE Apache just to get SSL
working.
The Apache group REJECTED this EAPI design and
interface and so it was never made part of the
'regular' Apache code distribution and now the mod_ssl
folks were up the creek without a paddle.
So they punted and just decided to bundle the EAPI
stuff along with mod_ssl itself and require users to
let THEIR installation routines rewrite Apache and
install this EAPI thing that mod_ssl depends on.
That's why you will sometimes get that crazy startup
warning in the Apache logs about some module
"Not being compiled for EAPI". Once you let mod_ssl
rewrite Apache and install this EAPI stuff it is now
not even smart enough to tell the difference between
modules that were included in the re-compile and
ones that were not so it will 'warn' you if any module
doesn't contain THEIR signature. The mod_ssl rewrite
actually ADDS things to the standard Apache module
dispatch control structure so the size of it is different.
They add their stuff to the END of it, though, and so the
warning really doesn't matter as long as it is truly not a
situation where a module is trying to use one of the
mod_ssl EAPI calls and was not actually compiled
to do so. That's all the warning is really for.
They still thought that even though Apache officially
rejected the EAPI interface that other module authors
would start 'using' it in their own modules so that's
why they added the 'warning' to the startup... just to
remind other authors that they might have forgotten
to re-compile with EAPI switch ON.
To this day, however, I don't thing ANY other module
uses ANY of the EAPI stuff other than mod_ssl so
it's really just a 'private' deal for mod_ssl.
If you look at the code for mod_gzip you will see that
there never really was this necessity for mod_ssl to
rewrite standard Apache 1.3.x in order to do what they
want but the mod_ssl folks just didn't see how it was
possible to take over the input/output streams without
this EAPI 'rewrite' of Apache. mod_ssl pre-dates
mod_gzip.
So mod_ssl is really not a 'standard' Apache module
at all and it doesn't 'follow the rules' established for
modules. It just happens to 'look' like a standard
module.
Anyone can 'rewrite' Apache and make it do whatever
they want but mod_gzip does what it does by 'following
the rules' and was written as a standard 'plug and play'
module so that no one would have to apply any patches
or 'rewrite' Apache in order to use it. This was the whole
idea behind the 'modular' design of Apache 1.x.
(...and ANY modular design, actually. You're not supposed
to have to recompile anything. )
So once mod_ssl has 'rewritten' Apache... all the low-level
connections are 'taken over' by mod_ssl itself and the
Apache input/output is no longer going through the
'standard' Apache 1.x 'buff' interface. That's why mod_gzip
is unable to compress the outbound data... mod_ssl has
it locked up for itself.
* APACHE 2.x SERVER
The new 'filtering' scheme in the new Apache 2.x Server
was actually specifically designed to handle this mod_ssl
'hack' and other issues about filtering Apache I/O and
do away with hacks like mod_ssl uses once and for all.
It is NOW possible to write a module for Apache that
CAN intercept the connections and the I/O at a very
low level and you do NOT need the old EAPI mod_ssl
stuff to do it.
The entire time they were designing and coding this
new low-level filtering scheme in Apache 2.0 the
only real examples of using it that any of the designers
could ever come up with was either COMPRESSION or
ENCRYPTION issue(s).
They realized it would 'work' for a lot of other filtering
situation if they pulled it off ( like character translation
and other simple stuff ) but the only serious discussions
were centered on COMPRESSION and ENCRYPTION
and that sort of ( transport layer ) stuff.
What they have now is really what they wanted in the
first place and is, in their minds, the 'better' way to
'filter' the data coming into and out of Apache.
mod_ssl for Apache 2.x has actually be 'rewritten' to
use the new 'filtering' scheme to do the encryption
and as far as I know it actually works... but I'm not
sure it's been tested a whole lot.
There was a real frap about doing this when the time
came for it to be done but the Apache folks slugged
it out with the mod_ssl folks and got them to
rewrite mod_ssl for the 'new' filtering scheme.
So it is now THEORETICALLY possible to just add
mod_gzip into the filter chain along with mod_ssl
and get the outbound data compressed as well as
encrypted... but I am not sure anyone has actually
tried/tested this with Apache 2.x
Not many people are using Apache 2.x even though
it's been out for almost 2 YEARS now. It still has
a LOT of bugs.
That's about the long and short of it.
Hope that answers your question.
Later...
Kevin
http://lists.over.net/pipermail/mod_gzip/2003-October/007208.html [lists.over.net]
Es gaebe hoechtens einen fiesen Hack mit Proxy, aber das finde ich extrem unschoen:
http://lists.over.net/pipermail/mod_gzip/2003-July/007141.html [lists.over.net]
