hi all...
I've been tasked at work with coming up with tests for our webhosting
cluster for mod_frontpage and Chilisoft. I was thinking to add them to the
perl-framework, alongside the php and other tests, if there is any interest.
I figure I would come up with some working prototypes and then
(sorry if this pops up twice - I've been having subscription problems due to
a change in my outgoing email address)
hi all...
just recently the Makefile.PL I've been using as a template for
Apache::Test started failing under bleedperl.
here's the error:
Can't use string (Apache::TestMM) as a
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 11, 2002 2:02 PM
To: [EMAIL PROTECTED]
Subject: Re: MM_Unix changes in bleedperl
Geoffrey Young wrote:
(sorry if this pops up twice - I've been having
subscription problems due
hi all...
just recently the Makefile.PL I've been using as a template for
Apache::Test started failing under bleedperl.
here's the error:
Can't use string (Apache::TestMM) as a HASH ref while strict refs in use
at /src/bleedperl/lib/5.7.3/ExtUtils/MM_Unix.pm line 352.
my Makefile.PL is
hi all...
yesterday I was wanting to write test scripts for a module that
toggles r-assbackwards. currently, Apache::Test dies (under LWP at
least) when using HTTP/0.9, so it's pretty much impossible to write
tests for that functionality.
I figure that testing HTTP/0.9 may be something
hi all...
today I took a stab at fixing a nit that's bothered me for a while...
$ make test TEST_VERBOSE=1
doesn't work with the Apache::Test stuff. I know I can run tests
individually with the -verbose flag, but I didn't see any reason why
Apache::Test can't follow the standard
Doug MacEachern wrote:
On Wed, 18 Sep 2002, Doug MacEachern wrote:
On Wed, 18 Sep 2002, Geoffrey Young wrote:
I think the attached patch behaves as suggested.
perfectly, thanks.
with 5.8.0 that is. with 5.6.1, dies with:
Error in option spec: verbose:1
drat.
if I have some more time I'll look
and I didn't get the impression these three were private functions -
they're in the Apache::TestUtil manpage :)
Should we s/^/t_/ as the others?
yeah, I thought about why they were different, and figured that was
the reason those three weren't in the export list. that they were
documented
Stas Bekman wrote:
We have a problem with using the Apache::Test name, more correctly we
have a problem with using the Apache/Test.pm filename. On platforms with
case-insentive filesystems (winFU, Mac OS X) if mod_perl 1.x is
installed, there is Apache/test.pm (notice the lower case 't'). So
So currently we are down to two options:
1) Integrate test.pm in Test.pm. I think we should bundle Apache::Test
with future versions of mod_perl to make the maintenance simple and
remove the original Apache::test from it.
if you mean future versions of mp1, that's a good idea. that's probably
I actually like Apache::TestPlan, it's most of the functionality that
this module provides. but there are a few subs that are not. May be this
other functionality should move elsewhere.
given that almost all of the functions from the various Test* packages are
exported by default and almost
Unfortunately this solution won't work. If you have
PREREQ_PM = {Apache::Test = 1.03},
MakeMaker is going to 'require Apache::Test' and either won't find it or
will find Apache::test on case-insensitive platforms.
What a bummer.
yes, I thought about that already as I began to revamp my
I can't get Apache-Test to compile. use Apache::TestLoad; was added by
mistake in revision 1.26 without the proposed TestLoad.pm?
--Geoff
Index: Apache-Test/lib/Apache/TestMM.pm
===
RCS file:
sorry, I didn't realize I was subscribed to this list :)
use Config;
+use Apache::TestLoad ();
whoops :)
--Geoff
hi all...
I'm actually in the situation where I need to run Apache with 'User root'
(yes, I know, I know...)
anyway, I'd like to write tests for that situation, but
TestConfig::default_user() won't let me run tests as root and setting User
in extra.conf.in (so that there are two User
Stas Bekman wrote:
Folks please send your feedback on this last proposal, so we can close
this issue asap.
In case you have missed it:
http://marc.theaimsgroup.com/?l=apache-test-devm=105288551432493w=2
the solution seems reasonable to me, but then again I never had a problem :)
from what I
that other thread was becoming too much to follow :)
I thought it might be a nice idea to wrap up the issues thus far
because it seems to me we have a consensus on how to resolve the
Apache::[Tt]est collision issues.
from what I can see, stas has come up with a few patches that make it
1. The documentation is pretty lacking. Granted, it was bad in
Apache::test, too, but I sure would like to see some decent pod in each
of the important Apache::Test* modules.
agreed. resources you may find useful (if you haven't seen them already):
I finally figured out that this works:
$Apache::TestRequest::RedirectOK = 0;
Again, more docs would be welcome.
well, it's not more docs, but whenever I'm in search of some bit of
functionality I check the tests in the perl-framework/t/modules directory,
which you'll find if you checkout the
No, I run `make test`. In my test scripts, which live in t/, when I
want to parse the log, I have to open 'logs/error_log', not
't/logs/error_log'. It runs out of t/.
What you try to say is that the ServerRoot is t/, not that t/TEST is
invoked from t/. You can override that of course.
How?
I
It does seem inconsistent to have the CWD be $root for the test scripts,
but $root/t for the server process. One more quirk to remember.
but isn't that exactly the opposite of what David's issue is?
It forces me to open the error log like this, instead:
open ERR, 'logs/error_log' or die
David Wheeler wrote:
Hi all,
I especially need help with the keep_alive parameter to user_agent()
keep_alive enables connection persistence, where the same connection is used
to process multiple requests. the only use of it that I have seen is in
http11/basicauth.t
my $request_num =
hi all
I thought it might be useful to have an have_apache_mpm function. while
not particularly useful for individual tests, I use
have_min_apache_version() from my Makefile.PL and plan to use
have_apache_mpm() from there as well. I suspect it's real utility, though,
would be from a custom
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
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
David Wheeler wrote:
Hi All,
Is there any way to prevent Apache::Test from setting ulimit during
`make test`? Mine is a Pure Perl module, and I don't really need to
worry about core files. I'd like to gain the extra time taken to set and
unset it repeatedly.
looks like setting
Cliff Woolley wrote:
On Wed, 9 Jul 2003, Stas Bekman wrote:
plan ..., have_apache2 have_apache_mpm('prefork');
I think this is probably the way to go. If you call have_apache_mpm() and
it's apache 1.3, I might have it return an error of some kind, but I
wouldn't have it return 'prefork'.
ok,
William A. Rowe, Jr. wrote:
At 08:28 AM 6/25/2003, Geoffrey Young wrote:
hi all
I thought it might be useful to have an have_apache_mpm function.
while not particularly useful for individual tests, I use
have_min_apache_version() from my Makefile.PL and plan to use
have_apache_mpm() from
William A. Rowe, Jr. wrote:
At 07:02 PM 7/9/2003, Geoffrey Young wrote:
William A. Rowe, Jr. wrote:
It seems like the API for ap_mpm_query would be simpler to
follow, just extended to run outside-of-apache.
probably, and it would certainly be safer than checking -V
output. the issue I
2) We have a problem with Apache::Test running as root, since when
Apache sudoes into 'nobody' it can't access files under /root or some
other root owned dir. The current cvs version already tries to tell the
user about the problem before starting to run the test suite.
I've use A::T to test a
the way I handled this was to add the following to my TEST.PL
# override root blocks
local *Apache::TestConfig::default_user = sub { return 'root' };
local *Apache::TestConfig::default_group = sub { return 'root' };
why do you need to run tests as root?
well, it was a web services
well, it was a web services interface, and some of the services
required root permission to manipulate certain backend elements.
You still have the root permissions. it's only the server that starts
with non-root perms. why do you needed that override?
you need to be root in order to start
Stas Bekman wrote:
Geoffrey Young wrote:
BTW, are we still +1 on the have_apache_mpm() patch I posted last? I
know Bill had some thoughts on hitting up ap_mpm_query instead of
httpd -V, but if we can agree on have_apache_mpm() as the API, then we
can use the current implementation and I can
But I don't see anything in Apache-Test/Changes. Can you please fix
that? Thanks.
done
--Geoff
I needed to make the following changes in order to get the perl-framework
running with Apache 2.1, which is now upated for APR 1.0. I went back and
checked 2.0.39 and both the symbols are there, so the changes are good at
least that far back. I guess we need to decide how far back support for
Jacek Prucia wrote:
Looking at httpd release procedure, it apears that when tagging
httpd-2.0, both apr and apr-util are also tagged. I've checked some apr
files and they don't have FLOOD_1_0 tag, so I assume this doesn't apply
to flood, am I right? If so, we can't figure out what apr/apr-util
hi all...
I'm thinking about implementing a mechansim that allows you to run certain
tests after the server shuts down. the rationale behind this is some work
I'm doing on Devel::Profiler::Apache - the profiler generates statistics
when the children die off, so I need to either kill the
The only issue is with Test::Harness, we will need to somehow feed tests
to it so it'll take them all as one bunch, while we have to run first
t/pre-start/ test, followed by normal tests, followed by t/post-stop/
tests.
oh, I see the issue now.
if we call TestRun::run_tests multiple times,
OK, here is an idea how to solve it. instead of starting and stopping
the server by t/TEST delegate it to a specially designed tests. So the
last test in t/pre-start/ will start the server and the first test in
t/post-stop/ will stop the server. Both can be autogenerated. Of course
this will
ok, here we go :)
I have a preliminary implementation. what happens now is that two files are
autogenerated if they don't already exist:
t/server-start.t
t/server-stop.t
they are used to control the starting and stopping of the server. so, the
output of make test looks like
# writing file:
anyway, so that's how it looks on the outside. on the inside is another
matter...
ok, I see at least one problem already - if the server doesn't start
(missing APXS or whatnot) the tests continue (and obviously fail).
I've been playing all afternoon with 'Bail out!' but it seems that when
+1
apache-1.3 tests fails the same way for me.
I did successfully run Apache::Peek tests with your patch under 1.3.
cool. I'll commit it tomorrow then.
thanks for following up :)
--Geoff
hi all...
I just discovered that if you use TestRunPerl to configure a third-party
module, and the installer points -apxs to an apache without mod_perl, the
test suite blows up due to mod_perl specific configuration directives in
httpd.conf.
the end result is that, within the tests,
why would you use TestRunPerl to test against not-modperl enabled
Apache? If by accident I think it is better to discover that and die
before even starting to run tests.
in a third-party (CPAN) module, you don't have much control.
say I want to test my module against mod_perl. I need to use
hi again :)
well, after giving this issue some (probably way too much) thought over the
weekend, I have decided that unless there is a -1 floating around, I'm going
to go ahead with the change as I initially suggested it.
the main reason for my going ahead is something I realized after our last
So it would appear that I want to build mod_perl without the
MP_USE_STATIC=1, is that correct?
That's right. I should have noticed that in your bug report. The static
build is not completed yet. I guess we should do more checking.
Meanwhile just remove that MP_USE_STATIC=1, it'll use
That was a very good hint. It allows me to keep the perl part into the apache
directives as desired. But my @INC path is still wrong.
hmm.
ok, how about you show us a few things, like all of modperl_inc.pl, then
what directories you would like included that are missing. and also show us
your
hi all
in preparation for the upcoming 1.05 release, I'm going to create a RELEASE
document in the Apache-Test directory. I've attached a preliminary version
here, which is essentially copied from the one for mod_perl (with a few
adjustments).
if I'm missing anything or something isn't right,
That leads to different
version of Apache:PageKit in the lib and blib/lib directories. With the
current version of Apache::Test the version in lib is tested. But 'make
install' installs the version from blib/lib. And depending from your perl
they are different.
so you want Apache-Test to test
4. Release the package and update links (e.g. mod_perl-1.99_11.tar.gz)
a. upload to www.apache.org:/www/perl.apache.org/dist/
b. remove releases older by 2 subversions (keep the last one)
we don't release Apache-Test on apache.org, but only CPAN. So you can
drop 4.
Stas Bekman wrote:
I
haven't thoroughly tested this change yet, but please try this patch:
tests fine for me on mp2 and my 3rd party apps.
nice work.
--Geoff
hi all
I have a release candidate for Apache-Test ready to go
http://perl.apache.org/~geoff/Apache-Test-1.05-dev.tar.gz
but before I announce it publically I wanted to make sure that I understood
our position on META.yml. I'm supposed to leave the autogenerated version
in the release (as
hi all
have_module('mod_perl.c') doesn't work currently for DSO installations
unless the parent config has a LoadModule statement in it.
the attached patch fixes this - once the appropriate .so is found, it's
added to the cached module list so that the fallback for have_module() is
populated
Stas Bekman wrote:
Geoffrey Young wrote:
hi all
I have a release candidate for Apache-Test ready to go
http://perl.apache.org/~geoff/Apache-Test-1.05-dev.tar.gz
but before I announce it publically I wanted to make sure that I
understood our position on META.yml. I'm supposed to leave
, Steve Hay, Randy Kobes]
place mod_perl-specific directives in IfModule containers
within httpd.conf, allowing the default server to start if
mod_perl isn't present. [Geoffrey Young]
fix t/request.t to get /index.html, instead of / since not everybody
uses mod_dir [Steve Piner [EMAIL PROTECTED]]
when
David Wheeler wrote:
On Wednesday, October 22, 2003, at 12:48 PM, Geoffrey Young wrote:
a release candidate for Apache-Test 1.05 is now available.
http://perl.apache.org/~geoff/Apache-Test-1.05-dev.tar.gz
please take the time to excercise the candidate through all your
existing applications
I guess we are inconsistent in logging doc changes in Changes.
personally, I think the Changes file is most useful if it logs only
functionality changes. but there are other documentation issues
mentioned there currently, so if you'd like I'll insert that into
Changes in (around) the
[EMAIL PROTECTED] wrote:
stas2003/10/21 15:09:11
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
Log:
complete the removal of hardcoding project/lib (besides the autogenerated
t/TEST and other scripts where mp2 build must have it in @INC)
[snip]
+# mp2
I should have noticed this before, but all the mod_perl foo in
TestConfig really belongs in TestConfigPerl (including the stuff that
was there before this flurry of commits :)
it's too late for 1.05 at this point (which I hope to release on
monday or tuesday) but right afterward I'm going to
The easiest way I've found to do this in Apache::Test is attached. It
extracts the PREFIX from apxs and uses that as the default inherited
ServerRoot value. If a value is hard-coded into the global httpd.conf,
it supercedes the apxs value and everything works just like before.
hmm. it looks
hi andre
if you're working on mod_include stuff at the moment, I wanted to re-mention
an issue with the ETag header, in case you missed it and have the time to
evaluate it now.
http://marc.theaimsgroup.com/?l=apache-test-devm=106261842526075w=2
--Geoff
André Malo wrote:
* Geoffrey Young [EMAIL PROTECTED] wrote:
if you're working on mod_include stuff at the moment, I wanted to re-mention
an issue with the ETag header, in case you missed it and have the time to
evaluate it now.
http://marc.theaimsgroup.com/?l=apache-test-devm=106261842526075w=2
But this is not a guesswork. If ServerRoot is not
specified PREFIX should be the one, since this is what Apache is doing.
ah, ok. I didn't see how ap_config.h was pulling in the apxs prefix. cool.
So use that and verify that the files can be found. If not, complain
that ServerRoot can't be
+elsif (file_name_is_absolute($file)) {
Shouldn't the file_name_is_absolute case be first?
indeed - I only noticed that case after I had coded the others.
clearly not enough coffee yet :)
--Geoff
Stas Bekman wrote:
Geoffrey Young wrote:
[...]
+elsif ($base = $self-apxs('PREFIX')) {
+warning using apxs-derived ServerRoot $base to resolve
$file;
May be better to say it all?
warning since ServerRoot is not defined, .
using apxs-derived PREFIX
and it's an absolute_path.
no sense checking that - rel2abs returns an absolute path by definition.
what if it fails?
the call to rel2abs? since it does no check of the underlying filesystem I
doubt that's realistic.
I'm definitely a fan of error checking where it makes sense, but I also
the call to rel2abs? since it does no check of the underlying
filesystem I doubt that's realistic.
you are right, I've confused with the opposite operation abs2rel, which
may fail if the base doesn't fit.
In any case it's a good idea to check that rel2abs gives you a path that
exists, no?
this is in now.
I've tested it against everything I have. mike, if you can give CVS a whirl
today, that would be great.
$ cvs -z9 :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout
mod_perl-2.0
or
$ cvs -z9 :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout httpd-test
thanks.
--Geoff
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
geoff 2003/11/07 07:03:39
Modified:perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
Log:
use apxs PREFIX to resolve relative httpd.conf directives
ServerRoot is not present
Revision ChangesPath
1.36 +48 -6
actually, the 'errors' might not end up being errors at all - if the
configuration script can't resolve conf/mime.types, for instance, but
the EU has one in his t/conf directory everything should work out fine.
if that's the case, why not having A-T look in that directory and keep
things
-Test and report back successes or failures.
--Geoff
Changes since 1.05:
added -startup_timeout and $ENV{APACHE_TEST_STARTUP_TIMEOUT} as places
to specify the maximum number of seconds to wait for the test
server to start. the default is still 60 seconds. [Geoffrey Young]
use apxs PREFIX
Mike Cramer wrote:
Geoffrey Young wrote:
I've tested it against everything I have. mike, if you can give CVS a
whirl today, that would be great.
I finally had a chance to try this out this morning and it worked
perfectly -- and when I forgot to feed it the path to apxs the first
time I tried
to specify the maximum number of seconds to wait for the test
server to start. the default is still 60 seconds. [Geoffrey Young]
use apxs PREFIX to resolve relative httpd.conf directives
ServerRoot is not present [Mike Cramer]
add support for a new subclass method 'bug_report', which if provided
hi all
I've been thinking about this situation for a while now...
Original Message
Subject: FAIL Apache-Test-1.06 darwin 6.8
Date: Tue, 11 Nov 2003 01:03:19 +0200 (IST)
!!! no test server configured, please specify an httpd or apxs or put either
in your PATH. For example:
t/TEST
hi all
currently, the perl-framework for 1.3, 2.0, and cvs fail miserably for me,
and have for some time.
1.3)
Failed TestStat Wstat Total Fail Failed List of Failed
---
apache/chunkinput.t
André Malo wrote:
* Geoffrey Young [EMAIL PROTECTED] wrote:
modules/include.t 9 2304?? ?? % ??
what does this null information mean?
pretty much that the script died before it could complete. for 2.1, for
instance, it's a result of this warning
Use of bare
Use of bare to mean is deprecated at modules/include.t line 120.
which is probably new to 5.8.2.
Interesting. doesn't occur within include.t. So it happens within the
framework?
hmm, perhaps. I was actually planning on getting down and dirty tomorrow :)
but yes, it could be the
Cliff Woolley wrote:
On Mon, 8 Dec 2003, Geoffrey Young wrote:
Use of bare to mean is deprecated at modules/include.t line 120.
which is probably new to 5.8.2.
Interesting. doesn't occur within include.t. So it happens within the
framework?
hmm, perhaps. I was actually planning
well, since I know andre is paying attention, I thought I'd start with
mod_include :)
ok, I made some adjustments to t/modules/include.t to accommodate 1.3, 2.0,
and 2.1. hopefully, all I did was shuffle things around so that it's easier
to keep track of the three cases: proper behavior,
Just to add to the concern Bill has voiced, there is a risk of fixing
testing here. You see that the sub-tests have failed only if you run in
the verbose mode. Most people won't do that, and will miss those
failures, thinking that everything is proper.
hmm, what gives you that impression?
hi all
t/apache/limits.t has one failure on Apache 1.3 - a chunked body that
exceeds the limits. 2.0/2.1 returns 413 (entity too large) while 1.3
returns 400 (bad request).
after looking at the code in 1.3 I think this is intentional -
ap_get_client_block specifically handles this condition,
the fsize test fails in 1.3, because the abbrev computation is different (and
the files are so *small* :-)
ok, that is TODO on 1.3 now.
The flastmod test fails on my box because of weird timezone problems.
POSIX::strftime() and mod_include's strftime produce different timezone
strings
William McKee wrote:
On Mon, Dec 22, 2003 at 04:06:02PM -0800, Stas Bekman wrote:
Use this archive instead:
Thanks for the link.
Hmm, are you sure you've spelled things right? That's t/logs/error_log. Do
you get anything at all written to it?
Yes, I do get some output written
However, I do like the idea of keeping the server
running since it takes several seconds for my slow system to bring it
up. Running `make t/TEST -run-tests` seems to work fine though.
excellent. I don't use that feature myself, so it's good to know it's
working for people :)
--Geoff
Stas Bekman wrote:
Moreover the prefix
ideally should be: APACHE_TEST_ and not APACHE_, since we already have a
bunch of env vars which start with APACHE_TEST_
Though I'm in favor to just drop them, making
everybody move to the better API.
+1
--Geoff
committed. looking forward to hear about the odd parts.
the first thing that strikes me is that when I build mod_perl with
MP_APXS=/foo/bin/apxs then make make test I get the dialogue asking me to
choose httpd and apxs binaries.
I don't think we want a prompt for the mod_perl test suite - it
Geoffrey Young wrote:
committed. looking forward to hear about the odd parts.
the first thing that strikes me is that when I build mod_perl with
MP_APXS=/foo/bin/apxs then make make test I get the dialogue asking me to
choose httpd and apxs binaries.
I don't think we want a prompt
Yes, thank you Geoff, I've noticed that too late. And my mail server was
down most of the day :(
:)
I think I have fixed these problems now.
What bothers me is the call to default_httpd, which may pick a wrong
server. So I've removed it. It is used in the interactive config, to
help
Donald Doane wrote:
Can someone please confirm whether or not apr_psprintf is thread safe.
Thank you.
sorry, wrong list. try [EMAIL PROTECTED]
--Geoff
-my $has_version = $module-VERSION || 0;
-return 1 if $has_version = $version;
+return 1 if eval { $module-VERSION($version) };
Are you sure you haven't dropped something here? why did you remove the
comparison line?
becuase it's both wrong and unnecessary:
VERSION
Can you please run t/TEST -debug=trace and see which TestConfigData.pm
is loaded? what's inside of it? May be the simple solution is not to
load custom_config when running from inside modperl-2.0? I think that's
the best solution.
I've already cleaned everything out for today, but I'll do
$ perl Makefile.PL MP_APXS=/apache/2.1/prefork/perl-5.8.2/bin/apxs
...
Configuring Apache/2.1.0-dev mod_perl/1.99_13-dev Perl/v5.8.2
$ make make test
...
using Apache/2.0.49-dev (prefork MPM)
waiting 120 seconds for server to start: .httpd: module mod_perl.c
is not
compatible with
[EMAIL PROTECTED] wrote:
nd 2004/01/12 08:04:50
Modified:perl-framework/t/modules autoindex.t
not to be a pest, but I still have this patch floating around. if there's
no interest I'll just scrap it.
--Geoff
Index: t/modules/include.t
André Malo wrote:
* [EMAIL PROTECTED] wrote:
Modified:perl-framework/t/modules include.t
Log:
cross-version updates
Thanks.
You just forgot to commit echo3.shtml and size.shtml :-)
whoops, sorry about that - I guess I've been away from this for a while :)
a fresh checkout
ok, here's my latest problem...
given a 3rd party module installation
$ perl Makefile.PL -apxs /foo/bin/apxs
two issues arrive
1) $HOME/.apache-test is created when the tests are run, not when the module
is installed. which means that even without any actual installs
2) -apxs is
Stas Bekman wrote:
any objections for this patch?
-if (-e $result) {
-debug $file successfully resolved to existing file $result;
well, you're removing the file check in favor of a directory check. in the
interests of debugging, I'd probably like to preserve the check and throw
In any case, adding a check for a file is fine with me as long as you
s/warning/debug/, so it won't appear in the normal output and users
don't send false complaints. How about adding it as an extra check on
top of this patch?
that all sounds fine.
--Geoff
which means that even without any actual installs
I think you didn't finish the sentence?
which means that even without any actually installs [2]
:)
I think because we test only for httpd's setting. that must be the
reason. Try passing -httpd instead for now.
I will
I know lots
Honestly, I am trying my best. The problems I am encountering are
changing perspective from a cgi to a mod_perl framework which thus
entails learning lots more about the Apache server than I've ever known
before. My apologies if you think these questions are inane or
off-topic.
no, I'm
There's one last piece that I'm still unclear on which your article did
not mention--reponse handlers. Is this where the two paths diverge? I'm
not sure that I see much difference between the way you do it and the
highly magical stuff.
well, that's the next step. instead of calling plan()
1 - 100 of 268 matches
Mail list logo
