simple-conf ready for merge
I'm pretty-much done shredding the default config and I will give a couple days for review before I merge it. Feel free to correct any problems you see. Things that I know are missing: - updates to docs: new-features, upgrading, apachectl (remove startssl), CHANGES - changes to windows config. The actual config file changes are easy enough, but I'm not sure my nmake/awk skills are good enough to fix the install. I think this config is far clearer and more manageable for a newcomer, and probably also for an experienced httpd-user. It is also more secure in that it has less features enabled by default. And it clears out a lot of cruft that had built up over the years. The disadvantages are that it takes a little more work to get some basic features enabled, and it may tempt some users into the death by a thousand config files syndrome, although it by no means forces them into this. You can see the new config here: http://svn.apache.org/repos/asf/httpd/httpd/branches/simple-conf/docs/conf/ Joshua.
Default Modules
I changed mod_imap this morning from 'yes' to 'most', because I was tired of disabling it every time I do a new install. I think we should reconsider what modules are enabled by default. Here is my list of suggested changes: mod_version: all - yes mod_asis: yes - no mod_imap: most - no mod_dumpio: most - all mod_rewrite: most - yes I think adding mod_rewrite as a default is the most controversial... so, what about the others :) ? A setting of 'yes' means the module will be enabled by default, without any extra flags to be set by the user. A setting of 'no' means the user must explicitly enable the module, eg, --enable-imap. A setting of 'all' or 'most' means it will be included in --enable-mods-shared=[all |most] -Paul
Re: Default Modules
Paul Querna wrote: I changed mod_imap this morning from 'yes' to 'most', because I was tired of disabling it every time I do a new install. I think we should reconsider what modules are enabled by default. Here is my list of suggested changes: mod_version: all - yes mod_asis: yes - no mod_imap: most - no mod_dumpio: most - all mod_rewrite: most - yes +1 on all of these. I think adding mod_rewrite as a default is the most controversial... so, what about the others :) ? How about mod_ssl being on in most? --Rich
RE: simple-conf branch
As part of this, it could be useful to generate a RunningConfig.cnf file as part httpd startup, which would be a merged config file with comments indicating which file set the option (and possibly which options have taken defaults). This would hopefully reduce problems with conflicting options in multiple config files, and also make it easy to work out what defaults have been used. Of course, this is a more involved change than a simpler default config. Phil Lello
Re: simple-conf branch
On 6-Apr-05, at 11:43 AM, Phil Lello wrote: As part of this, it could be useful to generate a RunningConfig.cnf file as part httpd startup, which would be a merged config file with comments indicating which file set the option (and possibly which options have taken defaults). You can get easily get most of that information with the version of mod_info in 2.1.
Re: simple-conf ready for merge
--On Wednesday, April 6, 2005 10:42 AM -0400 Joshua Slive [EMAIL PROTECTED] wrote: I'm pretty-much done shredding the default config and I will give a couple days for review before I merge it. Feel free to correct any problems you see. +1 to merge back to trunk. (14k vs. 38k. Yay!) One last thought: do we really need 'UseCanonicalName Off' - isn't our unset default equivalent? Same goes for HostnameLookups (the unset default is Off). IMHO, these seem more appropriate for httpd-default.conf. -- justin
Re: Default Modules
--On Wednesday, April 6, 2005 12:29 PM -0400 Rich Bowen [EMAIL PROTECTED] wrote: How about mod_ssl being on in most? In the past, we've said that SSL must be explicit because of the crypto legal restrictions. -- justin
Re: Default Modules
--On Wednesday, April 6, 2005 9:15 AM -0700 Paul Querna [EMAIL PROTECTED] wrote: I changed mod_imap this morning from 'yes' to 'most', because I was tired of disabling it every time I do a new install. I think we should reconsider what modules are enabled by default. Here is my list of suggested changes: mod_version: all - yes Sure. mod_asis: yes - no mod_imap: most - no I would prefer we keep mod_imap as most. Probably the same for mod_asis. These were default modules in 2.0 - therefore, I think disabling them unless explicit in 2.2 could be worrisome. mod_dumpio: most - all mod_dumpio shouldn't have been most as it is debugging only... mod_rewrite: most - yes I would rather prefer we make mod_rewrite 'no', but that's me. =) I'm also fine promoting mod_proxy and mod_cache to most in 2.2. -- justin
Re: svn commit: r158798 - in httpd/httpd/trunk: CHANGES server/protocol.c
--On Wednesday, March 23, 2005 4:36 PM + [EMAIL PROTECTED] wrote:
another @@ -1008,7 +1023,15 @@
rnew-status = HTTP_OK;
-rnew-headers_in = r-headers_in;
+/* did the original request have a body? (e.g. POST w/SSI tags)
+ * if so, make sure the subrequest doesn't inherit body headers
+ */
+if (r-read_length) {
+clone_headers_no_body(rnew, r);
+} else {
+/* no body (common case). clone headers the cheap way */
+rnew-headers_in = r-headers_in;
+}
As I just noted in STATUS for 2.0, read_length isn't a sufficient check.
It'd only be set if the client has *already* read the body *and* they used
the 1.3.x mechanisms for reading the request body.
The proper check is to look for Transfer-Encoding and Content-Length in the
request headers. This is what ap_http_filter in http_filters.c does to
look for a request body. -- justin
Re: Default Modules
Rich Bowen wrote: Paul Querna wrote: I changed mod_imap this morning from 'yes' to 'most', because I was tired of disabling it every time I do a new install. I think we should reconsider what modules are enabled by default. Here is my list of suggested changes: mod_version: all - yes mod_asis: yes - no No? wouldn't most be sufficient? It's not totally obscure ... mod_imap: most - no mod_dumpio: most - all mod_rewrite: most - yes Hmmm... well, it's very popular, but very commonly used when totally unnecessary. Also big. Not convinced about changing it. How about mod_ssl being on in most? Disagree. It's big and complex and should only ever be *deliberately* enabled, IMHO. Similar comments apply to things like proxy and cache: they shouldn't catch a rookie admin by stealth. -- Nick Kew
Re: Default Modules
Justin Erenkrantz wrote: mod_asis: yes - no mod_imap: most - no I would prefer we keep mod_imap as most. Probably the same for mod_asis. These were default modules in 2.0 - therefore, I think disabling them unless explicit in 2.2 could be worrisome. Serously? Have you ever used mod_imap? Or, at least, since 1996? I have a hard time even explaining to people what mod_imap does, let alone finding anyone who has actually ever used it. I'm completely certain that nobody would ever notice if we just completely yanked it from the distribution. Well, except that I'd have one less thing to complain about. :-) --Rich
Re: Default Modules
--On Wednesday, April 6, 2005 1:30 PM -0400 Rich Bowen [EMAIL PROTECTED] wrote: Have you ever used mod_imap? Or, at least, since 1996? I have a hard Yes. Yes. I do wish it were renamed to mod_imagemap though! mod_imap is a poor name. Note that we could always re-introduce the imagemap CGI program. ;-) *chuckle* -- justin
Re: Default Modules
At 11:15 AM 4/6/2005, you wrote: I changed mod_imap this morning from 'yes' to 'most', because I was tired of disabling it every time I do a new install. I think we should reconsider what modules are enabled by default. Here is my list of suggested changes: mod_version: all - yes mod_asis: yes - no mod_imap: most - no mod_dumpio: most - all mod_rewrite: most - yes I think adding mod_rewrite as a default is the most controversial... so, what about the others :) ? rewrite does -nothing- if not told to. I'm happy with that. Disabling modules is more controversial. Very few use imap, so I agree. I'd disagree with asis. It does nothing if not told to, and provides a vital functionality for a limited number of cgi's. At 11:26 AM 4/6/2005, Rici Lake wrote: mod_ident: most - no mod_ssl: no - all mod_proxy (and friends) no - all Totally disagree with proxy and ssl. Installed, they change the entire scope of httpd operation. To run a basic http: protocol server, you use neither. To add https: may or may not violate local ordinances, so we must not enable it unless explicitly told to, and to add proxy behavior means you have a specific intent for that httpd server. I agree with ident for the very same reasons. Extending http using the (very -slow- and infrequently deployed) ident method is an exceptional, not typical feature, and has nothing to do with the http: protocol.
Re: Default Modules
On Wed, Apr 06, 2005 at 09:15:38AM -0700, Paul Querna wrote: I changed mod_imap this morning from 'yes' to 'most', because I was tired of disabling it every time I do a new install. I think we should reconsider what modules are enabled by default. Here is my list of suggested changes: mod_version: all - yes mod_asis: yes - no I'd prefer - most as it is rarely used but not totally useless. mod_imap: most - no mod_dumpio: most - all mod_rewrite: most - yes +1 on those - as far as I'm concerned, mod_imap should have gone years ago. Others mentioned mod_ssl which I think is too much trouble to be worth enabling other than when requested explicitly - there's the whole crypto regs issue and it does link in another lib, which is something that I prefer limiting to when it is actually needed. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: Default Modules
At 01:41 PM 4/6/2005, Justin Erenkrantz wrote: --On Wednesday, April 6, 2005 1:30 PM -0400 Rich Bowen [EMAIL PROTECTED] wrote: I do wish it were renamed to mod_imagemap though! mod_imap is a poor name. ++1 - 8.3 filenames are so 1980 :) We are changing a number of other module names, this rename would be much more intuitive. Bill
Re: simple-conf ready for merge
--On Wednesday, April 6, 2005 12:49 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: The reason not to drop them is that when the gods of httpd ([EMAIL PROTECTED]) decide to change their minds about the 'default' choice, it doesn't harm existing installations which were explicitly configured tested and deployed. Isn't that a good thing? If the admin doesn't know any better, why should our prior mistakes come back to haunt us? -- justin
Re: Default Modules
* Paul Querna wrote: I changed mod_imap this morning from 'yes' to 'most', because I was tired of disabling it every time I do a new install. I think we should reconsider what modules are enabled by default. Here is my list of suggested changes: mod_version: all - yes +1. mod_asis: yes - no - most mod_imap: most - no mod_dumpio: most - all +1 mod_rewrite: most - yes -1 (vote, not veto) nd -- Gib' mal folgendes in die Kommandozeile ein (und einen Moment warten): net send localhost Buuuh! Na, erschreckt? -- Markus Becker in mpdsh
Re: Default Modules
* William A. Rowe, Jr. wrote: At 01:41 PM 4/6/2005, Justin Erenkrantz wrote: --On Wednesday, April 6, 2005 1:30 PM -0400 Rich Bowen [EMAIL PROTECTED] wrote: I do wish it were renamed to mod_imagemap though! mod_imap is a poor name. ++1 - 8.3 filenames are so 1980 :) We are changing a number of other module names, this rename would be much more intuitive. +1 here as well. nd -- Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III Im Westen was neues: http://pub.perlig.de/books.html#apache2
Re: Default Modules
On 6-Apr-05, at 12:56 PM, Mads Toftum wrote: mod_asis: yes - no I'd prefer - most as it is rarely used but not totally useless. Others mentioned mod_ssl which I think is too much trouble to be worth enabling other than when requested explicitly - there's the whole crypto regs issue and it does link in another lib, which is something that I prefer limiting to when it is actually needed. So what are the criteria for yes, no, most and all? I think it would be more productive to come up with common criteria than to argue about individual modules. Perhaps all should just go away. It obviously does not really mean all and it is hard to come up with a good description of what it does mean. As I said earlier, a lot of people seem to be surprised at what all does not include (ssl and proxy, for example). And as no tool is provided to list what all and most actually do, people are pretty well left to their own intuitions. The current list (as produced by the shell script I pasted in an earlier message) is: 3. all cern_meta 3. all log_forensic 3. all mime_magic 3. all unique_id 3. all usertrack 3. all version So what do those six modules have in common?
Re: simple-conf ready for merge
On Wed, 6 Apr 2005, Joshua Slive wrote: I think this config is far clearer and more manageable for a newcomer, and probably also for an experienced httpd-user. It is also more secure I know this is propably too controversial; but one thing I'd love to have in there is somethign like Directory / AllowOverride none order allow,deny deny from all /Directory Just to make crystal clear tha the default should be a no. Dw
Re: Default Modules
On Wed, 6 Apr 2005, Justin Erenkrantz wrote: I do wish it were renamed to mod_imagemap though! mod_imap is a poor name. +1 - lets leave the 80ties behind us :-) Dw.
Re: simple-conf ready for merge
Dirk-Willem van Gulik wrote: On Wed, 6 Apr 2005, Joshua Slive wrote: I think this config is far clearer and more manageable for a newcomer, and probably also for an experienced httpd-user. It is also more secure I know this is propably too controversial; but one thing I'd love to have in there is somethign like Directory / AllowOverride none order allow,deny deny from all /Directory Just to make crystal clear tha the default should be a no. It's there already in 2.1 (but not 2.0). Joshua.
Re: simple-conf ready for merge
Brad Nicholes wrote: I'm still not a big fan of removing the MPM settings from the httpd.conf file. All of the other extra .conf files contain supplemental configuration but the MPM configuration seems to be more along the lines of a ServerRoot or Listen. Despite the fact that these are technically module directives, MPM directives just feel more like core directives. It's not really a question of core/module. Lots of core directives were removed too. The question is: Is this a directive that many/most users need to change? For most of the mpm directives, the answer is clearly no. (Although you could argue about something like MaxClients/MaxThreads.) [ Side note: The other question is How much confusion does the presence of these directives add to the config file? That mess of IfModule xxx_mpm was horribly confusing IMHO. That could be solved by intelligently including only the section for the relevant mpm in the default config, but that would require more complex build changes than I am up to. ] Joshua.
Re: simple-conf ready for merge
I see your rational, but I am looking at it from the point of view that the user knows that one of the first things that they need to do is tweak the MPM to fit their load/resource requirements. This is more a matter of where it they go? I could have sworn they were right here a minute ago. And I certainly wouldn't classify them as extra. [ Side note: The other question is How much confusion does the presence of these directives add to the config file? That mess of IfModule xxx_mpm was horribly confusing IMHO. That could be solved by intelligently including only the section for the relevant mpm in the default config, but that would require more complex build changes than I am up to. I agree, but I would still rather see only the applicable platform MPM directives anyway no matter whether they are implemented in httpd.conf or extra/httpd-mpm.conf. Brad [EMAIL PROTECTED] Wednesday, April 06, 2005 1:17:10 PM Brad Nicholes wrote: I'm still not a big fan of removing the MPM settings from the httpd.conf file. All of the other extra .conf files contain supplemental configuration but the MPM configuration seems to be more along the lines of a ServerRoot or Listen. Despite the fact that these are technically module directives, MPM directives just feel more like core directives. It's not really a question of core/module. Lots of core directives were removed too. The question is: Is this a directive that many/most users need to change? For most of the mpm directives, the answer is clearly no. (Although you could argue about something like MaxClients/MaxThreads.) [ Side note: The other question is How much confusion does the presence of these directives add to the config file? That mess of IfModule xxx_mpm was horribly confusing IMHO. That could be solved by intelligently including only the section for the relevant mpm in the default config, but that would require more complex build changes than I am up to. ] Joshua.
Re: svn commit: r160313 - httpd/httpd/branches/2.0.x/STATUS
--On Wednesday, April 6, 2005 12:54 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: At 12:17 PM 4/6/2005, you wrote: Author: jerenkrantz Remove merged backport, block one, vote for one. @@ -382,6 +381,7 @@ non experimental status. +1: bnicholes, wrowe +0: minfrin (wait till the last cache bugs are ironed out) + -1: jerenkrantz Technical justification for veto? Or is this just a straightforward objection for majority vote? I took that section to be majority vote not veto. -- justin
Renaming mod_imap - mod_imagemap
From the 'Default Modules' thread for renaming mod_imap: +1 Dirk, nd, justin. If there are no objections I will rename mod_imap to mod_imagemap and all the documentation later tonight. -Paul
Re: svn commit: r158798 - in httpd/httpd/trunk: CHANGES server/protocol.c
Justin Erenkrantz wrote: As I just noted in STATUS for 2.0, read_length isn't a sufficient check. It'd only be set if the client has *already* read the body *and* they used the 1.3.x mechanisms for reading the request body. both true in 100% of the cases I've seen in the wild. ok, I'll admit it is only one case :) The proper check is to look for Transfer-Encoding and Content-Length in the request headers. This is what ap_http_filter in http_filters.c does to look for a request body. -- justin I'm a little concerned about path length, but I guess subrequests aren't as critical. unfortunately a lot of headers start with C so the Content-Length table hash isn't as quick as it could be. Greg
[PATCH 9298][BUG 18757] Patch doesn't fix bug!
Title: Message Patch 9298 for bug 18757 doesn't fix bug 18757 (No Content-Length for proxied HEAD requests)... can this patch be removed from Bugzilla?
Re: Renaming mod_imap - mod_imagemap
Paul Querna wrote: From the 'Default Modules' thread for renaming mod_imap: +1 Dirk, nd, justin. If there are no objections I will rename mod_imap to mod_imagemap and all the documentation later tonight. +1
Re: Renaming mod_imap - mod_imagemap
Paul Querna wrote: From the 'Default Modules' thread for renaming mod_imap: +1 Dirk, nd, justin. If there are no objections I will rename mod_imap to mod_imagemap and all the documentation later tonight. +1
[STATUS] (httpd-2.0) Wed Apr 6 23:45:34 2005
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2005-04-06 13:17:53 -0400 (Wed, 06 Apr 2005) $]
The current version of this file can be found at:
http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
Release history:
2.0.54 : in development
2.0.53 : released February 7, 2005 as GA.
2.0.52 : released September 28, 2004 as GA.
2.0.51 : released September 15, 2004 as GA.
2.0.50 : released June 30, 2004 as GA.
2.0.49 : released March 19, 2004 as GA.
2.0.48 : released October 29, 2003 as GA.
2.0.47 : released July 09, 2003 as GA.
2.0.46 : released May 28, 2003 as GA.
2.0.45 : released April 1, 2003 as GA.
2.0.44 : released January 20, 2003 as GA.
2.0.43 : released October 3, 2002 as GA.
2.0.42 : released September 24, 2002 as GA.
2.0.41 : rolled September 16, 2002. not released.
2.0.40 : released August 9, 2002 as GA.
2.0.39 : released June 17, 2002 as GA.
2.0.38 : rolled June 16, 2002. not released.
2.0.37 : rolled June 11, 2002. not released.
2.0.36 : released May 6, 2002 as GA.
2.0.35 : released April 5, 2002 as GA.
2.0.34 : tagged March 26, 2002.
2.0.33 : tagged March 6, 2002. not released.
2.0.32 : released Feburary 16, 2002 as beta.
2.0.31 : rolled Feburary 1, 2002. not released.
2.0.30 : tagged January 8, 2002. not rolled.
2.0.29 : tagged November 27, 2001. not rolled.
2.0.28 : released November 13, 2001 as beta.
2.0.27 : rolled November 6, 2001
2.0.26 : tagged October 16, 2001. not rolled.
2.0.25 : rolled August 29, 2001
2.0.24 : rolled August 18, 2001
2.0.23 : rolled August 9, 2001
2.0.22 : rolled July 29, 2001
2.0.21 : rolled July 20, 2001
2.0.20 : rolled July 8, 2001
2.0.19 : rolled June 27, 2001
2.0.18 : rolled May 18, 2001
2.0.17 : rolled April 17, 2001
2.0.16 : rolled April 4, 2001
2.0.15 : rolled March 21, 2001
2.0.14 : rolled March 7, 2001
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 : released August 18, 2000
2.0a5 : released August 4, 2000
2.0a4 : released June 7, 2000
2.0a3 : released April 28, 2000
2.0a2 : released March 31, 2000
2.0a1 : released March 10, 2000
Please consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS
Contributors looking for a mission:
* Just do an egrep on TODO or XXX in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the PatchAvailable bugs in the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable
After testing, you can append a comment saying Reviewed and tested.
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
* Forward binary compatibility is expected of Apache 2.0.x releases, such
that no MMN major number changes will occur. Such changes can only be
made in the trunk.
* All commits to branches/2.0.x must be reflected in SVN trunk,
as well, if they apply. Logical progression is commit to trunk,
get feedback and votes in STATUS, and then merge into branches/2.0.x.
RELEASE SHOWSTOPPERS:
PATCHES TO BACKPORT FROM TRUNK:
[ please place SVN revisions from trunk here, so it is easy to
identify exactly what the proposed changes are! ]
[ please append new backports at the end of this list not the top. ]
*) util_ldap: Add the directive LDAPConnectionTimeout to control
the socket timeout value when binding to an LDAP server
svn rev 126565
+1: bnicholes, trawick (no need for APLOG_NOERRNO in Apache =2), jim
*) several changes to improve logging of connection-oriented errors,
including
ap_log_cerror() API (needs minor bump in addition to changes below)
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/core.c?r1=1.289r2=1.291
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.150r2=1.151
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/include/http_log.h?r1=1.46r2=1.48
+1: trawick, stoddard
*) mod_headers: Support {...}s tag for SSL variable lookup.
http://www.apache.org/~jorton/mod_headers-2.0-ssl.diff
+1: jorton, trawick
nd: two comments:
(1) is the use of APR_ASCII_* ebcdic-safe? I.e. shouldn't we use the
native chars here and it will be converted later? (I'm not sure)
jorton: I have no idea, let an EBCDIC-er complain if it breaks?
trawick: seems that '\r' and '\n' are the
[STATUS] (httpd-2.1) Wed Apr 6 23:45:44 2005
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2005-03-30 18:16:16 -0500 (Wed, 30 Mar 2005) $] The current version of this file can be found at: http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS Release history: [NOTE that only Alpha/Beta releases occur in 2.1 development] 2.1.5 : in development 2.1.4 : not released. 2.1.3 : Released on 2/22/2005 as alpha. 2.1.2 : Released on 12/08/2004 as alpha. 2.1.1 : Released on 11/19/2004 as alpha. 2.1.0 : not released. Please consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2 jerenkrantz asks: Why should this block a release? * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2 jerenkrantz asks: Why should this block a release? stas replies: because it requires a rewrite of the filters stack implementation (you have suggested that) and once 2.2 is released you can't do that anymore. CURRENT VOTES: * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), erikabele d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin, Lars Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj, nd +0: Lars, Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars pquerna: Do we want to change this for 2.2? RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Patches submitted to the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable * The Event MPM does not work on Solaris 10. PR 34040. * Filter stacks and subrequests, redirects and fast redirects. There's at least one PR that suffers from the current unclean behaviour (which lets the server send garbage): PR 17629 nd says: Every subrequest should get its own filter stack with the subreq_core filter as bottom-most. That filter does two things: - swallow EOS buckets
httpd-trunk configure dying on OSX: error: mod_so has been requested but cannot be built on your system
ok, so let's try this here ... i'm *not* certain this is a dev-list issue; pls
let me know if it's not ... thx! richard
hey richard, you should submit a bug or try the developers list for this
hi all,
i've just started playing with the latest dev trunk; i've had both earlier
dev-revisions and 2.0.53 up-n-running on OSX 10.3.8 ...
now, after 'svn co' of httpd-trunk, apr apr-util (currently, Revision:
160328)
i've sucessfully built/installed apr apr-util into /usr/local/httpd-dev,
where:
% ls -al /usr/local/httpd-dev/bin/ap*config
-rwxr-xr-x 1 root wheel 6882 Apr 6 15:31 apr-1-config
-rwxr-xr-x 1 root wheel 5937 Apr 6 15:49 apu-1-config
however, when I attepmt to configure httpd-trunk with my 'old' config:
./configure \
--with-apr=/usr/local/httpd-dev \
--with-apr-util=/usr/local/httpd-dev \
--enable-mods-shared=all --disable-static \
--enable-so \
--enable-cgi \
--enable-dav --enable-dav-fs --enable-dav-lock \
--enable-ssl --with-ssl=/usr/local/ssl \
--enable-authn-dbm --enable-authz-dbm \
--with-berkeley-db=/usr/local/berkeley-db \
--with-pcre=/usr/local/pcre50/ \
--enable-proxy \
--enable-proxy-connect \
--enable-proxy-ftp \
--enable-proxy-http \
--enable-logio \
--with-imap
configure dies with:
configure: error: mod_so has been requested but cannot be built on your
system
googling on the error hasn't done a lot for me yet, so looking in
'configure', the stanza in question is:
@19557
case x$enable_so in
xyes)
if test $ac_cv_define_APR_HAS_DSO = no; then
{ { echo $as_me:$LINENO: error: mod_so has
been requested but cannot be
built on your system 5
echo $as_me: error: mod_so has been requested but cannot be built on
your
system 2;}
{ (exit 1); exit 1; }; }
fi
;;
xshared)
{ { echo $as_me:$LINENO: error: mod_so can not be built as
a shared DSO
5
echo $as_me: error: mod_so can not be built as a shared DSO 2;}
{ (exit 1); exit 1; }; }
;;
xno)
;;
x)
enable_so=$ac_cv_define_APR_HAS_DSO
;;
esac
i note the presence of the APR_HAS_DSO check. it's new to me, and i'm
unclear if/where it's defined on OSX.
certainly, DSO support HAS been there for OSX for earlier versions
s, did something change and i've missed it? or is something broken
here that needs some attention?
thanks!
richard
