Re: Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
Joe Orton wrote: On Sat, Nov 06, 2004 at 12:48:50AM -0800, Justin Erenkrantz wrote: --On Saturday, November 6, 2004 8:28 AM + [EMAIL PROTECTED] wrote: @@ -125,6 +125,8 @@ +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? Seems reasonable to do so. 2.0 was our first threaded release - making a threaded MPM by default (if available) for 2.2 seems fine by me. -- justin I don't really agree with this. Many third-party modules still aren't thread-safe (and probably quite a few shipped in httpd too e.g. mod_example!). Making worker the default won't solve that, it'll just create a stream of I upgraded to 2.2 and now everything segfaults bug reports and people will stick with 1.3/2.0. 2.2 can be a compelling upgrade without making worker the default. I second that. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
On Sat, Nov 06, 2004 at 12:48:50AM -0800, Justin Erenkrantz wrote: --On Saturday, November 6, 2004 8:28 AM + [EMAIL PROTECTED] wrote: @@ -125,6 +125,8 @@ +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? Seems reasonable to do so. 2.0 was our first threaded release - making a threaded MPM by default (if available) for 2.2 seems fine by me. -- justin I don't really agree with this. Many third-party modules still aren't thread-safe (and probably quite a few shipped in httpd too e.g. mod_example!). Making worker the default won't solve that, it'll just create a stream of I upgraded to 2.2 and now everything segfaults bug reports and people will stick with 1.3/2.0. 2.2 can be a compelling upgrade without making worker the default. joe
Re: Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
It's not Linux but here is a piece of information that should help. NetWare is a thread only environment which means that we have been shipping and running all of the standard modules since day one with really no report of any threading related issues. I can't speak for any third party modules out there that may not be thread safe and I understand that Apache for NetWare has nowhere near the number of installations as Linux or others, but our standard modules seem to be doing well from a NetWare point of view. Even on multi-proc machines. Granted we don't normally stress test mod_example ;). Brad [EMAIL PROTECTED] Thursday, November 11, 2004 3:38:29 AM On Sat, Nov 06, 2004 at 12:48:50AM -0800, Justin Erenkrantz wrote: --On Saturday, November 6, 2004 8:28 AM + [EMAIL PROTECTED] wrote: @@ -125,6 +125,8 @@ +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? Seems reasonable to do so. 2.0 was our first threaded release - making a threaded MPM by default (if available) for 2.2 seems fine by me. -- justin I don't really agree with this. Many third-party modules still aren't thread-safe (and probably quite a few shipped in httpd too e.g. mod_example!). Making worker the default won't solve that, it'll just create a stream of I upgraded to 2.2 and now everything segfaults bug reports and people will stick with 1.3/2.0. 2.2 can be a compelling upgrade without making worker the default. joe
Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
--On Saturday, November 6, 2004 8:28 AM + [EMAIL PROTECTED] wrote: @@ -125,6 +125,8 @@ +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? Seems reasonable to do so. 2.0 was our first threaded release - making a threaded MPM by default (if available) for 2.2 seems fine by me. -- justin
Re: Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
Seems reasonable to do so. 2.0 was our first threaded release - making a threaded MPM by default (if available) for 2.2 seems fine by me. -- justin agreed :) however, something that I heard recently is that if you specify a threaded MPM on a platform that does not support it, the build process silently switches to prefork (or whatever the default is for the platform, I guess) now, I haven't seen this myself, so I don't want to propagate FUD, but if it's true I might suggest that halting the build process is preferable to switching behind the scenes (or even switching with a little warning) - from a support standpoint, I built apache like this... should tell the truth about the build in question. if I'm off my rocker, well, sorry. I'll buy a round at the hackathon to make up for it :) --Geoff
Re: Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
On Sat, 6 Nov 2004, Geoffrey Young wrote: MPM on a platform that does not support it, the build process silently switches to prefork (or whatever the default is for the platform, I guess) now, I haven't seen this myself, so I don't want to propagate FUD, but if it's true I might suggest that halting the build process is preferable to switching behind the scenes (or even switching with a little warning) - from That does seem to match my memory of the situation, fwiw. I would have no problem with halting the build if they specified --with-threads and none were available, though I would have a problem with halting the build if using a threaded MPM were simply used by default and none were available. --Cliff
Re: cvs commit: httpd-2.0 STATUS
On Wed, Nov 03, 2004 at 10:16:55PM -, [EMAIL PROTECTED] wrote: ... +*) mod_authnz_ldap: Added the directive Requires ldap-attribute that + allows the module to only authorize a user if the attribute value + specified matches the value of the user object. PR 31913 + modules/aaa/mod_authnz_ldap.c: r1.7 +docs/manual/mod/mod_authnz_ldap.xml: r1.3 + +1: bnicholes mod_authnz_ldap doesn't exist in 2.0; would this diff actually apply to mod_auth_ldap? If not then a separate patch needs to be posted somewhere for review. joe
Re: cvs commit: httpd-2.0 STATUS
You are correct that a patch based on mod_authnz_ldap.c won't apply cleanly to mod_auth_ldap.c because of various differences in the code base. But the patch is fairly self-contained meaning that the same chunk of code can easily be copied from mod_authnz_ldap.c and pasted into mod_auth_ldap.c without modification to the code snipet itself. I can certainly create and post an actual patch file that will apply cleanly to mod_auth_ldap.c if required. But it shouldn't be difficult to review the patch as it stands in mod_authnz_ldap.c. Brad [EMAIL PROTECTED] Wednesday, November 03, 2004 4:01:07 PM On Wed, Nov 03, 2004 at 10:16:55PM -, [EMAIL PROTECTED] wrote: ... +*) mod_authnz_ldap: Added the directive Requires ldap-attribute that + allows the module to only authorize a user if the attribute value + specified matches the value of the user object. PR 31913 + modules/aaa/mod_authnz_ldap.c: r1.7 +docs/manual/mod/mod_authnz_ldap.xml: r1.3 + +1: bnicholes mod_authnz_ldap doesn't exist in 2.0; would this diff actually apply to mod_auth_ldap? If not then a separate patch needs to be posted somewhere for review. joe
Re: cvs commit: httpd-2.0 STATUS
At 05:02 PM 10/10/2004, [EMAIL PROTECTED] wrote: +*) Allow for the use of --with-module=foo:bar where the ./modules/foo + directory is a local addition to the ./modules directory. + Assumes, of course, that the required files are in ./modules/foo, + but makes it easier to statically build external modules by + simply adding them to ./modules. + modules/config5.m4: 1.4 + +1: jim Jim, just a suggestion, instead of a more complex foo:bar syntax, would it help instead to accept a directive to ./buildconf such as; --add-modules-path=foo where foo could be relative to aproot/modules/foo, or given as an abs path? If it's absolute, then we could still strip down to the actual directory name for vpath builds, e.g. --add-modules-path=/opt/org/foo would still build into aproot/modules/foo/mod_ule.o This way, once you have run ./buildconf with --add-modules-path, the config.m4 could elect to follow the usual most or all groupings or perform additional feature checks. If it's run at ./configure time, I suspect we would lose the ability to modify ap_config_auto.h settings. Bill
Re: cvs commit: httpd-2.0 STATUS
On 22 Sep 2004 08:57:30 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: jorton 2004/09/22 01:57:30 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Find a third 2.0.51 regression THIS WEEK and win a FREE subscription to [EMAIL PROTECTED] OFFER ENDS SOON. mod_mem_cache double-free ;)
Re: cvs commit: httpd-2.0 STATUS
Can we quickly identify what else was broken to roll out 2.0.52 in the next day or two? I presume this too was 2.0.51 specific? Bill jorton 2004/09/22 01:57:30 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Find a third 2.0.51 regression THIS WEEK and win a FREE subscription to [EMAIL PROTECTED] OFFER ENDS SOON. +*) Another ap_rgetline_core fix. + http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/protocol.c?r1=1.152r2=1.153 + +1: jorton
Re: cvs commit: httpd-2.0 STATUS
On Wed, 22 Sep 2004 08:39:04 -0500, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Can we quickly identify what else was broken to roll out 2.0.52 in the next day or two? I presume this too was 2.0.51 specific? it is my understanding that the mod_mem_cache double-free was a regression introduced in 2.0.51
Re: cvs commit: httpd-2.0 STATUS
On Wed, 22 Sep 2004 11:20:02 -0400, Jeff Trawick [EMAIL PROTECTED] wrote: On Wed, 22 Sep 2004 08:39:04 -0500, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Can we quickly identify what else was broken to roll out 2.0.52 in the next day or two? I presume this too was 2.0.51 specific? it is my understanding that the mod_mem_cache double-free was a regression introduced in 2.0.51 oops, FirstBill tells me that the mod_mem_cache double-free was an old problem... I guess I don't get a free subscription to the commit list
Re: cvs commit: httpd-2.0 STATUS
On Mon, Sep 13, 2004 at 03:56:19PM -, [EMAIL PROTECTED] wrote: --- STATUS 13 Sep 2004 15:39:57 - 1.751.2.1044 +++ STATUS 13 Sep 2004 15:56:19 - 1.751.2.1045 @@ -75,16 +75,17 @@ *) mod_dav_fs: Fix indirect lock record handling on 64-bit platforms. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/fs/lock.c?r1=1.31r2=1.32 + jerenkrantz asks: Won't this break already existing lock DBs? +1: jorton On platforms with sizeof(int) == sizeof(apr_size_t), the change is a noop, so no break there. On other platforms, any indirect lock records which have already been written to the database by the =2.0.50 code will be corrupt and unreadable anyway. If no indirect records have been written it doesn't matter, and any new records which are written by the new code will be OK. Hope that makes sense... joe
Re: cvs commit: httpd-2.0 STATUS
--On Monday, September 13, 2004 5:13 PM +0100 Joe Orton [EMAIL PROTECTED] wrote: On platforms with sizeof(int) == sizeof(apr_size_t), the change is a noop, so no break there. On other platforms, any indirect lock records which have already been written to the database by the =2.0.50 code will be corrupt and unreadable anyway. If no indirect records have been written it doesn't matter, and any new records which are written by the new code will be OK. Hope that makes sense... Yup. Thanks! -- justin
Re: cvs commit: httpd-2.0 STATUS
On 26 Aug 2004 18:04:20 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -*) Allocate buffer memory from the temp_pool rather than the stack to - avoid over-running a fixed length stack while evaluating nested - include directives. - server/config.c: r1.180 - +1: bnicholes, nd - nd: oops... This already went into the include recursion stopper - backport. Any objections? ;-) for the record, I'll be #3 (grin)
Re: cvs commit: httpd-2.0 STATUS
On Thu, Aug 19, 2004 at 06:55:52PM -, [EMAIL PROTECTED] wrote: @@ -184,6 +184,7 @@ ssl_engine_kernel.c r1.107 ssl_private.h r1.7 +1: trawick, jorton +nd: Is it wise to backport XXX code into the stable? Which bit is XXX code, did you put that comment in the right place? None of [...pause...oh for a single URL - changeset diff lookup...] these changes seem to include XXX comments? http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/mod_ssl.c?r1=1.98r2=1.99 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_config.c?r1=1.93r2=1.94 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_kernel.c?r1=1.106r2=1.107 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_private.h?r1=1.6r2=1.7
Re: cvs commit: httpd-2.0 STATUS
* [EMAIL PROTECTED] wrote: + nd: oops... This already went into the include recursion stopper + backport. Any objections? ;-) I'm very sorry for this accident. If we get another +1, this entry can be deleted... nd -- package Hacker::Perl::Another::Just;print [EMAIL PROTECTED] split/::/ =__PACKAGE__]}~; # André Malo # http://www.perlig.de #
Re: cvs commit: httpd-2.0 STATUS
Do we care about backporting the overhaul into the 2.0 tree? I don't see that it really buys us anything unless you think that it is necessary in order to get auth_ldap out of experimental. After I get the latest util-ldap fixes backported, that should get mod_auth_ldap working in 2.0. Once it actually works, I think we can then propose that it is moved out of experimental. The next thing that needs to be done would be to rework mod_auth_ldap so that it complies with the rest of the 2.1 auth module structure.The util-ldap overhaul could be considered part of that work and only be available in 2.1. Thoughts? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, August 03, 2004 7:09:01 PM minfrin 2004/08/03 18:09:01 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Propose a backport. Revision ChangesPath No revision No revision 1.751.2.965 +7 -1 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.964 retrieving revision 1.751.2.965 diff -u -r1.751.2.964 -r1.751.2.965 --- STATUS3 Aug 2004 19:07:03 - 1.751.2.964 +++ STATUS4 Aug 2004 01:09:00 - 1.751.2.965 @@ -73,6 +73,12 @@ [ please place file names and revisions from HEAD here, so it is easy to identify exactly what the proposed changes are! ] +*) Remove LDAP toolkit specific code from util_ldap and mod_auth_ldap. + modules/experimental/mod_auth_ldap.c: 1.28 + modules/experimental/util_ldap.c: 1.36 + +1: minfrin (this requires the apr-util LDAP overhaul to be ported to +apr-util v0.9 first) + *) Add load balancer support to the scoreboard in preparation for load balancing support in mod_proxy. include/scoreboard.h: 1.52
Re: cvs commit: httpd-2.0 STATUS
Brad Nicholes wrote: Do we care about backporting the overhaul into the 2.0 tree? I don't see that it really buys us anything unless you think that it is necessary in order to get auth_ldap out of experimental. After I get the latest util-ldap fixes backported, that should get mod_auth_ldap working in 2.0. Once it actually works, I think we can then propose that it is moved out of experimental. In theory it doesn't really buy us anything no - it depends on how strongly people feel about the fooness in the LDAP code being removed from APR v0.9.4, but as to my knowledge there has never been an ASF blessed release of the 0.9 branch of APR, so in theory there would be no point. The next thing that needs to be done would be to rework mod_auth_ldap so that it complies with the rest of the 2.1 auth module structure.The util-ldap overhaul could be considered part of that work and only be available in 2.1. Thoughts? That definitely is next - as mod_auth_ldap is currently non functional in v2.1 due to it not following the authn/authz convention. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: httpd-2.0 STATUS
On 4 Aug 2004 19:57:30 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: jerenkrantz2004/08/04 12:57:30 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Hey, look, I can cast votes! no way, what happened to the mysterious authentication which allowed only a small number of people to ever review/cast votes ;) While it seems like no one else cares, my proposed backport of mod_ssl config logic is stalling. We *still* can't build mod_ssl out of the box on RHEL... I'll have a look...
Re: cvs commit: httpd-2.0 STATUS
jerenkrantz2004/08/04 12:57:30 --- STATUS4 Aug 2004 19:31:58 - 1.751.2.967 +++ STATUS4 Aug 2004 19:57:29 - 1.751.2.968 @@ -94,15 +94,19 @@ modules/experimental/util_ldap.c: 1.36 +1: minfrin (this requires the apr-util LDAP overhaul to be ported to apr-util v0.9 first) + -0: jerenkrantz + jerenkrantz: I don't think we can change the APR 0.9 interfaces. +They are supposed to be set in stone. You cannot change the APR 0.9 interfaces. You can add new API calls, but not break binary compatibility with existing functions. That means you cannot rescope public - private entities, cannot make transparent structures into opaque ones, and cannot change args or the return values of functions. E.g. if you need extra args to apr_foo_create(), make a new 0.9-specific function, apr_foo_create_ex(), that is folded as the real apr_foo_create() in 1.0. Bill
Re: cvs commit: httpd-2.0 STATUS
At 08:36 PM 7/29/2004, Roy T. Fielding wrote: I'd be surprised if it were even possible for an independent module to allocate a scoreboard struct, but it has been a while since I looked at that code. I think you are right - allocation is in control of httpd itself. Mladen wants to be able to 'extend' a scoreboard, for mod_ssl for example, or for the load balancer. I think this is the right design choice. Examples of heavy scoreboard consumption include snmp and other external monitoring modules. But they aren't creating, only consuming, so either patch would be safe (with the the new struct member moved to the end of the struct declaration.) Bill
Re: cvs commit: httpd-2.0 STATUS
At 05:55 PM 7/28/2004, [EMAIL PROTECTED] wrote:
minfrin 2004/07/28 15:55:15
Modified:.Tag: APACHE_2_0_BRANCH STATUS
Log:
Propose a backport
+*) Add load balancer support to the scoreboard in preparation for
+ load balancing support in mod_proxy.
+ include/scoreboard.h: 1.52
+ server/scoreboard.c: 1.75
+ +1: minfrin
Rather than vote... afraid I have to veto (for 2.0)...
--- scoreboard.h 9 Feb 2004 20:38:21 - 1.51
+++ scoreboard.h 28 Jul 2004 22:50:54 - 1.52
@@ -32,6 +32,7 @@
#include apr_thread_proc.h
#include apr_portable.h
#include apr_shm.h
+#include apr_optional.h
/* Scoreboard file, if there is one */
#ifndef DEFAULT_SCOREBOARD
@@ -118,6 +119,7 @@
typedef struct {
int server_limit;
int thread_limit;
+int lb_limit;
ap_scoreboard_e sb_type;
ap_generation_t running_generation; /* the generation of children which
* should still be serving requests. */
This definitely breaks binary compatibility.
Bill
RE: cvs commit: httpd-2.0 STATUS
William A. Rowe, Jr. wrote:
/* Scoreboard file, if there is one */
#ifndef DEFAULT_SCOREBOARD
@@ -118,6 +119,7 @@
typedef struct {
int server_limit;
int thread_limit;
+int lb_limit;
ap_scoreboard_e sb_type;
ap_generation_t running_generation; /* the
generation of children which
* should still
be serving
requests. */
This definitely breaks binary compatibility.
Moving the lb_limit to the end of the struct will not break the binary
compatibility. Correct?
MT.
smime.p7s
Description: S/MIME cryptographic signature
Re: cvs commit: httpd-2.0 STATUS
* Mladen Turk [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
/* Scoreboard file, if there is one */
#ifndef DEFAULT_SCOREBOARD
@@ -118,6 +119,7 @@
typedef struct {
int server_limit;
int thread_limit;
+int lb_limit;
ap_scoreboard_e sb_type;
ap_generation_t running_generation; /* the
generation of children which
* should still
be serving
requests. */
This definitely breaks binary compatibility.
Moving the lb_limit to the end of the struct will not break the binary
compatibility. Correct?
Not Correct. It *may* be the case. Depending on who allocates the stuff.
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: cvs commit: httpd-2.0 STATUS
André Malo wrote: William A. Rowe, Jr. wrote: This definitely breaks binary compatibility. Moving the lb_limit to the end of the struct will not break the binary compatibility. Correct? Not Correct. It *may* be the case. Depending on who allocates the stuff. Can you explain that a bit. Seems to me that there is a single ap_scoreboard_image-global, and it is allocated when the scoreboard gets created. IMO if the lb_limit is moved to the end of the struct it will not affect the existing binaries. Cannot speak on all builds but FreeBSD 4.1.10 and WIN32 are binary compatible (mod_status is the only that directly uses global). The only way where it might create problems is ap_scoreboard_image::servers not global, for some 3rd party module that directly uses this pointer array instead using ap_get_scoreboard_worker. Scoreboard file format is not binary compatible for sure, and this is the only part that might rise concerns, but only if that compatibility is required after all. MT. smime.p7s Description: S/MIME cryptographic signature
RE: cvs commit: httpd-2.0 STATUS
At 02:24 AM 7/29/2004, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
/* Scoreboard file, if there is one */
#ifndef DEFAULT_SCOREBOARD
@@ -118,6 +119,7 @@
typedef struct {
int server_limit;
int thread_limit;
+int lb_limit;
ap_scoreboard_e sb_type;
ap_generation_t running_generation; /* the
generation of children which
* should still
be serving
requests. */
This definitely breaks binary compatibility.
Moving the lb_limit to the end of the struct will not break the binary
compatibility. Correct?
Yes, in the case of global_score, that would be safer. It seems that
the additional lb_score 's element point was better placed.
If you changed worker_score, it would still have broken (or if you change
balancers in the future.) Agents reviewing the scoreboard are presuming
scoreboard_entry *psb can be accessed as psb[0..n] and that -will- be
broken with any size/alignment change to the struct.
E.g.
Bill
RE: cvs commit: httpd-2.0 STATUS
William A. Rowe, Jr. wrote: Moving the lb_limit to the end of the struct will not break the binary compatibility. Correct? Yes, in the case of global_score, that would be safer. It seems that the additional lb_score 's element point was better placed. If you changed worker_score, it would still have broken (or if you change balancers in the future.) Agents reviewing the scoreboard are presuming scoreboard_entry *psb can be accessed as psb[0..n] and that -will- be broken with any size/alignment change to the struct. I was afraid you've gonna said that. Those 3rd party... :). How about adding extra data to the end of the entire scoreboard withouth touching any existing structs or data? It will require an extra copy on child_init, but there will be no compatibility issues, thought. Will that rise any objections? MT. smime.p7s Description: S/MIME cryptographic signature
RE: cvs commit: httpd-2.0 STATUS
At 10:26 AM 7/29/2004, William A. Rowe, Jr. wrote: If you changed worker_score, it would still have broken (or if you change balancers in the future.) Agents reviewing the scoreboard are presuming scoreboard_entry *psb can be accessed as psb[0..n] and that -will- be broken with any size/alignment change to the struct. E.g. [...?] we have individual element accessors, but older style code presumes it can loop through the array of individual worker threads/procs. Adding another element to worker_score would break the starting offset of the members psb[1..n]. Although we create the pointer-pointer logic in the children to avoid this, it's still possible that the code would break some modules. I can't envision a case where any of the scoreboard entries are allocated outside of our scoreboard.c code. At 11:01 AM 7/29/2004, Mladen Turk wrote: I was afraid you've gonna said that. Those 3rd party... :). How about adding extra data to the end of the entire scoreboard withouth touching any existing structs or data? It will require an extra copy on child_init, but there will be no compatibility issues, thought. You aren't changing worker_score so this isn't an issue. The patch already creates (new) a fourth lb_score array. Bill
RE: cvs commit: httpd-2.0 STATUS
William A. Rowe, Jr. wrote: Although we create the pointer-pointer logic in the children to avoid this, it's still possible that the code would break some modules. I can't envision a case where any of the scoreboard entries are allocated outside of our scoreboard.c code. OK, then. I'll revert the patch and for 2.1 too, and we'll use our own shm for loadbalancer. Can we then create two extra hooks aka on_scoreboard_create and on_scoreboard_attach with ap_scoreboard_e, thread and server limit params. It will also help other modules like mod_ssl (currently using pool tag to supress double creation on post_config). MT. smime.p7s Description: S/MIME cryptographic signature
[PATCH] scoreboard WAS RE: cvs commit: httpd-2.0 STATUS
Hi all,
Since there was some concerns regarding binary compatibility, here is the
patch that uses different approach.
1. Revert the patch with changes to scoreboard structures
2. Add an extra hook that is run during ap_reopen_scoreboard with detached
param.
We will use our own shm, opening by hooking pre_mpm, and attaching in child
on reopen_scoreboard.
This will resolve any binary compatibility concerns.
Regards,
MT.
Index: scoreboard.h
===
RCS file: /home/cvspublic/httpd-2.0/include/scoreboard.h,v
retrieving revision 1.53
diff -u -r1.53 scoreboard.h
--- scoreboard.h29 Jul 2004 15:18:40 - 1.53
+++ scoreboard.h29 Jul 2004 18:28:21 -
@@ -124,7 +124,6 @@
* should still be serving requests.
*/
apr_time_t restart_time;
-int lb_limit;
} global_score;
/* stuff which the parent generally writes and the children rarely read */
@@ -138,13 +137,6 @@
*/
};
-/* stuff which is lb specific */
-typedef struct lb_score lb_score;
-struct lb_score{
-/* TODO: make a real stuct from this */
-unsigned char data[1024];
-};
-
/* Scoreboard is now in 'local' memory, since it isn't updated once created,
* even in forked architectures. Child created-processes (non-fork) will
* set up these indicies into the (possibly relocated) shmem records.
@@ -153,7 +145,6 @@
global_score *global;
process_score *parent;
worker_score **servers;
-lb_score **balancers;
} scoreboard;
typedef struct ap_sb_handle_t ap_sb_handle_t;
@@ -179,7 +170,6 @@
AP_DECLARE(worker_score *) ap_get_scoreboard_worker(int x, int y);
AP_DECLARE(process_score *) ap_get_scoreboard_process(int x);
AP_DECLARE(global_score *) ap_get_scoreboard_global(void);
-AP_DECLARE(lb_score *) ap_get_scoreboard_lb(int child_num, int lb_num);
AP_DECLARE_DATA extern scoreboard *ap_scoreboard_image;
AP_DECLARE_DATA extern const char *ap_scoreboard_fname;
@@ -198,11 +188,13 @@
AP_DECLARE_HOOK(int, pre_mpm, (apr_pool_t *p, ap_scoreboard_e sb_type))
/**
- * proxy load balancer
- * @return the number of load balancer workers.
+ * Hook for reopening scoreboard, reopen scoreboard.
+ * @param detached Non-zero if this is a seperate child process.
+ * @ingroup hooks
+ * @return OK or DECLINE on success; anything else is a error
*/
-APR_DECLARE_OPTIONAL_FN(int, ap_proxy_lb_workers,
-(void));
+AP_DECLARE_HOOK(int, reopen_scoreboard, (int detached))
+
/* for time_process_request() in http_main.c */
#define START_PREQUEST 1
Index: scoreboard.c
===
RCS file: /home/cvspublic/httpd-2.0/server/scoreboard.c,v
retrieving revision 1.75
diff -u -r1.75 scoreboard.c
--- scoreboard.c28 Jul 2004 22:50:54 - 1.75
+++ scoreboard.c29 Jul 2004 18:33:01 -
@@ -53,21 +53,23 @@
APR_HOOK_STRUCT(
APR_HOOK_LINK(pre_mpm)
+APR_HOOK_LINK(reopen_scoreboard)
)
AP_IMPLEMENT_HOOK_RUN_ALL(int,pre_mpm,
(apr_pool_t *p, ap_scoreboard_e sb_type),
(p, sb_type),OK,DECLINED)
-static APR_OPTIONAL_FN_TYPE(ap_proxy_lb_workers)
-*proxy_lb_workers;
+AP_IMPLEMENT_HOOK_RUN_ALL(int,reopen_scoreboard,
+ (int detached),
+ (detached),OK,DECLINED)
struct ap_sb_handle_t {
int child_num;
int thread_num;
};
-static int server_limit, thread_limit, lb_limit;
+static int server_limit, thread_limit;
static apr_size_t scoreboard_size;
/*
@@ -93,18 +95,9 @@
ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, thread_limit);
ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, server_limit);
-if (!proxy_lb_workers)
-proxy_lb_workers = APR_RETRIEVE_OPTIONAL_FN(ap_proxy_lb_workers);
-if (proxy_lb_workers)
-lb_limit = proxy_lb_workers();
-else
-lb_limit = 0;
-
scoreboard_size = sizeof(global_score);
scoreboard_size += sizeof(process_score) * server_limit;
scoreboard_size += sizeof(worker_score) * server_limit * thread_limit;
-if (lb_limit)
-scoreboard_size += sizeof(lb_score) * server_limit * lb_limit;
return scoreboard_size;
}
@@ -116,8 +109,7 @@
ap_calc_scoreboard_size();
ap_scoreboard_image =
-calloc(1, sizeof(scoreboard) + server_limit * sizeof(worker_score *) +
- server_limit * lb_limit * sizeof(lb_score *));
+calloc(1, sizeof(scoreboard) + server_limit * sizeof(worker_score *));
more_storage = shared_score;
ap_scoreboard_image-global = (global_score *)more_storage;
more_storage += sizeof(global_score);
@@ -129,19 +121,9 @@
ap_scoreboard_image-servers[i] = (worker_score *)more_storage;
more_storage += thread_limit * sizeof(worker_score);
}
-if
Re: cvs commit: httpd-2.0 STATUS
On Thursday, July 29, 2004, at 05:58 AM, André Malo wrote:
* Mladen Turk [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
/* Scoreboard file, if there is one */
#ifndef DEFAULT_SCOREBOARD
@@ -118,6 +119,7 @@
typedef struct {
int server_limit;
int thread_limit;
+int lb_limit;
ap_scoreboard_e sb_type;
ap_generation_t running_generation; /* the
generation of children which
* should still
be serving
requests. */
This definitely breaks binary compatibility.
Moving the lb_limit to the end of the struct will not break the binary
compatibility. Correct?
Not Correct. It *may* be the case. Depending on who allocates the
stuff.
Then the question to ask is whether any independent modules
(those that are not installed when the server is installed)
are likely to use that structure, and how they are expected
to use it.
I'd be surprised if it were even possible for an independent
module to allocate a scoreboard struct, but it has been a while
since I looked at that code.
Roy
Re: cvs commit: httpd-2.0 STATUS
At 07:45 PM 7/1/2004, [EMAIL PROTECTED] wrote: minfrin 2004/07/01 17:45:43 1.751.2.942 +6 -1 httpd-2.0/STATUS +*) Add the NOTICE file to the rpm spec file in compliance with the Apache + v2.0 license. + build/rpm/httpd.spec.in: 1.6 + +1: minfrin As you point out, we mandated this. No need for a vote.
Re: cvs commit: httpd-2.0 STATUS
Loading a process in its own address space require that all of the modules that it has direct dependencieson,have alsoto be loaded in that same address space. This is an expensive process, especially when it comes to CGIs that are loaded to serve their content and then unloaded. A marshaling layer exist between the protected address space and the kernel to ensure that loaded applications cannot corrupt kernel memory. The performance hits of isolating a process is not negligible. Process running in OS address space are also easier to debugusing our internal debuggerthen having the same process running in its ownaddress space. intwo worlds: performance and usability [EMAIL PROTECTED] 6/22/2004 8:34:54 PM Uh, then may I follow up with another stupid, obvious question, if usinganother address space insulates the parent application and, in somecases, the server from a crash resulting from an unstable module, why dothey all use the same address space on novell? Does this compromise asecurity measure in the case of a module fail or crash?
NetWare and protected address space (was: Re: cvs commit: httpd-2.0 STATUS)
Just to provide a little background on NetWare (and if you don't care, don't read any further). NetWare is not your standard general purpose operating system. NetWare was origninally designed and built to be a high performance, highly scalable and very secure file and print server. Over the years it has evolved into something that sits somewhere between its original design purpose and a general purpose OS. In order to achieve the performance levels that it does, as much overhead as possible was eliminated which includes the concept of processes and what most people understand to be address spaces. Everything that runs on NetWare runs as a thread in Kernel address space. The idea of a separate address space or Protected Address Space (as it is called around here) didn't show up in NetWare until NetWare 5 (I think that was the first version). Basically a protected address space is just that. NetWare allocates a separate address space in which it is able to run an application. In order for an application to run in this address space, everything that it depends on has to be loaded in that address space. This mean code as well as data. A protected address space on NetWare could probably be thought of more as a virtual machine than a process. This is why it is so expensive to spin up a CGI in a separate address space on Netware. But running everything in kernel address space is not as scary as it sounds on NetWare. If you have a wild module that causes the Apache instance to abend (another old time term that is still widely used when refering to NetWare), it will bring Apache down, but the OS is smart enough to isolate the offending application and still allow the server to continue running. The downside is that the only way to clear an abend in kernel address space is to restart the server. While an abend in a protected address space can simply be unloaded and cleared. Some NetWare administrators will choose to run applications like Apache in a protected address space simply for the ability to easily clean it up if something goes wrong. But by doing so they sacrifice some level of performance of the web server as well as system resources. Others may consider applications like Apache to be so stable and the performance hit so great, that they are comfortable in running them in kernel address space. For the most part, this is the case. But Apache is a long lived application. Once it is spun up and running, the overhead is gone. CGIs, as we all know, can come and go at anytime. Because of the same performance reason, other platforms have been able to increase performance by using mod_cgid rather than mod_cgi to avoid the same type of process creation overhead. But on NetWare, not only is starting up a CGI in protected address space much more expensive than forking a process on other platforms, we don't have fork/exec on NetWare. The bottom line is that because of the nature of the NetWare OS, it is much more efficient and much easier to run things in kernel address space. It is just the nature of the OS. What's the benefit? Performance, scalability and yes, security. (OK, that sounds a lot like a marketing line, but its true) Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, June 22, 2004 8:34:54 PM Uh, then may I follow up with another stupid, obvious question, if using another address space insulates the parent application and, in some cases, the server from a crash resulting from an unstable module, why do they all use the same address space on novell? Does this compromise a security measure in the case of a module fail or crash? -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. On Tue, 2004-06-22 at 16:49, Jean-Jacques Clar wrote: Can I ask the obvious, then? When would a separate address space be desirable for an apr-based app to invoke a child/forked process? It is a desirable option mainly for developers using unstable modules to ensure the child process will not kill the parent application, or the server, in case a major problem happens inside the child. By default on NetWare, the http server and all of its child processes are started in the same address space.
Re: cvs commit: httpd-2.0 STATUS
At what cost (in terms of security) does this gain in performance, etc come at? You also mention something about a marshalling layer. In general terms, what is this and how trustworthy/foolproof is it? -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. On Wed, 2004-06-23 at 10:03, Jean-Jacques Clar wrote: The performance hits of isolating a process is not negligible. Process running in OS address space are also easier to debug using our internal debugger then having the same process running in its own address space. in two worlds: performance and usability [EMAIL PROTECTED] 6/22/2004 8:34:54 PM Uh, then may I follow up with another stupid, obvious question, if using another address space insulates the parent application and, in some cases, the server from a crash resulting from an unstable module, why do they all use the same address space on novell? signature.asc Description: This is a digitally signed message part
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: clar2004/06/21 12:11:56 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Removing bb proposal since it will require a major number bump Revision ChangesPath No revision No revision 1.751.2.932 +1 -12 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.931 retrieving revision 1.751.2.932 diff -u -r1.751.2.931 -r1.751.2.932 --- STATUS 20 Jun 2004 13:12:26 - 1.751.2.931 +++ STATUS 21 Jun 2004 19:11:56 - 1.751.2.932 @@ -77,17 +77,6 @@ hooks just like DSO modules can [Philippe M. Chiasson gozer cpan.org] +1: geoff -*) mod_cgi: Added API call and new field in apr_procattr_t and cgi_exec_info_t - structures to support loading in current or new address space for CGIs. - It fixes NetWare that is currently broken after changes done to log.c r1.145. - modules/generators/mod_cgi.c r1.164 - modules/generators/mod_cgi.h r1.14 - modules/arch/netware/mod_netware r1.18 - +1: jjclar, bnicholes - -0: nd - trawick: is minor mmn bump needed to reflect that API structure was extended? - nd: same as mod_ssl.h issues. It's actually a major bump. Jeff eventually needs to backport the use of a different cmdtype for piped loggers in order to fix an outstanding PR and NetWare still needs to create piped logger processes as expected and recover from a historical lack of information provided to APR about whether or not the child process should run within the same address space of the parent. Surely there is some way to make this happen? What if the default in APR is to run in a separate address space*, and in places in Apache where on NetWare the child process should run in the same address space there is a call to the proper procattr manipulator to override the default so that the child runs in the same address space? (and ignore any APR_ENOTIMPL retcode from that procattr manipulator so that no ifdef NETWARE is needed around the call) This at least avoids adding a field to the end of the cgi structure allocated by Apache and passed to modules implementing the optional function, which (at the moment) a minority of people think requires a major bump. *sounds natural to me; that also means that the default is the same on all platforms -- run child in different address space
Re: cvs commit: httpd-2.0 STATUS
What if the default in APR is to run in a separate address space*, and in places in Apache where on NetWare the child process should run in the same address space there is a call to the proper procattr manipulator to override the default so that the child runs in the same address space? (and ignore any APR_ENOTIMPL retcode from that procattr manipulator so that no ifdef NETWARE is needed around the call) The is actually the behavior that we don't want on NetWare. Running CGI's or utilities like RotateLogs in a separate address space is very painful and requires overhead and a performance hit that we don't want. On NetWare we need to default to the current address space. BTW, an address space on NetWare is, for the most part, very different than on other platforms. 90% of what is running on the box, is running in the same address space. When we implemented the CGIMapExtension directive to associate a CGI extension with an executible (NetWare doesn't have a shell like BASH to handle the associations) there is an optional parameter called detach which allows the user to specify wheither the associated executible should be run in the current address space or a separate address space. The default is the current address space. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Tuesday, June 22, 2004 5:45:58 AM [EMAIL PROTECTED] wrote: clar2004/06/21 12:11:56 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Removing bb proposal since it will require a major number bump Revision ChangesPath No revision No revision 1.751.2.932 +1 -12 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.931 retrieving revision 1.751.2.932 diff -u -r1.751.2.931 -r1.751.2.932 --- STATUS 20 Jun 2004 13:12:26 - 1.751.2.931 +++ STATUS 21 Jun 2004 19:11:56 - 1.751.2.932 @@ -77,17 +77,6 @@ hooks just like DSO modules can [Philippe M. Chiasson gozer cpan.org] +1: geoff -*) mod_cgi: Added API call and new field in apr_procattr_t and cgi_exec_info_t - structures to support loading in current or new address space for CGIs. - It fixes NetWare that is currently broken after changes done to log.c r1.145. - modules/generators/mod_cgi.c r1.164 - modules/generators/mod_cgi.h r1.14 - modules/arch/netware/mod_netware r1.18 - +1: jjclar, bnicholes - -0: nd - trawick: is minor mmn bump needed to reflect that API structure was extended? - nd: same as mod_ssl.h issues. It's actually a major bump. Jeff eventually needs to backport the use of a different cmdtype for piped loggers in order to fix an outstanding PR and NetWare still needs to create piped logger processes as expected and recover from a historical lack of information provided to APR about whether or not the child process should run within the same address space of the parent. Surely there is some way to make this happen? What if the default in APR is to run in a separate address space*, and in places in Apache where on NetWare the child process should run in the same address space there is a call to the proper procattr manipulator to override the default so that the child runs in the same address space? (and ignore any APR_ENOTIMPL retcode from that procattr manipulator so that no ifdef NETWARE is needed around the call) This at least avoids adding a field to the end of the cgi structure allocated by Apache and passed to modules implementing the optional function, which (at the moment) a minority of people think requires a major bump. *sounds natural to me; that also means that the default is the same on all platforms -- run child in different address space
Re: cvs commit: httpd-2.0 STATUS
At 12:00 PM 6/22/2004, Brad Nicholes wrote: What if the default in APR is to run in a separate address space*, and in places in Apache where on NetWare the child process should run in the same address space there is a call to the proper procattr manipulator to override the default so that the child runs in the same address space? (and ignore any APR_ENOTIMPL retcode from that procattr manipulator so that no ifdef NETWARE is needed around the call) The is actually the behavior that we don't want on NetWare. Running CGI's or utilities like RotateLogs in a separate address space is very painful and requires overhead and a performance hit that we don't want. On NetWare we need to default to the current address space. BTW, an address space on NetWare is, for the most part, very different than on other platforms. 90% of what is running on the box, is running in the same address space. When we implemented the CGIMapExtension directive to associate a CGI extension with an executible (NetWare doesn't have a shell like BASH to handle the associations) there is an optional parameter called detach which allows the user to specify wheither the associated executible should be run in the current address space or a separate address space. The default is the current address space. Can I ask the obvious, then? When would a separate address space be desirable for an apr-based app to invoke a child/forked process?
Re: cvs commit: httpd-2.0 STATUS
Uh, then may I follow up with another stupid, obvious question, if using another address space insulates the parent application and, in some cases, the server from a crash resulting from an unstable module, why do they all use the same address space on novell? Does this compromise a security measure in the case of a module fail or crash? -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. On Tue, 2004-06-22 at 16:49, Jean-Jacques Clar wrote: Can I ask the obvious, then? When would a separate address space be desirable for an apr-based app to invoke a child/forked process? It is a desirable option mainly for developers using unstable modules to ensure the child process will not kill the parent application, or the server, in case a major problem happens inside the child. By default on NetWare, the http server and all of its child processes are started in the same address space. signature.asc Description: This is a digitally signed message part
Re: cvs commit: httpd-2.0 STATUS
At 05:43 AM 6/12/2004, Joe Orton wrote: On Sat, Jun 12, 2004 at 09:54:56AM -, [EMAIL PROTECTED] wrote: --- STATUS 11 Jun 2004 21:05:21 - 1.751.2.920 +++ STATUS 12 Jun 2004 09:54:56 - 1.751.2.921 @@ -74,8 +74,10 @@ *) mod_ssl: Remove some unused functions (after CAN-2004-0488 fix is applied) http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_util.c?r1=1.46r2=1.47 - +1: jorton, nd + +1: jorton trawick: need changes to mod_ssl.h to remove prototypes for those removed functions + -1: nd: actually that's a public API change (major bump) then and not + applicable for 2.0, just let 'em in The entire contents of mod_ssl.h just cannot be considered a public API, that's too much, even the config structures are in there. The only thing that's usable from other modules is the optional hook, and in reality that declaration just gets cut'n'pasted anyway (even by third-party modules I've seen). Although I'm totally in agreement that these should never have become public, the fact is they are. It's a good effort but not worth any investment in 2.0.x, with 2.2 (2.1-dev) these finally go 'into hiding' as they should have been in the first place. Bill
Re: cvs commit: httpd-2.0 STATUS
The entire contents of mod_ssl.h just cannot be considered a public API, that's too much, even the config structures are in there. The only thing that's usable from other modules is the optional hook, and in reality that declaration just gets cut'n'pasted anyway (even by third-party modules I've seen). Agreed. Without the proper API wrapper (AP_DECLARE) a function may fail to be usable multiplatform anyway. Anything without API wrappers should be considered implementation details. We could issue an RFC on this issue with next stable release, stating how module authors can determine whether a callable function in an Apache header file is considered an API, and explaining our need to modify implementation details as necessary to keep the code base maintainable as we make fixes and enhancements. Any screaming could hopefully be converted into clear requests for certain interfaces to be considered APIs. Sounds like a good plan. +1 david
Re: cvs commit: httpd-2.0 STATUS
For precedent there have already been two binary backwards-incompatible changes made on the 2.0 branch of such exposed but really private interfaces: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/mod_ssl.h?r1=1.122.2.5r2=1.122.2.6only_with_tag=APACHE_2_0_BRANCH http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/main/mod_dav.h?r1=1.65.2.1r2=1.65.2.2 I don't really care about this patch in particular, but moving forward I think it would be good to backport the mod_ssl.h-ssl_private.h split to 2.0 both to prevent further confusion and facilitate other useful backports like the hooks into mod_ssl from mod_rewrite and mod_headers. joe
RE: cvs commit: httpd-2.0 STATUS
-Original Message- From: Joe Orton [mailto:[EMAIL PROTECTED] Sent: Sunday, June 13, 2004 2:02 PM To: [EMAIL PROTECTED] Subject: Re: cvs commit: httpd-2.0 STATUS For precedent there have already been two binary backwards-incompatible changes made on the 2.0 branch of such exposed but really private interfaces: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/mod_ssl .h?r1=1.122.2.5r2=1.122.2.6only_with_tag=APACHE_2_0_BRANCH http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/main/mo d_dav.h?r1=1.65.2.1r2=1.65.2.2 I don't really care about this patch in particular, but moving forward I think it would be good to backport the mod_ssl.h-ssl_private.h split to 2.0 both to prevent further confusion and facilitate other useful backports like the hooks into mod_ssl from mod_rewrite and mod_headers. I totally agree with Joe here - there are a whole bunch of useful features that can be back ported if we can do the mod_ssl.h - ssl_private.h split. For the record, we've got a number of requests to back port the mod_rewrite and mod_headers features to 2.0 on hp-ux. Yes - we can back port the changes without going for the split - but the split would just make the things a lot easier in the future. +1 for the back port -Madhu
Re: cvs commit: httpd-2.0 STATUS
On Sat, Jun 12, 2004 at 09:54:56AM -, [EMAIL PROTECTED] wrote: --- STATUS 11 Jun 2004 21:05:21 - 1.751.2.920 +++ STATUS 12 Jun 2004 09:54:56 - 1.751.2.921 @@ -74,8 +74,10 @@ *) mod_ssl: Remove some unused functions (after CAN-2004-0488 fix is applied) http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_util.c?r1=1.46r2=1.47 - +1: jorton, nd + +1: jorton trawick: need changes to mod_ssl.h to remove prototypes for those removed functions + -1: nd: actually that's a public API change (major bump) then and not + applicable for 2.0, just let 'em in The entire contents of mod_ssl.h just cannot be considered a public API, that's too much, even the config structures are in there. The only thing that's usable from other modules is the optional hook, and in reality that declaration just gets cut'n'pasted anyway (even by third-party modules I've seen). joe
Re: cvs commit: httpd-2.0 STATUS
* Joe Orton [EMAIL PROTECTED] wrote: On Wed, May 05, 2004 at 03:05:45PM -0400, Jeff Trawick wrote: [EMAIL PROTECTED] wrote: jorton 2004/05/05 09:29:59 Index: STATUS *) Readd suexec setuid and user check (now APR supports it) os/unix/unixd.c: r1.69 +1: nd, trawick + +1: jorton, if surrounded with #ifdef APR_USETID to retain + compatibility with APR 0.9.5 why the compatibility restriction? APR 0.9.4 is the latest released version of APR, and it's desirable that the 2.0 branch is always usable with a released version of APR. Just for the records: I agree with this argumentation :-) nd
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: jorton 2004/05/05 09:29:59 Index: STATUS *) Readd suexec setuid and user check (now APR supports it) os/unix/unixd.c: r1.69 +1: nd, trawick + +1: jorton, if surrounded with #ifdef APR_USETID to retain + compatibility with APR 0.9.5 why the compatibility restriction?
Re: cvs commit: httpd-2.0 STATUS
On Wed, May 05, 2004 at 03:05:45PM -0400, Jeff Trawick wrote: [EMAIL PROTECTED] wrote: jorton 2004/05/05 09:29:59 Index: STATUS *) Readd suexec setuid and user check (now APR supports it) os/unix/unixd.c: r1.69 +1: nd, trawick + +1: jorton, if surrounded with #ifdef APR_USETID to retain + compatibility with APR 0.9.5 why the compatibility restriction? APR 0.9.4 is the latest released version of APR, and it's desirable that the 2.0 branch is always usable with a released version of APR. joe
Re: cvs commit: httpd-2.0 STATUS
On Sat, Apr 10, 2004 at 06:51:50PM -, [EMAIL PROTECTED] wrote: @@ -200,10 +202,11 @@ *) mod_dav: Send an EOS at the end of the multistatus brigade. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/main/mod_dav.c?r1=1.105r2=1.106 +1: jorton + nd asks: Sure, you want to drop the return code of ap_pass_brigade? No, not particularly, but that's what the original code did and the above change makes no difference to that AFAICT. Does dropping the return code cause Real Bugs? Regards, joe
Re: cvs commit: httpd-2.0 STATUS
* Joe Orton [EMAIL PROTECTED] wrote: On Sat, Apr 10, 2004 at 06:51:50PM -, [EMAIL PROTECTED] wrote: @@ -200,10 +202,11 @@ *) mod_dav: Send an EOS at the end of the multistatus brigade. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/main/mod_dav.c?r1=1.105r2=1.106 +1: jorton + nd asks: Sure, you want to drop the return code of ap_pass_brigade? No, not particularly, but that's what the original code did and the above change makes no difference to that AFAICT. Does dropping the return code cause Real Bugs? It breaks the return code chain and hides filter errors. That would be enough for me to just return it ;) nd
Re: cvs commit: httpd-2.0 STATUS
On Thu, 15 Apr 2004, Joe Orton wrote: + nd asks: Sure, you want to drop the return code of ap_pass_brigade? No, not particularly, but that's what the original code did and the above change makes no difference to that AFAICT. Does dropping the return code cause Real Bugs? It can, yes. --Cliff
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: ben 2004/03/28 20:00:17 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Add mod_log_forensic... +++ STATUS 29 Mar 2004 04:00:16 - 1.751.2.780 @@ -304,6 +304,9 @@ CURRENT VOTES: +* Backport mod_log_forensic. + +1: ben I can put a +1 (concept) in, but it would helpful if there were a patch and/or a set of 2.1-dev commits to review (as with the other back-port proposals in the previous section of STATUS).
Re: cvs commit: httpd-2.0 STATUS
On Tue, Mar 09, 2004 at 06:14:00PM -, [EMAIL PROTECTED] wrote: madhum 2004/03/09 10:14:00 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Propose a backport (for mod_rewrite to recognize SSL variables) Thanks for committing that Madhu. The mod_ssl.h-ssl_private.h change is a prerequisite backport for this however, to allow mod_ssl.h to be safely included in other modules even when mod_ssl is not enabled. +*) mod_rewrite: Support for recognizing SSL variables in RewriteCond + using the new SSL: format. + modules/mappers/mod_rewrite.c: 1.253 + modules/mappers/mod_ssl.c: 1.38 + +1: madhum +
RE: cvs commit: httpd-2.0 STATUS
Yep - I was actually in a dual-mind to propose it as a backport (since it's based on the new mod_ssl.h). I'll just remove the proposal for now (and let the fix come in as part of Bill Rowe's proposal to backport entire mod_ssl 2.1 to mod_ssl 2.0) Thanks, -Madhu -Original Message- From: Joe Orton [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 11:55 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: httpd-2.0 STATUS On Tue, Mar 09, 2004 at 06:14:00PM -, [EMAIL PROTECTED] wrote: madhum 2004/03/09 10:14:00 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Propose a backport (for mod_rewrite to recognize SSL variables) Thanks for committing that Madhu. The mod_ssl.h-ssl_private.h change is a prerequisite backport for this however, to allow mod_ssl.h to be safely included in other modules even when mod_ssl is not enabled. +*) mod_rewrite: Support for recognizing SSL variables in RewriteCond + using the new SSL: format. + modules/mappers/mod_rewrite.c: 1.253 + modules/mappers/mod_ssl.c: 1.38 + +1: madhum +
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: gregames2004/02/26 12:12:13 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: vote on exception hook backport. review was fine, extra credit for cleaning up the duplication of signal handling between the mpms. Tested on RH9 w/prefork - no regression, worker - no regression, enabled mod_backtrace here which worked as expected once I set EnableExceptionHook On in httpd.conf. cool, thanks for testing I need to get the 2.x versions of mod_backtrace and mod_whatkilledus cleaned up to match the 1.3 versions and stick them in 2.1-dev's experimental directory.
Re: cvs commit: httpd-2.0 STATUS
* [EMAIL PROTECTED] wrote: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/metadata/mod_expires.c?r1=1.45r2=1.46 Hrm. The whole check is probably segfaulting with something like ExpiresByType text isn't it? (Sorry for so late jumping in). nd
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: rederpj 2004/02/04 06:37:40 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: (sheepishly) add a vote... (darn, missed the warning scrolling by. Good catch, thanks). we're up to 4 now... I'll commit the fix.
Re: cvs commit: httpd-2.0 STATUS
Joe Orton wrote: On Sat, Jan 24, 2004 at 12:48:33AM +0100, André Malo wrote: * Greg Stein [EMAIL PROTECTED] wrote: On Fri, Jan 23, 2004 at 11:28:28PM +0100, André Malo wrote: Hmm, and then? I'd see it as a workaround for buggy clients like the redirect-carefully variable. It's a matter of degree. Just how many clients are broken, and what percentage of traffic do they represent? The redirect-carefully was put in because of a great many, popular clients were borken. Dunno ;-) How many clients are we talking about? Redirect-Carefully IMHO affects all Microsoft Webfolder clients. Maybe this needs to be added to the (webfolder) issues list? Julian Reschke's bug-tracker lists the versions of the MS clients this is known to affect: (that doesn't really answer the question, I know) http://greenbytes.de/tech/webdav/webfolder-client-list.html#issue-hashmark-escaping As I understand it, the clients only screw up when hash is the first character of the last path segment: is that right Julian? I'd consider it a relatively obscure issue, it's not worth putting a lot of effort into other than making sure the requests are rejected. If the hashmark is the first character of a path segment, buggy servers will apply the request to the parent collection instead of just rejecting the request (it's not a valid request according to RFC2616). This is of course a desaster for DELETE. On the other hand, if the hashmark isn't the first character, the request may get applied to the resource identified by the path segment truncated at the #. So, you may want to delete a%23b, but what get's deleted is a. Still a major problem. So there are (were) two issues: a client (Webfolder) that didn't escape the hashmark (only a few releases, and I think this issue is resolved in later clients), and a server that doesn't (didn't?) reject invalid requests. Hope this helps. Julian P.S.: The issue list mentioned above depends on people contributing empirical data. Hint, hint. :-) -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: cvs commit: httpd-2.0 STATUS
On Mon, Jan 12, 2004 at 12:04:38AM -, [EMAIL PROTECTED] wrote: * mod_dav: Reject requests including fragment part in the Request-URI. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/main/mod_dav.c?r1=1.102r2=1.103 PR: 21779 +1: jorton +nd asks: Should we make it runtime configurable either to 400, drop the + fragment or just treat it as part of the filename? I missed this till now, sorry. I don't see why it's worth a config option: the client is generating an invalid request, so let it break rather than trying to second-guess the escaping rules. The error_log message makes it clear what is wrong. Regards, joe
Re: cvs commit: httpd-2.0 STATUS
* Joe Orton [EMAIL PROTECTED] wrote: On Mon, Jan 12, 2004 at 12:04:38AM -, [EMAIL PROTECTED] wrote: * mod_dav: Reject requests including fragment part in the Request-URI. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/main/mod_dav.c?r1=1.102r2=1.103 PR: 21779 +1: jorton +nd asks: Should we make it runtime configurable either to 400, drop the+ fragment or just treat it as part of the filename? I missed this till now, sorry. I don't see why it's worth a config option: the client is generating an invalid request, so let it break rather than trying to second-guess the escaping rules. The error_log message makes it clear what is wrong. Hmm, and then? I'd see it as a workaround for buggy clients like the redirect-carefully variable. nd
Re: cvs commit: httpd-2.0 STATUS
On Fri, Jan 23, 2004 at 11:28:28PM +0100, André Malo wrote: * Joe Orton [EMAIL PROTECTED] wrote: On Mon, Jan 12, 2004 at 12:04:38AM -, [EMAIL PROTECTED] wrote: * mod_dav: Reject requests including fragment part in the Request-URI. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/main/mod_dav.c?r1=1.102r2=1.103 PR: 21779 +1: jorton +nd asks: Should we make it runtime configurable either to 400, drop the+ fragment or just treat it as part of the filename? I missed this till now, sorry. I don't see why it's worth a config option: the client is generating an invalid request, so let it break rather than trying to second-guess the escaping rules. The error_log message makes it clear what is wrong. Hmm, and then? I'd see it as a workaround for buggy clients like the redirect-carefully variable. It's a matter of degree. Just how many clients are broken, and what percentage of traffic do they represent? The redirect-carefully was put in because of a great many, popular clients were borken. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0 STATUS
* Greg Stein [EMAIL PROTECTED] wrote: On Fri, Jan 23, 2004 at 11:28:28PM +0100, André Malo wrote: Hmm, and then? I'd see it as a workaround for buggy clients like the redirect-carefully variable. It's a matter of degree. Just how many clients are broken, and what percentage of traffic do they represent? The redirect-carefully was put in because of a great many, popular clients were borken. Dunno ;-) How many clients are we talking about? nd
Re: cvs commit: httpd-2.0 STATUS
On Sat, Jan 24, 2004 at 12:48:33AM +0100, André Malo wrote: * Greg Stein [EMAIL PROTECTED] wrote: On Fri, Jan 23, 2004 at 11:28:28PM +0100, André Malo wrote: Hmm, and then? I'd see it as a workaround for buggy clients like the redirect-carefully variable. It's a matter of degree. Just how many clients are broken, and what percentage of traffic do they represent? The redirect-carefully was put in because of a great many, popular clients were borken. Dunno ;-) How many clients are we talking about? Julian Reschke's bug-tracker lists the versions of the MS clients this is known to affect: (that doesn't really answer the question, I know) http://greenbytes.de/tech/webdav/webfolder-client-list.html#issue-hashmark-escaping As I understand it, the clients only screw up when hash is the first character of the last path segment: is that right Julian? I'd consider it a relatively obscure issue, it's not worth putting a lot of effort into other than making sure the requests are rejected. Regards, joe
Re: cvs commit: httpd-2.0 STATUS
* unescaped error logs seem to be essential for some folks
backport -DAP_UNSAFE_ERROR_LOG_UNESCAPED to 2.0 and 1.3
server/log.c: r1.139, r1.140
-+1: nd
++1: nd, stas
should this get another vote, I have patches for 2.0 and 1.3 ready.
--Geoff
Index: server/log.c
===
RCS file: /home/cvspublic/httpd-2.0/server/log.c,v
retrieving revision 1.127.2.6
diff -u -r1.127.2.6 log.c
--- server/log.c1 Jan 2004 13:30:43 - 1.127.2.6
+++ server/log.c14 Jan 2004 15:19:00 -
@@ -401,7 +401,10 @@
const request_rec *r, apr_pool_t *pool,
const char *fmt, va_list args)
{
-char errstr[MAX_STRING_LEN], scratch[MAX_STRING_LEN];
+char errstr[MAX_STRING_LEN];
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
+char scratch[MAX_STRING_LEN];
+#endif
apr_size_t len, errstrlen;
apr_file_t *logf = NULL;
const char *referer;
@@ -538,15 +541,28 @@
}
errstrlen = len;
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
if (apr_vsnprintf(scratch, MAX_STRING_LEN - len, fmt, args)) {
len += ap_escape_errorlog_item(errstr + len, scratch,
MAX_STRING_LEN - len);
}
+#else
+len += apr_vsnprintf(errstr + len, MAX_STRING_LEN - len, fmt, args);
+#endif
if ( r (referer = apr_table_get(r-headers_in, Referer))
- ap_escape_errorlog_item(scratch, referer, MAX_STRING_LEN - len)) {
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
+ ap_escape_errorlog_item(scratch, referer, MAX_STRING_LEN - len)
+#endif
+) {
len += apr_snprintf(errstr + len, MAX_STRING_LEN - len,
-, referer: %s, scratch);
+, referer: %s,
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
+scratch
+#else
+referer
+#endif
+);
}
/* NULL if we are logging to syslog */
Index: src/main/http_log.c
===
RCS file: /home/cvspublic/apache-1.3/src/main/http_log.c,v
retrieving revision 1.98
diff -u -r1.98 http_log.c
--- src/main/http_log.c 1 Jan 2004 13:32:54 - 1.98
+++ src/main/http_log.c 16 Jan 2004 16:15:14 -
@@ -313,11 +313,15 @@
const server_rec *s, const request_rec *r,
const char *fmt, va_list args)
{
-char errstr[MAX_STRING_LEN], scratch[MAX_STRING_LEN];
+char errstr[MAX_STRING_LEN];
size_t len;
int save_errno = errno;
FILE *logf;
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
+char scratch[MAX_STRING_LEN];
+#endif
+
if (s == NULL) {
/*
* If we are doing stderr logging (startup), don't log messages that are
@@ -445,10 +449,14 @@
}
#endif
+#ifndef AP_UNSAFE_ERROR_LOG_UNESCAPED
if (ap_vsnprintf(scratch, sizeof(scratch) - len, fmt, args)) {
len += ap_escape_errorlog_item(errstr + len, scratch,
sizeof(errstr) - len);
}
+#else
+len += ap_vsnprintf(errstr + len, sizeof(errstr) - len, fmt, args);
+#endif
/* NULL if we are logging to syslog */
if (logf) {
Re: cvs commit: httpd-2.0 STATUS
On Fri, Dec 26, 2003 at 04:10:04PM -0800, Justin Erenkrantz wrote: --On Tuesday, December 23, 2003 2:59 PM + [EMAIL PROTECTED] wrote: + PR 24469, broken reverse lookups with IPv4-mapped addrs on old OS X +The autoconf check added between 2.0.47 and 2.0.48 isn't +sufficient for catching the OS X problem, because building the +IPv4 numeric address string from IPv4-mapped address would work +but actually resolving the host would not. To catch the check +via retcode, you have to specify the NI_NAMEREQD flag. I think APR 1.0 already has this fix. It's probably that we need to backport r1.24 of build/apr_network.m4 (which was done after the 0.9 branch point). Or, am I misunderstanding? As long as the broken version of OS X ships with an /etc/hosts file or some equivalent and resolver library that will resolve 127.0.0.1, that should be absolutely fine. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: cvs commit: httpd-2.0 STATUS
On Dec 28, 2003, at 7:03 PM, Colm MacCarthaigh wrote: On Fri, Dec 26, 2003 at 04:10:04PM -0800, Justin Erenkrantz wrote: --On Tuesday, December 23, 2003 2:59 PM + [EMAIL PROTECTED] wrote: + PR 24469, broken reverse lookups with IPv4-mapped addrs on old OS X +The autoconf check added between 2.0.47 and 2.0.48 isn't +sufficient for catching the OS X problem, because building the +IPv4 numeric address string from IPv4-mapped address would work +but actually resolving the host would not. To catch the check +via retcode, you have to specify the NI_NAMEREQD flag. I think APR 1.0 already has this fix. It's probably that we need to backport r1.24 of build/apr_network.m4 (which was done after the 0.9 branch point). Or, am I misunderstanding? yep As long as the broken version of OS X ships with an /etc/hosts file or some equivalent and resolver library that will resolve 127.0.0.1, that should be absolutely fine. it will be fine anyway :) it is okay to fail the test, as it just brings a few extra instructions... it is only bad to pass the test when in fact it should be failed some number of boxes will start failing the test now, and incur the trivial amount of extra code in APR for resolving IPv4-mapped addresses
Re: cvs commit: httpd-2.0 STATUS
On Sun, Dec 28, 2003 at 09:09:42PM -0500, Jeff Trawick wrote: it will be fine anyway :) it is okay to fail the test, as it just brings a few extra instructions... it is only bad to pass the test when in fact it should be failed some number of boxes will start failing the test now, and incur the trivial amount of extra code in APR for resolving IPv4-mapped addresses Ah how time changes things, the original patch I had was just #ifdef'd for DARWIN, a wholly simpler solution ;) It does no harm on working systems and will fix the broken ones - me 4 months ago. Curse whoever wrote that test (NB: may have been me :/). Does anyone still have a Darwin system that exhibits the broken behaviour? Does anyone know what getnameinfo() returns when passed ::127.0.0.1? If it's somethign useful like EAI_SYSTEM, EAI_FAIL or EAI_FAMILY that can be used to detect that particular failure mode (as opposed to just EAI_NONAME). -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: jerenkrantz2003/12/26 23:41:28 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Reflect merged backports (those that I casted at least the 3rd +1 for), and cast some votes on those with less than 3 +1s. Happy holidays!!! Index: STATUS @@ -209,7 +185,8 @@ modules/generators/mod_cgid.c r1.152, r1.161 server/mpm_common.c r1.111 PREREQ: ap_mpm_query(mpm-state) support in Unix MPMs -+1: trawick, stoddard +jerenkrantz asks: What does mpm_common.c r1.111 have to do with this? ++1: trawick, stoddard, jerenkrantz Prior to r1.111, that code relied on a global variable (holding the pid) to be set in a child process. However, the global variable was not being set for a *restarted* cgid daemon, so if a *restarted* cgid daemon crashed, an entry would be written to the error log stating that the parent had crashed. The change removes the requirement for having the global variable set. * ab: catch out of memory (reasoning report ID 29) support/ab.c: r1.125 @@ -239,6 +216,7 @@ around... :) Yes, I think, a useful error message is better than a coredump in this case. + jerenkrantz: Oh, bah. Let 'em segfault. Use flood! how about a shell script (flab?) to generate appropriate xml from an ab command-line, and then run it? * Fix a long delay with CGI requests and keepalive connections on AIX. modules/generators/mod_cgid.c r1.159 - +1: trawick, stoddard + jerenkrantz: Could we do this on other platforms, too? + +1: trawick, stoddard, jerenkrantz extremely likely :)
Re: cvs commit: httpd-2.0 STATUS
--On Saturday, December 27, 2003 7:51 AM -0500 Jeff Trawick [EMAIL PROTECTED] wrote: Happy holidays!!! A good way to end the year by closing as many backports as possible. ;-) @@ -209,7 +185,8 @@ modules/generators/mod_cgid.c r1.152, r1.161 server/mpm_common.c r1.111 PREREQ: ap_mpm_query(mpm-state) support in Unix MPMs -+1: trawick, stoddard +jerenkrantz asks: What does mpm_common.c r1.111 have to do with this? ++1: trawick, stoddard, jerenkrantz Prior to r1.111, that code relied on a global variable (holding the pid) to be set in a child process. However, the global variable was not being set for a *restarted* cgid daemon, so if a *restarted* cgid daemon crashed, an entry would be written to the error log stating that the parent had crashed. The change removes the requirement for having the global variable set. Ah. Gotcha. The signal handler would still be registered with the children. how about a shell script (flab?) to generate appropriate xml from an ab command-line, and then run it? Possible. I'd really like to see ab die... * Fix a long delay with CGI requests and keepalive connections on AIX. modules/generators/mod_cgid.c r1.159 - +1: trawick, stoddard + jerenkrantz: Could we do this on other platforms, too? + +1: trawick, stoddard, jerenkrantz extremely likely :) Yeah, I noticed that Darwin's getpgid() has the same behavior as AIX. Hence, my +1. -- justin
Re: cvs commit: httpd-2.0 STATUS
--On Tuesday, December 23, 2003 2:59 PM + [EMAIL PROTECTED] wrote: + PR 24469, broken reverse lookups with IPv4-mapped addrs on old OS X +The autoconf check added between 2.0.47 and 2.0.48 isn't +sufficient for catching the OS X problem, because building the +IPv4 numeric address string from IPv4-mapped address would work +but actually resolving the host would not. To catch the check +via retcode, you have to specify the NI_NAMEREQD flag. I think APR 1.0 already has this fix. It's probably that we need to backport r1.24 of build/apr_network.m4 (which was done after the 0.9 branch point). Or, am I misunderstanding? -- justin
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: + PR 24469, broken reverse lookups with IPv4-mapped addrs on old OS X +The autoconf check added between 2.0.47 and 2.0.48 isn't +sufficient for catching the OS X problem, because building the +IPv4 numeric address string from IPv4-mapped address would work +but actually resolving the host would not. To catch the check +via retcode, you have to specify the NI_NAMEREQD flag. A patch should be easy, but I have no system to test on (upgraded to Panther). I'm a bit nervous about doing a name lookup at configure time anyway. Thoughts? Is there any system other than OS X Panther that ever had this problem? I thought z/OS did because the autoconf test was failing, but it turned out that the autoconf test needed a little porting help.
Re: cvs commit: httpd-2.0 STATUS
A patch should be easy, but I have no system to test on (upgraded to Panther). I'm a bit nervous about doing a name lookup at configure time anyway. I have a 10.1 box that I use as a web server. I have not been upgrading that machine for several reasons, and can use it for testing stuff out. It will also be unable to do name lookups well, because it sits in a DMZ and is all firewalled 'n stuff. This also means there's no outward facing ssh and I'd have to copy a source tree from within the network behind the DMZ, but if you send me a patch against HEAD I can take that for a spin. I upgraded both my other boxes to Panther, so no Jaguar installations remain. This is unfortunate because I think no one should be encouraged to use 10.1 anyway... Let me know, S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: cvs commit: httpd-2.0 STATUS
+ nd replies: But if it can't be 0 the alternatives thereafter make no + sense anymore, right? Good point, so if that is true then isn't the code in the else part of ap_get_server_port() also wrong. In other words, ap_default_port() would never be called if UseCanonicalName is ON. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Friday, November 21, 2003 4:25:37 PM nd 2003/11/21 15:25:37 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: vote note Revision ChangesPath No revision No revision 1.751.2.554 +4 -2 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.553 retrieving revision 1.751.2.554 diff -u -u -r1.751.2.553 -r1.751.2.554 --- STATUS21 Nov 2003 22:38:42 - 1.751.2.553 +++ STATUS21 Nov 2003 23:25:37 - 1.751.2.554 @@ -307,6 +307,8 @@ bnicholes response: I couldn't tell you for sure if local_addr-port could be 0. But it makes sense that if it were then Apache wouldn't be listening on any port so it wouldn't matter anyway. + nd replies: But if it can't be 0 the alternatives thereafter make no + sense anymore, right? * mod_status: Report total CPU time accurately when using a threaded MPM. PR: 23795 @@ -364,7 +366,7 @@ * Fix display of empty variables via mod_include. PR 24734. modules/metadata/mod_env.c r1.31 - +1: trawick + +1: trawick, nd CURRENT RELEASE NOTES:
Re: cvs commit: httpd-2.0 STATUS
* [EMAIL PROTECTED] wrote: yep. too bad there are so many places in the code where this problem appears. i feel like we ought to take the opposite approach and guarantee that r-filename is never NULL, but oh well. we've gone down this path instead, so this is clearly a correct fix. Note that this happens, because mod_include is a filter, added by type text/html in global server context. The error condition is very specific, say, 400 Response for malformed Host header, which appears to be a text/html response. What would r-filename be in this case? IMHO this is totally besides the r-filename should not be NULL problem, isn't it? nd
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: jorton 2003/09/16 06:01:06 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Fix a PR# and vote on tested backports. Revision ChangesPath No revision No revision 1.751.2.470 +6 -6 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.469 retrieving revision 1.751.2.470 diff -u -u -r1.751.2.469 -r1.751.2.470 --- STATUS 16 Sep 2003 01:00:07 - 1.751.2.469 +++ STATUS 16 Sep 2003 13:01:06 - 1.751.2.470 @@ -240,14 +240,14 @@ +1: fielding, nd, jerenkrantz, erikabele * mod_ssl: Fix a problem setting variables that represent the - client certificate chain. PR 21397 + client certificate chain. PR 21371 whoops! I don't even want to know what a woody extension is modules/ssl/ssl_engine_vars.c: r1.24 - +1: trawick, nd + +1: trawick, nd, jorton will commit soon-ish
Re: cvs commit: httpd-2.0 STATUS
On Tue, Sep 16, 2003 at 09:27:54AM -0400, Jeff Trawick wrote: ... * mod_ssl: Fix a problem setting variables that represent the - client certificate chain. PR 21397 + client certificate chain. PR 21371 whoops! I don't even want to know what a woody extension is I do, and she loves me for it. :-) -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0 STATUS
Greg Stein wrote: On Tue, Sep 16, 2003 at 09:27:54AM -0400, Jeff Trawick wrote: ... * mod_ssl: Fix a problem setting variables that represent the - client certificate chain. PR 21397 + client certificate chain. PR 21371 whoops! I don't even want to know what a woody extension is I do, and she loves me for it. :-) I'm glad somebody was paying attention :)
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: jim 2003/08/20 05:10:11 Modified:.Tag: APACHE_2_0_BRANCH STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.433 retrieving revision 1.751.2.434 diff -u -r1.751.2.433 -r1.751.2.434 --- STATUS19 Aug 2003 16:06:20 - 1.751.2.433 +++ STATUS20 Aug 2003 12:10:11 - 1.751.2.434 @@ -201,6 +201,14 @@ os/unix/unixd.c 1.58 os/unix/unixd.h 1.38 +1: trawick, jerenkrantz + 0: jim (it seems to me that the locking mech itself + should have the required flags to determine whether + uid/gid and chown is required, rather than placing + that knowledge in unixd.c (kind of what is done for + the SSL stuff already with ChownMutexFile). Thus + unixd would simply check those out and do what is + required rather than having internal APR knowledge + it shouldn't). There is no longer ChownMutexFile in mod_ssl with this patch, the philosophy being that if APR doesn't know how to handle these platform-specific permissions issues, at least we can segregate it in unixd.c rather than having various modules have to think about it. So where we are with this patch is that the platform-specific guts are split between unixd.c and APR... APR tells unixd.c what mutex type it is, and unixd.c knows that flock needs the chown()... modules don't need to know much, and it would better if they didn't even have to know not to call the function on Win32/OS2/whatever What would be the interface if APR instead tells unixd.c that the lock file needs chown()? Wouldn't that be adding an API to APR that we don't want long-term? Also, is it an improvement for the chown() issue to be split in two places? I don't see a big improvement until APR has some serious support for permissions/identity and unixd.c can say hey, make sure this uid/gid can play with the mutex.
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: nd 2003/03/26 17:10:59 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: I consider these important enough to treat them as showstoppers. RELEASE SHOWSTOPPERS: +* Forward port: Escape special characters (especially control + characters) in mod_log_config to make a clear distinction between + client-supplied strings (with special characters) and server-side + strings. This was already introduced in version 1.3.25. +* Fix mod_rewrite's path handling. It's essentially broken for non-unices + for ages. PR 12902. alternative opinion: neither of these are showstoppers... not a security problem, not new breakage compared with previous release, instead something that has been working that way for ages and will not be an unpleasant surprise to anyone
Re: cvs commit: httpd-2.0 STATUS
* Jeff Trawick wrote: +* Forward port: Escape special characters (especially control + characters) in mod_log_config to make a clear distinction between + client-supplied strings (with special characters) and server-side + strings. This was already introduced in version 1.3.25. +* Fix mod_rewrite's path handling. It's essentially broken for non-unices + for ages. PR 12902. alternative opinion: neither of these are showstoppers... Sure :) not a security problem, hmm. Bogus characters _can_ break the logfiles and it was never ported to 2.x. At least it may prevent some people to switch from 1.3 to 2.x. But ok, it may be a question of taste. not new breakage compared with previous release, instead something that has been working that way for ages and will not be an unpleasant surprise to anyone mod_rewrite was finally broken in http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/mod_rewrite.c.diff?r1=1.83r2=1.84diff_format=h which is 2.0.27 (log time ago). Before this change it was mostly usable by some workarounds. The change was unfortunately backported to 1.3.25 (http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/modules/standard/mod_rewrite.c.diff?r1=1.175r2=1.176diff_format=h) which made it also unusable in nearly all cases in 1.3. I'm still considering the mod_rewrite fix to be _very_ important. The very small subset of RewriteRules that do work on non-unices is IMHO not sufficient for a *GA* version. nd -- package Hacker::Perl::Another::Just;print [EMAIL PROTECTED] split/::/ =__PACKAGE__]}~; # André Malo # http://www.perlig.de #
Re: cvs commit: httpd-2.0 STATUS
* William A. Rowe, Jr. wrote: At 05:42 AM 3/27/2003, Jeff Trawick wrote: [EMAIL PROTECTED] wrote: nd 2003/03/26 17:10:59 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: I consider these important enough to treat them as showstoppers. RELEASE SHOWSTOPPERS: +* Forward port: Escape special characters (especially control + characters) in mod_log_config to make a clear distinction between + client-supplied strings (with special characters) and server-side + strings. This was already introduced in version 1.3.25. +* Fix mod_rewrite's path handling. It's essentially broken for non-unices + for ages. PR 12902. alternative opinion: neither of these are showstoppers... not a security problem, not new breakage compared with previous release, instead something that has been working that way for ages and will not be an unpleasant surprise to anyone I agree that neither are regressions so neither is a valid showstopper this late into an announced release plan. If someone wants to +1 that first patch I don't have a problem adopting it, but I'm not in a rush to do so. The second was +1'ed by yourself and Brad, so I'm giving you a provisional +1 for 2.0.45 based on my first review, and will run the complete regressions once you've committed to APACHE_2_0_BRANCH. But I won't hold the release any longer unless we find regressions. I see one potential issue in cgid on sparc/solaris, and I need to determine this is not a regression before I can bless with a tarball. Well, then I'll re-move the first one down to the other backports and put the rewrite thing in. If there are problems with the patch, I'm ready for reverting it. Thanks, nd -- [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet? DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da so reinpacken und dann absolut positionieren ... -- Florian Hartig und Lars Kasper in dciwam
RE: cvs commit: httpd-2.0 STATUS
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 7:43 PM +++ STATUS 7 Mar 2003 18:42:44 - 1.751.2.157 @@ -74,6 +74,10 @@ wrowe: yes - it would be cool to have debug flavors in the same files as their non-debug versions - but for macros, then what? Andre - suggest an alternative :-) + nd: ehm, just to be clear: I was talking about get/set_module_config. + (hmm, are the macros ever used now?). These should go into + config.c, imho. It seems, I don't fully understand all the + #defines and #undefs that happen there. It's to ensure we have the _functions_ ap_[gs]et_module_config all the time. When AP_DEBUG is not defined, these are defined as macros. And, yes, I agree that config.c would be a better place for those functions. However, I didn't want to move anything in this commit, but just wanted to compile them in unconditionally. Sander
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: gstein 2003/02/27 04:53:19 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: trawick wanted commentary in STATUS rather than on the mailing list. fine... I don't care whether commentary on this topic is in STATUS or on the mailing list (I for one put all of my commentary on this topic on the mailing list). I do want to make sure that people who appear to disagree with the status quo take the opportunity to formalize that with a vote, because it is that vote that directly controls how things are done, not the megabytes of commentary. Regarding your comment But now we're seeing this stupid R-T-C hammer being used to smack developers over the head. Stas didn't follow the rules that the group chose, and I took exception because his action interfered with my own desires to carefully review anything within my grasp which is committed to the stable branch. End of story. [IMO he didn't follow the rules not because he was bad and needed to be smacked over the head but because he was not accustomed to how the stable branch was being handled and needed to be steered in the right direction. I'm definitely in the Stas fan club and don't plan on trying to smack him over the head. I also have faith that he is clever enough to realize that procedural comments on a commit (be they gripes about whitespace or missing information or otherwise) are not smacks on the head but instead attempts to steer somebody in the right direction.]
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: + + Yes, I'm ranting, and hey, I'm even sober. :-) =:o -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Trust and Review was Re: cvs commit: httpd-2.0 STATUS
--On Thursday, February 27, 2003 12:53 PM + [EMAIL PROTECTED] wrote: + The problem here is that R-T-C expresses a fundamental + DISTRUST of your peers. We had problems stabilizing the + code simply because there are numerous interests in the + codebase, and those are not fully compatible. With the It's also the fact that I have no way of knowing whether my fix is perfect - I might think it is, but I just won't stake my reputation or this group's reputation on it. Actively enforcing peer review allows some confidence that at least two other people agree with the change. It's a way of backchecking not as a matter of distrust. In fact, I'd say it is the reverse: R-T-C mandates a trust in your peers that they are able and willing to understand the code. Creating code in isolation without anyone else understanding it is harmful. We're developing this server together. We have a number of places in our code that there may only be one or two people who fully understand it. I don't believe that is goodness on our parts. If we enforce code review, then it makes it such that others start to get exposed to other areas they may not have been exposed to before. That is the best way we can deal with people leaving and abandoning 'their' code. Even the most trivial 'common sense' commits can generate essential feedback that a single developer overlooked. I can only perform limited testing on it with my own platforms, compilers, etc. I may be too close to the problem to get an accurate view of what the fix should be. I view peer review as a safeguard and a mechanism to show the community that we are doing our best to produce the highest-quality releases that we can. The fact is that with C-T-R, we hardly ever did R. The sheer volume of commits was just too much for lots of developers - AIUI, this is why we abandoned R-T-C not because anyone in the Apache Group wanted to. If we all weren't so damn lazy, C-T-R might have worked in producing stable releases. I just don't believe that materialzed. Our release quality has been reducing for a long-time because we haven't been relying on what made us good: 'high-quality well-tested releases.' -- justin
Re: cvs commit: httpd-2.0 STATUS
On Sat, Feb 22, 2003 at 05:15:22AM -, [EMAIL PROTECTED] wrote: jerenkrantz2003/02/21 21:15:22 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Why is anyone still using SUNOS4? On Apache 2.0? Why? Anyway, fill out some more votes. People are still using Apache 1.2, and you ask whether SunOS4 is in use? Hah... (altho, to be honest, I'm on the fence whether SunOS4 users are bound to Apache 1.3, and they've gotta OS0-upgrade to get A2) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0 STATUS
--On Saturday, February 22, 2003 6:46 PM + [EMAIL PROTECTED] wrote: Thanks you folks and sorry again for the non-sufficient log entries. Ah, geez. It's *not* that big of a deal. =) -- justin
Re: cvs commit: httpd-2.0 STATUS
On Thu, 30 Jan 2003 [EMAIL PROTECTED] wrote: stoddard2003/01/30 10:07:17 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Done -* Port stoddard's patch to mod_file_cache to call apr_mmap_dup - -* mod_file_cache segfault bugfix. PR 16313. Thanks Bill! --Cliff
Re: cvs commit: httpd-2.0 STATUS
On Tue, 2002-12-10 at 15:53, [EMAIL PROTECTED] wrote: stoddard2002/12/10 15:53:50 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Looking for votes... Any objections? +PATCHES TO PORT FROM 2.1 +* stoddard: All mod_cache (and related) patches as of 12/10/02. I can't remember whether votes for these are supposed to be in STATUS or on the mailing list, but: +1 Brian
Re: cvs commit: httpd-2.0 STATUS
On Monday, November 25, 2002, at 04:58 PM, Aaron Bannert wrote: I guess I just didn't read that much in to it. I just want to see us move forward without getting bogged down in misinterpreted emails and already acknowledged mistakes, and to do that I'm trying to stay objective (eg. a Vote). To me this looks like the set of concerns: 1) we want 2.0 maintenance 2) we want 2.1 development 3) we want parallel development of each 4) a bad name for a combined 2.0+2.1 CVS module is httpd-2.0 5) having separate CVS modules means we lose future history 6) creating a brand new CVS module means we lose past history (does this cover everyone's concerns?) Those aren't concerns -- they are answers. One recent problem I've noted is that we have lost the art of phrasing votes so that they don't cut across several issues at once. The vote on establishing separate development trees of stable and unstable versions was fine, but none of that implied a single new repository would be created with a variety of branches interwoven within it. We can decide that now in STATUS. Therefore I'm proposing that we just keep the httpd-2.0 CVS module we have for a little longer, eventually on some well-in-advance forewarned flag day we rename it to something more generic, like just httpd and then keep a readonly artifact of the old httpd-2.0 CVS module around for posterity. Too many issues at once. Do we want the new repository in order to clean up legacy stuff, or simply because having 2.0 in the name is confusing? In either case, httpd is the wrong name -- httpd-2 would be okay. Working within an ancient CVS module makes sense while directory names and the purposes of files remain essentially the same, but people are fooling themselves if they think CVS merge will work after a large-scale change such as async-io. Personally, I have a hard time keeping track of branch-based modifications, even though I know where to look in the commit message. Maybe we could move the branch tag into the subject? I don't think we have a contract with developers to maintain the httpd-2.0 module name for eternity, though the right solution is an alias in CVSROOT modules, not a symlink. FYI, a symlink is *never* appropriate under /home/cvs, for any reason, because it doubles the committable space while at the same time bifurcating access control, commitlogs, notices, etc. It is better to break existing commit access and force people to checkout a fresh tree. But, as OtherBill suggested, my main objection was that the changes were made without discussion, and hence without a chance for me to point out that symlinks are bad under /home/cvs, and it seemed better to revert that change than try to accommodate it the right way with changes to modules, avail, and apmail. I still prefer new modules for 2.1 and 2.2 simply because I know the performance will be better, but that won't be substantial for another six months or so of dabbling, and I wasn't even planning to vote on that because I am more interested in 3.0. Roy
Re: cvs commit: httpd-2.0 STATUS
Just in case, I want to note 2 things: 1. I'm 100% cool. I understand that Bill meant no harm or foul to anyone and I apologize for thinking he did. 2. At no time did I become a potty mouth. (#2 will be funnier to those who attended the Apache Town Meeting :) ). Cheers! -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: cvs commit: httpd-2.0 STATUS
On Monday, November 25, 2002, at 05:59 PM, Roy T. Fielding wrote: On Monday, November 25, 2002, at 04:58 PM, Aaron Bannert wrote: I guess I just didn't read that much in to it. I just want to see us move forward without getting bogged down in misinterpreted emails and already acknowledged mistakes, and to do that I'm trying to stay objective (eg. a Vote). To me this looks like the set of concerns: 1) we want 2.0 maintenance 2) we want 2.1 development 3) we want parallel development of each 4) a bad name for a combined 2.0+2.1 CVS module is httpd-2.0 5) having separate CVS modules means we lose future history 6) creating a brand new CVS module means we lose past history (does this cover everyone's concerns?) Those aren't concerns -- they are answers. Well, I was trying to list the set of things people have noted over time so that we could come to a consensus on the whole thing. Maybe it is too many issues at the same time, but it is difficult to deal with one without having to deal with the others. One recent problem I've noted is that we have lost the art of phrasing votes so that they don't cut across several issues at once. The vote on establishing separate development trees of stable and unstable versions was fine, but none of that implied a single new repository would be created with a variety of branches interwoven within it. We can decide that now in STATUS. Cool. Will you add it in? I've never claimed skill in this art. :) Therefore I'm proposing that we just keep the httpd-2.0 CVS module we have for a little longer, eventually on some well-in-advance forewarned flag day we rename it to something more generic, like just httpd and then keep a readonly artifact of the old httpd-2.0 CVS module around for posterity. Too many issues at once. Do we want the new repository in order to clean up legacy stuff, or simply because having 2.0 in the name is confusing? In either case, httpd is the wrong name -- httpd-2 would be okay. Funny you should mention httpd-2, since that was also my suggestion at the time when the httpd symlink was created. Working within an ancient CVS module makes sense while directory names and the purposes of files remain essentially the same, but people are fooling themselves if they think CVS merge will work after a large-scale change such as async-io. I personally don't want to fool with a CVS merge unless I have to. I would think that for something like that we would just do a manual merge with patches. Personally, I have a hard time keeping track of branch-based modifications, even though I know where to look in the commit message. Maybe we could move the branch tag into the subject? +1. I have the same problem, and IIRC PHP does the subject thing and I like that. I don't think we have a contract with developers to maintain the httpd-2.0 module name for eternity, though the right solution is an alias in CVSROOT modules, not a symlink. FYI, a symlink is *never* appropriate under /home/cvs, for any reason, because it doubles the committable space while at the same time bifurcating access control, commitlogs, notices, etc. It is better to break existing commit access and force people to checkout a fresh tree. So CVSROOT/modules aliasing will also alias commit logs, access control, etc? I also suggested using this method, but thought it was merely another form of symbolic linking specific to CVS. If it does everything then that's obviously the way to go. But, as OtherBill suggested, my main objection was that the changes were made without discussion, and hence without a chance for me to point out that symlinks are bad under /home/cvs, and it seemed better to revert that change than try to accommodate it the right way with changes to modules, avail, and apmail. I still prefer new modules for 2.1 and 2.2 simply because I know the performance will be better, but that won't be substantial for another six months or so of dabbling, and I wasn't even planning to vote on that because I am more interested in 3.0. Call it what you will, what features are you referring to? -aaron
Re: cvs commit: httpd-2.0 STATUS
At 02:54 PM 11/25/2002, you wrote: jim 2002/11/25 12:54:59 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: It appears that I am unworthy to have an opinion... How do you mean? Don't read between the lines in my comments; backseat drivers *are* welcome, and you are one of the few who actively pursue 1.3 bugs [which is goodness!] Were my comments *that* offensive? Gheesh, gotta read my own comments three ways to Sunday. The gist of my message was that there are many different ways to participate and that nobody should dictate how someone participates (bug-hunter, doc-er, new -dev hacker, or however they want to participate!) I'm reading the resistance that folks against this whole 2.1 stuff want to pigeonhole developers into bug-fix mode and are resistant to progressing with a new version on the chance that 2.0 will be 'orphaned'. The bottom line of my message was that 1.3 fixers should be welcome, 2.0 fixers should be welcome, 2.1 new-code-hackers should be welcome. Each scratching their own itches. But that this group gets lost in folks beating each other up because that person isn't marching to the same drummer of another. That's normal. Rather than criticize one another or complain that folks don't want to all do the same thing, we aught to be able to pursue the side of httpd maintenance or development that we like. That includes new brainstorming that can't quite fit into whatever we are shipping today (e.g. Apache 2.0). Imagine for a moment if the list had told Ryan to sit out a year or two instead of pursuing his ideas for APR and filters? Would httpd be half of what it is today? Worse, for that time folks were discouraged from committing fixes or improvements to 1.3; why? Let hackers hack, let maintainers maintain. Let everyone provide input into the best way to go about things, and let the majority rule on structural and project things [while continuing our tradition of votes including hard vetoes against technical disputes.] No designations of what your 'role' is, everyone is self-designating around here, and most of us like wearing several hats. Apparently these points were lost because I stated it so badly, and I've offended several of you. Sorry. I'll shut up already. Bill
Re: cvs commit: httpd-2.0 STATUS
At 3:16 PM -0600 11/25/02, William A. Rowe, Jr. wrote: At 02:54 PM 11/25/2002, you wrote: jim 2002/11/25 12:54:59 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: It appears that I am unworthy to have an opinion... How do you mean? Don't read between the lines in my comments; backseat drivers *are* welcome, and you are one of the few who actively pursue 1.3 bugs [which is goodness!] I think calling *any* developer (whether they produce massive amounts of code because they have the time or job that allows it; or someone that has almost no time, but still finds the time to code what they can and track down what they can) a backseat driver is incredibly insulting. Next you know we'll be counting CVS commits and LOC to see who deserves the title backseat driver and frontseat driver. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: cvs commit: httpd-2.0 STATUS
Language can be a terrible thing... If Jim feels like this then we should all be pausing for thought. Aaron, calling for a vote will not accomplish anything with feelings having been so inflamed. In fact there seems to have been a rash of this sort of outburst and ensuing chaos recently. One of the catchphrases at the 'Con among a group of us became Can't we all just get along... - maybe it's also valid here? david [EMAIL PROTECTED] wrote: jim 2002/11/25 12:54:59 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: It appears that I am unworthy to have an opinion... On what grounds? I would assume that if you aren't worthy then neither am I, so I would need to participate in a similar exorcism of opinions... I assumed all committers were worthy. -- Paul J. Reder --- The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure. -- Albert Einstein
Re: cvs commit: httpd-2.0 STATUS
I guess I just didn't read that much in to it. I just want to see us move forward without getting bogged down in misinterpreted emails and already acknowledged mistakes, and to do that I'm trying to stay objective (eg. a Vote). To me this looks like the set of concerns: 1) we want 2.0 maintenance 2) we want 2.1 development 3) we want parallel development of each 4) a bad name for a combined 2.0+2.1 CVS module is httpd-2.0 5) having separate CVS modules means we lose future history 6) creating a brand new CVS module means we lose past history (does this cover everyone's concerns?) Therefore I'm proposing that we just keep the httpd-2.0 CVS module we have for a little longer, eventually on some well-in-advance forewarned flag day we rename it to something more generic, like just httpd and then keep a readonly artifact of the old httpd-2.0 CVS module around for posterity. -aaron On Monday, November 25, 2002, at 04:39 PM, David Reid wrote: Language can be a terrible thing... If Jim feels like this then we should all be pausing for thought. Aaron, calling for a vote will not accomplish anything with feelings having been so inflamed. In fact there seems to have been a rash of this sort of outburst and ensuing chaos recently. One of the catchphrases at the 'Con among a group of us became Can't we all just get along... - maybe it's also valid here? david [EMAIL PROTECTED] wrote: jim 2002/11/25 12:54:59 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: It appears that I am unworthy to have an opinion... On what grounds? I would assume that if you aren't worthy then neither am I, so I would need to participate in a similar exorcism of opinions... I assumed all committers were worthy. -- Paul J. Reder --- The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure. -- Albert Einstein
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Bill Stoddard [EMAIL PROTECTED] writes: I think that R-T-C is the most likely way we'll get good reviews of code moved to the stable tree. Jeff is speaking from his experience with 2.0 development and I would have to agree with him in this regard. I believe that our experiences with 2.0 development (and recent 1.3 maintenance) are indicative of what is going to happen with 2.0-stable, or at least much more so than any experiences from several years ago. Obviously the interpretation of that experience is subject to debate :) --/-- Everybody has their own vision and we have to find the greatest commonality to decide how to work. Here are some aspects of mine: . 1.3 maintenance needs to be a bit healthier... more involvement of people when somebody wants to fix something... right now it can be hard to get anybody to give a shit when you want to fix something... . 2.0-stable maintenance along the lines of 1.3, but I think that fixing things in 2.0-stable is much more important than fixing things in 1.3.. 2.0-stable maintenance right now is for the relatively few who try 2.x before the hoped-for avalanche, and fixing their problems is going to prevent a world of hurt later on (1.3 clearly works well-enough for almost anybody) . 2.1... just like what has happened with 2.0 thus far... This has nothing to do with C-T-R vs. R-T-C; that is just a choice of which crude tool can best be used to achieve a goal. One of the useful properties of R-T-C is that if you don't have enough interest to keep a tree maintained in a healthy manner it becomes painfully obvious almost immediately. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Given the recent behavior of some I'm actually now in favour of C-T-R for any stable tree... Treat adults as adults until they prove they can't be so treated. +1 for C_T_R for stable branches david - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 24, 2002 2:20 PM Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP Bill Stoddard [EMAIL PROTECTED] writes: I think that R-T-C is the most likely way we'll get good reviews of code moved to the stable tree. Jeff is speaking from his experience with 2.0 development and I would have to agree with him in this regard. I believe that our experiences with 2.0 development (and recent 1.3 maintenance) are indicative of what is going to happen with 2.0-stable, or at least much more so than any experiences from several years ago. Obviously the interpretation of that experience is subject to debate :) --/-- Everybody has their own vision and we have to find the greatest commonality to decide how to work. Here are some aspects of mine: . 1.3 maintenance needs to be a bit healthier... more involvement of people when somebody wants to fix something... right now it can be hard to get anybody to give a shit when you want to fix something... . 2.0-stable maintenance along the lines of 1.3, but I think that fixing things in 2.0-stable is much more important than fixing things in 1.3.. 2.0-stable maintenance right now is for the relatively few who try 2.x before the hoped-for avalanche, and fixing their problems is going to prevent a world of hurt later on (1.3 clearly works well-enough for almost anybody) . 2.1... just like what has happened with 2.0 thus far... This has nothing to do with C-T-R vs. R-T-C; that is just a choice of which crude tool can best be used to achieve a goal. One of the useful properties of R-T-C is that if you don't have enough interest to keep a tree maintained in a healthy manner it becomes painfully obvious almost immediately. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Whoops...not enough sleep :) That should read as R-T-C not C-T-R... I also tend to think this should be applied to the 1.3 tree. david - Original Message - From: David Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 24, 2002 8:36 PM Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP Given the recent behavior of some I'm actually now in favour of C-T-R for any stable tree... Treat adults as adults until they prove they can't be so treated. +1 for C_T_R for stable branches david - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 24, 2002 2:20 PM Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP Bill Stoddard [EMAIL PROTECTED] writes: I think that R-T-C is the most likely way we'll get good reviews of code moved to the stable tree. Jeff is speaking from his experience with 2.0 development and I would have to agree with him in this regard. I believe that our experiences with 2.0 development (and recent 1.3 maintenance) are indicative of what is going to happen with 2.0-stable, or at least much more so than any experiences from several years ago. Obviously the interpretation of that experience is subject to debate :) --/-- Everybody has their own vision and we have to find the greatest commonality to decide how to work. Here are some aspects of mine: . 1.3 maintenance needs to be a bit healthier... more involvement of people when somebody wants to fix something... right now it can be hard to get anybody to give a shit when you want to fix something... . 2.0-stable maintenance along the lines of 1.3, but I think that fixing things in 2.0-stable is much more important than fixing things in 1.3.. 2.0-stable maintenance right now is for the relatively few who try 2.x before the hoped-for avalanche, and fixing their problems is going to prevent a world of hurt later on (1.3 clearly works well-enough for almost anybody) . 2.1... just like what has happened with 2.0 thus far... This has nothing to do with C-T-R vs. R-T-C; that is just a choice of which crude tool can best be used to achieve a goal. One of the useful properties of R-T-C is that if you don't have enough interest to keep a tree maintained in a healthy manner it becomes painfully obvious almost immediately. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
