[PATCH] Test TestRequest pod
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional headers
via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \ and . The bare versions seemed to be the
most prevelant.
-=Chris
Index: Test.pm
===
--- Test.pm (revision 109410)
+++ Test.pm (working copy)
@@ -604,7 +604,7 @@
the tests will be skipped if the function returns a false value. For
example:
-plan tests = 5, \need_lwp;
+plan tests = 5, need_lwp;
the test will be skipped if LWP is not available
@@ -654,13 +654,13 @@
=item need_http11
- plan tests = 5, need_http11;
+ plan tests = 5, need_http11;
Require HTTP/1.1 support.
=item need_ssl
- plan tests = 5, need_ssl;
+ plan tests = 5, need_ssl;
Require SSL support.
@@ -668,13 +668,13 @@
=item need_lwp
- plan tests = 5, need_lwp;
+ plan tests = 5, need_lwp;
Require LWP support.
=item need_cgi
- plan tests = 5, need_cgi;
+ plan tests = 5, need_cgi;
Requires mod_cgi or mod_cgid to be installed.
Index: TestRequest.pm
===
--- TestRequest.pm (revision 109410)
+++ TestRequest.pm (working copy)
@@ -780,6 +780,19 @@
installed. It's best, therefore, to check Chave_lwp before running
tests that rely on a redirection from CPOST.
+Sometimes it is desireable to have CApache::TestRequest remember
+cookies sent by the pages you are testing and send them back to the
+server on subsequent requests. This is especially necessary when
+testing pages whose functionality relies on sessions or the presence
+of preferences stored in cookies.
+
+By default, CLWP::UserAgent does Bnot remember cookies between
+requests. You can tell it to remember cookies by adding the following
+to Cuser_agent():
+
+ Apache::TestRequest::user_agent(reset =,
+ cookie_jar = {});
+
=head1 FUNCTIONS
CApache::TestRequest exports a number of functions that will likely
@@ -837,6 +850,11 @@
Sends a simple GET request to the Apache test server. Returns an
CHTTP::Response object.
+You can also supply additional headers to be sent with the request
+by adding their name/value pairs after the Curl parameter:
+
+ my $res = GET $url, 'Accept-Language' = 'de,en-us,en;q=0.5';
+
=head3 GET_STR
A shortcut function for CGET($uri)-Egtas_string.
[STATUS] (flood) Wed Dec 1 23:46:36 EST 2004
flood STATUS: -*-text-*- Last modified at [$Date: 2003/07/01 20:55:12 $] Release: 1.0: Released July 23, 2002 milestone-03: Tagged January 16, 2002 ASF-transfer: Released July 17, 2001 milestone-02: Tagged August 13, 2001 milestone-01: Tagged July 11, 2001 (tag lost during transfer) RELEASE SHOWSTOPPERS: * Everything needs to work perfectly Other bugs that need fixing: * I get a SIGBUS on Darwin with our examples/round-robin-ssl.xml config, on the second URL. I'm using OpenSSL 0.9.6c 21 dec 2001. * iPlanet sends Content-length - there is a hack in there now to recognize it. However, all HTTP headers need to be normalized before checking their values. This isn't easy to do. Grr. * OpenSSL 0.9.6 Segfaults under high load. Upgrade to OpenSSL 0.9.6b. Aaron says: I just found a big bug that might have been causing this all along (we weren't closing ssl sockets). How can I reproduce the problem you were seeing to verify if this was the fix? * SEGVs when /tmp/.rnd doesn't exist are bad. Make it configurable and at least bomb with a good error message. (See Doug's patch.) Status: This is fixed, no? * If APR has disabled threads, flood should as well. We might want to have an enable/disable parameter that does this also, providing an error if threads are desired but not available. * flood needs to clear pools more often. With a long running test it can chew up memory very quickly. We should just bite the bullet and create/destroy/clear pools for each level of our model: farm, farmer, profile, url/request-cycle, etc. * APR needs to have a unified interface for ephemeral port exhaustion, but aparently Solaris and Linux return different errors at the moment. Fix this in APR then take advantage of it in flood. * The examples/analyze-relative scripts fail when there are less than 5 unique URLs. Other features that need writing: * More analysis and graphing scripts are needed * Write robust tool (using tethereal perhaps) to take network dumps and convert them to flood's XML format. Status: Justin volunteers. Aaron had a script somewhere that is a start. Jacek is working on a Mozilla application, codename Flood URL bag (much like Live HTTP Headers) and small HTTP proxy. * Get chunked encoding support working. Status: Justin volunteers. He got sidetracked by the httpd implementation of input filtering and never finished this. This is a stopgap until apr-serf is completed. * Maybe we should make randfile and capath runtime directives that come out of the XML, instead of autoconf parameters. * We are using apr_os_thread_current() and getpid() in some places when what we really want is a GUID. The GUID will be used to correlate raw output data with each farmer. We may wish to print a unique ID for each of farm, farmer, profile, and url to help in postprocessing. * We are using strtol() in some places and strtoll() in others. Pick one (Aaron says strtol(), but he's not sure). * Validation of responses (known C-L, specific strings in response) Status: Justin volunteers * HTTP error codes (ie. teach it about 302s) Justin says: Yeah, this won't be with round_robin as implemented. Need a linked list-based profile where we can insert new URLs into the sequence. * Farmer (Single-thread, multiple profiles) Status: Aaron says: If you have threads, then any Farmer can be run as part of any Farm. If you don't have threads, you can currently only run one Farmer named Joe right now (this will be changed so that if you don't have threads, flood will attempt to run all Farmers in serial under one process). * Collective (Single-host, multiple farms) This is a number of Farms that have been fork()ed into child processes. * Megaconglomerate (Multiple hosts each running a collective) This is a number of Collectives running on a number of hosts, invoked via RSH/SSH or maybe even some proprietary mechanism. * Other types of urllists a) Random / Random-weighted b) Sequenced (useful with cookie propogation) c) Round-robin d) Chaining of the above strategies Status: Round-robin is complete. * Other types of reports Status: Aaron says: simple reports are functional. Justin added a new type that simply prints the approx. timestamp when the test was run, and the result as OK/FAIL; it is called easy reports (see flood_easy_reports.h). Furthermore,
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional headers
via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \ and . The bare versions seemed to be the
most prevelant.
Thanks Chris, commited. But see below.
Also in the future please try to post diffs against the root of the
project so it's easier to apply those. Thanks.
Index: TestRequest.pm
+ Apache::TestRequest::user_agent(reset =,
+ cookie_jar = {});
Sorry, but what's that 'reset = ' thing? I've committed just:
Apache::TestRequest::user_agent(cookie_jar = {});
as in the test.
=head1 FUNCTIONS
CApache::TestRequest exports a number of functions that will likely
@@ -837,6 +850,11 @@
Sends a simple GET request to the Apache test server. Returns an
CHTTP::Response object.
+You can also supply additional headers to be sent with the request
+by adding their name/value pairs after the Curl parameter:
really it's a dup of the more extensive docs at:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
but committed anyway :)
--
__
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: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional
headers via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \ and . The bare versions seemed to be
the most prevelant.
Thanks Chris, commited. But see below.
Also in the future please try to post diffs against the root of the
project so it's easier to apply those. Thanks.
I assume you mean http://svn.apache.org/repos/asf/httpd/test/trunk/, and
not just the root of Apache-Test correct?
No, no, the root of A-T. An example will be more useful:
--- lib/Apache/Test.pm (revision 109410)
+++ lib/Apache/Test.pm (working copy)
I can chdir into the root of the project and apply your patch immediately.
Index: TestRequest.pm
+ Apache::TestRequest::user_agent(reset =,
+ cookie_jar = {});
Sorry, but what's that 'reset = ' thing? I've committed just:
Apache::TestRequest::user_agent(cookie_jar = {});
as in the test.
Geez. Apparently I'm in the clouds this week. Maybe I need to do these
changes during the day instead of at night. :-/
:)
=head1 FUNCTIONS
CApache::TestRequest exports a number of functions that will likely
@@ -837,6 +850,11 @@
Sends a simple GET request to the Apache test server. Returns an
CHTTP::Response object.
+You can also supply additional headers to be sent with the request
+by adding their name/value pairs after the Curl parameter:
really it's a dup of the more extensive docs at:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
Well, yes, and that was on purpose. I hated reading the A-T pod and
never knowing there was an extra param for GET. THe pod usualy is enough
to get start, and I wouldn't exptec to have to read:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
Agreed, but dups are evil from the maintenance point of view. I'd rather
have everything in one place and have the other document link to the first
one. Unfortunately A-T pods are nowhere on perl.apache.org.
Were you looking for something more extensive?
No, no, it's perfectly fine. The next person looking for the same solution
will most likely easily find it.
--
__
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: [PATCH] Test TestRequest pod
Stas Bekman wrote: No, no, the root of A-T. An example will be more useful: --- lib/Apache/Test.pm(revision 109410) +++ lib/Apache/Test.pm(working copy) I can chdir into the root of the project and apply your patch immediately. Understood. Makes sense. Agreed, but dups are evil from the maintenance point of view. I'd rather have everything in one place and have the other document link to the first one. Unfortunately A-T pods are nowhere on perl.apache.org. Were you looking for something more extensive? No, no, it's perfectly fine. The next person looking for the same solution will most likely easily find it. On that note, what else can I work on? Apparently I'm a glutton for punishment. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so now
one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
--
__
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: need to require Cwd 2.06 for A-T
Stas Bekman wrote:
I know we tried to avoid external dependencies, but Cwd coming with
5.6.x is unusable under -T. At the moment this breaks some mp2 tests
(the problem comes from A-T, which indirectly invokes Cwd::cwd via
File::Spec's rel2abs. I've tried to code a workaround, but it doesn't
work and it's a bad idea to get it working since it's very OS specific.
(_backtick_pwd is the problem).
so we probably have no choice but require Cwd 2.06
So it's:
WriteMakefile(
NAME = 'Apache::Test',
VERSION = $VERSION,
PREREQ_PM = { 'File::Spec' = '0.8',
'Cwd'= '2.06',
},
...
);
but if this is not run from CPAN/CPANPLUS shell, most likely this
requirement will be ignored. Should we add:
die Cwd 2.06 or higher is required
unless eval { require Cwd $Cwd::VERSION = 2.06 };
after WriteMakefile(), this won't get on the way of CPAN/CPANPLUS shell
will it?
--
__
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: need to require Cwd 2.06 for A-T
Stas Bekman wrote: Stas Bekman wrote: I know we tried to avoid external dependencies, but Cwd coming with 5.6.x is unusable under -T. At the moment this breaks some mp2 tests (the problem comes from A-T, which indirectly invokes Cwd::cwd via File::Spec's rel2abs. I've tried to code a workaround, but it doesn't work and it's a bad idea to get it working since it's very OS specific. (_backtick_pwd is the problem). so we probably have no choice but require Cwd 2.06 if it's only breaking mp2 tests then those tests should probably have plan tests = $n, need_min_module_version(Cwd = 2.06); instead of requiring an external dependency for the entire framework. not that I'm against external dependencies, but we should only require an external dependency when the codebase itself requires it. that is, it is your tests that need a higher Cwd, not Apache-Test proper. --Geoff
Re: need to require Cwd 2.06 for A-T
Geoffrey Young wrote: Stas Bekman wrote: Stas Bekman wrote: I know we tried to avoid external dependencies, but Cwd coming with 5.6.x is unusable under -T. At the moment this breaks some mp2 tests (the problem comes from A-T, which indirectly invokes Cwd::cwd via File::Spec's rel2abs. I've tried to code a workaround, but it doesn't work and it's a bad idea to get it working since it's very OS specific. (_backtick_pwd is the problem). so we probably have no choice but require Cwd 2.06 if it's only breaking mp2 tests then those tests should probably have plan tests = $n, need_min_module_version(Cwd = 2.06); instead of requiring an external dependency for the entire framework. not that I'm against external dependencies, but we should only require an external dependency when the codebase itself requires it. that is, it is your tests that need a higher Cwd, not Apache-Test proper. It can affect any test, the problem is triggered by A-T. Any File::Spec-rel2abs call may trigger the problem. It just happens to be triggered so far under mp2 tests. -- __ 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: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to
do for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so
now one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
Hmmm, sounds easy enough since you already included module2url. :-)
Famous last words.
Still someone needs to do the work and verify that things are working.
Is this just a concern in t/modperl? I came up with 77 hits in t/, and
11 of those are in t/modperl. Maybe that small subset is a same place
for me to start.
It's all t/. But you can start with a subset.
Am I correct in assuming that the modperl in SVN is the 2.0 trunk (the
one I want) and that 1.0 is stuck back in CVS? I'm still trying to wrap
my brainpan around what modules are where and what perl-framework really
encompasses.
That's correct. I tried to argue that we want it to be called modperl-2.0,
but the httpd-way was preferrable on other developers.
The online docs have all the info:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
--
__
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: [PATCH] Test TestRequest pod
Stas Bekman wrote: Still someone needs to do the work and verify that things are working. That will fun in and of itself. Right now, the only thing close to meeting the requirements of running the overall tests is my 5.6.1 install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03. It'll probably take some time just to get my unmodded working copy to run all of it's test before I even start coding. I may just have to whip up another FBSD tinker box. -=Chris
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote:
I think all kind of refactoring would be great. One thing I wanted to
do for tests again vhosts, is to add this function next to
module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so
now one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
After another look at things like t/merge.t, it looks like there are at
least 2 different use cases for module2perl.
1) The $module sent to module2perl will be sent to ::module() and will
be the same as the path. This is your first example:
Foo::Bar = /Foo__Bar
2) The $module sent to module2perl will be sent to ::module(), but a
DIFFERENT path is required; like in merge3.t where the path ==
'/merge3/ != TestModperl::merge
What about make mopdeul2url have a hashref as the second arg in which we
can override $path, and of course $scheme
Apache::TestRequest::module2path('TestModePerl::merge', {
scheme = 'https',
path = '/merge3/
}
Of course it should take the necessary precautions for when / is and
isn't included, etc.
-=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
I think all kind of refactoring would be great. One thing I wanted
to do for tests again vhosts, is to add this function next to
module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so
now one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
After another look at things like t/merge.t, it looks like there are at
least 2 different use cases for module2perl.
1) The $module sent to module2perl will be sent to ::module() and will
be the same as the path. This is your first example:
Foo::Bar = /Foo__Bar
2) The $module sent to module2perl will be sent to ::module(), but a
DIFFERENT path is required; like in merge3.t where the path ==
'/merge3/ != TestModperl::merge
What about make mopdeul2url have a hashref as the second arg in which we
can override $path, and of course $scheme
Apache::TestRequest::module2path('TestModePerl::merge', {
scheme = 'https',
path = '/merge3/
}
Isn't merge3 an odd ball? Originally I was thinking to do the refactoring
for the code which identical and leave the more complex cases alone. But
if you wish to implement the suggested functionality go for it. It
definitely makes the test more readable, and those wishing to use the old
functionality still can do that.
though it's module2url, not module2path (saw your update)
Of course it should take the necessary precautions for when / is and
isn't included, etc.
What do you mean? Examples?
--
__
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: [PATCH] Test TestRequest pod
Stas Bekman wrote:
Of course it should take the necessary precautions for when / is and
isn't included, etc.
What do you mean? Examples?
Well, let's go with the running sample:
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
If looks as though module2path() returns the path starting with /.
If we override that with the path from the hashref module2url($url,
{path = 'mypath'}) we would end up with scheme://host:portmypath
instead of scheme://host:port/mypath.
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
Of course it should take the necessary precautions for when / is and
isn't included, etc.
What do you mean? Examples?
Well, let's go with the running sample:
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
If looks as though module2path() returns the path starting with /.
If we override that with the path from the hashref module2url($url,
{path = 'mypath'}) we would end up with scheme://host:portmypath
instead of scheme://host:port/mypath.
You are correct. Then yes, if the $path argument is provided by the user
strip the leading /.
--
__
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: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Still someone needs to do the work and verify that things are working. That will fun in and of itself. Right now, the only thing close to meeting the requirements of running the overall tests is my 5.6.1 install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03. It'll probably take some time just to get my unmodded working copy to run all of it's test before I even start coding. I may just have to whip up another FBSD tinker box. -=Chris And so it starts. I'm having problems subscribing to the modperl-win32 list at the moment, otherwise I'd ask this there. Is there any other way to test my changes other than trying to build mp2 itself? I want to get started on the changes but I can get mp2 to build on Win32: Configure mod_perl with C:\Development\Apache2? [y] Configuring Apache/2.0.52 mod_perl/1.99_18-dev Perl/v5.8.4 Note (probably harmless): No library found for /lib/libapr.lib Of course, my %LIB% contains the appropriate Apache2/lib directory and that dir is also in my Config.pm. Thanks for putting up with the newb. -=Chris
