Re: [RELEASE CANDIDATE] Apache-Test-1.27 RC2
Philip M. Gollucci wrote: A release candidate for Apache-Test 1.27 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.27-RC2.tar.gz Please take the time to exercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. This candidate contains the following fixes found from RC1: http://svn.apache.org/viewcvs?rev=293485view=rev http://svn.apache.org/viewcvs?rev=314992view=rev Changes since 1.26: localize ScriptSock directive to always point to t/logs/cgisock regardless of inherited and custom mod_cgid settings [Geoffrey Young] Prevent the config file from being overwritten on platforms such as WIN32 under certain conditions. [Randy Kobes] make sure that the TESTS Makefile.PL parameter is properly recognized [Christopher H. Laco apache-test chrislaco.com] Add the output of ldd(unix/cygwin) and otool -L (darwin) for httpd to the mp2bug report script. [Philip M. Gollucci] fall back on using httpd-defined HTTPD_ROOT as the base for httpd.conf if all other options fail. [Geoffrey Young] All tests pass on Ubuntu 5.04 with 2.0.54 prefork and Apache 1.3.33, Perl 5.8.4. All tests pass on FreeBSD 5.4-STABLE, Apache 2.0.54 prefork, Perl 5.8.4. All tests pass on Windows XP, Apache 1.3.33, and Perls 5.8.6 and 5.6.1. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: [RELEASE CANDIDATE] Apache-Test 1.21
Geoffrey Young wrote: a release candidate for Apache-Test 1.21 is now available. http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz I'm unable to download. I've tried at work and at home without success. I just get a connection timeout error. C:\Documents and Settings\claconslookup cvs.apache.org Server: trinity.dmz.matrix.network Address: 10.10.10.5 Non-authoritative answer: Name:cvs.apache.org Address: 209.237.227.194 Work is behind a proxy. Home is not. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: loading mod_perl first?
Geoffrey Young wrote: in general, I think it is atypical that one apache module depends on another module being loaded before it itself can load. that is, in a LoadModule sense - sure, lots of things depend on mod_perl, but they use PerlModule not LoadModule. embperl seems to be the exception to this. axkit would be the only other I could think of but I just verified that it uses PerlModule as well. Don't the new 2.x proxy modules have the same type of dependency? mod_proxy_connect, mod_proxy_http and mod_proxy_ftp require mod_proxy, but I've never tried loading them out of order to see if they fail. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Error linking to ApacheCore.lib in win32
My apologies because this is probably not the correct list, but I'm
looking for someone intimate with C and the httpd internals/exports.
I didn't figured I'd get much of an anwser from users@ and this isn't
exactly a mod_* question either.
--
I'm trying to compile a whole slew of things for a new install on my
laptop for dev, including libxml2, libxslt, mod_perl, and AxKit.
Everything is done and passed all the tests with the exception of AxKit.
What does this have to do with Apache you ask? Well, I'm getting errors
linking against ApacheCore.lib in my 1.3.33 Apache install. This is the
packages binary install from apache.org.
The error is:
axconfig.obj : error LNK2001: unresolved external symbol _ap_invoke_handler
blib\arch\auto\AxKit\AxKit.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
'0x460'
Stop.
Now, the AxKit Makefile has the full path to ApacheCore.lib in it;
without spaces. Removing that entry produces more errors, so it's
definately getting linked to.
The relevant portion in AxKits' axconfig.c is:
/* - axconfig.c - */
static int axkit_handler(request_rec *r)
{
int retval;
SV * handler_sv;
SV * cfg;
SV * debuglevel;
SV * errorlevel;
if (S_ISDIR(r-finfo.st_mode)) {
axkit_dir_config * cfg = (axkit_dir_config
*)ap_get_module_config(r-per_dir_config, XS_AxKit);
if (!cfg || cfg-handle_dirs != 1) {
return DECLINED;
}
}
handler_sv = newSVpv(AxKit::fast_handler, 0);
cfg = perl_get_sv(AxKit::Cfg, FALSE);
debuglevel = perl_get_sv(AxKit::DebugLevel, FALSE);
errorlevel = perl_get_sv(Error::Debug, FALSE);
ENTER;
save_item(cfg);
save_item(debuglevel);
save_item(errorlevel);
retval = perl_call_handler(handler_sv, (request_rec *)r, Nullav);
LEAVE;
SvREFCNT_dec(handler_sv);
if (retval == DECLINED) {
r-handler = default-handler;
return ap_invoke_handler(r);
}
return retval;
}
/* - axconfig.c - */
I've also done a dumpbin on ApacheCore.lib and ApacheCore.dll to confirm
that ap_invoke_handler is indeed exported.
The Microsoft KB has a million and one reasons that cause LNK1120 error,
and I don't know a damn thing about C.
Any C guru Apache internals god out there have any ideas?
Thanks,
-=Chris
Re: svn commit: r111983 - /httpd/test/trunk/perl-framework/Apache-Test/ToDo
Stas Bekman wrote: Chris, if you are still looking at what to do to improve A-T, I think this two new todo items might be of interest to you. I'm knee deep in another project at the moment, but I'm sure I'll get sick of it and need a break by the end of the weekend. No problem, there is no hurry, those are nice to have things. also these two items shouldn't take more than an hour, probably most of the time will be spent for testing I still need to take a crack at the mp2 RC and see if it will build on my setup as well. that's definitely more important! I would think so. I did a quick test that night, and I still couldn't do a stock perl Makefile.PL and have it find libs without doing perl Makefile.PL MP_AP_PREFIX=C:\Development\Apache2 instead. I thought there were a few patches for that, but maybe not. since I hadn't spent more than 2 minutes on the process, I didn't submit a bug report as of yet. -=Chris
Re: [PATCH] module2path/module2url pod
Stas Bekman wrote: Christopher H. Laco wrote: Shouldn't that be: Index: TestRequest.pm - $url = Apache::TestRequest::module2url($module, %options); + $url = Apache::TestRequest::module2url($module, \%options); Thanks Chris, fixed. Any other grunt work can work on? if you didn't get tired from module2url manipulations, there are a few tests in the httpd-test repository that could use the same refactoring. This is the repository used by the httpd project. To exract it do: svn checkout http://svn.apache.org/repos/asf/httpd/test/trunk/ httpd-test it lives in httpd-test/perl-framework/t/ Other than that, I'm going to commit soon a new test framework that tests Apache-Test config itself, so you may want to help out with that, once it's in. You are on the [EMAIL PROTECTED] list, right? That list shows all the commits to the httpd-test project (which includes Apache-Test). I'm going to put this on hold for a bit. I can't get a remotely clean make test. Aside from test failures, I'm fighting this if mod_rewrite is loaded: [Wed Dec 08 20:02:01 2004] [error] (OS 193)%1 is not a valid Win32 application. : mod_rewrite: could not startup RewriteMap program (null) and this when it's not: waiting 60 seconds for server to start: .Syntax error on line 243 of C:/Development/httpd-test/perl-framework/t/conf/extra.conf: Invalid ScriptLog path C:/Development/httpd-test/perl-framework/t/logs/mod_cgi.log I even went to far as to uninstall every piece of Apache/Apache2 and perl 5.6.1/5.8.4 and reinstall Apache2/5.8.4 letting it setup the ENV variables so it was the only perl. Maybe if I get more energy on my day off Friday I'll take another crack at it. Time for some HL2. :-) -=Chris
[PATCH] module2path/module2url pod
Here's my first crack at pod for module2path and module2url.
I decided to put it at the end of the FUNCTONS head1. It didn't seem to
make much sense at the beginning and it felt like I should keep focus on
the exported functions.
Let me know if you had something else in mind and I'll rework it.
-=Chris
Index: lib/Apache/TestRequest.pm
===
--- lib/Apache/TestRequest.pm (revision 94)
+++ lib/Apache/TestRequest.pm (working copy)
@@ -1088,6 +1088,50 @@
specification, section 9.2, at
Ihttp://www.faqs.org/rfcs/rfc2616.html for more information.
+=head2 Helper Functions
+
+CApache::TestRequest also includes a few helper functions to aid in
+the creation of urls used in the functions above.
+
+=over 4
+
+=item module2path
+
+ my $module = 'MyTestModule::TestHandler';
+ my $path = Apache::TestRequest::module2path($module);
+# returns 'MyTestModule__TestHandler'
+
+ my $res = GET /$path;
+
+Converts a module name to a path safe for use in the various request
+methods above.
+
+=item module2url
+
+ my $module = 'MyTestModule::TestHandler';
+ my $uri= Apache::TestRequest::module2url($module);
+# returns 'http://host:port/MyTestModule__TestHandler'
+
+ my $res = GET $uri;
+
+Converts a module name to a full uri including the current
+configurations host:port and sets Cmodule accordingly.
+
+The default scheme used is Chttp. You can override this by passing
+your preferred scheme into an optional second param:
+
+ my $module = 'MyTestModule::TestHandler';
+ my $uri = Apache::TestRequest::module2uri($module, {scheme = 'https'});
+# returns 'https://host:port/MyTestModule__TestHandler'
+
+You may also override the default path with a path of your own:
+
+ my $module = 'MyTestModule::TestHandler';
+ my $uri = Apache::TestRequest::module2uri($module, {path = '/foo'});
+# returns 'http://host:port/foo'
+
+=back
+
=head1 ENVIRONMENT VARIABLES
The following environment variables can affect the behavior of
Re: [PATCH] module2path/module2url pod
Stas Bekman wrote:
Christopher H. Laco wrote:
Here's my first crack at pod for module2path and module2url.
I decided to put it at the end of the FUNCTONS head1. It didn't seem
to make much sense at the beginning and it felt like I should keep
focus on the exported functions.
There is already one head1 FUNCTIONS there.
I've called your header:
=head2 URL Manipulation Functions
since all function in this module are 'helper functions' :)
Let me know if you had something else in mind and I'll rework it.
Looks good. I've massaged it a bit and commited.
Thanks Chris.
Shouldn't that be:
Index: TestRequest.pm
===
--- TestRequest.pm (revision 111269)
+++ TestRequest.pm (working copy)
@@ -1121,7 +1121,7 @@
=head3 Cmodule2url
$url = Apache::TestRequest::module2url($module);
- $url = Apache::TestRequest::module2url($module, %options);
+ $url = Apache::TestRequest::module2url($module, \%options);
Convert a module name to a full URL including the current
configurations Chostname:port and sets Cmodule accordingly.
Maybe it's just me. The former leads me to believe that I might be able
to do:
module2url('MyMod::Test',
scheme = 'https', path = '/merge3/');
instead of
module2url('MyMod::Test',
{scheme = 'https', path = '/merge3/'});
while the later make that more clear.
Any other grunt work can work on?
-=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco 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.
OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm
going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one list of the other?
-=Chris
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) Another opinion question amungst the A-TR and t/modperl changes: module2url vs. module2uri and my $url =vs. my $uri = -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? -=Chris
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. Baby steps, Chris. Baby steps. I should have a set of patches out for modperl/t and A::TR::module2url shortly after a few more distclean/nmake tests. -=Chris
Re: [PATCH] Test TestRequest pod
Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Now I have to go searching again. :-) modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. I know there's a couple more lurkers in there, but maybe I'll stumble across those during another round of module2path-ing. -=Chris
[PATCH] Apache::TestRequest::module2url
Here's the patch for Apache::TestRequest::module2url().
A set of patches to use it within the modperl tests is on it's way to
the dev list.
-=Chris
Index: lib/Apache/TestRequest.pm
===
--- lib/Apache/TestRequest.pm (revision 110069)
+++ lib/Apache/TestRequest.pm (working copy)
@@ -107,6 +107,23 @@
return $path;
}
+sub module2url {
+my $module = shift;
+my $opt = shift || {};
+my $scheme = $opt-{scheme} || 'http';
+my $path = $opt-{path} ||
+Apache::TestRequest::module2path($module);
+
+$path =~ s/^\///;
+
+Apache::TestRequest::module($module);
+
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+
+return $scheme://$hostport/$path;
+}
+
sub user_agent {
my $args = [EMAIL PROTECTED];
Re: [PATCH] Apache::TestRequest::module2url
Stas Bekman wrote: Christopher H. Laco wrote: Here's the patch for Apache::TestRequest::module2url(). A set of patches to use it within the modperl tests is on it's way to the dev list. Thanks Chris, committed with a few tweaks. Next it'd be nice to add a pod entries for this and module2path wrappers. As I have suggested earlier, if you have a patch that touches both modperl and a-t it's the best to send it together (even though svn's externals handling sucks and it won't show you 'svn diff' for the two at once, one needs to run those separately :( Oke dokie. I'll tackle the pod tomorrow. Thanks, -=Chris
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. You mean t/hooks/trans.t? sure it does: Apache::TestRequest::module($module); or are you talking about a different test? ANd so it does. On that note, I'm going to bed. :-/
[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.
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
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
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: 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
Re: FW: Re: Apache::TestRequest + Cookies
Ok, here's my first crack at a quick n dirty cookies test. The new test is t/cookies.t, and it's supporting server file is t/htdocs/cgi-bin/cookies.pl. I figured the extra cgi-bin directory was good for sanity sake. I've also included the necessary patches to MANIFEST and extra.conf.in against A-T 1.16. -=Chris a-t-cookie-test.tar.gz Description: GNU Zip compressed data
Re: FW: Re: Apache::TestRequest + Cookies
Stas Bekman wrote: Christopher H. Laco wrote: Thanks, Chris, committed with a few small adjustements. You can see the commits here: http://svn.apache.org/viewcvs?view=revrev=109277 http://svn.apache.org/viewcvs?view=revrev=109279 Thanks. Glad to contribute. It looks like the only change was naming the cookies.pl to cookies.pl.PL. That was needed to get the path to #!perl right What cnvention did I miss so I don't make that mistake again? The only missing thing was to check that CGI and CGI::Cookie were available in plan(). Duh. Silly me. I moved htdocs/cgi-bin/ = cgi-bin/ and did a few minor syntax changes. You can see what was applied at the URLs quoted at the top of this email. Now looking forward for docs updates. Thanks again.
[OT] CVS - SVN Thoughts
This is mostly off topic, but I wanted to get thoughts from the committers on how they're liking the conversion from CVS to SVN so far. What do you really like/hate about it vs. CVS? I've been toying around with the idea of moving that way at home. I'm not to sure I'm keen having to use copy for tagging and such, but maybe that's just the CVS brainwashing in me. I do dig the http/WebDAV background. It seems a lot easier to give the world read access. Thanks, -=Chris
Re: FW: Re: Apache::TestRequest + Cookies
Stas Bekman wrote: Christopher H. Laco wrote: Ok, here's my first crack at a quick n dirty cookies test. The new test is t/cookies.t, and it's supporting server file is t/htdocs/cgi-bin/cookies.pl. I figured the extra cgi-bin directory was good for sanity sake. I've also included the necessary patches to MANIFEST and extra.conf.in against A-T 1.16. Thanks, Chris, committed with a few small adjustements. You can see the commits here: http://svn.apache.org/viewcvs?view=revrev=109277 http://svn.apache.org/viewcvs?view=revrev=109279 You probably want to get the svn checkout to continue working with the latest version: svn checkout http://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test Apache-Test For docs (where you can find the latest testing.pod) it's: svn co http://svn.apache.org/repos/asf/perl/modperl/docs/trunk modperl-docs Thanks. Glad to contribute. It looks like the only change was naming the cookies.pl to cookies.pl.PL. What cnvention did I miss so I don't make that mistake again? -=Chris
Re: Apache::TestRequest + Cookies
just a very simple test that verifies that the documented technique works. later on it may evolve to include a special A-T API if we ever add one. Is it enought to do IfModule mod_usertrack.c and also need_module(mod_usertrack.c) to determine if the usertrack mnodule is installed, or is there someplace deeper within the setup where we can actually add LoadModule mod_usertrack.c? Thanks, -=Chris
Re: Apache::TestRequest + Cookies
but most people won't have this module installed... Installed, or loaded? I know the httpd.conf defaults to having that module commented out, but the module itself should be around. Maybe relying on Apache::Session would cover more install scnerios instead. I was trying to avoid writing a custom handler just to accept and toss some cookies in the test environment, but maybe that's better. At least then everyone install should be able to run the A-T cookie test.
Re: FW: Re: Apache::TestRequest + Cookies
CChristopher H. Laco wrote: Maybe relying on Apache::Session would cover more install scnerios instead. I was trying to avoid writing a custom handler just to accept and toss some cookies in the test environment, but maybe that's better. At least then everyone install should be able to run the A-T cookie test. I think the same_interp setup will do what you want. e.g. see in modperl-2.0 repository this test couple: t/response/TestModperl/sameinterp.pm t/modperl/sameinterp.t Yeah, I'll have to check that out. Thanks. (Yes, I just played the email switch-a-roo)
Re: FW: Re: Apache::TestRequest + Cookies
Stas Bekman wrote:
[snip]
Why don't you first post what you had on your mind. May be your idea
doesn't need that at all.
Well, here's what I was thinking. First, write a quick and dirty
mod_perl handler that looked for a specific cookie; let's say 'ApacheTest'.
If it wasn't supplied by the client, send a new copy out. If it was sent
by the client, simply return the supplied cookie/value.
Shouldn't take more than a few lines of code, and it removes the
dependency of usertrack and Apache::Session.
Then, simply write a test that makes a series of requests to that
handler. The first response should return a new ApacheTest cookie/value,
and the second test should pass back the same ApacheTest cookie/value if
Apache::TestRequest::user_agent( cookie_jar = {});
and it's surroundings are woroking fine.
-=Chris
Re: FW: Re: Apache::TestRequest + Cookies
Stas Bekman wrote: Sounds good. Though it'll probably need to leave in the modperl2's test suite and not Apache-Test's one. but let's see the code first and then see where it's the best to apply it. You can use the http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz to make it easy to write the test. I guess that's where I'm getting confused. Why would this be in mp2 rather than in A-T, since I'm really trying to confirm a scenerio under A-T. Obviously there's something I'm missing. -=Chris
Re: FW: Re: Apache::TestRequest + Cookies
Stas Bekman wrote: Michael Peters wrote: Stas Bekman wrote: Christopher H. Laco wrote: Stas Bekman wrote: Sounds good. Though it'll probably need to leave in the modperl2's test suite and not Apache-Test's one. but let's see the code first and then see where it's the best to apply it. You can use the http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz to make it easy to write the test. I guess that's where I'm getting confused. Why would this be in mp2 rather than in A-T, since I'm really trying to confirm a scenerio under A-T. Obviously there's something I'm missing. It should be in A-T, but since your test requires modperl it'd be better be in modperl, since chances are that A-T won't have modperl available and then it'll be skipped. So may be your original mod_usertrack idea was better, as it doesn't depend on mod_perl's availability (but at the same time depends on mod_usertrack). Can't the test be done with mod_cgi and not mod_perl? This should be available more often than mod_usertrack I would think. Yes, I was thinking the same. Good idea Michael. And it's enabled in the default shipping httpd.conf too! Great idea. I'll pursue it that method for now. -=Chris
Pickyness question
Just because I'm like that. :-)
I noticed in A-T/t/redirect.t we have:
plan tests = 6, need_module('mod_alias.c') need_lwp;
Of course, I noticed this after skimming over the A-T pod again , where
it mentions:
It's also important to mention to avoid using:
plan tests = 1, requirement1 requirement2;
For that matter, sometimes I see:
plan tests - 1, need_lwp;
plan tests - 1, need_lwp;
plan tests - 1, \need_lwp;
From a pure A-T coding standpoint, which is preferred?
-=Chris
Re: Pickyness question
Christopher H. Laco wrote:
Just because I'm like that. :-)
I noticed in A-T/t/redirect.t we have:
plan tests = 6, need_module('mod_alias.c') need_lwp;
Of course, I noticed this after skimming over the A-T pod again , where
it mentions:
It's also important to mention to avoid using:
plan tests = 1, requirement1 requirement2;
For that matter, sometimes I see:
plan tests - 1, need_lwp;
plan tests - 1, need_lwp;
plan tests - 1, \need_lwp;
From a pure A-T coding standpoint, which is preferred?
-=Chris
Sigh. Of course I meant:
plan tests = 1, need_lwp;
plan tests = 1, need_lwp;
plan tests = 1, \need_lwp;
Re: svn commit: r109235 - /httpd/test/trunk/perl-framework/Apache-Test/t/redirect.t
Geoffrey Young wrote:
-plan tests = 6, need_module('mod_alias.c') need_lwp;
+plan tests = 6, need need_module('mod_alias.c'), need_lwp;
^
?
:)
--Geoff
Ha, now see what I've started. :-)
Re: Apache::TestRequest + Cookies
Thanks. I'll give that a whirl tonight.
I finally got the hack approach working by calling
$apacheRequestResponse-headers(Set-Cookie) and passing that result right
back into the [scantily mentioned] second param of Apache::TestRequest::GET
'url', headername = headervalue
Since I only had on cookie, it works. All hell would break loose the minute
I had more I assume.
-=Chris
From: Michael Peters [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Apache::TestRequest + Cookies
Date: Wed, 24 Nov 2004 14:29:02 -0500
MIME-Version: 1.0
Received: from mail.apache.org ([209.237.227.199]) by mc7-f8.hotmail.com
with Microsoft SMTPSVC(5.0.2195.6824); Wed, 24 Nov 2004 11:28:56 -0800
Received: (qmail 99929 invoked by uid 500); 24 Nov 2004 19:28:40 -
Received: (qmail 99899 invoked by uid 99); 24 Nov 2004 19:28:39 -
Received: pass (hermes.apache.org: local policy)
Received: from Unknown (HELO plusthree.com) (65.61.157.8) by apache.org
(qpsmtpd/0.28) with SMTP; Wed, 24 Nov 2004 11:28:37 -0800
Received: (qmail 18178 invoked from network); 24 Nov 2004 19:28:21 -
Received: from h-66-167-36-5.mclnva23.covad.net (HELO ?192.168.1.164?)
([EMAIL PROTECTED]) by 0 with SMTP; 24 Nov 2004 19:28:21 -
X-Message-Info: JGTYoYF78jFk/IwND13SP4Tqx2eQ6P3t
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
X-ASF-Spam-Status: No, hits=0.0 required=10.0tests=
X-Spam-Check-By: apache.org
User-Agent: Mozilla Thunderbird 0.8 (X11/20041020)
X-Accept-Language: en-us, en
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
X-Virus-Checked: Checked
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 24 Nov 2004 19:28:57.0468 (UTC)
FILETIME=[D7A04BC0:01C4D25B]
Stas Bekman wrote:
Christopher H. Laco wrote:
Has anyone used ApacheTestRequest to test pages using cookiessessions?
I'm writing some quick and dirty tests for an AxKit session module I've
adopted. I've got everything up and running config wise and the pages are
getting run through AxKit just fine.
The first two tests simply consist of a set-value page which uses
Apache::Session::File to store a value, and a get-value page that
confirms the value is returned. Of course the get-value test, test 2,
fails because Apache::TestRequest is ignore the sessionid cookie [or all
cookies really].
I have LWP installed and I've tried a few different encantations using
-cookie_jar and HTTPCookie without any luck. Is there a Tutorial or
examples somwhere that cover dealing with sessions within
Apache::TestRequest?
I guess the silence means that no one has used it with cookies. I suppose
that you could fix it to work with cookies though. But I could be wrong
and it already works but not documented. there is a lot of such code in
there.
LWP::UserAgent doesn't by default keep a cookie_jar. All I had to do was
add this near the top of my test script before any GET/POST calls.
Apache::TestRequest::user_agent( cookie_jar = {});
HTH
--
Michael Peters
Developer
Plus Three, LP
Re: Apache::TestRequest + Cookies
[snip] Or more to the point: my $r = GET 'url', Cookie = $apacheRequestResponse-headers(Set-Cookie);
Re: Apache::TestRequest + Cookies
if you could also contribute the cookie test that would be handy too. I'm feeling a bit dense at the moment. To the list, or to the forthcoming [self] test suite? I'm not sure I understand the request. P.S. Sorry about my list replies full of headers. I need to unsubscribe from Hotmail and use a real email client from my home account. -=Chris
Re: Apache::TestRequest + Cookies
Either way if you find how to use A-T to handle cookies or fix it to do so,
it's be handy to add a new A-T tests (in addition to existing ones in
Apache-Test/t/) so we don't break this feature in the future, which is
easily possible sans having a test.
Plus it'll be great to have this documented... if you don't have the time
to send a proper patch, feel free to send some blurb+example(s) here and
I'll adopt it for the docs.
Assuming Michaels solution works:
Apache::TestRequest::user_agent( cookie_jar = {});
Are we looking for something more official to the actual Test::Request API;
a new method, better parameters, etc; or is the above just good enough for a
little mention?
Re: [ANNOUNCE] Apache::Test 1.08 RC1
On Mon, 2004-02-23 at 16:53 -0800, Stas Bekman wrote: We would like to release Apache::Test 1.08. It includes multiple changes and improvements, therefore we need your help to test it and report any problems you may have noticed. All tests successful : + Linux-2.6 + Linux-2.4 + OpenBSD 3.4 (IPv4) + OpenBSD 3.4 (IPv6) All tests successful: + FreeBSD 5.2.1 (IPv4 and IPv6) Thanks! Andrew All tests successful: + FreeBSD 4.9-STABLE However, 'make' was a little cranky about pod2man: [EMAIL PROTECTED] ~/Apache-Test-1.08-dev] $ make mkdir blib mkdir blib/lib mkdir blib/lib/Apache cp lib/Apache/TestUtil.pm blib/lib/Apache/TestUtil.pm cp lib/Apache/TestHandler.pm blib/lib/Apache/TestHandler.pm cp lib/Apache/TestClient.pm blib/lib/Apache/TestClient.pm cp lib/Apache/TestSmoke.pm blib/lib/Apache/TestSmoke.pm cp lib/Apache/Test.pm blib/lib/Apache/Test.pm cp lib/Apache/TestSort.pm blib/lib/Apache/TestSort.pm cp lib/Apache/TestRunPerl.pm blib/lib/Apache/TestRunPerl.pm cp lib/Apache/TestConfigPerl.pm blib/lib/Apache/TestConfigPerl.pm cp lib/Apache/TestCommon.pm blib/lib/Apache/TestCommon.pm cp lib/Apache/TestRequest.pm blib/lib/Apache/TestRequest.pm cp lib/Apache/Test5005compat.pm blib/lib/Apache/Test5005compat.pm cp lib/Apache/TestCommonPost.pm blib/lib/Apache/TestCommonPost.pm cp lib/Apache/TestReportPerl.pm blib/lib/Apache/TestReportPerl.pm cp lib/Apache/TestTrace.pm blib/lib/Apache/TestTrace.pm cp lib/Apache/TestConfigData.pm blib/lib/Apache/TestConfigData.pm cp lib/Apache/TestBuild.pm blib/lib/Apache/TestBuild.pm cp lib/Apache/TestConfigParse.pm blib/lib/Apache/TestConfigParse.pm cp lib/Apache/TestSmokePerl.pm blib/lib/Apache/TestSmokePerl.pm cp lib/Apache/TestHarness.pm blib/lib/Apache/TestHarness.pm cp lib/Apache/TestRun.pm blib/lib/Apache/TestRun.pm cp lib/Apache/TestConfig.pm blib/lib/Apache/TestConfig.pm cp lib/Apache/TestSSLCA.pm blib/lib/Apache/TestSSLCA.pm cp lib/Apache/TestServer.pm blib/lib/Apache/TestServer.pm cp lib/warnings.pm blib/lib/warnings.pm cp lib/Apache/TestConfigC.pm blib/lib/Apache/TestConfigC.pm cp lib/Apache/TestPerlDB.pm blib/lib/Apache/TestPerlDB.pm cp lib/Apache/TestMM.pm blib/lib/Apache/TestMM.pm cp lib/Bundle/ApacheTest.pm blib/lib/Bundle/ApacheTest.pm cp lib/Apache/TestReport.pm blib/lib/Apache/TestReport.pm mkdir blib/arch mkdir blib/arch/auto mkdir blib/arch/auto/Apache mkdir blib/arch/auto/Apache/Test mkdir blib/lib/auto/Apache mkdir blib/lib/auto/Apache/Test mkdir blib/man3 Manifying blib/man3/Apache::TestUtil.3 Manifying blib/man3/Apache::TestSmoke.3 Manifying blib/man3/Apache::TestTrace.3 Manifying blib/man3/Apache::Test.3 Manifying blib/man3/Apache::TestRun.3 Manifying blib/man3/Apache::TestRequest.3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 178 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 181 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 183 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 185 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 187 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 189 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 191 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 193 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 196 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 198 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 200 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 202 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 204 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 206 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 208 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 211 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 213 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 215 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 217 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 219 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 221 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 223 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod directive in paragraph 228 of lib/Apache/TestRequest.pm: head3 /usr/bin/pod2man: Unrecognized pod
Re: [ANNOUNCE] Apache::Test 1.08 RC1
What kind of pod2man is that? what perl version? All modern perls support more than head[12]. An therein lies the fun: it's the stock 5.005_3 perl included in the base OS install. I know I should upgrade, but I just can't break the if-it-aint-broke-dont-fix-it-rule just yet. :-) -=Chris _ Get a FREE online computer virus scan from McAfee when you click here. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Re: Apache::TestMM::generate_script vs. Win32 Paths
This case should be handled I'd think on the Apache::Test side. Does my $exe = 'C:\Program Files\Apache Group\Apache\Apache.exe'; $exe = Win32::GetShortPathName($exe); push @ARGV, '-httpd', $exe; work? If so, I'll look at seeing where this could be added within Apache::Test. -- best regards, randy kobes That fixes the problem. I guess the same would need to be applied to the -d and -f parameters passed to apache in the event that the test and config directories are also in directory with spaces in the names. Thanks, -=Chris _ Find high-speed net deals comparison-shop your local providers here. https://broadband.msn.com
Re: Apache::TestMM::generate_script vs. Win32 Paths
And just for the curious person in me, calling: Win32::GetShortPathName( Win32::GetShortPathName( $path_to_exe ) ); yields the same result as Win32::GetShortPathName( $path_to_exe ); So no worries about adding this to my Makefile.PL AND having Apache::Test possibly call it again further down the process in the event someone doesn't want to check $Apache::Test::VERSION. :-) -=Chris _ Let the new MSN Premium Internet Software make the most of your high-speed experience. http://join.msn.com/?pgmarket=en-uspage=byoa/premST=1
