RE: cvs commit: httpd-2.0/server/mpm/perchild mpm.h perchild.c
rbb 02/04/01 00:27:43 Modified:server/mpm/perchild mpm.h perchild.c Log: Migrate perchild to the new lock API, and clean up some of the logic surrounding the FD passing. This doesn't work yet, but it is getting closer. Currently, the problem is that we don't correctly read the data from the socket so that it can be passed to the correct child. To be clear, the MPM will serve pages, but it doesn't pass file descriptors. I am hoping to get that working tomorrow sometime. Ryan
Re: cvs commit: httpd-2.0/modules/generators mod_cgi.c mod_cgid.c
* Jeff Trawick ([EMAIL PROTECTED]) wrote : Thom May [EMAIL PROTECTED] writes: This change appears to have broken some cgі scripts - cricket http://cricket.sourceforge.net/ worked fine in 2.0.33 but in 2.0.34 and 35-dev: [Sat Mar 30 15:20:03 2002] [error] [client 192.168.0.34] malformed header from : /usr/lib/cgi-bin/cricket/grapher.cgi Cheers, -Thom I don't really see how. The code executed was completely unchanged except when nph is set. nph should only be set for a nph script -- one that starts with nph-. That message malformed header makes me wonder if a recent change to avoid reading one byte at a time broke it. Look at Brian Pane's (I think it was him) recent commit to change the way we read headers from the CGI script. Maybe there is a connection between that change and the breakage of your cgi. If you have a simple example I'm willing to debug. OK, this is fixed in the current 2.0.34 tag - my apologies for the wrong diagnosis. -Thom
Re: 2.0.34 up-to-date wrt cvs HEAD
* William A. Rowe, Jr. ([EMAIL PROTECTED]) wrote : The 2.0.34 tag is now refreshed to cvs HEAD, please test and report before we go ahead a roll in a day or so. Bill Looks good here - the problem I was seeing with CGIs is gone. Cheers, -Thom
Re: cvs commit: httpd-2.0/modules/generators mod_cgi.c mod_cgid.c
Thom May [EMAIL PROTECTED] writes: OK, this is fixed in the current 2.0.34 tag - my apologies for the wrong diagnosis. no apologies necessary... frankly, I always blame Ryan for everything even if he is nowhere in sight... if you want to blame me than that is only fair :) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Drop md5 from htpasswd docs please
I am getting rather tired of answering questions on this one. Could we please drop this crap about htpasswd using md5. A modified md5 is no longer md5, so let's not call it md5 at all. Over and over again people ask me why md5($string) doesn't match what is in htpasswd-generated password files. -Rasmus
RE: cvs commit: httpd-2.0/modules/generators mod_cgi.c mod_cgid.c
From: [EMAIL PROTECTED] [mailto:trawick@rdu88-250- Thom May [EMAIL PROTECTED] writes: OK, this is fixed in the current 2.0.34 tag - my apologies for the wrong diagnosis. no apologies necessary... frankly, I always blame Ryan for everything even if he is nowhere in sight... if you want to blame me than that is only fair :) It's good to feel loved and appreciated. :-) Ryan
[PATCH] Rename apr_explode_localtime to apr_time_exp_lt
As the subject. compiled and tested.
--
Thom May - [EMAIL PROTECTED]
* liiwi starts planning breakfast
aj And then, squadron A will attempt to extract the cereal from quadrant 34,
while teams F and Q ensure the lactic fluid remains chilled and readily
available...
? autom4te.cache
? docs/docroot/error/include/public_html
? srclib/apr
Index: modules/mappers/mod_rewrite.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_rewrite.c,v
retrieving revision 1.104
diff -u -u -r1.104 mod_rewrite.c
--- modules/mappers/mod_rewrite.c 20 Mar 2002 17:41:55 - 1.104
+++ modules/mappers/mod_rewrite.c 1 Apr 2002 14:44:46 -
@@ -3244,7 +3244,7 @@
char tstr[80];
apr_size_t len;
-apr_explode_localtime(t, apr_time_now());
+apr_time_exp_lt(t, apr_time_now());
apr_strftime(tstr, len, 80, [%d/%b/%Y:%H:%M:%S , t);
apr_snprintf(tstr + strlen(tstr), 80-strlen(tstr), %c%.2d%.2d],
@@ -3527,12 +3527,12 @@
/* XXX: wow this has gotta be slow if you actually use it for a lot, recalculates
exploded time for each variable */
/* underlaying Unix system stuff */
else if (strcasecmp(var, TIME_YEAR) == 0) {
-apr_explode_localtime(tm, apr_time_now());
+apr_time_exp_lt(tm, apr_time_now());
apr_snprintf(resultbuf, sizeof(resultbuf), %04d, tm.tm_year + 1900);
result = resultbuf;
}
#define MKTIMESTR(format, tmfield) \
-apr_explode_localtime(tm, apr_time_now()); \
+apr_time_exp_lt(tm, apr_time_now()); \
apr_snprintf(resultbuf, sizeof(resultbuf), format, tm.tmfield); \
result = resultbuf;
else if (strcasecmp(var, TIME_MON) == 0) {
@@ -3554,7 +3554,7 @@
MKTIMESTR(%d, tm_wday)
}
else if (strcasecmp(var, TIME) == 0) {
-apr_explode_localtime(tm, apr_time_now());
+apr_time_exp_lt(tm, apr_time_now());
apr_snprintf(resultbuf, sizeof(resultbuf),
%04d%02d%02d%02d%02d%02d, tm.tm_year + 1900,
tm.tm_mon+1, tm.tm_mday,
Index: modules/ssl/ssl_engine_log.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_engine_log.c,v
retrieving revision 1.16
diff -u -u -r1.16 ssl_engine_log.c
--- modules/ssl/ssl_engine_log.c28 Mar 2002 17:11:12 - 1.16
+++ modules/ssl/ssl_engine_log.c1 Apr 2002 14:44:48 -
@@ -212,7 +212,7 @@
if (add SSL_NO_TIMESTAMP)
tstr[0] = NUL;
else {
-apr_explode_localtime(t, apr_time_now());
+apr_time_exp_lt(t, apr_time_now());
apr_strftime(tstr, len, 80, [%d/%b/%Y %H:%M:%S, t);
apr_snprintf(tstr + strlen(tstr), 80 - strlen(tstr), %05d] ,
(unsigned int)getpid());
Index: server/util.c
===
RCS file: /home/cvspublic/httpd-2.0/server/util.c,v
retrieving revision 1.123
diff -u -u -r1.123 util.c
--- server/util.c 21 Mar 2002 10:10:40 - 1.123
+++ server/util.c 1 Apr 2002 14:44:58 -
@@ -180,7 +180,7 @@
fmt = tf;
}
else {
-apr_explode_localtime(xt, t);
+apr_time_exp_lt(xt, t);
}
/* check return code? */
Index: server/util_time.c
===
RCS file: /home/cvspublic/httpd-2.0/server/util_time.c,v
retrieving revision 1.6
diff -u -u -r1.6 util_time.c
--- server/util_time.c 21 Mar 2002 10:10:41 - 1.6
+++ server/util_time.c 1 Apr 2002 14:44:59 -
@@ -133,7 +133,7 @@
return apr_time_exp_gmt(xt, t);
}
else {
-return apr_explode_localtime(xt, t);
+return apr_time_exp_lt(xt, t);
}
}
else {
@@ -148,7 +148,7 @@
r = apr_time_exp_gmt(xt, t);
}
else {
-r = apr_explode_localtime(xt, t);
+r = apr_time_exp_lt(xt, t);
}
if (!APR_STATUS_IS_SUCCESS(r)) {
return r;
@@ -177,7 +177,7 @@
AP_DECLARE(apr_status_t) ap_recent_ctime(char *date_str, apr_time_t t)
{
/* ### This code is a clone of apr_ctime(), except that it
- * uses ap_explode_recent_localtime() instead of apr_explode_localtime().
+ * uses ap_explode_recent_localtime() instead of apr_time_exp_lt().
*/
apr_time_exp_t xt;
const char *s;
Re: cvs commit: httpd-2.0/modules/generators mod_cgi.c mod_cgid.c
Ryan Bloom [EMAIL PROTECTED] writes: It's good to feel loved and appreciated. :-) ;) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
bugzilla: remember to add bugs@ as a cc if you change owner
Remember, because of the way bugzilla is configured, you can not assign bugs to people unless you add bugs@ to the cc list. If you do not add bugs@, then no one else sees any updates to the bug... I went and made the fix for this bug. On 1 Apr 2002 [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7642. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7642 Problem on IPv6 only machine [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: httpd-2.0/server/mpm/mpmt_os2 mpmt_os2_child.c
This is a severe crash-bug fix, can the 2.0.34 tag be bumped for it? On 1 Apr 2002 16:42:02 -, [EMAIL PROTECTED] wrote: bjh 02/04/01 08:42:02 Modified:server/mpm/mpmt_os2 mpmt_os2_child.c Log: Destroy the connection pool (and therefore run the cleanups) before destroying the bucket_alloc as the cleanups refer to buckets allocated by the bucket_alloc. Revision ChangesPath 1.19 +1 -1 httpd-2.0/server/mpm/mpmt_os2/mpmt_os2_child.c Index: mpmt_os2_child.c === RCS file: /home/cvs/httpd-2.0/server/mpm/mpmt_os2/mpmt_os2_child.c,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- mpmt_os2_child.c 29 Mar 2002 08:17:25 - 1.18 +++ mpmt_os2_child.c 1 Apr 2002 16:42:02 - 1.19 @@ -442,8 +442,8 @@ ap_lingering_close(current_conn); } -apr_bucket_alloc_destroy(bucket_alloc); apr_pool_destroy(pconn); +apr_bucket_alloc_destroy(bucket_alloc); ap_update_child_status_from_indexes(child_slot, thread_slot, SERVER_READY, NULL); } -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
2.0.34 - apr_lock_create fails on daedalus
2.0.34 built cleanly on daedalus. But when I tried to start it, I got:
[gregames@daedalus apache2.0.34]$ tail logs/www/error_log
[Mon Apr 01 08:36:31 2002] [notice] suEXEC mechanism enabled (wrapper:
/usr/local/apache2.0.34/bin/suexec)
[Mon Apr 01 08:36:31 2002] [crit] (28)No space left on device: mod_rewrite:
could not create rewrite_log_lock
Configuration Failed
The msg appears to be bogus; we have space. Here's the code:
/* create the rewriting lockfiles in the parent */
if ((rv = apr_lock_create(rewrite_log_lock, APR_MUTEX, APR_LOCKALL,
APR_LOCK_DEFAULT, NULL, p)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, s,
mod_rewrite: could not create rewrite_log_lock);
return HTTP_INTERNAL_SERVER_ERROR;
I'll gdb this after lunch. If you have any thoughts about what may be causing
this, please speak up.
Greg
Re: 2.0.34 - apr_lock_create fails on daedalus
Greg Ames wrote:
The msg appears to be bogus; we have space. Here's the code:
/* create the rewriting lockfiles in the parent */
if ((rv = apr_lock_create(rewrite_log_lock, APR_MUTEX, APR_LOCKALL,
APR_LOCK_DEFAULT, NULL, p)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, s,
mod_rewrite: could not create rewrite_log_lock);
return HTTP_INTERNAL_SERVER_ERROR;
I'll gdb this after lunch. If you have any thoughts about what may be causing
this, please speak up.
Sounds like we're using SysV shared mem or sems on this build. If
these variants can't create the segment or sem, that's the error
that pops up. Check out the current usage (ipcs) and see if we're
running out of slots or memory space.
--
===
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/server/mpm/mpmt_os2 mpmt_os2_child.c
On Tue, 2 Apr 2002, Brian Havard wrote: This is a severe crash-bug fix, can the 2.0.34 tag be bumped for it? OOPS!! Sorry about that. Thanks for the fix! :) ++1 to bumping 2.0.34 for this change, by all means... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.34 - apr_lock_create fails on daedalus
Greg Ames [EMAIL PROTECTED] writes: 2.0.34 built cleanly on daedalus. But when I tried to start it, I got: [gregames@daedalus apache2.0.34]$ tail logs/www/error_log [Mon Apr 01 08:36:31 2002] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache2.0.34/bin/suexec) [Mon Apr 01 08:36:31 2002] [crit] (28)No space left on device: mod_rewrite: could not create rewrite_log_lock Configuration Failed The msg appears to be bogus; we have space. Here's the code: ENOSPC is one of the possible errnos returned by SysV semaphore operations. You could do a truss and see which syscall is actually returning ENOSPC. I think JimJag changed the APR rules for picking the default mutex recently. That could have resulted in this change in behavior. If it were me I'd take two asynch approaches: 1) see what syscall failed and how to make it stop failing (OS tuning perhaps?) 2) validate that SysV sem is the proper mutex mechanism we should be using by default on FreeBSD -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
[EMAIL PROTECTED] wrote: Log: ap_proxy_http_request needs to check the return status of ap_pass_brigade Does the same problem exist in proxy_ftp? Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: bugzilla: remember to add bugs@ as a cc if you change owner
Marc Slemko [EMAIL PROTECTED] writes: Remember, because of the way bugzilla is configured, you can not assign bugs to people unless you add bugs@ to the cc list. If you do not add bugs@, then no one else sees any updates to the bug... I went and made the fix for this bug. Thanks! -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: 2.0.34 - apr_lock_create fails on daedalus
Jim Jagielski wrote: Sounds like we're using SysV shared mem or sems on this build. yep, and it's changed from 2.0.32: [gregames@daedalus httpd-2.0.32]$ diff -u srclib/apr/include/apr.h ../httpd-2.0.34/srclib/apr/include/apr.h | grep SERIALIZE #define APR_USE_FLOCK_SERIALIZE 0 -#define APR_USE_SYSVSEM_SERIALIZE 0 -#define APR_USE_FCNTL_SERIALIZE 1 +#define APR_USE_SYSVSEM_SERIALIZE 1 +#define APR_USE_FCNTL_SERIALIZE 0 #define APR_USE_PROC_PTHREAD_SERIALIZE0 #define APR_USE_PTHREAD_SERIALIZE 0 If these variants can't create the segment or sem, that's the error that pops up. Check out the current usage (ipcs) and see if we're running out of slots or memory space. will do. Thanks for the hints. Greg
Re: 2.0.34 - apr_lock_create fails on daedalus
Jeff Trawick wrote: 1) see what syscall failed and how to make it stop failing (OS tuning perhaps?) daedulus's truss doesn't have an option to follow fork()s :( But I think I'll switch to Plan B anyway...see below. 2) validate that SysV sem is the proper mutex mechanism we should be using by default on FreeBSD Probably not. apache-1.3's ap_config.h defines HAVE_FLOCK_SERIALIZED_ACCEPT for FreeBSD, but apr_hint.m4 doesn't have similar logic in 2.0. I'll patch that, and give it a shot. Greg
Re: 2.0.34 up-to-date wrt cvs HEAD
On Sun, Mar 31, 2002 at 06:36:58PM -0800, Ryan Bloom wrote: If it's possible, I would like to get the perchild changes that I am working on tonight into 2.0.34. I am tired of the reports that perchild doesn't compile. :-) I am hoping to have the whole thing working by the end of the day. I'm not the RM, so it isn't up to me, but I'd prefer that we didn't include perchild in this tag/release. If it were more obvious that it is an experimental piece (by moving it to an experimental directory) then I'd be fine with any changes regardless of how much exposure the new changes have had. -aaron
Re: cvs commit: httpd-2.0/server/mpm/mpmt_os2 mpmt_os2_child.c
At 10:51 AM 4/1/2002, you wrote: This is a severe crash-bug fix, can the 2.0.34 tag be bumped for it? bjh 02/04/01 08:42:02 Modified:server/mpm/mpmt_os2 mpmt_os2_child.c Log: Destroy the connection pool (and therefore run the cleanups) before destroying the bucket_alloc as the cleanups refer to buckets allocated by the bucket_alloc. Revision ChangesPath 1.19 +1 -1 httpd-2.0/server/mpm/mpmt_os2/mpmt_os2_child.c Moved tag APACHE_2_0_34 for this version. Nice catch! Bill
Re: 2.0.34 up-to-date wrt cvs HEAD
William A. Rowe, Jr. [EMAIL PROTECTED] writes: The 2.0.34 tag is now refreshed to cvs HEAD, please test and report before we go ahead a roll in a day or so. Does somebody want to clean up this ugliness in the configure output (if --prefix=foo doesn't exist yet)? ../apr/apr-config[117]: /home/trawick/regress/install/bin: not found. ../apr/apr-config[117]: /home/trawick/regress/install/bin: not found. ../apr/apr-config[117]: /home/trawick/regress/install/bin: not found. ../apr/apr-config[117]: /home/trawick/regress/install/bin: not found. ../apr/apr-config[117]: /home/trawick/regress/install/bin: not found. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Drop md5 from htpasswd docs please
Is it possible for whomever knows best to provide code or help to the PHP group and make a PHP bsd|apache_md5() function? Or adapt the current PHP function w/ an additional attribute to select which type of hash to use? md5($string, ..., HASH_NORM|HASH_BSD), it'd be very nice if the latter was accepted, I'm sure in the future there will be at least one more implementation of md5 to cope with. Thanks for listening, David Rasmus Lerdorf wrote: I am getting rather tired of answering questions on this one. Could we please drop this crap about htpasswd using md5. A modified md5 is no longer md5, so let's not call it md5 at all. Over and over again people ask me why md5($string) doesn't match what is in htpasswd-generated password files. -Rasmus
Re: 2.0.34 up-to-date wrt cvs HEAD
At 11:45 AM 4/1/2002, you wrote: On Sun, Mar 31, 2002 at 06:36:58PM -0800, Ryan Bloom wrote: If it's possible, I would like to get the perchild changes that I am working on tonight into 2.0.34. I am tired of the reports that perchild doesn't compile. :-) I am hoping to have the whole thing working by the end of the day. I'm not the RM, so it isn't up to me, but I'd prefer that we didn't include perchild in this tag/release. If it were more obvious that it is an experimental piece (by moving it to an experimental directory) then I'd be fine with any changes regardless of how much exposure the new changes have had. MPMs should never exist in modules/. I don't think a 'broken mpm' is any worse than an MPM that doesn't compile at all. But if you want to insist that --with-mpm=perchild yields some sort of This MPM is experimental -- it is not expected to work at this time ... that would be fine. But I see no reason not to fold these fixes into 2.0.34 unless they start touching files outside of server/mpm/perchild/ Bill
Re[2]: Drop md5 from htpasswd docs please
Hi, Is it possible for whomever knows best to provide code or help to the PHP group and make a PHP bsd|apache_md5() function? Or adapt the current PHP function w/ an additional attribute to select which type of hash to use? md5($string, ..., HASH_NORM|HASH_BSD), it'd be very nice if the latter was accepted, I'm sure in the future there will be at least one more implementation of md5 to cope with. how about contributing to mhash? http://www.php.net/manual/en/ref.mhash.php Daniel
Big memory leak in Windows...
I suspect apr_bucket_alloc_create() is called in the wrong place. Working on it. SHould have a patch in 30 min or so. Bill
Re: Drop md5 from htpasswd docs please
See the CPAN Perl module; search www.cpan.org for Crypt-PasswdMD5 It has a supported 'apachified' passwd variant. Bill At 12:11 PM 4/1/2002, you wrote: Is it possible for whomever knows best to provide code or help to the PHP group and make a PHP bsd|apache_md5() function? Or adapt the current PHP function w/ an additional attribute to select which type of hash to use? md5($string, ..., HASH_NORM|HASH_BSD), it'd be very nice if the latter was accepted, I'm sure in the future there will be at least one more implementation of md5 to cope with. Thanks for listening, David Rasmus Lerdorf wrote: I am getting rather tired of answering questions on this one. Could we please drop this crap about htpasswd using md5. A modified md5 is no longer md5, so let's not call it md5 at all. Over and over again people ask me why md5($string) doesn't match what is in htpasswd-generated password files. -Rasmus
Re: Drop md5 from htpasswd docs please
Or we just add an extra flag to not just have the FreeBSD md5 password format - but also the generic one. Dw. -- Dirk-Willem van Gulik On Mon, 1 Apr 2002, William A. Rowe, Jr. wrote: See the CPAN Perl module; search www.cpan.org for Crypt-PasswdMD5 It has a supported 'apachified' passwd variant. Bill At 12:11 PM 4/1/2002, you wrote: Is it possible for whomever knows best to provide code or help to the PHP group and make a PHP bsd|apache_md5() function? Or adapt the current PHP function w/ an additional attribute to select which type of hash to use? md5($string, ..., HASH_NORM|HASH_BSD), it'd be very nice if the latter was accepted, I'm sure in the future there will be at least one more implementation of md5 to cope with. Thanks for listening, David Rasmus Lerdorf wrote: I am getting rather tired of answering questions on this one. Could we please drop this crap about htpasswd using md5. A modified md5 is no longer md5, so let's not call it md5 at all. Over and over again people ask me why md5($string) doesn't match what is in htpasswd-generated password files. -Rasmus
[PATCH] Fix apxs so it is relocatable...
Hi,
This patch addes an equivalent functionality to htppd's -d argument to apxs.
The code works in two ways - if you explicitly specify -d, it uses that,
otherwise, it first checks to see if it's in the directory specified during
the configure process, and if not it then attempts to guess what the server
root is. If all this fails, it dies.
(The code has also been slightly altered so that arguments are parsed before
config_vars.mk is read, and the output makefile uses $installbuilddir rather
than $prefix/build)
This has only been tested on linux - it works in all the test cases I've
thrown at it; but I'd apreciate testing on other archs/OSs.
Cheers,
-Thom, going to don the asbestos suit, and hide in the fallout shelter...
---
Index: support/apxs.in
===
RCS file: /home/cvspublic/httpd-2.0/support/apxs.in,v
retrieving revision 1.36
diff -u -u -r1.36 apxs.in
--- support/apxs.in 13 Mar 2002 20:48:05 - 1.36
+++ support/apxs.in 1 Apr 2002 17:33:09 -
@@ -58,36 +58,6 @@
package apxs;
##
-## Configuration
-##
-
-my $prefix = @prefix@;
-my $CFG_PREFIX = $prefix;
-
-# read the configuration variables once
-my %config_vars = ();
-get_config_vars($prefix/build/config_vars.mk,\%config_vars);
-
-my $exec_prefix= get_vars(exec_prefix);
-my $CFG_TARGET = get_vars(progname);
-my $CFG_SYSCONFDIR = get_vars(sysconfdir);
-my $CFG_CFLAGS = join ' ', map { get_vars($_) }
- qw(SHLTCFLAGS CFLAGS NOTEST_CPPFLAGS EXTRA_CPPFLAGS EXTRA_CFLAGS);
-my $includedir = get_vars(includedir);
-my $CFG_INCLUDEDIR = eval qq($includedir);
-my $CFG_CC = get_vars(CC);
-my $libexecdir = get_vars(libexecdir);
-my $CFG_LIBEXECDIR = eval qq($libexecdir);
-my $sbindir= get_vars(sbindir);
-my $CFG_SBINDIR= eval qq($sbindir);
-my $ltflags= $ENV{'LTFLAGS'};
-$ltflags or $ltflags = --silent;
-
-my %internal_vars = map {$_ = 1}
-qw(TARGET CC CFLAGS CFLAGS_SHLIB LD_SHLIB LDFLAGS_SHLIB LIBS_SHLIB
- PREFIX SBINDIR INCLUDEDIR LIBEXECDIR SYSCONFDIR);
-
-##
## parse argument line
##
@@ -108,6 +78,7 @@
my $opt_A = 0;
my $opt_q = 0;
my $opt_h = 0;
+my $opt_d = '';
# this subroutine is derived from Perl's getopts.pl with the enhancement of
# the + metacharacter at the format string to allow a list to be built by
@@ -174,19 +145,19 @@
}
sub usage {
-print STDERR Usage: apxs -g [-S var=val] -n modname\n;
-print STDERRapxs -q [-S var=val] query ...\n;
-print STDERRapxs -c [-S var=val] [-o dsofile] [-D
name[=value]]\n;
+print STDERR Usage: apxs -d server-root -g [-S var=val] -n modname\n;
+print STDERRapxs -d server-root -q [-S var=val] query ...\n;
+print STDERRapxs -d -c [-S var=val] [-o dsofile] [-D
+name[=value]]\n;
print STDERR[-I incdir] [-L libdir] [-l libname]
[-Wc,flags]\n;
print STDERR[-Wl,flags] files ...\n;
-print STDERRapxs -i [-S var=val] [-a] [-A] [-n modname] dsofile
...\n;
-print STDERRapxs -e [-S var=val] [-a] [-A] [-n modname] dsofile
...\n;
+print STDERRapxs -d server-root -i [-S var=val] [-a] [-A] [-n
+modname] dsofile ...\n;
+print STDERRapxs -d server-root -e [-S var=val] [-a] [-A] [-n
+modname] dsofile ...\n;
exit(1);
}
# option handling
my $rc;
-($rc, @ARGV) = Getopts(qn:gco:I+D+L+l+W+S+eiaA, @ARGV);
+($rc, @ARGV) = Getopts(d:qn:gco:I+D+L+l+W+S+eiaA, @ARGV);
usage if ($rc == 0);
usage if ($#ARGV == -1 and not $opt_g);
usage if (not $opt_q and not ($opt_g and $opt_n) and not $opt_i and not $opt_c and
not $opt_e);
@@ -217,10 +188,74 @@
}
}
+
+##
+## Configuration
+##
+
+# read the configuration variables once
+my %config_vars = ();
+my $mode;
+my $working_dir;
+my $server_root;
+my $installbuilddir;
+
+if ($0 =~ /^(.*)\/apxs/){
+$working_dir=$1;
+}
+
+if ($opt_d ne ''){
+$mode=rel_;
+$server_root=$opt_d ./;
+$installbuilddir=$server_root . @rel_installbuilddir@;
+}
+elsif ($working_dir eq '@exp_bindir@') {
+#if ($working_dir eq '@exp_bindir@') {
+#we are in absolute mode
+$installbuilddir = '@exp_installbuilddir@/';
+$mode = exp_;
+$server_root='@prefix@'./;
+}
+elsif ($working_dir =~ /(.*)@rel_bindir@/) {
+#we are working in relative mode.
+#we need to calculate what the server root is,
+#and then use that as a base to work from
+$server_root = $1;
+$mode = rel_;
+$installbuilddir=$server_root . @rel_installbuilddir@;
+}
+else {
+die Can't calculate what the server root is. Please use -d\n;
+}
+
+get_config_vars($installbuilddir/config_vars.mk,\%config_vars)||die Can't open
+config_vars.mk, $!;
+
+my $prefix = $server_root;
+my $CFG_PREFIX = $prefix;
+my $exec_prefix= $server_root.get_vars(rel_exec_prefix);
+my $progname = get_vars(progname);
+my $CFG_TARGET = $progname;
+my $CFG_SYSCONFDIR =
Re: 2.0.34 - apr_lock_create fails on daedalus
Greg Ames wrote: 2) validate that SysV sem is the proper mutex mechanism we should be using by default on FreeBSD Probably not. apache-1.3's ap_config.h defines HAVE_FLOCK_SERIALIZED_ACCEPT for FreeBSD, but apr_hint.m4 doesn't have similar logic in 2.0. I'll patch that, and give it a shot. With apr_hints.m4 patched to use FLOCK on FreeBSD, apr.h looks right. But when I start it, I get: [Mon Apr 01 10:10:02 2002] [emerg] (9)Bad file descriptor: Couldn't initialize cross-process lock in child [Mon Apr 01 10:10:02 2002] [emerg] (9)Bad file descriptor: Couldn't initialize cross-process lock in child [Mon Apr 01 10:10:02 2002] [notice] Apache/2.0.34 (Unix) configured -- resuming normal operations [Mon Apr 01 10:10:02 2002] [alert] Child 74540 returned a Fatal error... Apache is exiting! ...and the parent bails, leaving the children orphaned. I'll try FCNTL next. Greg
Re: Big memory leak in Windows...
On Mon, 1 Apr 2002, Bill Stoddard wrote: I suspect apr_bucket_alloc_create() is called in the wrong place. I really just threw these in there so the things would have some miniscule hope of compiling. The windows one and the OS/2 ones at least should be examined in detail. There's got to be a better place to do it, as you say. Working on it. SHould have a patch in 30 min or so. Thanks! --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Big memory leak in Windows...
On Mon, 1 Apr 2002, Bill Stoddard wrote: I suspect apr_bucket_alloc_create() is called in the wrong place. Working on it. SHould have a patch in 30 min or so. A semi-related question:: Should apr_bucket_alloc_create() be registering a cleanup on the pool that's passed into it so that apr_bucket_alloc_destroy() is called automatically when that pool dies? I didn't do this before because I was hoping to get rid of the pool parameter to apr_bucket_alloc_create() entirely. Right now we're not using it for anything. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: Big memory leak in Windows...
I suspect apr_bucket_alloc_create() is called in the wrong place. Working on it. SHould have a patch in 30 min or so. A semi-related question:: Should apr_bucket_alloc_create() be registering a cleanup on the pool that's passed into it so that apr_bucket_alloc_destroy() is called automatically when that pool dies? I didn't do this before because I was hoping to get rid of the pool parameter to apr_bucket_alloc_create() entirely. Right now we're not using it for anything. Yes, we should be using pool cleanups to take care of this for us. Ryan
Re: 2.0.34 up-to-date wrt cvs HEAD
On Mon, Apr 01, 2002 at 12:09:35PM -0600, William A. Rowe, Jr. wrote: MPMs should never exist in modules/. I don't think a 'broken mpm' is any worse than an MPM that doesn't compile at all. But if you want to insist that --with-mpm=perchild yields some sort of This MPM is experimental -- it is not expected to work at this time ... that would be fine. But I see no reason not to fold these fixes into 2.0.34 unless they start touching files outside of server/mpm/perchild/ I'm not saying that we shouldn't include the perchild changes, I'm just saying we shouldn't imply that by including them the perchild MPM is any less experimental. In fact, I think we should go one step further and create a server/mpm/experimental to put things like perchild, leader-follower, door, and whatever else comes along. I'm all for a message from the configure script, but I don't think that it is obvious enough by itself. -aaron
Re: 2.0.34 - apr_lock_create fails on daedalus
Greg Ames wrote: With apr_hints.m4 patched to use FLOCK on FreeBSD, apr.h looks right. But when I start it, I get: [Mon Apr 01 10:10:02 2002] [emerg] (9)Bad file descriptor: Couldn't initialize cross-process lock in child ...and the parent bails, leaving the children orphaned. I'll try FCNTL next. It's up running on port 8092 using FCNTL. Greg
Re: Big memory leak in Windows...
On Mon, 1 Apr 2002, Bill Stoddard wrote: I suspect apr_bucket_alloc_create() is called in the wrong place. Working on it. SHould have a patch in 30 min or so. A semi-related question:: Should apr_bucket_alloc_create() be registering a cleanup on the pool that's passed into it so that apr_bucket_alloc_destroy() is called automatically when that pool dies? No I don't think so. The callwe of apr_bucket_alloc_create() can register a cleanup against the proper pool but this is not something apr_bucket_alloc_create should do (because, as you mention, apr_bucket_alloc_create() does not really need a pool.) I didn't do this before because I was hoping to get rid of the pool parameter to apr_bucket_alloc_create() entirely. Right now we're not using it for anything. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Bug report for Apache httpd-1.3 [2002/03/31]
Cliff Woolley [EMAIL PROTECTED] wrote: On Sun, 31 Mar 2002 [EMAIL PROTECTED] wrote: +---+ | Bugzilla Bug ID | | +-+ | 7266|New|Nor|2002-03-20|Log Files Corrupt: Strange ASCII Chars| Would anyone object if I asked for these (very nice, btw) summaries to be sent out in multipart format with an HTML version so that the bugID can be an href to the full PR? Most mailing lists will reject and/or strip messages containing text/html, so, there's no point in doing it :) On http://nagoya.apache.org/bugzilla/ in the index page, there's a little form where you can input the bug number, so avoiding the query page... Use that... Pier
Re: cvs commit: apr CHANGES apr-config.in
On Mon, Apr 01, 2002 at 07:30:27PM -, [EMAIL PROTECTED] wrote: jerenkrantz02/04/01 11:30:27 Modified:.CHANGES apr-config.in Log: Fix apr-config so that it will not attempt to cd to bindir if it doesn't exist yet. Oh glorious RM, this might be worthy for inclusion into 2.0.34. -- justin
RE: Big memory leak in Windows...
On Mon, 1 Apr 2002, Bill Stoddard wrote: I suspect apr_bucket_alloc_create() is called in the wrong place. Working on it. SHould have a patch in 30 min or so. A semi-related question:: Should apr_bucket_alloc_create() be registering a cleanup on the pool that's passed into it so that apr_bucket_alloc_destroy() is called automatically when that pool dies? +1, yes. I didn't do this before because I was hoping to get rid of the pool parameter to apr_bucket_alloc_create() entirely. Err, ok, you could do that, but I'd be in favor of having pools do our cleanup. When we need to shutdown*, the allocator should be destroyed and memory should be returned. *) shutdown, or any other operation that will tear down stuff. Right now we're not using it for anything. Only for the bucket_alloc struct itself, right? --Cliff
RE: Big memory leak in Windows...
On Mon, 1 Apr 2002, Sander Striker wrote: Right now we're not using it for anything. Only for the bucket_alloc struct itself, right? Not even that. I took your advice and the apr_allocator is created first, then the bucket_alloc struct is the first thing allocated from it. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Big memory leak in Windows...
From: Bill Stoddard [mailto:[EMAIL PROTECTED]] On Mon, 1 Apr 2002, Bill Stoddard wrote: I suspect apr_bucket_alloc_create() is called in the wrong place. Working on it. SHould have a patch in 30 min or so. A semi-related question:: Should apr_bucket_alloc_create() be registering a cleanup on the pool that's passed into it so that apr_bucket_alloc_destroy() is called automatically when that pool dies? No I don't think so. The callwe of apr_bucket_alloc_create() can register a cleanup against the proper pool but this is not something apr_bucket_alloc_create should do (because, as you mention, apr_bucket_alloc_create() does not really need a pool.) But that means that person who creates the bucket_alloc also needs to register the cleanup. It would be much cleaner to just pass in the pool, and let the code that is creating the bucket_alloc_t register the cleanup. It frees the person creating the bucket_alloc_t from having to remember to register the cleanup. I know I would personally forget to do it every time I wrote bucket code. Ryan That's true. I can go either way. Bill
RE: Big memory leak in Windows...
From: Cliff Woolley [mailto:[EMAIL PROTECTED]] Sent: 01 April 2002 21:39 On Mon, 1 Apr 2002, Sander Striker wrote: Right now we're not using it for anything. Only for the bucket_alloc struct itself, right? Not even that. I took your advice and the apr_allocator is created first, then the bucket_alloc struct is the first thing allocated from it. *grin* Can you tell I haven't done review yet ;) Sander
include/pcreposix.h
Anyone know why we have include/pcreposix.h? What is its relationship to srclib/pcre/pcreposix.h? The differences only seem to be in the comments. Do we really need both? -- justin
[PATCH] AddOutputFilterByType issues.
I've been partly out of it lately, but I think there is a problem
with AddOutputFilterByType. Since ap_set_content_type() can
be called arbitrarily many times, it will try to add each filter
as directed by AddOutputFilterByType on each call. For certain
filters, that isn't a terrifically good idea - such as mod_deflate.
For others (say mod_include), this is okay.
We can't compress a file twice (and is causing problems with
Subversion right now), but that's what we are doing now -
mod_deflate is in the chain twice. mod_mime calls
ap_set_content_type twice in its normal execution (I dunno why,
but that's sucky).
I'm using the following patch to minimize how often
ap_add_output_filters_by_type is called. This fixes the symptom,
but perhaps we should think of a better solution? Perhaps only
allow AP_FTYPE_RESOURCE filters to be added multiple times, and
AP_FTYPE_CONTENT_SET or higher can only be added once?
Thoughts? -- justin
Index: modules/http/http_protocol.c
===
RCS file: /home/cvs/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.406
diff -u -r1.406 http_protocol.c
--- modules/http/http_protocol.c29 Mar 2002 08:17:22 - 1.406
+++ modules/http/http_protocol.c1 Apr 2002 21:43:07 -
-1272,14 +1272,16
AP_DECLARE(void) ap_set_content_type(request_rec *r, const char *ct)
{
-r-content_type = ct;
+if (!r-content_type || strcmp(r-content_type, ct)) {
+r-content_type = ct;
-/* Insert filters requested by the AddOutputFiltersByType
- * configuration directive. Content-type filters must be
- * inserted after the content handlers have run because
- * only then, do we reliably know the content-type.
- */
-ap_add_output_filters_by_type(r);
+/* Insert filters requested by the AddOutputFiltersByType
+ * configuration directive. Content-type filters must be
+ * inserted after the content handlers have run because
+ * only then, do we reliably know the content-type.
+ */
+ap_add_output_filters_by_type(r);
+}
}
typedef struct header_filter_ctx {
[PATCH] -DNO_DETACH and/or apr_proc_detach() confusion?
This gets -DNO_DETACH working for me with Apache's prefork MPM on
Linux and FreeBSD. But from Aaron's commit log for revision
1.34 I gather that this will break daemontools-like programs.
How should I get ./httpd -DNO_DETACH to work? Calling setsid() is
bogus.
This patch avoids the setsid() logic if we don't daemonize.
Index: srclib/apr/threadproc/unix/procsup.c
===
RCS file: /home/cvspublic/apr/threadproc/unix/procsup.c,v
retrieving revision 1.35
diff -u -r1.35 procsup.c
--- srclib/apr/threadproc/unix/procsup.c13 Mar 2002 20:39:30 - 1.35
+++ srclib/apr/threadproc/unix/procsup.c1 Apr 2002 21:49:20 -
@@ -57,42 +57,34 @@
APR_DECLARE(apr_status_t) apr_proc_detach(int daemonize)
{
int x;
-pid_t pgrp;
chdir(/);
#if !defined(MPE) !defined(OS2) !defined(TPF) !defined(BEOS)
/* Don't detach for MPE because child processes can't survive the death of
* the parent. */
if (daemonize) {
- if ((x = fork()) 0) {
- exit(0);
+if ((x = fork()) 0) {
+exit(0);
}
- else if (x == -1) {
- perror(fork);
- fprintf(stderr, unable to fork new process\n);
- exit(1); /* we can't do anything here, so just exit. */
- }
- /* RAISE_SIGSTOP(DETACH); */
-}
-#endif
-
+else if (x == -1) {
+perror(fork);
+fprintf(stderr, unable to fork new process\n);
+exit(1); /* we can't do anything here, so just exit. */
+}
+/* RAISE_SIGSTOP(DETACH); */
#ifdef HAVE_SETSID
-if ((pgrp = setsid()) == -1) {
-return errno;
-}
+if (setsid() == -1) {
+return errno;
+}
#elif defined(NEXT) || defined(NEWSOS)
-if (setpgrp(0, getpid()) == -1 || (pgrp = getpgrp(0)) == -1) {
-return errno;
-}
-#elif defined(OS2) || defined(TPF)
-/* OS/2 don't support process group IDs */
-pgrp = getpid();
-#elif defined(MPE)
-/* MPE uses negative pid for process group */
-pgrp = -getpid();
+if (setpgrp(0, getpid()) == -1) {
+return errno;
+}
#else
-if ((pgrp = setpgid(0, 0)) == -1) {
-return errno;
+if (setpgid(0, 0) == -1) {
+return errno;
+}
+#endif
}
#endif
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
RE: [PATCH] AddOutputFilterByType issues.
I've been partly out of it lately, but I think there is a problem with AddOutputFilterByType. Since ap_set_content_type() can be called arbitrarily many times, it will try to add each filter as directed by AddOutputFilterByType on each call. For certain filters, that isn't a terrifically good idea - such as mod_deflate. For others (say mod_include), this is okay. We can't compress a file twice (and is causing problems with Subversion right now), but that's what we are doing now - mod_deflate is in the chain twice. mod_mime calls ap_set_content_type twice in its normal execution (I dunno why, but that's sucky). I'm using the following patch to minimize how often ap_add_output_filters_by_type is called. This fixes the symptom, but perhaps we should think of a better solution? Perhaps only allow AP_FTYPE_RESOURCE filters to be added multiple times, and AP_FTYPE_CONTENT_SET or higher can only be added once? Thoughts? -- justin I have two conflicting thoughts, so I'll put them both out there for discussion. 1) I agree (mostly) RESOURCE filters are really the only ones that make sense to add multiple times. We should ensure that no other filters are added more than once. 2) It is up to the filter to protect against this case. That can be done by walking the filter chain to ensure that the same filter isn't in the list already. Of course, walking the chain could be slow, depending on how many filters there are. Regardless, this patch is all good-ness, and should be committed ASAP. Ryan
Re: [PATCH] -DNO_DETACH and/or apr_proc_detach() confusion?
On Mon, Apr 01, 2002 at 04:53:29PM -0500, Jeff Trawick wrote: This gets -DNO_DETACH working for me with Apache's prefork MPM on Linux and FreeBSD. But from Aaron's commit log for revision 1.34 I gather that this will break daemontools-like programs. How should I get ./httpd -DNO_DETACH to work? Calling setsid() is bogus. This patch avoids the setsid() logic if we don't daemonize. I don't understand how this is broken. If you don't want to daemonize but you still want to detach, you must be sure that httpd will not be a process group leader when it is started. This can be done by running httpd from a shell script or as a child of another process (like from daemontools). Running ./httpd -DNO_DETACH from the command line will cause httpd to be a process group leader [in most modern shells], which causes setsid() to fail and httpd to spit out an error. This seems correct to me. What am I missing? Perhaps apr_proc_detach needs to fail with a more specific error, and httpd should detect that error and write a more appropriate message? -aaron
Re: connect to listener warning message
[Thu Mar 28 13:11:43 2002] [warn] (49)Can't assign requested address: connect to listener one per second sounds like idle server maintenance That does seem to be the Apache code where the message is coming from based on the comments around it. can't assign requested address on a connect sounds like your machine is out of ephemeral ports (you were whacking it over loopback I'll bet) to assign to the source socket doing the dummy connection Actually no - I am wacking it from a remote machine. I think that something else is going on, but what I don't know at the moment. The problem starts when a load is put on the machine but continues well after the load is removed (as in hours). The machine is tuned well enough that it handles the load without a sweat with 1.3 I can reproduce the problem with ./ab -n 400 -c 20 http://hostname/staticfile which should hardly be enough load to warm up the cpu. I am going to try turning off ipv6 to see if that makes any difference, and if that does not put some debugging code in to see if I can figure out what is going on. Any other suggestions as to what to look for would be appreciated. Dave Hill
Re: [PATCH] AddOutputFilterByType issues.
On Mon, Apr 01, 2002 at 02:05:04PM -0800, Ryan Bloom wrote: I have two conflicting thoughts, so I'll put them both out there for discussion. 1) I agree (mostly) RESOURCE filters are really the only ones that make sense to add multiple times. We should ensure that no other filters are added more than once. 2) It is up to the filter to protect against this case. That can be done by walking the filter chain to ensure that the same filter isn't in the list already. Of course, walking the chain could be slow, depending on how many filters there are. How could the filter itself protect against this case? By the time it is called, it is already too late - the chain is created. Or am I missing something? The only thing I can think of is that it it looks at f/f-next to make sure that there are no other copies left in the chain that haven't been called. I think it would be better to just protect against that when we *add* filters rather than when we execute them. I will commit the strcmp check now. -- justin
Re: [PATCH] -DNO_DETACH and/or apr_proc_detach() confusion?
Aaron Bannert [EMAIL PROTECTED] writes: On Mon, Apr 01, 2002 at 04:53:29PM -0500, Jeff Trawick wrote: This gets -DNO_DETACH working for me with Apache's prefork MPM on Linux and FreeBSD. But from Aaron's commit log for revision 1.34 I gather that this will break daemontools-like programs. How should I get ./httpd -DNO_DETACH to work? Calling setsid() is bogus. This patch avoids the setsid() logic if we don't daemonize. I don't understand how this is broken. If you don't want to daemonize but you still want to detach, you must be sure that httpd will not be a process group leader when it is started. This can be done by running httpd from a shell script or as a child of another process (like from daemontools). Running ./httpd -DNO_DETACH from the command line will cause httpd to be a process group leader [in most modern shells], which causes setsid() to fail and httpd to spit out an error. This seems correct to me. What am I missing? Perhaps apr_proc_detach needs to fail with a more specific error, and httpd should detect that error and write a more appropriate message? as far as error reporting: the error is written to the log, not to stderr, so you don't see it as far as what I want to do: I just want to run httpd in the foreground (e.g., from gdb); should I be doing something other than gdb prefix/bin/httpd break foo r -DNO_DETACH ? Thanks, -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] -DNO_DETACH and/or apr_proc_detach() confusion?
On Mon, Apr 01, 2002 at 05:23:07PM -0500, Jeff Trawick wrote: as far as error reporting: the error is written to the log, not to stderr, so you don't see it Can we correct this so there is immediate response on stderr? as far as what I want to do: I just want to run httpd in the foreground (e.g., from gdb); should I be doing something other than gdb prefix/bin/httpd break foo r -DNO_DETACH ? This is working for me (or so it seems). Perhaps 'foo' is never called in the parent? -aaron
RE: [PATCH] AddOutputFilterByType issues.
On Mon, Apr 01, 2002 at 02:05:04PM -0800, Ryan Bloom wrote: I have two conflicting thoughts, so I'll put them both out there for discussion. 1) I agree (mostly) RESOURCE filters are really the only ones that make sense to add multiple times. We should ensure that no other filters are added more than once. 2) It is up to the filter to protect against this case. That can be done by walking the filter chain to ensure that the same filter isn't in the list already. Of course, walking the chain could be slow, depending on how many filters there are. How could the filter itself protect against this case? By the time it is called, it is already too late - the chain is created. Or am I missing something? The only thing I can think of is that it it looks at f/f-next to make sure that there are no other copies left in the chain that haven't been called. I think it would be better to just protect against that when we *add* filters rather than when we execute them. I will commit the strcmp check now. -- Justin All it needs to do is leave a message for itself in the request_rec. That can be done in either the per_request vector, or the r-notes table. I wouldn't want to use r-notes, because that could get really large quickly. The reality though is that the filter needs to be the one to check this. There are easily some RESOURCE filters that shouldn't be added more than once, for example the mod_header_footer filter should only be inserted once. There are some other methods that I can think of, but none of them are really clean. I kind of like the idea of just putting a note in the per-request vector. Ryan
2.0.34 - erratic behavior with autoindexes
I noticed something weird on daedalus on the test build. It looks like we're not autoindexing directories with HEADER.html or README.html files correctly. You see the contents of HEADER.html and/or README.html, but not the other files or subdirs in the directory. Often, the Mozilla animation keeps going as if the browser thinks more info is coming. Examples of the failure: http://www.apache.org:8092/dist/ http://www.apache.org:8092/dist/httpd/ http://jakarta.apache.org:8092/builds/ The second one gives me different results from IE5 when I hit refresh - sometimes the end of the README.html appears to be missing; sometimes it displays as plain text with the first part of the HEADER.html missing, the http headers visable in the middle, followed by duplicate html. But this one, which doesn't have a HEADER.html or README.html, works fine: http://jakarta.apache.org:8092/builds/jakarta-tomcat/ (get rid of the :8092 to see how the production server behaves.) I have band practice tonight so I'll be offline shortly. I'll leave 2.0.34 up on daedalus in case anyone wants to check it out. Greg
Re: cvs commit: httpd-2.0/docs/manual/mod mpm_common.xml
On Tue, Apr 02, 2002 at 01:07:43AM -, [EMAIL PROTECTED] wrote: aaron 02/04/01 17:07:43 Modified:docs/manual/mod mpm_common.xml Log: Update the docs on the ScoreBoardFile directive for the new apr_shm.h API and the removal of the old SCOREBOARD_FILE stuff. Can someone verify both my grammar and my xml syntax? :) -aaron
Re: cvs commit: httpd-2.0/docs/manual/mod mpm_common.xml
On Mon, 1 Apr 2002, Aaron Bannert wrote: Can someone verify both my grammar and my xml syntax? :) I have three little grammar nits with it. I'll fix them in a little while. As for XML syntax, that's for someone else to decide. :) --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [PATCH] -DNO_DETACH and/or apr_proc_detach() confusion?
Aaron Bannert [EMAIL PROTECTED] writes: On Mon, Apr 01, 2002 at 05:23:07PM -0500, Jeff Trawick wrote: as far as error reporting: the error is written to the log, not to stderr, so you don't see it Can we correct this so there is immediate response on stderr? as far as what I want to do: I just want to run httpd in the foreground (e.g., from gdb); should I be doing something other than gdb prefix/bin/httpd break foo r -DNO_DETACH ? This is working for me (or so it seems). Perhaps 'foo' is never called in the parent? it isn't called in the parent... that's why I wanted to use -DNO_DETACH :) note that -DNO_DETACH from gdb is doomed... setsid() will fail (at least with my normal environment)... -DNO_DETACH doesn't work for you from gdb, you just hit your breakpoint before the failure point I'll forget about it for now (but I will commit a cleanup of apr_proc_detach() which won't change the semantics). For the long term I guess I want -DFOREGROUND and appropriate support in apr_proc_detach(). -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Drop md5 from htpasswd docs please
Well, we don't need a whole lot of help to implment apache_md5 in PHP. I don't think I'd call it that though. As far as I am concerned there is no such thing as modified md5. It is either md5 or it isn't. -Rasmus On Mon, 1 Apr 2002, David Ford wrote: Is it possible for whomever knows best to provide code or help to the PHP group and make a PHP bsd|apache_md5() function? Or adapt the current PHP function w/ an additional attribute to select which type of hash to use? md5($string, ..., HASH_NORM|HASH_BSD), it'd be very nice if the latter was accepted, I'm sure in the future there will be at least one more implementation of md5 to cope with. Thanks for listening, David Rasmus Lerdorf wrote: I am getting rather tired of answering questions on this one. Could we please drop this crap about htpasswd using md5. A modified md5 is no longer md5, so let's not call it md5 at all. Over and over again people ask me why md5($string) doesn't match what is in htpasswd-generated password files. -Rasmus
Re: 2.0.34 - erratic behavior with autoindexes
At 04:39 PM 4/1/2002, you wrote: I noticed something weird on daedalus on the test build. It looks like we're not autoindexing directories with HEADER.html or README.html files correctly. You see the contents of HEADER.html and/or README.html, but not the other files or subdirs in the directory. Often, the Mozilla animation keeps going as if the browser thinks more info is coming. Examples of the failure: http://www.apache.org:8092/dist/ http://www.apache.org:8092/dist/httpd/ http://jakarta.apache.org:8092/builds/ I consider this to be a showstopper to a responsible release of 2.0.34... that release is on -hold-. Let's all try [I'll take a whack in the a.m.] to figure out this pickle. Bill
Re: cvs commit: apr CHANGES apr-config.in
At 01:31 PM 4/1/2002, you wrote: On Mon, Apr 01, 2002 at 07:30:27PM -, [EMAIL PROTECTED] wrote: jerenkrantz02/04/01 11:30:27 Modified:.CHANGES apr-config.in Log: Fix apr-config so that it will not attempt to cd to bindir if it doesn't exist yet. Oh glorious RM, this might be worthy for inclusion into 2.0.34. -- justin 1. then don't trim the revision number, makes it harder to bump ;-) 2. then get me a +1 to the patch, 2.0.34 is in review mode :-) And I'd be happy to
Re: cvs commit: apr STATUS
Are these also for consideration in the 2.0.34 release? Bill gregames02/04/01 13:07:13 Modified:buildapr_hints.m4 .STATUS Log: FreeBSD: use fcntl cross-process locks by default. Make note of problems experienced with flock and SysV sems. Revision ChangesPath 1.38 +5 -0 apr/build/apr_hints.m4 1.107 +6 -1 apr/STATUS trawick 02/04/01 13:03:04 Modified:.CHANGES locks/unix proc_mutex.c Log: Get flock-based mutexes to work in apps like Apache. Use the same permissions on flock- and fcntl-based mutexes as Apache 1.3. Revision ChangesPath 1.251 +4 -0 apr/CHANGES 1.13 +6 -4 apr/locks/unix/proc_mutex.c
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c mpm_winnt.h
Now incorporated into APACHE_2_0_34 stoddard02/04/01 10:55:46 Modified:server/mpm/winnt mpm_winnt.c mpm_winnt.h Log: Win32: Move apr_bucket_alloc() to a more reasonable location to fix memory leak. Revision ChangesPath 1.253 +4 -6 httpd-2.0/server/mpm/winnt/mpm_winnt.c 1.36 +1 -0 httpd-2.0/server/mpm/winnt/mpm_winnt.h
Re: cvs commit: apr CHANGES apr-config.in
William A. Rowe, Jr. [EMAIL PROTECTED] writes: At 01:31 PM 4/1/2002, you wrote: On Mon, Apr 01, 2002 at 07:30:27PM -, [EMAIL PROTECTED] wrote: jerenkrantz02/04/01 11:30:27 Modified:.CHANGES apr-config.in Log: Fix apr-config so that it will not attempt to cd to bindir if it doesn't exist yet. Oh glorious RM, this might be worthy for inclusion into 2.0.34. -- justin 2. then get me a +1 to the patch, 2.0.34 is in review mode :-) +1 -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: apr STATUS
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Are these also for consideration in the 2.0.34 release? gregames02/04/01 13:07:13 Modified:buildapr_hints.m4 .STATUS Log: FreeBSD: use fcntl cross-process locks by default. Make note of problems experienced with flock and SysV sems. I think a later level of apr_hints.m4 is desirable... this particular change to apr_hints.m4 was a temporary work-around. Revision 1.39, which supercedes 1.38 (mentioned above), needs to have the tag. trawick 02/04/01 13:03:04 Modified:.CHANGES locks/unix proc_mutex.c Log: Get flock-based mutexes to work in apps like Apache. Use the same permissions on flock- and fcntl-based mutexes as Apache 1.3. This was pure fix and is necessary for the eventual FreeBSD fix (apr_hints.m4 revision 1.39). -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] -DNO_DETACH and/or apr_proc_detach() confusion?
On Mon, Apr 01, 2002 at 09:07:28PM -0500, Jeff Trawick wrote: I'll forget about it for now (but I will commit a cleanup of apr_proc_detach() which won't change the semantics). For the long term I guess I want -DFOREGROUND and appropriate support in apr_proc_detach(). Please, please don't change the semantics because it will make it again impossible to run Apache under a process controller. While I'm here, would anybody please have a look at bug 7628? Thanks. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
cvs commit: httpd-2.0/modules/proxy mod_proxy.h proxy_http.cproxy_util.c (fwd)
RM can you bump the .34 tag on these files? thanks.
-- Forwarded message --
Date: 2 Apr 2002 04:30:49 -
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: httpd-2.0/modules/proxy mod_proxy.h proxy_http.c
proxy_util.c
dougm 02/04/01 20:30:49
Modified:modules/proxy mod_proxy.h proxy_http.c proxy_util.c
Log:
Reviewed by: Ryan Bloom
remove call to ap_proxy_reset_output_filters() and the function itself.
this call breaks ssl proxy when the client is using keepalives.
this function is also no longer needed with recent-ish filter changes.
Revision ChangesPath
1.78 +0 -1 httpd-2.0/modules/proxy/mod_proxy.h
Index: mod_proxy.h
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/mod_proxy.h,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- mod_proxy.h 29 Mar 2002 07:29:11 - 1.77
+++ mod_proxy.h 2 Apr 2002 04:30:49 - 1.78
@@ -271,7 +271,6 @@
PROXY_DECLARE(int) ap_proxy_checkproxyblock(request_rec *r, proxy_server_conf
*conf, apr_sockaddr_t *uri_addr);
PROXY_DECLARE(int) ap_proxy_pre_http_request(conn_rec *c, request_rec *r);
PROXY_DECLARE(apr_status_t) ap_proxy_string_read(conn_rec *c, apr_bucket_brigade
*bb, char *buff, size_t bufflen, int *eos);
-PROXY_DECLARE(void) ap_proxy_reset_output_filters(conn_rec *c);
PROXY_DECLARE(void) ap_proxy_table_unmerge(apr_pool_t *p, apr_table_t *t, char
*key);
PROXY_DECLARE(int) ap_proxy_connect_to_backend(apr_socket_t **, const char *,
apr_sockaddr_t *, const char *, proxy_server_conf *, server_rec *, apr_pool_t *);
PROXY_DECLARE(int) ap_proxy_ssl_enable(conn_rec *c);
1.143 +0 -3 httpd-2.0/modules/proxy/proxy_http.c
Index: proxy_http.c
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/proxy_http.c,v
retrieving revision 1.142
retrieving revision 1.143
diff -u -r1.142 -r1.143
--- proxy_http.c 30 Mar 2002 06:19:14 - 1.142
+++ proxy_http.c 2 Apr 2002 04:30:49 - 1.143
@@ -326,9 +326,6 @@
p_conn-sock = client_socket;
new = 0;
-/* reset the connection filters */
-ap_proxy_reset_output_filters(*origin);
-
/* save timeout */
apr_getsocketopt(p_conn-sock, APR_SO_TIMEOUT, current_timeout);
/* set no timeout */
1.88 +0 -19 httpd-2.0/modules/proxy/proxy_util.c
Index: proxy_util.c
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/proxy_util.c,v
retrieving revision 1.87
retrieving revision 1.88
diff -u -r1.87 -r1.88
--- proxy_util.c 22 Mar 2002 21:41:14 - 1.87
+++ proxy_util.c 2 Apr 2002 04:30:49 - 1.88
@@ -1062,25 +1062,6 @@
return APR_SUCCESS;
}
-/* remove other filters (like DECHUNK) from filter stack */
-PROXY_DECLARE(void) ap_proxy_reset_output_filters(conn_rec *c)
-{
-ap_filter_t *f = c-output_filters;
-
-while (f) {
-if (!strcasecmp(f-frec-name, CORE) ||
-!strcasecmp(f-frec-name, CONTENT_LENGTH) ||
-!strcasecmp(f-frec-name, HTTP_HEADER)) {
-f = f-next;
-continue;
-}
-else {
-ap_remove_output_filter(f);
-f = f-next;
-}
-}
-}
-
/* unmerge an element in the table */
PROXY_DECLARE(void) ap_proxy_table_unmerge(apr_pool_t *p, apr_table_t *t, char *key)
{
Bump a few more tags. :-)
In httpd-2.0/server/mpm/perchild mpm.h -- version 1.16 perchild.c -- version 1.120 Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA
Re: cvs commit: httpd-2.0/modules/proxy mod_proxy.h proxy_http.c proxy_util.c (fwd)
At 10:33 PM 4/1/2002, you wrote: RM can you bump the .34 tag on these files? thanks. Caught it [note they are actually -reviewed- :-] ... files below are now moved to tag APACHE_2_0_34 dougm 02/04/01 20:30:49 Modified:modules/proxy mod_proxy.h proxy_http.c proxy_util.c Log: Reviewed by: Ryan Bloom remove call to ap_proxy_reset_output_filters() and the function itself. this call breaks ssl proxy when the client is using keepalives. this function is also no longer needed with recent-ish filter changes. Revision ChangesPath 1.78 +0 -1 httpd-2.0/modules/proxy/mod_proxy.h 1.143 +0 -3 httpd-2.0/modules/proxy/proxy_http.c 1.88 +0 -19 httpd-2.0/modules/proxy/proxy_util.c
Re: Bump a few more tags. :-)
At 10:44 PM 4/1/2002, you wrote: In httpd-2.0/server/mpm/perchild mpm.h -- version 1.16 perchild.c -- version 1.120 Both are bumped... anyone else care to cvs up -r APACHE_2_0_34 and verify that perchild builds? Bill
Re: Bump a few more tags. :-)
On Mon, 1 Apr 2002, William A. Rowe, Jr. wrote:
Both are bumped... anyone else care to cvs up -r APACHE_2_0_34
and verify that perchild builds?
perchild.c: In function `worker_thread':
perchild.c:693: warning: variable `lr' might be clobbered by `longjmp' or
`vfork'
perchild.c:693: warning: variable `last_lr' might be clobbered by
`longjmp' or `vfork'
All tests pass except ssl/proxy.t. That one gets stuck here:
(gdb) bt
#0 0x403a89be in select () from /lib/libc.so.6
#1 0x4004223c in __DTOR_END__ () from /root/apache/test/lib/libapr.so.0
#2 0x400362f2 in apr_recv (sock=0x81cc978,
buf=0x8274c70
pL?@pL?@V]nzw{6u\016[42C\205*\021\177\026\222B\223ks\236x\001\225NLM\025\023~A\r\031p\002wS\f/_V\225f\232\025\034`\004A\210i\016\005\027\207\002XtUW%\027a\\Irm3VGlC\e{9\215\217gQa-\222BV\223\fpIV\036?\ak^kj\0061hE#4\236\201\231|\231\234\216\025\e\216W\031U\232|!\216j\213mV\222}%N5...,
len=0xbf7fd5a0)
at sendrecv.c:142
#3 0x4001b14f in socket_read (a=0x827a000, str=0xbf7fd59c,
len=0xbf7fd5a0,
block=1127800088) at apr_buckets_socket.c:74
#4 0x80d033b in core_input_filter (f=0x823a950, b=0x823a910,
mode=AP_MODE_READBYTES, block=1127800088, readbytes=7) at core.c:3430
#5 0x80c9c47 in ap_get_brigade (next=0x823a950, bb=0x823a910,
mode=AP_MODE_READBYTES, block=1127800088, readbytes=7) at
util_filter.c:507
#6 0x8087cb0 in bio_bucket_in_read (bio=0x8226e00,
in=0x826c460 H?@H?@\005];\\~xo\a6$\031D\b \223, inl=7)
at ssl_engine_io.c:395
#7 0x400b2661 in BIO_read () from /usr/lib/libssl.so.0
Cannot access memory at address 0x7
But still, this is major progress. +1 from me!
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Re: Bump a few more tags. :-)
Sounds like that could be Doug's latest changes he asked to incorporate.
Doug, was there an additional file to bump, beyond the three you cited?
Bill
At 11:09 PM 4/1/2002, you wrote:
On Mon, 1 Apr 2002, William A. Rowe, Jr. wrote:
Both are bumped... anyone else care to cvs up -r APACHE_2_0_34
and verify that perchild builds?
perchild.c: In function `worker_thread':
perchild.c:693: warning: variable `lr' might be clobbered by `longjmp' or
`vfork'
perchild.c:693: warning: variable `last_lr' might be clobbered by
`longjmp' or `vfork'
All tests pass except ssl/proxy.t. That one gets stuck here:
(gdb) bt
#0 0x403a89be in select () from /lib/libc.so.6
#1 0x4004223c in __DTOR_END__ () from /root/apache/test/lib/libapr.so.0
#2 0x400362f2 in apr_recv (sock=0x81cc978,
buf=0x8274c70
pL?@pL?@V]nzw{6u\016[42C\205*\021\177\026\222B\223ks\236x\001\225NLM\025\023~A\r\031p\002wS\f/_V\225f\232\025\034`\004A\210i\016\005\027\207\002XtUW%\027a\\Irm3VGlC\e{9\215\217gQa-\222BV\223\fpIV\036?\ak^kj\0061hE#4\236\201\231|\231\234\216\025\e\216W\031U\232|!\216j\213mV\222}%N5...,
len=0xbf7fd5a0)
at sendrecv.c:142
#3 0x4001b14f in socket_read (a=0x827a000, str=0xbf7fd59c,
len=0xbf7fd5a0,
block=1127800088) at apr_buckets_socket.c:74
#4 0x80d033b in core_input_filter (f=0x823a950, b=0x823a910,
mode=AP_MODE_READBYTES, block=1127800088, readbytes=7) at core.c:3430
#5 0x80c9c47 in ap_get_brigade (next=0x823a950, bb=0x823a910,
mode=AP_MODE_READBYTES, block=1127800088, readbytes=7) at
util_filter.c:507
#6 0x8087cb0 in bio_bucket_in_read (bio=0x8226e00,
in=0x826c460 H?@H?@\005];\\~xo\a6$\031D\b \223, inl=7)
at ssl_engine_io.c:395
#7 0x400b2661 in BIO_read () from /usr/lib/libssl.so.0
Cannot access memory at address 0x7
But still, this is major progress. +1 from me!
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
bio_bucket_in_read bug [was Re: Bump a few more tags. :-)]
On Tue, 2 Apr 2002, Cliff Woolley wrote: #3 0x4001b14f in socket_read (a=0x827a000, str=0xbf7fd59c, len=0xbf7fd5a0, block=1127800088) at apr_buckets_socket.c:74 #4 0x80d033b in core_input_filter (f=0x823a950, b=0x823a910, mode=AP_MODE_READBYTES, block=1127800088, readbytes=7) at core.c:3430 #5 0x80c9c47 in ap_get_brigade (next=0x823a950, bb=0x823a910, mode=AP_MODE_READBYTES, block=1127800088, readbytes=7) at util_filter.c:507 #6 0x8087cb0 in bio_bucket_in_read (bio=0x8226e00, in=0x826c460 H?@H?@\005];\\~xo\a6$\031D\b \223, inl=7) at ssl_engine_io.c:395 #7 0x400b2661 in BIO_read () from /usr/lib/libssl.so.0 Cannot access memory at address 0x7 There appears to be a bug in bio_bucket_in_read: it passes inbio-block as the block parameter to ap_get_brigade(), but inbio-block is uninitialized: /root/apache/httpd-2.0.34/modules/ssl# grep -- -block *.[ch] ssl_engine_io.c:AP_MODE_READBYTES, inbio-block, ssl_engine_io.c: buf, buf_len, inbio-block); --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [PATCH] -DNO_DETACH and/or apr_proc_detach() confusion?
On Mon, Apr 01, 2002 at 09:07:28PM -0500, Jeff Trawick wrote: it isn't called in the parent... that's why I wanted to use -DNO_DETACH :) by parent I meant apache parent, not just that process that forked other processes. note that -DNO_DETACH from gdb is doomed... setsid() will fail (at least with my normal environment)... -DNO_DETACH doesn't work for you from gdb, you just hit your breakpoint before the failure point I'll forget about it for now (but I will commit a cleanup of apr_proc_detach() which won't change the semantics). For the long term I guess I want -DFOREGROUND and appropriate support in apr_proc_detach(). I thought about adding a -DFOREGROUND but I guess I convinced myself that it was still just a replacement for -DNO_DETACH. Given this clear use case I'm totally for -DNO_DETACH simply not calling apr_proc_detach() (as before) and -DFOREGROUND calling apr_proc_detach() with the foreground flag. Better to get it right now rather than later. -aaron
Re: [PATCH] -DNO_DETACH and/or apr_proc_detach() confusion?
On Mon, Apr 01, 2002 at 08:20:24PM -0800, Jos Backus wrote: On Mon, Apr 01, 2002 at 09:07:28PM -0500, Jeff Trawick wrote: I'll forget about it for now (but I will commit a cleanup of apr_proc_detach() which won't change the semantics). For the long term I guess I want -DFOREGROUND and appropriate support in apr_proc_detach(). Please, please don't change the semantics because it will make it again impossible to run Apache under a process controller. No worries, the semantics will stay (even if the syntax changes). -aaron
Re: bio_bucket_in_read bug [was Re: Bump a few more tags. :-)]
your grep pattern missed this one: ctx-inbio.block = block;
Re: Bump a few more tags. :-)
On Mon, 1 Apr 2002, William A. Rowe, Jr. wrote: Sounds like that could be Doug's latest changes he asked to incorporate. Doug, was there an additional file to bump, beyond the three you cited? nope. sounds specific to perchild, cliff does the proxy test pass for you with prefork and/or worker? i can take a look in the morning.
Re: bio_bucket_in_read bug [was Re: Bump a few more tags. :-)]
On Mon, 1 Apr 2002, Doug MacEachern wrote: your grep pattern missed this one: ctx-inbio.block = block; Doh! :) Regardless, the value of -block that's getting passed in is fried. Some of the others might be too, I'll have to go back and poke through gdb more carefully. Right now I'm running httpd-test against worker and prefork. -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Bump a few more tags. :-)
On Mon, 1 Apr 2002, Doug MacEachern wrote: nope. sounds specific to perchild, cliff does the proxy test pass for you with prefork and/or worker? It does appear to be perchild-specific. It works on both prefork and worker. Just the usual from those two: all tests passed except ssl/http.t, which is a broken test. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: Bump a few more tags. :-)
On Mon, 1 Apr 2002, William A. Rowe, Jr. wrote: Sounds like that could be Doug's latest changes he asked to incorporate. Doug, was there an additional file to bump, beyond the three you cited? nope. sounds specific to perchild, cliff does the proxy test pass for you with prefork and/or worker? i can take a look in the morning. Perchild does some hokey stuff with sockets. The MPM is still experimental. I am hoping to have more time with it next weekend again. Ryan
Re: [PATCH] make mod_proxy not accept HTTP/0.9
Adam Sussman wrote: This patch adds a configuration directive ProxyRequireValidHTTPStatus. When enabled, mod_proxy will require a valid HTTP status line from the destination server and throw a 502 Bad Gateway error if it does not get it. Basicaly, this disallows backasswards reponses. Why would one want to do this? Well, I have a setup where my handler is first attempting one proxy destination, and if that does not work, it tries another. It works by discarding the output of any response that isn't a 200 and then trying another gateway. If the gateway doesn't return a valid HTTP 1.0 or better status line, mod_proxy assumes a 200 OK response. In my environment, I control all the gateway servers so I know that a working gateway will always give me a real HTTP status line. If it doesn't, I want to consider it a bad gateway and try another. This looks really arcane to me though - there are very few HTTP/0.9 servers out there that I am aware of to start with, adding functionality to specifically not support them seems like software bloat to me. Is this a real problem in your installation? Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
