httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: [PATCH] mod_deflate extensions
Date Sat, 23 Nov 2002 06:05:20 GMT
At 09:58 AM 11/21/2002, Henri Gomez wrote:
>>>So what about for 2.0.45 dev ?
>>
>>My prediction about interest in such a switch was independent of
>>timeframe.  I doubt that such a switch will ever happen.
>
>2.0.44 won't be the last 2.0 release isn't it ?

No... 2.0.45 will be compatible with 2.0.44 modules, if and when 
a significant number of bugfixes or a security hole is patched.

2.0.x will simply remain compatible with 2.0.42 forward.

Authors may choose not to backport new features to 2.0, or they
may do so, it's up to them.

>>>What do you means ?
>>>
>>>- Put zlib full source tree in Apache 2.0 tree and make
>>>  a static build ?
>>
>>not all of zlib is necessary...  and if we build zlib as a
>>library (instead of pulling specific objects into mod_deflate.so) we
>>have portability problems to deal with...
>
>We could grab the compression part, like does mod_gzip, mod_gzip even use zlib includes.

Actually, we do need decompression in some cases (which was subject
to the security hole suffered with earlier zlib versions).  Proxy might be
one such example.  Another would be ungzipping cached content based 
on the client accept-encoding details.

>>>- Put part of zlib code in Apache 2.0 source ?
>>
>>that is what I suspect to be the safest, easiest-to-understand way...
>>the build would work like on Windows, where the project file for
>>mod_deflate pulls in the right parts when building mod_deflate.so
>
>Ok

That is an interesting concept - I actually just took the time to get
zlib building on win32 with a parallel configure.pl script.  I'll post that
fun at some point.  The biggest PITA on Win32 was the choice of
compiling against static c libraries instead of msvcrt which Apache
lives with.  

Building in some static clib while leaving others dynamic just seemed 
evil to me, so none of the win32 library-build examples work out of 
the box to give you msvcrt linkage.  My playing with a configure.pl
script was just another means to that same end.

>>another nice feature of this is that if we know we are using our build
>>of the zlib source then we can turn on the zlib compile option to
>>namespace-protect the zlib routines and then change mod_deflate to
>>assume that (but perhaps the compile switch will make mod_deflate use
>>the namespace-protected versions automatically anyway)...  OtherBill
>>mentioned this namespace protection before but I haven't had a chance
>>to play with it
>
>Or what about adding zlib compression in APR project, which is more system related and
use it ? The APR 0.9 branch is still open ?

Good idea.  The point is that we can always add to a branch for a future
release as long as we aren't breaking compatibility.

>>I already saw a user having problems because a shared library used by
>>a 3rd party module also had a routine called crc32().
>
>Yes, and I've encountered problem with mod_gzip because one the PHP module was linked
against ct_lib ;)

Such a hassle, yes.

>>>- or make configure detect zlib shared lib and make mod_deflate
>>>  available by default ?
>>
>>if this can be made foolproof then this is perhaps a good option
>>too...  but I'm not sure that is portable on whether the DSO needs to
>>be linked with zlib or whether httpd needs to be linked with zlib...
>>and if httpd needs to be linked with zlib then the export file
>>generation needs to do the right thing...  IIRC, one solution that
>>would work fine on Linux and Solaris and FreeBSD wouldn't work on
>>HP-UX (I might have the platforms listed in the wrong place; maybe AIX
>>was one of the platforms)...
>
>So extracting zlib source part and include them in Apache or APR seems to be the best
solution.



Mime
View raw message