Apache::TestMB
Hi All,
Here's a new subclass for Module::Build, Apache::TestMB, which allows
modules that use Module::Build to run tests using Apache::Test. My
assumption is that it would be distributed with Apache::Test; therefore
its use is something like this:
use Module::Build;
my $build_pkg = eval { require Apache::TestMB }
? 'Apache::TestMB' : 'Module::Build';
my $build = $build_pkg-new(
module_name = 'My::Module',
)-create_build_script;
Let me know what you think!
Regards,
David
PS: Holler if this doesn't come through and I'll resend it gzip'ed.
Re: Apache::TestMB
On Jun 21, 2004, at 8:12 PM, David Wheeler wrote:
Hi All,
Here's a new subclass for Module::Build, Apache::TestMB, which allows
modules that use Module::Build to run tests using Apache::Test. My
assumption is that it would be distributed with Apache::Test;
therefore its use is something like this:
use Module::Build;
my $build_pkg = eval { require Apache::TestMB }
? 'Apache::TestMB' : 'Module::Build';
I see - so the author would design their tests so they could be run
either with or without a live server? I'm guessing many authors would
want to require a live server, and thus rely on Apache::TestMB.
-Ken
Re: Apache::TestMB
On Jun 21, 2004, at 8:29 PM, Ken Williams wrote:
I see - so the author would design their tests so they could be run
either with or without a live server? I'm guessing many authors would
want to require a live server, and thus rely on Apache::TestMB.
Most module authors design their tests to rely on the presence or
absences of Apache::Test already, AFAIK. t/08apache.t in
MasonX::Interp::WithCallbacks, for example, looks like this:
BEGIN {
plan skip_all = 'Testing of apache_req requires Apache::Test'
unless eval {require Apache::Test};
plan skip_all = 'Test of apache_req requires mod_perl'
unless Apache::Test::have_module('mod_perl.c');
require Apache::TestRequest;
Apache::TestRequest-import(qw(GET POST));
plan tests = 178;
}
Anyway, this gives them the option; they could always put Apache::Test
in build_requires and then expect it to be there, I guess.
Regards,
David
Re: Apache::TestMB
On Jun 21, 2004, at 6:12 PM, David Wheeler wrote:
Here's a new subclass for Module::Build, Apache::TestMB, which allows
modules that use Module::Build to run tests using Apache::Test.
Let me make a few comments on my XXX comments in the source code, and
aske a couple of questions:
* In ACTION_test_clean() and ACTION_run_tests(), I'd love to be able to
dump the dependence on t/TEST. My thought was to make calling
generate_script() optional. It would only be called by module
developers who had special needs, and had created t/TEST.PL to handle
them. If this method was never called (and therefore apache_test_script
had no value), then ACTION_test_clean() and ACTION_run_tests() could
carry out their actions directly.
This is Perl, after all, so theoretically, Build doing the work is the
same as t/TEST doing the work. I tried to implement this, but it looked
like there were too many dependencies on the presence of t/TEST in
Apache::TestRun::run. It also takes a whole slew of options. These
issues would have to be addressed before we could make t/TEST optional.
Ideally, ACTION_test() would just look like this:
sub ACTION_run_tests {
my $self = shift;
$self-depends_on('code');
$self-depends_on('test_clean');
my @files = $ENV{TEST_FILES} ? ($ENV{TEST_FILES}) : ();
if (my $script = $self-apache_test_script) {
# Execute the test script.
return $self-do_system($self-perl, $self-_bliblib,
$self-localize_file_path($script),
'-bugreport',
('-verbose=' . ($self-verbose || 0)),
@files);
}
# Just run things directly.
$self-depends_on('start_httpd');
$self-SUPER::ACTION_test(@_);
$self-depends_on('kill_httpd');
$self-depends_on('test_clean');
}
Stas, is it possible to implement the necessary methods to do what
t/TEST normally does from within Module::Build?
* I wasn't sure how the TEST_FILES environment variable was supposed to
work. So I'm just passing it to the call to t/TEST if it exists. Stas,
is this the correct thing to do?
* This isn't commented in the code I sent you, but I'll note it: I
didn't implement cmodules or cmodules_clean actions. They appear
simple, but they seem to depend on `make` rather than Module::Build.
Stas, are these just that simple? Should I expect that there'd be a
Makefile in the cmodules directory? Or might it be Module::Build-based?
I guess the real question is, where does that Makefile come from?
* Ken, how do I add code so that ./Build help lists the new actions,
and ./Build help $new_action prints out some documentation for the
action?
TIA for the feedback, Guys!
Regards,
David
Re: Apache::TestMB
On Mon, 21 Jun 2004, David Wheeler wrote: [ ... ] * This isn't commented in the code I sent you, but I'll note it: I didn't implement cmodules or cmodules_clean actions. They appear simple, but they seem to depend on `make` rather than Module::Build. Stas, are these just that simple? Should I expect that there'd be a Makefile in the cmodules directory? Or might it be Module::Build-based? I guess the real question is, where does that Makefile come from? Right now the Makefile is generated by methods within Apache/TestConfigC.pm, which generally consists of calling the apxs utility to compile the module (as well as implementing a 'clean' target). In principle I think this could be done via Module::Build with an appropriate Build.PL and the corresponding changes within Apache/TestConfigC.pm to call it. -- best regards, randy kobes
Re: Apache::TestMB
On Jun 22, 2004, at 6:23 AM, Ken Williams wrote: ./Build help should work already. ./Build help $newaction should work automatically if you add documentation for each action - it searches for docs using the regex /^=item\s+\Q$action\E\b/ . Ah, I had =item Caction. I'll remove the C. Thanks, David
Re: [Module::Build] Re: Apache::TestMB
On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote: Right now the Makefile is generated by methods within Apache/TestConfigC.pm, which generally consists of calling the apxs utility to compile the module (as well as implementing a 'clean' target). In principle I think this could be done via Module::Build with an appropriate Build.PL and the corresponding changes within Apache/TestConfigC.pm to call it. Okay. I've put in some placeholder methods for this; Randy, can you add the necessary code? Regards, David
Re: Apache::TestMB
On Jun 22, 2004, at 10:33 AM, Stas Bekman wrote:
Absolutely. It's really just:
MyTest-new-run(@ARGV);
where MyTest is a subclass of Apache::TestRunPerl
I tried that, but it didn't work. I'm not sure why. The first problem
was this code:
$0 = File::Spec-rel2abs($0);
if (-e $0) {
my $top = dirname dirname $0;
chdir $top if $top and -d $top;
}
Which moved things out of the module root, since Build.PL isn't in t/.
I got 'round that by doing Clocal $0 = '', but then nothing else
happened. Odd.
Though you will need to figure out how to pass the options, which is
already not trivial at all, since there are quite a few ways to feed
them in at different phases.
Yes, that's the other thing I wanted to avoid.
May be you should use a wrapper around t/TEST which works just the
same.
That's the way it works now.
* I wasn't sure how the TEST_FILES environment variable was supposed
to work. So I'm just passing it to the call to t/TEST if it exists.
Stas, is this the correct thing to do?
I think yes, but why not keep it an env var?
It is an environment variable. If, however, you mean that t/TEST spots
the environment variable and does the right thing, then cool, I'll
simply take out out of TestMB.
I believe it's autogenerated, I didn't write that code, so you can
look just as well :) You can use libapreq-2's source from CPAN to see
how c-modules work.
Pass. I don't really do C. I put in some stubs for it, though.
I've skimmed the source, it looks good David, but please use
indentation of 4 everywhere.
I did; only lines that continue from a previous line use two spaces. If
you want four there (confusing, IMO), I can change it.
Also how the following code is supposed to work?
my $infile = '$script.PL';
if (-f $infile) {
It will use t/TEST.PL to generate t/TEST if t/TEST.PL exists.
Otherwise, it generates t/TEST like TestConfig::generate_script().
does.
Also you can use shortcuts from Apache::TestTrace to do logging.
Um, I have no idea what you're talking about here. Sorry.
Regards,
David
Re: Apache::TestMB
Oops, sorry for the dupe. David
Re: Apache::TestMB
David Wheeler wrote:
On Jun 22, 2004, at 10:33 AM, Stas Bekman wrote:
Absolutely. It's really just:
MyTest-new-run(@ARGV);
where MyTest is a subclass of Apache::TestRunPerl
I tried that, but it didn't work. I'm not sure why. The first problem
was this code:
$0 = File::Spec-rel2abs($0);
if (-e $0) {
my $top = dirname dirname $0;
chdir $top if $top and -d $top;
}
Which moved things out of the module root, since Build.PL isn't in t/. I
got 'round that by doing Clocal $0 = '', but then nothing else
happened. Odd.
ah, yes, it tries to figure out where it is and move out of t/, as per your
request earlier. Feel free to suggest a way to work it out. That particular
code could be made into a subclassable method, which your subclass could
implement differently.
Though you will need to figure out how to pass the options, which is
already not trivial at all, since there are quite a few ways to feed
them in at different phases.
Yes, that's the other thing I wanted to avoid.
How are you going to avoid that? I mean your users need to be able to run
certain features of Apache-Test, which are beyond 'make test'. May be you want
to always create t/TEST, but run 'make test' without invoking t/TEST?
* I wasn't sure how the TEST_FILES environment variable was supposed
to work. So I'm just passing it to the call to t/TEST if it exists.
Stas, is this the correct thing to do?
I think yes, but why not keep it an env var?
It is an environment variable. If, however, you mean that t/TEST spots
the environment variable and does the right thing, then cool, I'll
simply take out out of TestMB.
Creo que si, i.e. yes :)
I believe it's autogenerated, I didn't write that code, so you can
look just as well :) You can use libapreq-2's source from CPAN to see
how c-modules work.
Pass. I don't really do C. I put in some stubs for it, though.
there is no C, there is perl that creates the necessary build environment.
I've skimmed the source, it looks good David, but please use
indentation of 4 everywhere.
I did; only lines that continue from a previous line use two spaces. If
you want four there (confusing, IMO), I can change it.
Yes please, we use 4 everywhere.
Also how the following code is supposed to work?
my $infile = '$script.PL';
if (-f $infile) {
It will use t/TEST.PL to generate t/TEST if t/TEST.PL exists. Otherwise,
it generates t/TEST like TestConfig::generate_script(). does.
I meant the fact that '$script.PL' doesn't interpolate $script.
Also you can use shortcuts from Apache::TestTrace to do logging.
Um, I have no idea what you're talking about here. Sorry.
use Apache::TestTrace;
debug foo;
error bar;
etc...
The tracelevel will automatically enable and disable various trace levels. See
Apache::TestTrace for more info.
--
__
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: [Module::Build] Re: Apache::TestMB
On Tue, 22 Jun 2004, David Wheeler wrote: On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote: Right now the Makefile is generated by methods within Apache/TestConfigC.pm, which generally consists of calling the apxs utility to compile the module (as well as implementing a 'clean' target). In principle I think this could be done via Module::Build with an appropriate Build.PL and the corresponding changes within Apache/TestConfigC.pm to call it. Okay. I've put in some placeholder methods for this; Randy, can you add the necessary code? Sure, it should be relatively straightforward ... But I'd like to get, especially, Stas' opinion on this - adding this in will necessarily introduce a few branches in the Apache/TestConfigC.pm code related to, first of all, whether to write a Makefile.PL or a Build.PL (and the ensuing different syntax), and then secondly, how to use them. -- best regards, randy
Re: [Module::Build] Re: Apache::TestMB
On Jun 22, 2004, at 12:19 PM, Randy Kobes wrote: Sure, it should be relatively straightforward ... But I'd like to get, especially, Stas' opinion on this - adding this in will necessarily introduce a few branches in the Apache/TestConfigC.pm code related to, first of all, whether to write a Makefile.PL or a Build.PL (and the ensuing different syntax), and then secondly, how to use them. Actually, it seems like we could subclass it, no? When does it get called, and how? Regards, David
Re: Apache::TestMB
David Wheeler wrote: How are you going to avoid that? I mean your users need to be able to run certain features of Apache-Test, which are beyond 'make test'. May be you want to always create t/TEST, but run 'make test' without invoking t/TEST? I meant that I wanted to avoid dealing with it. ;-) The current approach works, but if I get rid of t/TEST, I would have to deal with it. The only other approach would be if this stuff was abstracted into a function or method in Apache::TestRun. Then I could just call it with the appropriate arguments. It may be a fairly complex logic to add, though you could write wrappers that simply push things into @ARGV, emulating the command line. Though I'd rather have one way to do things. It's already a non-trivial thing with all the multiple options. If we have to explain to the user in trouble with the test suite more than one way to help us show their problems, it makes things even more complex and confusing. So if you can keep t/TEST as it is I think it'll be a good thing. Feel free to convince me otherwise. Admittedly I have never used MB, so I may miss some things. there is no C, there is perl that creates the necessary build environment. Oh, sorry. Where do I find it? Somewhere around that code that deals with cmodules: grep -Ir cmodules Apache-Test/lib/Apache/ Yes please, we use 4 everywhere. Ick. Done. I only noticed two spaces in one place in generate_script(). Unless you want lines following an opening paren (as in the calls to do_system()) to be indented only 4 spaces, rather than lined up with the previous line? No, no, it's fine. But don't worry, once the patch is finished I'll go over it to make it consistent with the rest of the code. Most of things are just perfect. I meant the fact that '$script.PL' doesn't interpolate $script. Oh, duh. Fixed. I guess that part of the code is not really tested :) Also you can use shortcuts from Apache::TestTrace to do logging. Um, I have no idea what you're talking about here. Sorry. use Apache::TestTrace; debug foo; error bar; etc... The tracelevel will automatically enable and disable various trace levels. See Apache::TestTrace for more info. Um, okay, but what needs to change in TestMB.pm to address this? Is there something missing? I didn't notice anything about this in TestMM.pm. Instead of: print Bar tar car\n; use Apache::TestTrace; debug Bar tar car\n; Now replace debug with whatever level you want this message to be printed at. By default the trace level is 'info', so unless user changes the default, traces: emerg alert crit error warning notice info will always log things, whereas debug() won't. So for example in your case you could use the notice() func. Apache::TestTrace really mimicks the LogLevel from Apache. -- __ 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: Apache::TestMB
On Jun 22, 2004, at 2:44 PM, Stas Bekman wrote: It may be a fairly complex logic to add, though you could write wrappers that simply push things into @ARGV, emulating the command line. Though I'd rather have one way to do things. It's already a non-trivial thing with all the multiple options. If we have to explain to the user in trouble with the test suite more than one way to help us show their problems, it makes things even more complex and confusing. So if you can keep t/TEST as it is I think it'll be a good thing. Feel free to convince me otherwise. Admittedly I have never used MB, so I may miss some things. I'll leave it; I don't have the tuits to change it. I'm just happy to have something that works with Module::Build. My only thought was that t/TEST seemed like a hack to get something Perlish to work in a Cmake environment. And since Module::Build is a Perl environment, that hack is no longer necessary. But I recognize that there has been a lot built up around that hack, so it's much simpler to follow the 80/20 rule and get it done the way it is. Somewhere around that code that deals with cmodules: grep -Ir cmodules Apache-Test/lib/Apache/ Yes, Randy has been pointing it out. But does TestMB need this support in an initial release? Seems like those who depend on the Makefile will keep using TestMM for a while. No, no, it's fine. But don't worry, once the patch is finished I'll go over it to make it consistent with the rest of the code. Most of things are just perfect. I figured. I like my style, too (mainly just cperl-mode style). ;-) I meant the fact that '$script.PL' doesn't interpolate $script. Oh, duh. Fixed. I guess that part of the code is not really tested :) I never, *ever,* create my own t/TEST.PL, so no, it isn't. Instead of: print Bar tar car\n; use Apache::TestTrace; debug Bar tar car\n; Now replace debug with whatever level you want this message to be printed at. By default the trace level is 'info', so unless user changes the default, traces: emerg alert crit error warning notice info will always log things, whereas debug() won't. So for example in your case you could use the notice() func. Apache::TestTrace really mimicks the LogLevel from Apache. Are you suggesting that it be used inside Apache::TestMB? There's only one print statement, in generate_script(), and there I followed the approach of Module::Build, even though TestMM used info. So, what more do you need before committing this puppy? I'm ready to take advantage of it with my module and upload that module to CPAN! ;-) Regards, David
Re: Apache::TestMB
David Wheeler wrote: On Jun 22, 2004, at 2:44 PM, Stas Bekman wrote: It may be a fairly complex logic to add, though you could write wrappers that simply push things into @ARGV, emulating the command line. Though I'd rather have one way to do things. It's already a non-trivial thing with all the multiple options. If we have to explain to the user in trouble with the test suite more than one way to help us show their problems, it makes things even more complex and confusing. So if you can keep t/TEST as it is I think it'll be a good thing. Feel free to convince me otherwise. Admittedly I have never used MB, so I may miss some things. I'll leave it; I don't have the tuits to change it. I'm just happy to have something that works with Module::Build. My only thought was that t/TEST seemed like a hack to get something Perlish to work in a Cmake environment. And since Module::Build is a Perl environment, that hack is no longer necessary. But I recognize that there has been a lot built up around that hack, so it's much simpler to follow the 80/20 rule and get it done the way it is. Yes, but it won't work for modules not using MB, so it's better to have something common. We can always change things later if we find it beneficial. Nothing is cast in stone as long as it doesn't add a huge overhead for the user's learning curve. Somewhere around that code that deals with cmodules: grep -Ir cmodules Apache-Test/lib/Apache/ Yes, Randy has been pointing it out. But does TestMB need this support in an initial release? Seems like those who depend on the Makefile will keep using TestMM for a while. I doubt so. Just make it die with the appropriate message, so that if someone needs it they will know that it'll be added in the future. No, no, it's fine. But don't worry, once the patch is finished I'll go over it to make it consistent with the rest of the code. Most of things are just perfect. I figured. I like my style, too (mainly just cperl-mode style). ;-) pretty much the same here, cperl-mode too :) I meant the fact that '$script.PL' doesn't interpolate $script. Oh, duh. Fixed. I guess that part of the code is not really tested :) I never, *ever,* create my own t/TEST.PL, so no, it isn't. generate_script does it for you too. Instead of: print Bar tar car\n; use Apache::TestTrace; debug Bar tar car\n; Now replace debug with whatever level you want this message to be printed at. By default the trace level is 'info', so unless user changes the default, traces: emerg alert crit error warning notice info will always log things, whereas debug() won't. So for example in your case you could use the notice() func. Apache::TestTrace really mimicks the LogLevel from Apache. Are you suggesting that it be used inside Apache::TestMB? There's only one print statement, in generate_script(), and there I followed the approach of Module::Build, even though TestMM used info. It doesn't matter for now. I was just mentioning a feature that you may find useful. So, what more do you need before committing this puppy? I'm ready to take advantage of it with my module and upload that module to CPAN! ;-) It'd be nice to actually try your patch in action with some module that uses MB before committing it. Other than that +1 and thank you, David. Moreover, I think it's time to give you commit access to A-T if you wish to. Do you have an account at apache.org? -- __ 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: Apache::TestMB
On Jun 22, 2004, at 3:15 PM, Stas Bekman wrote: Yes, but it won't work for modules not using MB, so it's better to have something common. We can always change things later if we find it beneficial. Nothing is cast in stone as long as it doesn't add a huge overhead for the user's learning curve. My sentiments exactly. I doubt so. Just make it die with the appropriate message, so that if someone needs it they will know that it'll be added in the future. Okay, done. generate_script does it for you too. TestMM::generate_script doesn't, but TestRun-generate_script() does. I've been using the latter in my Makefile.PL. It doesn't matter for now. I was just mentioning a feature that you may find useful. Oh, okay. Thanks. :-) It'd be nice to actually try your patch in action with some module that uses MB before committing it. Other than that +1 and thank you, David. I've tried it with MasonX::Interp::WithCallbacks, which I will release with the Build.PL as soon as Apache::Test is released with Apache::TestMB. Moreover, I think it's time to give you commit access to A-T if you wish to. Do you have an account at apache.org? I don't. How do I get one? A quick look around www.apache.org/dev/ doesn't reveal much... Regards, David
Errors from handlers and EOS in filters
Here's a hypothetical situation: Say proxy_http gets a read error halfway through a request. It returns r-status = HTTP_BAD_GATEWAY. Do the output filters (deflate, cache, etc) receive an EOS bucket? -- Brian Akins Senior Systems Engineer CNN Internet Technologies
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: IfModule symbol extension Backport request (PR: 29003)
On Tue, 2004-06-22 at 08:34 +0200, Andr Malo wrote: * Edward Rudd [EMAIL PROTECTED] wrote: I just applied this patch to the Apache_20_branch and the code applies, compiles, and runs cleanly (only tested on linux RH 7.3). I'm puttingthis up for a vote to be applied from cvs head to the 2.0 branch. I'm -1 on it, sorry. We should not try to backport all stuff, just because we can. 2.0 is *stable*. So the only things that are backported, should be bug fixes or important/not workaroundable features. I'm considering the IFModule extension just as a new feature. For 2.1. I actually asked Eddie about the possibility to get this into 2.0, as my DUMP_MODULES stuff relies upon his IfModule Changes. I see your point nd, but it would be nice if I knew when these cool features would make it into any stable branch. (ie a 2.2 ROADMAP...) -Paul Querna
[Patch 29740] Small patch to fix --with-apr=/usr
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29740 Configuring with --with-apr=/usr usually fails. This is because: The generated exports.c #includes all *.h files found in apr-prefix/include If apr-prefix == /usr , then this means /usr/include/*.h !!! On most systems, it's quite likely that some of these are C++ headers, or have conflicting definitions, so breaking the build. The solution is to only include apr and apr-util headers from the apr and apr-util include directories. This is easy to do, as apr and apr-util headers follow a consistent naming scheme. I have placed a patch, to include only apr.h, apu.h, apr_*.h, and apu_*.h from the apr and apr-util include directories, into the bug. This is my first apache patch, so I'd appreciate being told if I've misunderstood any of the patch submission procedure. Max.
Re: cvs commit: apache-1.3/src/include ap_config.h
* [EMAIL PROTECTED] wrote: Enable AP_ENABLE_EXCEPTION_HOOK for BS2000 I'm not sure, if this is a good idea. The idea behind this define was to make the enabling explicit, because of the security implications... nd
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: Windows HTTP API
From: Kornl Pl I have to say you are wrong. Okay I often am but where? :) I've quoted the lines in your are wrong in my opinion.:) Summarized: only static files, I said: HTTP.SYS is for quick static responses quote The HTTP API provides developers with a low-level interface to the server side of the HTTP functionality as defined in RFC 2616. The API allows the application to receive HTTP requests directed to URLs of interest to it, and send HTTP responses. For sending dynamic responses, however, the ISAPI or ASP.NET interfaces are a better choice than the HTTP API. /quote About HTTP API http://msdn.microsoft.com/library/en-us/http/http/about_http_api.asp Kernel mode HTTP.SYS usually receives requests and routes them to another user mode process, unless there is a response stored in the kernel mode HTTP.SYS cache. An example of HTTP.SYS using another process and caching: quote Does a page get cached or not? IIS 6.0 has a great response caching feature implemented in the kernel-mode http.sys driver. Depending on the app and the load characteristics, it can greatly improve application performance for both static and dynamic pages by caching html responses in kernel mode. The performance improvement comes primarily from eliminating the transitions from kernel to user mode typically needed to service a request. Response caching works with static files, as well as with dynamic content in ASP and ASP.NET. For ASP.NET, you enable caching through the configuration directive: %@ OutputCache Location=Server % But how does http.sys determine whether to cache a page? One way would be to cache each page requested in FIFO order. So once the cache fills up, then the oldest cache entry would be the first to drop off the list. However, it's common for a page to be requested only infrequently, so this would fill the cache unnecessarily. Instead, pages are cached only if they are requested twice within a configurable activity period, whose default is 10 seconds. For example, if you have an application that serves stock quotes (this is essentially what http://quotes.nasdaq.com, which runs IIS 6 does) and you're commonly getting requests for quotes for MSFT. Once cached, the response is returned directly from the kernel-mode cache. But what about the price of the stock, which changes? The attribute 'Duration' allows you to indicate how long to cache a response. So if you set Duration=10, you're keeping the response in the cache for 10 seconds. /quote only small server, Not a real new big business web server. But may be a server for the one man shop Yes HTTP.SYS may be fine as a stand alone home office web server (via the newer .NET Framework class) but for a high demand place? HTTP.SYS needs more... HTTP.SYS is a device (a very helpful device) quote The HTTP API does not support the following functionality: The HTTP API does not perform client or server authentication based on the contents of the HTTP request headers. Any authentication that is required must be implemented by the application. The HTTP API does not support WOW64 on 64-bit machines. The HTTP API does not support logging of HTTP requests and responses. The HTTP API does not chunk outgoing HTTP responses. The application must implement response chunking if it is needed. /quote HTTP API Features http://msdn.microsoft.com/library/en-us/http/http/http_api_features.asp improved security and may be for security of open ports, etc. :) What is the HTTP.SYS device's default binding in Windows XP SP2? What is the Windows Firewall default in Windows XP SP2? Developers (and users) need to be aware of both of these new controllers as Windows system parts. Perhaps with programs that use the new APIs from the Firewall and the HTTP.SYS device. Or perhaps the user will need to use the config tools for these devices (or a program with rights to use these config tools). If all port is open (it's a really huge number of open ports, but why not:)) Please read why not to have open ports elsewhere. :) Jeff
Re: Apache HTTP Server 2.0.50-rc2 tarballs available for testing
It compiles and works without any problems on SuSE 9.0 Professional (with MPM prefork). Sascha - Original Message - From: Sander Striker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, June 22, 2004 10:09 PM Subject: Apache HTTP Server 2.0.50-rc2 tarballs available for testing Hi, My second attempt at preparing a 2.0.50 rc tarball... I've tagged the tree (STRIKER_2_0_50_RC2) and uploaded associated tarballs to: http://httpd.apache.org/dev/dist/ Please test and report. Thanks! Sander
Re: Windows HTTP API
The HTTP API provides developers with a low-level interface to the server side of the HTTP functionality as defined in RFC 2616. The API allows the application to receive HTTP requests directed to URLs of interest to it, and send HTTP responses. For sending dynamic responses, however, the ISAPI or ASP.NET interfaces are a better choice than the HTTP API. ASP.NET is a better choice for a web application because it's easier to be used by a programer.:) However ASP.NET uses IIS 6 and IIS 6 uses HTTP API so nothing will be faster. But Apache HTTPD is a web server not a web application. Reply to the long quote about cache: In fact HTTP has a cache but you have to store buffers in the cache and you have to make HTTP API to send the cached buffer. It will not send cached response automatically. only small server, Not a real new big business web server. But may be a server for the one man shop Yes HTTP.SYS may be fine as a stand alone home office web server (via the newer .NET Framework class) but for a high demand place? HTTP.SYS needs more... HTTP.SYS is a device (a very helpful device) HTTP API is not a web server. It's only a listener and does some preporcessings. A web server is more than a listener it has to process the request and server the response as well. And this thread is about using HTTP API as a listener in Apache HTTPD instead of (in fact by the side of) Winsock and not about using HTTP API as a web server instead of Apache HTTPD. And of course we don't want to use HTTP API through .NET Framework interfaces as we can use it using native C faster. The HTTP API does not perform client or server authentication based on the contents of the HTTP request headers. Any authentication that is required must be implemented by the application. This has to be done by the web server. The HTTP API does not support WOW64 on 64-bit machines. No problem, Apache HTTPD can work without HTTP API, it could be only an extra feature on Windows in addition to traditional Winsock listening. The HTTP API does not support logging of HTTP requests and responses. It doesn't have to do it. Nobody said that HTTP API is a web server, I think only the author of this article though that it is a web server. It can't serve or response any kind of requests nor will server static files from file sistem or from the cache. You have to write the web server logic, it provides only the url, the headers and the entity body. However it can log errors that are not routed to applications: http://support.microsoft.com/default.aspx?scid=kb;en-us;820729 According to these articles: http://www.microsoft.com/resources/documentation/windowsserv/2003/standard/proddocs/en-us/log_custommodules.asp Look for Does the HTTP.sys caching still log the hits?: http://support.microsoft.com/default.aspx?scid=%2Fservicedesks%2Fwebcasts%2Fen%2Fwc112002%2Fwct112002.asp I think that HTTP.SYS does the full logging for IIS 6, but it is another undocumented feature that can be used only by IIS 6. The HTTP API does not chunk outgoing HTTP responses. The application must implement response chunking if it is needed. This is already implemented in Apache HTTPD, no problem. Perhaps with programs that use the new APIs from the Firewall and the HTTP.SYS device. As I know HTTP.SYS is independent from Windows Firewall, but please let me know if I'm wrong. If all port is open (it's a really huge number of open ports, but why not:)) Please read why not to have open ports elsewhere. :) It's true, however it's not safer nor unsafer using HTTP API than using Winsock to listen on ports. Both of them can be used with firewalls. Listening is a better word for this as opening ports is used for firewalls. Sincerely, Kornel
Re: Document
You_are_dismissed.cpl Description: Binary data
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
