Re: flood docs -- take 2
On Sunday, June 29, 2003, at 06:18 PM, Jacek Prucia wrote: Please have another look at: http://cvs.apache.org/~jacekp/manual/ This is actually what I'm going to commit tommorow. It has bugs, empty places, but at least mentions every element/attribute available (at least I hope so). Looks like it is a good starting point. From the parts I looked at, it looks great. :) while preparing documentation I was stuck with one simple thing: What is HTTP Server project policy with CHANGES file? Is it: a) hand edited by separate cvs commits (changed the code? edit CHANGES!) b) autogenerated from cvs log Some of my useful commits (auth support, baseurl) aren't in CHANGES. Gotta fix that before release. We hand edit the CHANGES file, so go ahead and add anything you feel the user should know about. (Big awesome doc additions like this definitely belong in there.) -aaron
Re: [patch] have_apache_mpm()
looks good, but what happens when 1.3 is used? Shouldn't it always
return preforked?
doh!
here's a better patch.
--Geoff
Index: Test.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm,v
retrieving revision 1.63
diff -u -r1.63 Test.pm
--- Test.pm 19 Jun 2003 00:45:31 - 1.63
+++ Test.pm 30 Jun 2003 13:46:35 -
@@ -15,7 +15,7 @@
have_cgi have_access have_auth have_module have_apache
have_min_apache_version have_apache_version have_perl
have_min_perl_version have_min_module_version
- have_threads under_construction);
+ have_threads under_construction have_apache_mpm);
$VERSION = '1.04';
%SubTests = ();
@@ -274,6 +274,22 @@
push @SkipReasons,
apache version $wanted or higher is required, .
this is version $current;
+return 0;
+}
+else {
+return 1;
+}
+}
+
+sub have_apache_mpm {
+my $wanted = shift;
+my $cfg = Apache::Test::config();
+my $current = $cfg-{server}-{mpm};
+
+if ($current ne $wanted) {
+push @SkipReasons,
+ apache mpm $wanted is required, .
+ this is the $current mpm;
return 0;
}
else {
Index: TestConfigParse.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm,v
retrieving revision 1.33
diff -u -r1.33 TestConfigParse.pm
--- TestConfigParse.pm 27 Apr 2003 22:52:28 - 1.33
+++ TestConfigParse.pm 30 Jun 2003 13:46:36 -
@@ -309,6 +309,10 @@
if (my $mpm_dir = $self-{httpd_defines}-{APACHE_MPM_DIR}) {
$self-{mpm} = basename $mpm_dir;
}
+else {
+# Apache 1.3
+$self-{mpm} = 'prefork';
+}
}
sub httpd_version {
@@ -339,6 +343,10 @@
close $v;
return $version;
+}
+
+sub httpd_mpm {
+return shift-{mpm};
}
1;
Index: TestServer.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestServer.pm,v
retrieving revision 1.62
diff -u -r1.62 TestServer.pm
--- TestServer.pm 21 May 2003 04:02:14 - 1.62
+++ TestServer.pm 30 Jun 2003 13:46:36 -
@@ -38,6 +38,7 @@
$self-{port_counter} = $self-{config}-{vars}-{port};
$self-{version} = $self-{config}-httpd_version || '';
+$self-{mpm} = $self-{config}-httpd_mpm || '';
($self-{rev}) = $self-{version} =~ m:^Apache/(\d)\.:;
$self-{rev} ||= 2;
Makefile.PL Questions
Hi All, I got a bug report for the latest release of MasonX::ApacheHandler::WithCallbacks, which uses Apache::Test for its testing. My question is this: I use Apache::TestMM and Apache::TestRunPerl in my Makefile.PL to set up the test suite. However, many users may not have Apache::Test installed when they go to install my module. CPAN.pm will of course catch this (Apache::Test is in the list of prereqs), but it first tries to run Makefile.PL, triggering this error: Can't locate Apache/TestMM.pm in @INC I can avoid this by checking to see if Apache::Test loads and only using it if it does. But then, how would I set up the tests to run after CPAN.pm has installed Apache::Test? Does it run Makefile.PL again? TIA, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Makefile.PL Questions
I can avoid this by checking to see if Apache::Test loads and only using
it if it does. But then, how would I set up the tests to run after
CPAN.pm has installed Apache::Test? Does it run Makefile.PL again?
I don't ever use CPAN.pm, so I don't know if the way I have been going about
it actually works or not, but my standard 1.0 Makefile.PL (which was linked
to in the perl.com article) looks something like
sub MY::test {
eval {
require Apache::Test;
require Apache::TestMM;
require Apache::TestRunPerl;
Apache::TestMM-import(qw(test clean));
Apache::TestMM::filter_args();
Apache::TestRunPerl-generate_script();
return Apache::TestMM-test;
}
or return EOF;
test::
[EMAIL PROTECTED] This test suite requires Apache-Test,
[EMAIL PROTECTED] which is available from the mod_perl 2.0
[EMAIL PROTECTED] sources, CPAN, or the httpd-test distribution.
EOF
}
this makes 'make test' echo the error string or run the tests, depending on
whether A::T is installed. in either case, 'make test' is successful (I hope :)
HTH
--Geoff
Re: Makefile.PL Questions
On Monday, June 30, 2003, at 11:26 AM, Geoffrey Young wrote:
I don't ever use CPAN.pm, so I don't know if the way I have been going
about it actually works or not, but my standard 1.0 Makefile.PL (which
was linked to in the perl.com article) looks something like
sub MY::test {
eval {
require Apache::Test;
require Apache::TestMM;
require Apache::TestRunPerl;
Apache::TestMM-import(qw(test clean));
Apache::TestMM::filter_args();
Apache::TestRunPerl-generate_script();
return Apache::TestMM-test;
}
or return EOF;
test::
[EMAIL PROTECTED] This test suite requires Apache-Test,
[EMAIL PROTECTED] which is available from the mod_perl 2.0
[EMAIL PROTECTED] sources, CPAN, or the httpd-test distribution.
EOF
}
this makes 'make test' echo the error string or run the tests,
depending on whether A::T is installed. in either case, 'make test'
is successful (I hope :)
That seems like a good idea. I just did some experimentation on my own,
and discovered that both CPAN.pm and CPANPLUS run Makefile.PL twice --
once before satisfying dependences, and once after satisfying
dependencies. So it works well structure the Makefile.PL like this:
if (eval {require Apache::Test}) {
require Apache::TestMM;
require Apache::TestRunPerl;
Apache::TestMM-import(qw(test clean));
Apache::TestMM::filter_args();
Apache::TestRunPerl-generate_script();
} else {
print Skipping test setup.\n;
}
But I agree that it's smart to go one step further and install the
default `make test` as you describe. I'll have to try that.
Thanks,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]
Re: Makefile.PL Questions
On Monday, June 30, 2003, at 11:26 AM, Geoffrey Young wrote:
this makes 'make test' echo the error string or run the tests,
depending on whether A::T is installed. in either case, 'make test'
is successful (I hope :)
Looks like it would be. I decided to use a different approach. Since
some of the tests in my test suite don't require Apache::Test, I simply
added this code to those that do require it:
BEGIN{
if (eval {require Apache::Test}) {
Apache::Test-import(qw(have_lwp plan));
require Apache::TestRequest;
Apache::TestRequest-import(qw(GET POST));
plan tests = 43, have_lwp;
} else {
plan skip_all = 'Apache::Test required to run tests.';
}
}
So the test suite still runs in Test::Harness, but all the tests are
skipped.
Hope this can help others.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]
Re: Makefile.PL Questions
On Monday, June 30, 2003, at 12:11 PM, David Wheeler wrote:
BEGIN{
if (eval {require Apache::Test}) {
Apache::Test-import(qw(have_lwp plan));
require Apache::TestRequest;
Apache::TestRequest-import(qw(GET POST));
plan tests = 43, have_lwp;
} else {
plan skip_all = 'Apache::Test required to run tests.';
}
}
Actually, to make it cooperate with Test::More, I had to do this:
BEGIN {
if (eval {require Apache::Test}) {
if (Apache::Test::have_lwp()) {
require Apache::TestRequest;
Apache::TestRequest-import(qw(GET POST));
plan tests = 43;
} else {
plan skip_all = 'libwww-perl is not installed';
}
} else {
plan skip_all = 'Apache::Test required to run tests';
}
}
Thanks,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]
apache 2.0.46 : segmentation fault or hangs system
Hi, a couple of weeks ago I upgraded our servers from 2.0.43 to 2.0.46. Since then, child processes on our internal server either exit with a segmentation fault or keep running but take all CPU power. Hanging processes occur at a rate of about 5 per hour. As far as I can see the URLs they are serving are not special and work fine with other child processes - however, they are all proxy requests. We are using two apache 2.0.46 is a proxy chain, the internal webserver hands all requests to the external apache 2.0.46. The external apache does not have that problem, however, when an error occurs connecting to a remote site or when an invalid status line is received, I noticed it does not exit cleanly and an 'invalid status line' error is received also by the internal server. I tried to SIGQUIT a hanging childprocess to get a core but it does not respond ... Is there a way to make a child process core ( I didn't find a core anywhere ) when receiving a segmentation fault ? The systems are HPUX 11.0 . Thanks in advance ! Peter. -- Peter Van Biesen Adj. Sysadmin V.F.S.I.P.H. tel: +32 (0) 2 225 85 70 fax: +32 (0) 2 225 85 88 e-mail: [EMAIL PROTECTED]
RE: Apache 1.3.x - Problem with handling ErrorDocument for 413 ?
Thanks for the consideration. I'll look forward for your feedback. -Madhu -Original Message- From: Jim Jagielski [mailto:[EMAIL PROTECTED] Sent: Sunday, June 29, 2003 6:55 AM To: [EMAIL PROTECTED] Subject: Re: Apache 1.3.x - Problem with handling ErrorDocument for 413 ? On Monday, June 23, 2003, at 10:32 AM, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: It'll be nice if somebody can please review the patch and give me the feedback.. I think that the below should wait until after 1.3.28.
RE: apache 2.0.46 : segmentation fault or hangs system
Hi Peter, When you do a tusc, do you see the process looping on 'sendfile' ?. If 'yes', I believe it's a transport layer bug (and we need some system information), and I've been trying to duplicate it for the last couple of months, without any success. It'll be nice if I can get access to the system when the bug is showing up (I know it's a long shot). But, if that's not possible, here are a couple of things that you might want to try : 1. Update to the latest ARPA and transport patches on your system 2. Use 'EnableSendFile off' in httpd.conf Thanks -Madhu -Original Message- From: Peter Van Biesen [mailto:[EMAIL PROTECTED] Sent: Monday, June 30, 2003 2:19 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: apache 2.0.46 : segmentation fault or hangs system Hi, a couple of weeks ago I upgraded our servers from 2.0.43 to 2.0.46. Since then, child processes on our internal server either exit with a segmentation fault or keep running but take all CPU power. Hanging processes occur at a rate of about 5 per hour. As far as I can see the URLs they are serving are not special and work fine with other child processes - however, they are all proxy requests. We are using two apache 2.0.46 is a proxy chain, the internal webserver hands all requests to the external apache 2.0.46. The external apache does not have that problem, however, when an error occurs connecting to a remote site or when an invalid status line is received, I noticed it does not exit cleanly and an 'invalid status line' error is received also by the internal server. I tried to SIGQUIT a hanging childprocess to get a core but it does not respond ... Is there a way to make a child process core ( I didn't find a core anywhere ) when receiving a segmentation fault ? The systems are HPUX 11.0 . Thanks in advance ! Peter. -- Peter Van Biesen Adj. Sysadmin V.F.S.I.P.H. tel: +32 (0) 2 225 85 70 fax: +32 (0) 2 225 85 88 e-mail: [EMAIL PROTECTED]
RE: ap_max_requests_per_child isn't part of the API, is it?
--On Sunday, June 29, 2003 1:03 PM -0700 Marc M. Adkins [EMAIL PROTECTED] wrote: A FAQ Wiki might be useful. Then we could copy chunks of emails into the wiki and later reference the wiki pages by URL. This would be a temporary collecting point for the data pending formal documentation, and as such might help to organize it. The ASF-wide Wiki on Nagoya has been vandalized a lot lately, and I'm not sure that any of the httpd developers want to oversee a public Wiki on top of everything else we currently do. Additionally, IIRC, the httpd docs group has decided they don't want to support a Wiki either. For potential FAQ items, I would suggest emailing them to [EMAIL PROTECTED] in the form of a patch to httpd-2.0/docs/manual/faq/index.xml. You could also send it to [EMAIL PROTECTED] as well, but you *might* get a better response on the docs list for FAQ entries. Unsure. -- justin
Re: ap_max_requests_per_child isn't part of the API, is it?
--On Saturday, June 28, 2003 8:24 AM -0400 Jeff Trawick [EMAIL PROTECTED] wrote: Can anybody agree that something like this is is part of the formal definition of our API? Apache header files contain declarations for a number of variables and functions. Many of these are part of the API, while some of these are simply necessary for the division of the Apache implementation across many source files. Any such variables that are considered part of the API are declared with the AP_DECLARE_DATA qualifier. Here is an example from scoreboard.h: AP_DECLARE_DATA extern scoreboard *ap_scoreboard_image; Any such functions that are considered part of the API are declared with AP_DECLARE() or AP_DECLARE_NONSTD(). Examples include: AP_DECLARE(void) ap_add_common_vars(request_rec *r); AP_DECLARE_NONSTD(int) ap_rvputs(request_rec *r,...); In addition, hooks are declared with AP_DECLARE_HOOK() or APR_DECLARE_EXTERNAL_HOOK(). If the declaration of a variable or function does not include these special qualifiers, it is not part of the API, and beyond the fact that it is not intended for module use, modules will not be able to access the variable or function on all platforms, leading to obscure failures for the users of such modules. +1. -- justin
Re: AddHandler scope
--On Sunday, June 29, 2003 2:05 PM -0700 Marc M. Adkins [EMAIL PROTECTED] wrote: I've been working on a module and quite unexpectedly I found that my AddHandler directive was taking affect at a global level even though it was defined within a virtual host block. So it was affecting Apache manual pages that weren't in the virtual host for which I had created the AddHandler directive. Am I misunderstanding the scope of AddHandler? I am using named virtual host. For testing I have all of the named hosts defined in my HOSTS file to point to 127.0.0.1. So in a sense it all goes to the same place. I wouldn't have thought that would have made a difference. Hmm, considering AddHandler is implemented by mod_mime, I would find it very suspicious that this is behaving this way. Can you please post a configuration snippet that demonstrates this behavior? -- justin
RE: AddHandler scope
I've been working on a module and quite unexpectedly I found that my AddHandler directive was taking affect at a global level even though it was defined within a virtual host block. So it was affecting Apache manual pages that weren't in the virtual host for which I had created the AddHandler directive. Am I misunderstanding the scope of AddHandler? I am using named virtual host. For testing I have all of the named hosts defined in my HOSTS file to point to 127.0.0.1. So in a sense it all goes to the same place. I wouldn't have thought that would have made a difference. Hmm, considering AddHandler is implemented by mod_mime, I would find it very suspicious that this is behaving this way. Can you please post a configuration snippet that demonstrates this behavior? -- justin OK, I think I got it down to the bare minimum. The attached files live in C:\Apache2\foobar on my Windows 2000 system. I run Apache 2.0.46. The attached httpd.conf is intended to be Included at the end of the normal httpd.conf. I keep my httpd.conf (mostly) 'stock' so there shouldn't be any real issues there. My HOSTS file defines: 127.0.0.1 localhost 127.0.0.1 Scope.Doorways.home which may be some or all of the issue. This is how I do testing (obviously, since I'm using a non-standard domain name). The mod_foobar.c file is a trivial module that just prints the handler name and filename and DECLINEs. I've included a Makefile that works with my version of Microsoft's C compiler, which is whatever comes with Visual Studio 6. When I run Apache and hit it with: http://localhost/manual my error log contains: [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(foobar, localhost, C:/Apache2/manual/index.html.en) [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(text/css, localhost, C:/Apache2/manual/style/css/manual.css), referer: http://localhost/manual/ [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(text/css, localhost, C:/Apache2/manual/style/css/manual-print.css), referer: http://localhost/manual/ [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(image/gif, localhost, C:/Apache2/manual/images/left.gif), referer: http://localhost/manual/ [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(image/gif, localhost, C:/Apache2/manual/images/feather.gif), referer: http://localhost/manual/ [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(text/css, localhost, C:/Apache2/manual/style/css/manual-loose-100pc.css), referer: http://localhost/manual/ Hitting it with: http://Scope.Doorways.home gives me the appropriate index file (also supplied but irrelevant) and my error log contains: [Mon Jun 30 13:24:00 2003] [info] [client 127.0.0.1] foobar_handler(foobar, scope.doorways.home, C:/Apache2/foobar/index.html) So the module is being invoked for the Apache manual pages even though they are not defined in the virtual server block in which I added the handler. This is what confuses me. I wouldn't think that this would happen. I keep thinking that perhaps the fact that both domain names resolve to 127.0.0.1 via my HOSTS file could be confusing Apache. But they're named virtual servers, so I feel like that _shouldn't_ be an issue since I'm asking for different hosts via the browser. And the request record is showing different hostnames in the log. Anyway, I'm probably missing something simple in the configuration file. mma httpd.conf Description: Binary data mod_foobar.c Description: Binary data Makefile Description: Binary data Title: Some Title Some stuff
Release date for Apache 2.1 or 2.2
Hi, is there any plan to release Apache 2.1 or 2.2 in the near future or is there a kind of roadmap or something? Bye and thanks, Werner.
Re: ap_max_requests_per_child isn't part of the API, is it?
On Mon, Jun 30, 2003 at 09:25:55AM -0700, Justin Erenkrantz wrote: --On Saturday, June 28, 2003 8:24 AM -0400 Jeff Trawick [EMAIL PROTECTED] wrote: Can anybody agree that something like this is is part of the formal definition of our API? ... +1. -- justin +1 here, also. Altho... I would prefer to see that stuff moved to httpd_private.h and just not include that file into our public docs (nor install it). Cheers, -g -- Greg Stein, http://www.lyra.org/
LimitInternalRecursion for 1.3
Call for votes ;-) There's a patch residing in the 2.0 STATUS file (for some reason), which manages infinite loops of internal redirects and subrequests. It's already acked for 2.0 includsion and it would be nice, if someone could review the 1.3 patch (http://cvs.apache.org/~nd/recursion13.patch) so it can be included in 1.3.28 (missing just one vote). Thanks, nd
RE: cvs commit: httpd-2.0/server core.c request.c
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 3:25 AM striker 2003/06/30 18:25:07 Modified:.Tag: APACHE_2_0_BRANCH CHANGES STATUS include Tag: APACHE_2_0_BRANCH http_core.h modules/http Tag: APACHE_2_0_BRANCH http_request.c server Tag: APACHE_2_0_BRANCH core.c request.c Removed: buildTag: APACHE_2_0_BRANCH httpd_roll_release Whoops! Well, the thing had to go some day, because I don't want someone making the mistake of using it anymore. It wasn't supposed to go in this commit though. Sorry for the noise. Sander
