Info: current module enable status for trunk

[Rainer Jung <ra...@kippdata.de>]

Whoever wishes to know, which module is enabled under what conditions: I 
compiled a list avalable under

http://people.apache.org/~rjung/patches/mods_enabled.txt

Most of it is done by the script

http://people.apache.org/~rjung/patches/mods_enabled.pl

(it needs to be started in the trunk directory) with a bit of hand 
editing w.r.t. the conditionally included modules. I hope the results 
are correct, at least they look plausible.

I think some modules should change. There is a nice "default" setting, 
that will enable a module when "--enable-modules=all" is used.

Some of the new modules (and filters) use this default, like mod_sed, 
some other older modules still stick to "no" (not even enabled with all) 
like mod_proxy. I'd say "no" should be only for unstable, example, 
debugging and test stuff. Mod_proxy and mod_ssl (if ssl toolkit was 
detected) make good candidates for moving from "no" to at least "default".

The borders between "most" and "default" (=all) are vague. It seems 
parts of "default" are old stuff not frequently used (e.g. cern_meta, 
mime_magic), parts are new stuff which didn't yet make it into most 
(e.g. sed).

Regards,

Rainer

Re: Info: current module enable status for trunk

[Sergey Chernyshev <se...@gmail.com>]

On Wed, Jun 2, 2010 at 5:26 PM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote:

> On 6/2/2010 4:21 PM, Eric Covener wrote:
> > On Wed, Jun 2, 2010 at 5:16 PM, William A. Rowe Jr. <wr...@rowe-clan.net>
> wrote:
> >> On 6/2/2010 3:39 PM, Rainer Jung wrote:
>

Thanks for the list! Do you know the best way to extract similar data for
distros?


> >>> Mod_proxy and mod_ssl (if ssl toolkit was
> >>> detected) make good candidates for moving from "no" to at least
> "default".
> >>
> >> mod_ssl was 'no' simply because of concerns about cryptographic law and
> >> users in all these crazy jurisdictions.  But I'm willing to consider
> 'yes'
> >> on the basis that if openssl is not found, the default becomes 'no'.
> >
> > Did you really mean no->yes or no->most for mod_ssl?
> >
> > Or are you also thinking some of the innocuous "most" move to yes
> > (rewrite, expires, headers).
>

Can we move these from "most" to "yes"? expires and headers are probably
tiny and will not do any harm and rewrite is so widely used that it's
probably a good idea to have it in the "yes" even if it's not so tiny.


> > Finally, remember that on unix if you don't do your ./configure
> > homework you end up with all this stuff static.
>
> Sure, that's the beauty of --enable-mods-shared=most.  Yes, I meant 'most'
> :)
>

The size comment above mostly matters for static.

Also, is there any way to have mod_deflate module to auto-detect zlib
similar to your mod_ssl recommendations?

           Sergey

Re: Info: current module enable status for trunk

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 6/2/2010 4:21 PM, Eric Covener wrote:
> On Wed, Jun 2, 2010 at 5:16 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>> On 6/2/2010 3:39 PM, Rainer Jung wrote:
>>> Mod_proxy and mod_ssl (if ssl toolkit was
>>> detected) make good candidates for moving from "no" to at least "default".
>>
>> mod_ssl was 'no' simply because of concerns about cryptographic law and
>> users in all these crazy jurisdictions.  But I'm willing to consider 'yes'
>> on the basis that if openssl is not found, the default becomes 'no'.
> 
> Did you really mean no->yes or no->most for mod_ssl?
> 
> Or are you also thinking some of the innocuous "most" move to yes
> (rewrite, expires, headers).
> 
> Finally, remember that on unix if you don't do your ./configure
> homework you end up with all this stuff static.

Sure, that's the beauty of --enable-mods-shared=most.  Yes, I meant 'most' :)

Re: Info: current module enable status for trunk

[Eric Covener <co...@gmail.com>]

On Wed, Jun 2, 2010 at 5:16 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On 6/2/2010 3:39 PM, Rainer Jung wrote:
>> Mod_proxy and mod_ssl (if ssl toolkit was
>> detected) make good candidates for moving from "no" to at least "default".
>
> mod_ssl was 'no' simply because of concerns about cryptographic law and
> users in all these crazy jurisdictions.  But I'm willing to consider 'yes'
> on the basis that if openssl is not found, the default becomes 'no'.

Did you really mean no->yes or no->most for mod_ssl?

Or are you also thinking some of the innocuous "most" move to yes
(rewrite, expires, headers).

Finally, remember that on unix if you don't do your ./configure
homework you end up with all this stuff static.

-- 
Eric Covener
covener@gmail.com

Re: Info: current module enable status for trunk

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 6/2/2010 3:39 PM, Rainer Jung wrote:
> Mod_proxy and mod_ssl (if ssl toolkit was
> detected) make good candidates for moving from "no" to at least "default".

mod_ssl was 'no' simply because of concerns about cryptographic law and
users in all these crazy jurisdictions.  But I'm willing to consider 'yes'
on the basis that if openssl is not found, the default becomes 'no'.  So
the user installing openssl is opening themselves up to accidentally
creating a cryptographic channel in httpd, which seems just fine.