SSL proxy configuration wierdness
In the SSL proxy tests, the configurations for proxy_http_https and proxy_https_https are somewhat different (aside from the fact that one has SSLEngine on!) Is there any reason for this? I'm seeing test failures (ssl/proxy 113-117) if I don't uncomment the SSLProxyMachineCertificateFile directive. Cheers, Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: POST with no data
On Tue, Sep 10, 2002 at 05:55:27PM +0100, Gary Benson wrote:
> I've been trying to write some tests and have been trying to send POST
> requests with no body. It seems that Apache::TestRequest::POST only
> adds a Content-Length when the length of the content is nonzero, so
> attempts to 'POST "/foo/bar", ""' result in a 411 Length Required from
> httpd.
>
> I'm not nearly good enough with Perl to work out where POST is defined;
> can anyone point me in the direction of what I need to change to cause a
> content-length to be added to all POST requests?
So I eventually managed to make a workaround for this (attached). I'm
still not sure if httpd-test is the correct place for the fix or whether
I should be fixing LWP so I won't commit it.
Cheers,
Gary
[ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Content-length headers don't seem to get added to POST requests with
empty bodies, causing httpd to return a 411 Length Required.
Index: perl-framework/Apache-Test/lib/Apache/TestRequest.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRequest.pm,v
retrieving revision 1.71
diff -u -r1.71 TestRequest.pm
--- perl-framework/Apache-Test/lib/Apache/TestRequest.pm4 Apr 2002
00:54:26 - 1.71
+++ perl-framework/Apache-Test/lib/Apache/TestRequest.pm11 Sep 2002
09:47:55 -
@@ -386,6 +386,9 @@
unless ($shortcut) {
#GET, HEAD, POST
+if ($r->method eq "POST" && !defined($r->header("Content-Length"))) {
+$r->header('Content-Length' => length($r->content));
+}
$r = $UA ? $UA->request($r) : $r;
my $proto = $r->protocol;
if (defined($proto)) {
POST with no data
Hi all, I've been trying to write some tests and have been trying to send POST requests with no body. It seems that Apache::TestRequest::POST only adds a Content-Length when the length of the content is nonzero, so attempts to 'POST "/foo/bar", ""' result in a 411 Length Required from httpd. I'm not nearly good enough with Perl to work out where POST is defined; can anyone point me in the direction of what I need to change to cause a content-length to be added to all POST requests? Cheers, Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
perl-framework vs mod_perl/t
Hi, I'm interested in seeing if I can drop mod_perl's t directory into httpd-test/perl-framework, so I can test them both at once. Is this feasable or should I just test them seperatly? I guess what I'm asking is: * Are httpd-test/perl-framework and mod_perl/t synchronized at all, or have they diverged over the past year? I'm mostly talking about mod_perl-1.99 here, since it looks like 1.26 is much older than httpd-test. * Are the tests in mod_perl solely for mod_perl functionality, or are there some generic httpd tests in there too? Cheers, Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: test-cvs mailing list archive, anybody?
On Thu, 7 Mar 2002, Stas Bekman wrote: > I need a browsable test-cvs mailing list archive. Any reason why it's > not on the http://httpd.apache.org/test/ mainpage along with httpd-dev? > Can somebody please add it there, or tell me if there is some other > similar resource elsewhere? I've got a mbox folder which contains every test-cvs message since (roughly) the start of August (and every test-dev as well). If you want I can mail it to you... Cheers, Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: Testing remote server
On Tue, 27 Nov 2001, Rodent of Unusual Size wrote: > Can it be done? Not without some trickery: loads of the scripts rely on being able to write directly to the server root. Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: [patch] adding the startup polling functionality
We used to use File::Tail to look for the "resuming normal operations" in the logfile; I mentioned putting this in httpd-test a while back but it was felt to be non-optimal due to the fact that File::Tail is not a standard module. Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: Wierd problem with apache/post test
On Fri, 16 Nov 2001, Cliff Woolley wrote: > On Fri, 16 Nov 2001, Gary Benson wrote: > > > Anyone have any objections to my rewriting mod_echo_post to dump > > everything to a temporary file and then read it back? > > I wish I understood exactly why this was happening... it seems almost > indicative of some problem in Apache or APR. The module shouldn't have to > buffer all this stuff... it should be able to do a read from the input > filter chain, process it, and send some output down the output filter > chain, and that ought to be it. Buffering the whole thing either in RAM > or on disk in a production environment would open a huge DoS hole. The problem isn't in Apache: what is happening is that the way mod_echo_post works is exposing a weakness in the client code, in this case libwwwperl. The clients should really read and write simultaneously, but this isn't normally a problem since what happens with the vast majority of requests is that the handler reads the request in its entirity, chews it over a bit and then returns something. This behaviour doesn't saturate the buffers. Of course, I say it is the clients' fault, but perhaps it is the OS: the problem seems to affect only some OSes and not others -- perhaps these OSes have fixed size socket buffers? A 100k mod_echo_post request is enough to cause problems and none of the machines we use are _that_ short on memory ;) Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: Wierd problem with apache/post test
On Thu, 15 Nov 2001, Doug MacEachern wrote: > yeah, the socket gets saturated, saw the same problem with ssl, see the > comment in apache/post.t: > #300, 500, 2000, 4000, 6000, 10_000); > #XXX: ssl currently falls over here I wondered if this was the same problem :) > i think your solution to modify mod_echo_post.c is the way to go, just > make sure you free() the malloced buffer. either that or write the post > data to a tmp file then send that back out. Write to a file was my favourite option (some of our machines are low on RAM), but I did the memory thing as a quick hack to check if it worked. Anyone have any objections to my rewriting mod_echo_post to dump everything to a temporary file and then read it back? Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: Orphaned semaphores on Linux/Apache 1.3.22
This has been happening since at least 13th September (on Red Hat Linux 7.1, Apache 1.3.20). I'd forgotton all about it... On Thu, 15 Nov 2001, Rodent of Unusual Size wrote: > Last night I started getting 'semget: No space left on device' > in the error_log when trying to run tests against 1.3. Sure > enough, there were tons of semaphores left around. > > I have verified that each run of t/TEST for actual tests > leaves at least one orphaned semaphore. This does not > appear to happen with apachectl management of the same > httpd binary, so I suspect the test server is being > terminated with extreme prejudice rather than with kindness. > > This is RH Linux 6.2 with Apache 1.3.23-dev, and httpd-test > from HEAD. > -- > #ken P-)} > > Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ > Author, developer, opinionist http://Apache-Server.Com/ > > "All right everyone! Step away from the glowing hamburger!" > [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Wierd problem with apache/post test
Hi all,
I came across a wierd problem with the apache/post test which seems to
occur on certain OSes. The symptoms are that the test locks up on one of
the subtests, LWP eventually times out on the request, the test fails and
then all subsequent tests that are run fail.
The problem seems to be this:
- LWP writes the entire request in one go.
- mod_echo_post send its response as it processes the request.
- only when it has finished sending the request does LWP attempt to read
the response.
I think what is happening is that, with large requests, a large amount of
data is simultanously being fed into the socket from both directions, and
some buffer somewhere in the OSes socket handler is being filled. My
suspicions are backed up by the fact that I modified mod_echo_post (see
attached) to read the entire request and only then send the response, and
this solves the problem.
If this is the case then it really should be fixed by making LWP read and
write simultanously; you may have guessed from my hazy terminology that I
don't really know a lot about how sockets _really_ work, but do any of
you guys think that this sounds about right? If so, I'll email the LWP
maintainers and see what they say.
Later,
Gary
[ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
#if CONFIG_FOR_HTTPD_TEST
SetHandler echo_post
#endif
#define APACHE_HTTPD_TEST_HANDLER echo_post_handler
#include "apache_httpd_test.h"
static int echo_post_handler(request_rec *r)
{
int rc;
long nrd, buff_size;
char *buff, *buff_p;
if (strcmp(r->handler, "echo_post")) {
return DECLINED;
}
if (r->method_number != M_POST) {
return DECLINED;
}
if ((rc = ap_setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
ap_log_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO,
#ifdef APACHE2
0,
#endif /* APACHE2 */
r->server,
"[mod_echo_post] ap_setup_client_block failed: %d", rc);
return 0;
}
if (!ap_should_client_block(r)) {
return OK;
}
/* Allocate a buffer to read the request into */
buff_size = r->remaining;
buff = malloc(buff_size);
if (!buff) {
ap_log_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO,
#ifdef APACHE2
0,
#endif /* APACHE2 */
r->server,
"[mod_echo_post] unable to malloc(%d)", buff_size);
return HTTP_INTERNAL_SERVER_ERROR;
}
fprintf(stderr, "[mod_echo_post] going to read %ld bytes...\n",
buff_size);
/* Read the request */
buff_p = buff;
while ((nrd = ap_get_client_block(r, buff_p, r->remaining)) > 0) {
fprintf(stderr,
"[mod_echo_post] read %ld bytes (remaining=%ld)\n",
nrd, r->remaining);
buff_p += nrd;
}
if (r->remaining) {
ap_log_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO,
#ifdef APACHE2
0,
#endif /* APACHE2 */
r->server,
"[mod_echo_post] data stopped %d bytes short",
r->remaining);
return HTTP_INTERNAL_SERVER_ERROR;
}
/* Send the response */
#ifdef APACHE1
fprintf(stderr, "[mod_echo_post] sending response headers...\n");
ap_send_http_header(r);
#endif
fprintf(stderr, "[mod_echo_post] sending response...\n");
ap_rwrite(buff, buff_size, r);
fprintf(stderr, "[mod_echo_post] done...\n");
return OK;
}
APACHE_HTTPD_TEST_MODULE(echo_post);
Re: cvs commit: httpd-test/perl-framework/t/http11 chunked.t
On Tue, 6 Nov 2001, Rodent of Unusual Size wrote: > Gary Benson wrote: > > > Oh, and you did run t/TEST -clean first, didn't you? It won't > > rebuild the modules if you don't. > > Yep; I even nuked the tree and did a clean checkout. Is the module actually being compiled? If not, are any of the other modules? With Apache 1.3, you should have (if I recall correctly) mod_authany, mod_echo_post and mod_test_rwrite, as well as mod_random_chunk. Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: cvs commit: httpd-test/perl-framework/t/http11 chunked.t
On Tue, 6 Nov 2001, Rodent of Unusual Size wrote: > [EMAIL PROTECTED] wrote: > > > > gbenson 01/11/06 08:03:00 > > > > Modified:perl-framework/c-modules/random_chunk mod_random_chunk.c > >perl-framework/t/http11 chunked.t > > Log: > > Fix for Apache 1.3 > > Not working for me on a fresh checkout; have_module 'random_chunk' > is still failing. Failing or not running? If failing, where? I'm using Apache 1.3.22, Perl 5.6.1 and LWP 5.60 (also checked with 5.5396), to name the things it seems most sensitive to. Oh, and you did run t/TEST -clean first, didn't you? It won't rebuild the modules if you don't. Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: mod_random_chunk
On Thu, 1 Nov 2001, Ryan Bloom wrote: > On Thursday 01 November 2001 12:57 pm, Doug MacEachern wrote: > > > On Mon, 22 Oct 2001, Gary Benson wrote: > > > > > > If you remove the "#define HTTPD_TEST_REQUIRE_APACHE 2" from > > > mod_random_chunk.c then it compiles and runs successfully but does not > > > pass the tests. It seems that it is not sending any headers: should it > > > be? > > > > it would need to call ap_send_http_header(r); #ifdef APACHE1 > > You could actually call that function in 1.3 or 2.0, the 2.0 version > is a no-op though. Thanks guys; I had hoped it might be something really simple like that. Fix coming up soon Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
mod_random_chunk
Hi, If you remove the "#define HTTPD_TEST_REQUIRE_APACHE 2" from mod_random_chunk.c then it compiles and runs successfully but does not pass the tests. It seems that it is not sending any headers: should it be? | $ t/TEST --start-httpd | ... blah blah blah ... | $ telnet localhost 8529 | Trying 127.0.0.1... | Connected to localhost.localdomain. | Escape character is '^]'. | GET /random_chunk?0,100 HTTP/1.1 | Host: localhost | | fd | 10101010101010101010MMM0101010101010?01010107III10101010101C@@0101010101010101310101010101010101011044LL10__END__:242 | Connection closed by foreign host. Cheers, Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: httpd-test results with Apache 1.3.22
On Thu, 11 Oct 2001, Justin Erenkrantz wrote: > Failed Test Status Wstat Total Fail Failed List of Failed > --- > modules/autoindex.t 84 84 100.00% 1-84 > modules/dir.t209 208 99.52% 1-208 > modules/env.t 33 100.00% 1-3 > modules/setenvif.t 111 111 100.00% 1-111 > modules/status.t 11 100.00% 1 > 13 tests skipped. > server localhost.localdomain:8529 shutdown > error running tests (please examine t/logs/error_log) > Failed 5/27 test scripts, 81.48% okay. 407/1228 subtests failed, 66.86% > okay. > > > > I dunno how many of these are because the test suite doesn't really > support 1.3 (which is my guess), but I think it'd be nice to make sure > that 1.3 works with httpd-test as well. > > I'm definitely not enough of a perl hacker to sort this out. =-) > -- justin I'm using httpd-test with 1.3, so I'll probably end up fixing it at some point in the near future. Not till 1.3.22 comes out though... Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: How to deal with PerlModule?
On Mon, 17 Sep 2001, Stas Bekman wrote: > Gary Benson wrote: > > > Hi all, > > > > In the config we maintain a list of modules, both compiled in and loaded > > via LoadModule, which is build in TestConfigParse.pm. I've been trying > > to figure out how to deal with modules loaded via PerlModule? For > > LoadModule ones it knows that mod_.so => mod_.c and lib.so => > > mod_.c, but how do you extract the .c name from a Perl module? > > > I'm not sure I understand your question. But PerlModule == use(), and > PerlRequire == require(). So if you want to load a perl module Foo::Bar > from .conf file you either do: > > PerlModule Foo::Bar > > or > > PerlRequire Foo/Bar.pm > > hope that answers your question It appears that I have become completely confused; sorry for wasting your time guys. Gary
How to deal with PerlModule?
Hi all, In the config we maintain a list of modules, both compiled in and loaded via LoadModule, which is build in TestConfigParse.pm. I've been trying to figure out how to deal with modules loaded via PerlModule? For LoadModule ones it knows that mod_.so => mod_.c and lib.so => mod_.c, but how do you extract the .c name from a Perl module? Thanks in advance, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ]
Re: Error from mod_cgi test
On Thu, 13 Sep 2001, john sachs wrote: > On Thu, Sep 13, 2001 at 09:16:38AM -0700, Ian Holsman wrote: > + error: cgi log not created! > + not ok 2 > + # Failed test 2 in modules/cgi.t at line 85 > > + error: cgi log does not exist! > + not ok 4 > + # Failed test 4 in modules/cgi.t at line 97 > > + dubious > + Test returned status 2 (wstat 512, 0x200) > + DIED. FAILED tests 2, 4, 10-36 > + Failed 29/36 tests, 19.44% okay > > ok, all these errors deal with the cgi log. at first i thought the > script was using relative paths to find the log, but thats not the > case. so the only thing i can think of is permissions? the test is > dying because its trying to do a stat on a non-existant file. i will > fix this, but it still doesnt tell us why the log file is not getting > created. any ideas anyone? What user is the cronjob running as? It may be that the cronjob is running as a different user... Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ]
Re: What is test.o?
On Wed, 12 Sep 2001, Doug MacEachern wrote: > On Thu, 13 Sep 2001, Gary Benson wrote: > > > Well, I moved it and it works properly now. I hope that you didn't spend > > too much time on it :-/ > > good news. not at all, i knew right away from past experience > MakeMaker was picking up a .c or .xs file you didn't mean it to, just > didn't know which one, diff against your Makefile revealed the culprit. Sweet.
Re: What is test.o?
On Wed, 12 Sep 2001, Doug MacEachern wrote: > On Wed, 12 Sep 2001, Gary Benson wrote: > > > The makefile itself makes the directory, and puts a .exists file in it, > > but I don't know what it is trying to to do it or why. I've attached my > > makefile if you want to compare, or if you send me yours then I'll compare > > it instead... > > looks like there's a mod_random_chunk.c in your perl-framework/ directory? Yes, it's the one I made the other day. I moved it out of its own directory so it didn't get nailed when I ran cvs update. Well, I moved it and it works properly now. I hope that you didn't spend too much time on it :-/ Cheers, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ]
Re: [Fwd: FAILURE httpd-2.0 automated test log]
Yeah, it passes for me too, but I thought I'd mention it; you never know. Running from cron used to break the mod_env tests too, but I think I fixed that a while back. On Wed, 12 Sep 2001, john sachs wrote: > i just had cron run the cgi test and it passed for me. > > On Wed, Sep 12, 2001 at 03:33:57PM +0100, Gary Benson wrote: > + > + On Sat, 8 Sep 2001, Doug MacEachern wrote: > + > + > On 6 Sep 2001, Ian Holsman wrote: > + > > + > > 1. running modules/cgi from a cron job fails on certain tests. > + > > + > haven't looked into that, could be a permissions problem? > + > + or a problem with the fact that cron runs stuff with a very limited > + environment. Try running "/bin/sh -c set > /tmp/env" from a cron job... > + > [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ]
Re: What is test.o?
On Wed, 12 Sep 2001, Doug MacEachern wrote:
> On Wed, 12 Sep 2001, Gary Benson wrote:
>
> > rm -f blib/arch/auto/httpd-test/test.so
> > LD_RUN_PATH="" gcc -shared test.o -o blib/arch/auto/httpd-test/test.so
> > gcc: test.o: No such file or directory
> > gcc: No input files
> > make: *** [blib/arch/auto/httpd-test/test.so] Error 1
>
> not seeing that here. do you have a test.c or test.xs file in that
> directory by chance? actually, why is there any httpd-test directory
> relative to perl-framework at all?
The makefile itself makes the directory, and puts a .exists file in it,
but I don't know what it is trying to to do it or why. I've attached my
makefile if you want to compare, or if you send me yours then I'll compare
it instead...
Gary
# This Makefile is for the httpd-test extension to perl.
#
# It was generated automatically by MakeMaker version
# 5.45 (Revision: 1.222) from the contents of
# Makefile.PL. Don't edit this file, edit Makefile.PL instead.
#
# ANY CHANGES MADE HERE WILL BE LOST!
#
# MakeMaker ARGV: ()
#
# MakeMaker Parameters:
# NAME => q[httpd-test]
# VERSION => q[0.01]
# clean => { FILES=>q[./t/htdocs/modules/rewrite/db.pl
./t/htdocs/modules/rewrite/numbers.pl ./t/htdocs/modules/rewrite/numbers2.pl
./t/htdocs/modules/cgi/bogus-perl.pl ./t/htdocs/modules/cgi/bogus1k.pl
./t/htdocs/modules/cgi/env.pl ./t/htdocs/modules/cgi/perl.pl
./t/htdocs/modules/cgi/perl_echo.pl t/TEST] }
# --- MakeMaker post_initialize section:
# --- MakeMaker const_config section:
# These definitions are from config.sh (via
/home/gary/temp/sh-inst.0006/lib/perl/Config.pm)
# They may have been overridden via Makefile.PL or on the command line
AR = ar
CC = gcc
CCCDLFLAGS = -fpic
CCDLFLAGS = -rdynamic
DLEXT = so
DLSRC = dl_dlopen.xs
LD = gcc
LDDLFLAGS = -shared
LDFLAGS =
LIBC = /lib/libc-2.2.2.so
LIB_EXT = .a
OBJ_EXT = .o
OSNAME = linux
OSVERS = 2.4.2-2smp
RANLIB = :
SO = so
EXE_EXT =
FULL_AR = /usr/bin/ar
# --- MakeMaker constants section:
AR_STATIC_ARGS = cr
NAME = httpd-test
DISTNAME = httpd-test
NAME_SYM = httpd_test
VERSION = 0.01
VERSION_SYM = 0_01
XS_VERSION = 0.01
INST_BIN = blib/bin
INST_EXE = blib/script
INST_LIB = blib/lib
INST_ARCHLIB = blib/arch
INST_SCRIPT = blib/script
PREFIX = /home/gary/temp/sh-inst.0006
INSTALLDIRS = site
INSTALLPRIVLIB = $(PREFIX)/lib/perl
INSTALLARCHLIB = $(PREFIX)/lib/perl
INSTALLSITELIB = $(PREFIX)/lib/perl/site
INSTALLSITEARCH = $(PREFIX)/lib/perl/site
INSTALLBIN = $(PREFIX)/bin
INSTALLSCRIPT = $(PREFIX)/bin
PERL_LIB = /home/gary/temp/sh-inst.0006/lib/perl
PERL_ARCHLIB = /home/gary/temp/sh-inst.0006/lib/perl
SITELIBEXP = /home/gary/temp/sh-inst.0006/lib/perl/site
SITEARCHEXP = /home/gary/temp/sh-inst.0006/lib/perl/site
LIBPERL_A = libperl.a
FIRST_MAKEFILE = Makefile
MAKE_APERL_FILE = Makefile.aperl
PERLMAINCC = $(CC)
PERL_INC = /home/gary/temp/sh-inst.0006/lib/perl/CORE
PERL = /home/gary/temp/sh-inst.0006/bin/perl
FULLPERL = /home/gary/temp/sh-inst.0006/bin/perl
FULL_AR = /usr/bin/ar
VERSION_MACRO = VERSION
DEFINE_VERSION = -D$(VERSION_MACRO)=\"$(VERSION)\"
XS_VERSION_MACRO = XS_VERSION
XS_DEFINE_VERSION = -D$(XS_VERSION_MACRO)=\"$(XS_VERSION)\"
PERL_MALLOC_DEF = -DPERL_EXTMALLOC_DEF -Dmalloc=Perl_malloc -Dfree=Perl_mfree
-Drealloc=Perl_realloc -Dcalloc=Perl_calloc
MAKEMAKER = /home/gary/temp/sh-inst.0006/lib/perl/ExtUtils/MakeMaker.pm
MM_VERSION = 5.45
# FULLEXT = Pathname for extension directory (eg Foo/Bar/Oracle).
# BASEEXT = Basename part of FULLEXT. May be just equal FULLEXT. (eg Oracle)
# ROOTEXT = Directory part of FULLEXT with leading slash (eg /DBD) !!!
Deprecated from MM 5.32 !!!
# PARENT_NAME = NAME without BASEEXT and no trailing :: (eg Foo::Bar)
# DLBASE = Basename part of dynamic library. May be just equal BASEEXT.
FULLEXT = httpd-test
BASEEXT = test
DLBASE = $(BASEEXT)
OBJECT = $(BASEEXT)$(OBJ_EXT)
LDFROM = $(OBJECT)
LINKTYPE = dynamic
# Handy lists of source code files:
XS_FILES=
C_FILES = mod_random_chunk.c
O_FILES = mod_random_chunk.o
H_FILES =
HTMLLIBPODS=
HTMLSCRIPTPODS =
MAN1PODS =
MAN3PODS =
HTMLEXT = html
INST_MAN1DIR = blib/man1
INSTALLMAN1DIR = $(PREFIX)/man/man1
MAN1EXT = 1
INST_MAN3DIR = blib/man3
INSTALLMAN3DIR = $(PREFIX)/man/man3
MAN3EXT = 3
PERM_RW = 644
PERM_RWX = 755
# work around a famous dec-osf make(1) feature(?):
makemakerdflt: all
.SUFFIXES: .xs .c .C .cpp .cxx .cc $(OBJ_EXT)
# Nick wanted to get rid of .PRECIOUS. I don't remember why. I seem to recall,
that
# some make implementations will delete the Makefile when we rebuild it. Because
# we call false(1) when we rebuild it. So make(1) is not completely wrong when
it
# does so. Our milage may vary.
# .PRECIOUS: Makefile# seems to be not necessary anymore
.PHONY: all config static dynamic test linkext manifest
# Where is the Config information that we are using/depend on
CONFIGDEP = $(
What is test.o?
Hi guys, Since sometime on Friday something has changed which has broken my build in a strange way. It's now looking for a file called `test.o' which it doesn't attempt to build (as far as I can see). I'm no Perl wizard; can any of you guys hazard a guess as to what is going on? Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ] % perl Makefile.PL generating script/t/htdocs/modules/rewrite/db.pl generating script/t/htdocs/modules/rewrite/numbers.pl generating script/t/htdocs/modules/rewrite/numbers2.pl generating script/t/htdocs/modules/cgi/bogus-perl.pl generating script/t/htdocs/modules/cgi/bogus1k.pl generating script/t/htdocs/modules/cgi/env.pl generating script/t/htdocs/modules/cgi/perl.pl generating script/t/htdocs/modules/cgi/perl_echo.pl generating script...t/TEST Checking if your kit is complete... Looks good Writing Makefile for Apache::Test Writing Makefile for httpd-test % make make[1]: Entering directory `/home/gary/work/httpd-test/perl-framework/Apache-Test' cp lib/Apache/TestHarness.pm ../blib/lib/Apache/TestHarness.pm cp lib/Bundle/ApacheTest.pm ../blib/lib/Bundle/ApacheTest.pm cp lib/Apache/TestRunPerl.pm ../blib/lib/Apache/TestRunPerl.pm cp lib/Apache/TestUtil.pm ../blib/lib/Apache/TestUtil.pm cp lib/Apache/TestSort.pm ../blib/lib/Apache/TestSort.pm cp lib/Apache/TestServer.pm ../blib/lib/Apache/TestServer.pm cp lib/Apache/TestPerlDB.pm ../blib/lib/Apache/TestPerlDB.pm cp lib/Apache/TestConfigParse.pm ../blib/lib/Apache/TestConfigParse.pm cp lib/Apache/TestConfigPerl.pm ../blib/lib/Apache/TestConfigPerl.pm cp lib/Apache/TestConfigC.pm ../blib/lib/Apache/TestConfigC.pm cp lib/Apache/TestRun.pm ../blib/lib/Apache/TestRun.pm cp lib/Apache/TestConfig.pm ../blib/lib/Apache/TestConfig.pm cp lib/Apache/Test.pm ../blib/lib/Apache/Test.pm cp lib/Apache/TestRequest.pm ../blib/lib/Apache/TestRequest.pm cp lib/Apache/TestHandler.pm ../blib/lib/Apache/TestHandler.pm cp lib/Apache/TestMM.pm ../blib/lib/Apache/TestMM.pm cp lib/Apache/TestTrace.pm ../blib/lib/Apache/TestTrace.pm Manifying ../blib/man3/Bundle::ApacheTest.3 Manifying ../blib/man3/Apache::Test.3 Manifying ../blib/man3/Apache::TestTrace.3 Manifying ../blib/man3/Apache::TestUtil.3 make[1]: Leaving directory `/home/gary/work/httpd-test/perl-framework/Apache-Test' Running Mkbootstrap for httpd-test () chmod 644 test.bs rm -f blib/arch/auto/httpd-test/test.so LD_RUN_PATH="" gcc -shared test.o -o blib/arch/auto/httpd-test/test.so gcc: test.o: No such file or directory gcc: No input files make: *** [blib/arch/auto/httpd-test/test.so] Error 1
Re: [Fwd: FAILURE httpd-2.0 automated test log]
On Sat, 8 Sep 2001, Doug MacEachern wrote: > On 6 Sep 2001, Ian Holsman wrote: > > > 1. running modules/cgi from a cron job fails on certain tests. > > haven't looked into that, could be a permissions problem? or a problem with the fact that cron runs stuff with a very limited environment. Try running "/bin/sh -c set > /tmp/env" from a cron job...
Re: cvs commit: httpd-test/perl-framework/c-modules/echo_post mod_echo_post.c
Thanks Doug. Gary On 8 Sep 2001 [EMAIL PROTECTED] wrote: > dougm 01/09/08 12:00:52 > > start cooking apache_httpd_test.h
Re: func5.t again.
God I hate this test...
I have no idea what is causing these two; $SCRIPT_FILENAME should be set
by Apache according to the PHP manual. As for the permissions, I just
don't know.
We could probably revert to the one that uses the logfile and tails it; I
think the ultimate problem was that there was a race going on (hence the
sleep 1 in func5.t).
I don't mind one way or another...
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
On Thu, 6 Sep 2001, john sachs wrote:
> hi,
> this is the first time im running the new func5, where it writes a file to
> say that it ran. its not working. i get this in the body of the initial
> request:
>
> foo() will be called on shutdown...
> Warning: fopen(".ran", "w") - Permission denied in
> /home/john/ht-cvs/httpd-test/perl-framework/t/htdocs/php/func5.php on line 9
>
> this in the error_log:
>
> can't write .ran.
>
> so it looks like a couple things are bad here.
> 1) $file = "$SCRIPT_FILENAME.ran"; is not getting set correctly
> 2) it seems php thinks it has no permission to write to the directory.
>
> i dont know enough about php to know how 1 should work.
> as far as 2...it should have permission to write anything its all running as
> same user...other scripts can write content to those dirs...
> ?
> -j
>
Porting c-modules to Apache 1.3
Hi guys,
I've been trying to port some of the c-modules to Apache 1.3, and before I
go any further I thought I'd check that I haven't done anything stupid :-)
Attached to the bottom is my patch to mod_random_chunk; I haven't managed
to test it fully since my LWP is too old (is 5.5396 a CVS version?) but I
just wanted to see if anyone has any problems with what I've done to make
it work? I'm not too familiar with Apache's internals...
Also, in cmodules_httpd_conf(), in TestConfigC.pm, it is looking for the
compiled module in "$dir/.libs/$mod->{name}.so", whereas on mine the
module gets compiled to "$dir/$mod->{name}.so"; is this another Apache 2
thing? Would this be an appropriate fix:
my $so = $self->{server}->{rev} == 1 ?
"$dir/$mod->{name}.so" :
"$dir/.libs/$mod->{name}.so";
Cheers,
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Index: perl-framework/c-modules/random_chunk/mod_random_chunk.c
===
RCS file:
/home/cvs/httpd-test/perl-framework/c-modules/random_chunk/mod_random_chunk.c,v
retrieving revision 1.4
diff -u -r1.4 mod_random_chunk.c
--- perl-framework/c-modules/random_chunk/mod_random_chunk.c2001/08/27
04:59:40 1.4
+++ perl-framework/c-modules/random_chunk/mod_random_chunk.c2001/09/07
17:11:37
@@ -1,5 +1,3 @@
-#define HTTPD_TEST_REQUIRE_APACHE 2
-
#if CONFIG_FOR_HTTPD_TEST
@@ -100,6 +98,11 @@
#define MAX_SEGMENT 32
#define ONE_WEIGHT (256-32)
+#ifdef APACHE1
+#define AP_METHOD_BIT 1
+typedef size_t apr_size_t;
+#endif /* APACHE1 */
+
static int random_chunk_handler(request_rec *r)
{
const char *args;
@@ -176,6 +179,8 @@
return 0;
}
+#ifdef APACHE2
+
static void random_chunk_register_hooks(apr_pool_t *p)
{
ap_hook_handler(random_chunk_handler, NULL, NULL, APR_HOOK_MIDDLE);
@@ -190,3 +195,38 @@
NULL, /* table of config file commands */
random_chunk_register_hooks /* register hooks */
};
+
+#endif /* APACHE2 */
+
+#ifdef APACHE1
+
+static const handler_rec random_chunk_handlers[] =
+{
+{"random-chunk", random_chunk_handler},
+{NULL}
+};
+
+module MODULE_VAR_EXPORT random_chunk_module =
+{
+STANDARD_MODULE_STUFF,
+NULL, /* initializer */
+NULL, /* create per-directory config structure */
+NULL, /* merge per-directory config structures */
+NULL, /* create per-server config structure */
+NULL, /* merge per-server config structures */
+NULL, /* command table */
+random_chunk_handlers, /* handlers */
+NULL, /* translate_handler */
+NULL, /* check_user_id */
+NULL, /* check auth */
+NULL, /* check access */
+NULL, /* type_checker */
+NULL, /* pre-run fixups */
+NULL, /* logger */
+NULL, /* header parser */
+NULL, /* child_init */
+NULL, /* child_exit */
+NULL /* post read-request */
+};
+
+#endif /* APACHE1 */
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Doug MacEachern wrote:
> On Thu, 6 Sep 2001, Gary Benson wrote:
>
> > > +# untaint
> > > +$ENV{PATH} = '/bin:/usr/bin';
>
> this should be 'local $ENV{PATH} = ...;', does that help at all?
Yeah, that fixed it.
Gary
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Stas Bekman wrote:
> On Thu, 6 Sep 2001, Gary Benson wrote:
>
> >
> > On 6 Sep 2001 [EMAIL PROTECTED] wrote:
> >
> > > stas01/09/05 19:36:44
> > >
> > > Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
> > > TestConfigParse.pm
> > > Log:
> > > - enable taint mode in tests via PerlSwitches -T
> > > - untaint $ENV{PATH} before using open "-|"
> >
> > [snip]
> >
> > > diff -u -r1.7 -r1.8
> > > --- TestConfigParse.pm 2001/08/20 15:20:50 1.7
> > > +++ TestConfigParse.pm 2001/09/06 02:36:44 1.8
> > > @@ -220,6 +220,8 @@
> > >
> > >my $version;
> > >my $cmd = "$httpd -v";
> > > +# untaint
> > > +$ENV{PATH} = '/bin:/usr/bin';
> > >open my $v, '-|', $cmd or die "$cmd failed: $!";
> > >
> > >local $_;
> >
> > This breaks on mine even though $httpd is an absolute path at this point.
>
> You mean if you don't add the patch from above?
>From a clean, current CVS checkout:
% cd httpd-test/perl-framework
% export PATH=/path/to/httpd-and-apxs:$PATH
% perl Makefile.PL
% make
% t/TEST -start-httpd
setting ulimit to allow core files
ulimit -c unlimited
exec t/TEST -start-httpd
cannot build c-modules without apxs
no test server configured, please specify an httpd or apxs or put either in
your PATH
> > I'm not familiar enough with Perl to know why this should be, but is there
> > a better way (like $ENV{PATH} = '/bin:/usr/bin' unless $httpd =~ m:^/:;).
> > Would that successfully untaint it?
>
> It's not about being absolute path or not, it's about opening "-|", which
> is insecure if $ENV{PATH} is not untainted.
I don't really think I understand this line:
|open my $v, '-|', $cmd or die "$cmd failed: $!";
As far as I see it, '-|' means perform an explicit fork, with return
value of open being child pid in the parent and 0 in the child. From what
I see, it looks like you should be doing either of these two:
|open my $v, "$httpd|" or die "$cmd failed: $!";
|open my $v, '-|' or exec $httpd or die "$cmd failed: $!";
I'm not saying that your code is _wrong_: I'm saying I don't understand
it. I can see what your line does, but now how it does it or why '-|' is
insecure.
> > I can't tell, since mine doesn't complain about it being tainted at this
> > point and I can't figure out a way to make it do so. Why do you need to
> > untaint here anyway? Is this something from mod_perl? I'm confused!
>
> What's your Perl version? perl -v ?
v5.6.1
I'm just running it as my UID, so would taint checking happen anyway?
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On 6 Sep 2001 [EMAIL PROTECTED] wrote:
> stas01/09/05 19:36:44
>
> Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
> TestConfigParse.pm
> Log:
> - enable taint mode in tests via PerlSwitches -T
> - untaint $ENV{PATH} before using open "-|"
[snip]
> diff -u -r1.7 -r1.8
> --- TestConfigParse.pm 2001/08/20 15:20:50 1.7
> +++ TestConfigParse.pm 2001/09/06 02:36:44 1.8
> @@ -220,6 +220,8 @@
>
>my $version;
>my $cmd = "$httpd -v";
> +# untaint
> +$ENV{PATH} = '/bin:/usr/bin';
>open my $v, '-|', $cmd or die "$cmd failed: $!";
>
>local $_;
This breaks on mine even though $httpd is an absolute path at this point.
I'm not familiar enough with Perl to know why this should be, but is there
a better way (like $ENV{PATH} = '/bin:/usr/bin' unless $httpd =~ m:^/:;).
Would that successfully untaint it?
I can't tell, since mine doesn't complain about it being tainted at this
point and I can't figure out a way to make it do so. Why do you need to
untaint here anyway? Is this something from mod_perl? I'm confused!
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: TestConfig->new deletes vhosts (et al)
On Wed, 5 Sep 2001, Doug MacEachern wrote:
> On Mon, 3 Sep 2001, Gary Benson wrote:
>
> >
> > Hi all,
> >
> > I'm getting problems with tests passing if I run:
> >
> > % perl t/TEST
> >
> > but failing if I run:
> >
> > % perl t/TEST -start-httpd
> > % perl t/TEST -run-tests
> > % perl t/TEST -stop-httpd
>
> works fine for me.
>
> > It seems that this chunk of code, from TestConfig.pm (~ line 140), is the
> > culprit. It deletes the section of the config file that contains the
> > virtual host stuff, which breaks the tests which need them.
> >
> > #regenerating config, so forget old
> > if ($args->{save}) {
> > for (qw(vhosts inherit_config modules inc)) {
> > delete $thaw->{$_} if exists $thaw->{$_};
> > }
> > }
> >
> > Does anyone know _why_ it deletes the vhosts stuff -- is it required by
> > something else, or was it once required but not any more?
>
> that should only happen when configuration is being generated, in which
> case the vhosts will be rediscovered. things like apxs are canidates for
> reuse from the old config. otherwise, cached config is used and that bit
> is not run. i wonder if you have something in your shell env that is
> triggering reconfiguration, such as:
> my %passenv = map { $_,1 } qw{
> APXS APACHE APACHE_GROUP APACHE_USER APACHE_PORT
> };
APACHE_PORT is set.
Should I explicitly set APACHE_PORT _only_ for t/TEST -start-httpd? Eg:
% APACHE_PORT=whatever t/TEST -start-httpd
% perl t/TEST -run-tests
% perl t/TEST -stop-httpd
But looking more closely, I see that there is a -port option. Perhaps
that makes more sense...
Okay, thanks for that,
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
TestConfig->new deletes vhosts (et al)
Hi all,
I'm getting problems with tests passing if I run:
% perl t/TEST
but failing if I run:
% perl t/TEST -start-httpd
% perl t/TEST -run-tests
% perl t/TEST -stop-httpd
It seems that this chunk of code, from TestConfig.pm (~ line 140), is the
culprit. It deletes the section of the config file that contains the
virtual host stuff, which breaks the tests which need them.
#regenerating config, so forget old
if ($args->{save}) {
for (qw(vhosts inherit_config modules inc)) {
delete $thaw->{$_} if exists $thaw->{$_};
}
}
Does anyone know _why_ it deletes the vhosts stuff -- is it required by
something else, or was it once required but not any more?
Cheers,
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
mod_expires failures on 1.3
I've been getting failures on mod_expires test numbers 13, 21, 33 and 45. Anyone know if anything significant changed between 1.3 and 2.0 in this area? Alternativly, it would be much appreciated if someone running 2.0 could do "t/TEST -v modules/expires > result" and mail it to me Cheers, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: My previous two commits
On Fri, 31 Aug 2001, Justin Erenkrantz wrote: > On Fri, Aug 31, 2001 at 08:53:24AM -0700, Aaron Bannert wrote: > > On Fri, Aug 31, 2001 at 02:47:58PM +0100, Gary Benson wrote: > > > > > > Since it seems that my previous two commit emails disappeared, so for your > > > pleasure I have recreated them. > > > > Gary, > > > > They were probably caught by the moderator. This tends to happen with > > new committers, so the posts won't show up until the moderator sees the > > posts (and he is probably somewhere over the mid pacific right now). You > > did the right thing by manually subscribing. > > Oh crap, I wonder if Roy forgot to add me as the moderator before he > left. I know he meant to do that. I'll drop a line to Brian about > that. -- justin It's not crucial at the moment -- they work now...
Re: commit emails
On Fri, 31 Aug 2001, Gary Benson wrote: > On Fri, 31 Aug 2001, Gary Benson wrote: > > > Sorry to be a pain, but I've made two commits in the past 12 hours and > > haven't received the commit emails. Could someone look into it for me? > > I just got told that httpd-test is probably a members-only can post > list, so when my commit message comes in from "[EMAIL PROTECTED]" it > gets rejected. > > I just subscribed from "[EMAIL PROTECTED]", so we'll see if that works... It did... [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
My previous two commits
Since it seems that my previous two commit emails disappeared, so for your
pleasure I have recreated them.
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Index: perl-framework/t/php/func5.t
===
RCS file: /home/cvs/httpd-test/perl-framework/t/php/func5.t,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- perl-framework/t/php/func5.t2001/08/19 20:21:51 1.5
+++ perl-framework/t/php/func5.t2001/08/31 00:51:11 1.6
@@ -9,31 +9,18 @@
my $env = Apache::TestConfig->thaw;
+my $file = "htdocs/php/func5.php.ran";
+unlink $file if -e $file;
+
my $expected = <) {
-if ($_ eq $expected) {
-$result = $_;
-last;
-}
-}
-
-close(ERROR_LOG);
-
-ok $result eq $expected;
+# Clean up
+unlink $file if -e $file;
Index: perl-framework/t/htdocs/php/func5.php
===
RCS file: /home/cvs/httpd-test/perl-framework/t/htdocs/php/func5.php,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- perl-framework/t/htdocs/php/func5.php 2001/08/10 17:12:57 1.2
+++ perl-framework/t/htdocs/php/func5.php 2001/08/31 00:51:11 1.3
@@ -1,8 +1,21 @@
Index: perl-framework/Apache-Test/lib/Apache/TestRun.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.42
diff -u -r1.42 TestRun.pm
--- perl-framework/Apache-Test/lib/Apache/TestRun.pm2001/08/30 06:20:14
1.42
+++ perl-framework/Apache-Test/lib/Apache/TestRun.pm2001/08/30 13:21:00
@@ -406,6 +406,11 @@
$self->default_run_opts;
+#export some environment variables for t/modules/env.t
+#(the values are unimportant)
+$ENV{TESTHOSTNAME} = 'test.host.name';
+$ENV{TESTHOSTTYPE} = 'z80';
+
$self->start;
$self->run_tests;
Index: perl-framework/t/conf/extra.conf.in
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/conf/extra.conf.in,v
retrieving revision 1.20
diff -u -r1.20 extra.conf.in
--- perl-framework/t/conf/extra.conf.in 2001/08/28 16:55:55 1.20
+++ perl-framework/t/conf/extra.conf.in 2001/08/30 13:21:00
@@ -210,12 +210,12 @@
## mod_env test config
##
-PassEnv HOSTNAME
+PassEnv TESTHOSTNAME
SetEnv ENV_TEST "mod_env test environment variable"
UnsetEnv UNSET
-PassEnv HOSTTYPE
-UnsetEnv HOSTTYPE
+PassEnv TESTHOSTTYPE
+UnsetEnv TESTHOSTTYPE
SetEnv NOT_HERE "this will not be here"
UnsetEnv NOT_HERE
Index: perl-framework/t/htdocs/modules/env/host.shtml
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/t/htdocs/modules/env/host.shtml,v
retrieving revision 1.1
diff -u -r1.1 host.shtml
--- perl-framework/t/htdocs/modules/env/host.shtml 2001/08/22 00:25:36
1.1
+++ perl-framework/t/htdocs/modules/env/host.shtml 2001/08/30 13:21:00
@@ -1 +1 @@
-
+
Index: perl-framework/t/htdocs/modules/env/type.shtml
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/t/htdocs/modules/env/type.shtml,v
retrieving revision 1.1
diff -u -r1.1 type.shtml
--- perl-framework/t/htdocs/modules/env/type.shtml 2001/08/22 00:25:36
1.1
+++ perl-framework/t/htdocs/modules/env/type.shtml 2001/08/30 13:21:00
@@ -1 +1 @@
-
+
Index: perl-framework/t/modules/env.t
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/modules/env.t,v
retrieving revision 1.4
diff -u -r1.4 env.t
--- perl-framework/t/modules/env.t 2001/08/28 16:18:17 1.4
+++ perl-framework/t/modules/env.t 2001/08/30 13:21:01
@@ -9,7 +9,7 @@
##
my %test = (
-'host' => $ENV{HOSTNAME},
+'host' => $ENV{TESTHOSTNAME},
'set' => "mod_env test environment variable",
'unset' => '(none)',
'type' => '(none)',
Re: commit emails
On Fri, 31 Aug 2001, Gary Benson wrote: > Sorry to be a pain, but I've made two commits in the past 12 hours and > haven't received the commit emails. Could someone look into it for me? I just got told that httpd-test is probably a members-only can post list, so when my commit message comes in from "[EMAIL PROTECTED]" it gets rejected. I just subscribed from "[EMAIL PROTECTED]", so we'll see if that works...
commit emails
Hi guys, Sorry to be a pain, but I've made two commits in the past 12 hours and haven't received the commit emails. Could someone look into it for me? Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: Is there a way to disable the ANSI?
At the moment I am testing the test :-) Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ] On Thu, 30 Aug 2001, john sachs wrote: > if you have the fix, just send along the patch and i can commit for you. > wait...did you already do that once? > -j > > On Thu, Aug 30, 2001 at 11:55:26PM +0100, Gary Benson wrote: > + > + On Thu, 30 Aug 2001, Ian Holsman wrote: > + > + > I'm trying to get a nightly test going, > + > (nearly done) > + > + If you are running it from cron then the mod_env tests will fail. Don't > + worry; when my commit access works I'll commit a fix... > + > + Gary > + > + [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ] > + >
Re: Is there a way to disable the ANSI?
Many apologies: didn't mean to send the last message. I pressed the wrong key :-/
Re: Is there a way to disable the ANSI?
On Thu, 30 Aug 2001, Doug MacEachern wrote:
> On Fri, 31 Aug 2001, Gary Benson wrote:
>
> > ANSI escape codes are what you send to a terminal to make it do stuff.
> > For example, if you print "\e[31;42;1m" to a terminal (where "\e" is ESC,
> > or ASCII 27) it will make text appear as bold red on a green background.
>
> ohh, those ansi escape codes.
>
> > In httpd-test, this is all hidden within Term::ANSIColor, which gets
> > called from Apache::TestTrace...
>
> colors can be turned off now with:
> $ENV{APACHE_TEST_NO_COLOR} = 1;
>
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: Is there a way to disable the ANSI?
On Thu, 30 Aug 2001, Doug MacEachern wrote: > On Thu, 30 Aug 2001, Ian Holsman wrote: > > > I'm trying to get a nightly test going, > > (nearly done) > > > > and the escape codes look ugly. > > anyway of disabling them?? > > what is 'the ANSI'? and 'escape codes'? ANSI escape codes are what you send to a terminal to make it do stuff. For example, if you print "\e[31;42;1m" to a terminal (where "\e" is ESC, or ASCII 27) it will make text appear as bold red on a green background. In httpd-test, this is all hidden within Term::ANSIColor, which gets called from Apache::TestTrace... Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: Is there a way to disable the ANSI?
On Thu, 30 Aug 2001, Ian Holsman wrote: > I'm trying to get a nightly test going, > (nearly done) If you are running it from cron then the mod_env tests will fail. Don't worry; when my commit access works I'll commit a fix... Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Anyone know what this means?
Access denied: Insufficient Karma (gbenson|httpd-test/perl-framework/t/php)cvs server: Pre-commit check failed Access denied: Insufficient Karma (gbenson|httpd-test/perl-framework/t/htdocs/php) cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! cvs commit: saving log message in /tmp/cvsS0ABZQ
Re: File::Tail
On Thu, 30 Aug 2001, Doug MacEachern wrote: > On Thu, 30 Aug 2001, Gary Benson wrote: > > > > > Hi all, > > > > I've got three problems which I could resolve easily if I were able to > > call on the File::Tail package (which tails files would you believe). These > > being: > > > > * php/func5.t fails if the log entry doesn't get written straight > >to the disk > > * php/func5.t will pass on the first "foo() has been called" message, so > >we could have false passes. > > i'd rather just change the test to write to its own file rather than > error_log, if we can prevent a dependency on File::Tail. What a fine idea. Consider it (about to be) done...
File::Tail
Hi all, I've got three problems which I could resolve easily if I were able to call on the File::Tail package (which tails files would you believe). These being: * php/func5.t fails if the log entry doesn't get written straight to the disk * php/func5.t will pass on the first "foo() has been called" message, so we could have false passes. * TestServer::start sometimes fails on slow machines What I want to know is if anyone has a problem with me using this package, and whether or not we could add it to the httpd-test-bundle. Comments? Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: Core dump scan breaks exit() status
On Wed, 29 Aug 2001, Stas Bekman wrote:
> On Wed, 29 Aug 2001, Stas Bekman wrote:
>
> > > > > The change was made in revision 1.28 of TestRun.pm, if you want to
> > > > > have a
> > > > > look at it yourself. I have no idea how to fix this in a nice way,
> > > > > short
> > > > > of moving it into a wrapper that runs t/TEST, remembers the exit
> > > > > status,
> > > > > then checks for coredumps afterwards and then exits accordingly.
> > > >
> > > > I guess you are talking about the END block:
> > > >
> > > > eval "END {
> > > > eval {
> > > > Apache::TestRun->new(test_config =>
> > > > Apache::TestConfig->thaw)->scan;
> > > > };
> > > > }";
> > > >
> > > > but what exit status was it returning before? I don't think we have any
> > > > definition of the exit status definitions according to the tests success
> > > > or failure. Or do we?
> > >
> > > At the moment (or at least before that END block was there) it returns 1
> > > if something breaks.
> >
> > I see, try this patch (untested):
>
> I didn't realize that END {} is a block already :) here is a simpler patch
> (still untested):
>
> Index: Apache-Test/lib/Apache/TestRun.pm
> ===
> RCS file:
> /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
> retrieving revision 1.41
> diff -u -r1.41 TestRun.pm
> --- Apache-Test/lib/Apache/TestRun.pm 2001/08/27 05:55:17 1.41
> +++ Apache-Test/lib/Apache/TestRun.pm 2001/08/29 15:49:48
> @@ -221,6 +221,7 @@
> #always run, a subclass might not want that
>
> eval "END {
> + local $?; # preserve the exit status
> eval {
> Apache::TestRun->new(test_config =>
> Apache::TestConfig->thaw)->scan;
Stas, thanks, that worked a treat. May I request that you commit it?
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: Core dump scan breaks exit() status
On Wed, 29 Aug 2001, Stas Bekman wrote:
> On Wed, 29 Aug 2001, Gary Benson wrote:
>
> >
> > Hi all,
> >
> > The core dump scanning bit in TestRun::install_sighandlers overwrites the
> > exit status, making t/TEST always return 0. This isn't too great if you
> > are calling it from a script ;-)
> >
> > I'm not interested in fixing it -- I've got a bunch of c-modules to port
> > ;-) -- but here's my take on the problem:
> >
> > The change was made in revision 1.28 of TestRun.pm, if you want to have a
> > look at it yourself. I have no idea how to fix this in a nice way, short
> > of moving it into a wrapper that runs t/TEST, remembers the exit status,
> > then checks for coredumps afterwards and then exits accordingly.
>
> I guess you are talking about the END block:
>
> eval "END {
> eval {
> Apache::TestRun->new(test_config =>
> Apache::TestConfig->thaw)->scan;
> };
> }";
>
> but what exit status was it returning before? I don't think we have any
> definition of the exit status definitions according to the tests success
> or failure. Or do we?
At the moment (or at least before that END block was there) it returns 1
if something breaks.
Core dump scan breaks exit() status
Hi all, The core dump scanning bit in TestRun::install_sighandlers overwrites the exit status, making t/TEST always return 0. This isn't too great if you are calling it from a script ;-) I'm not interested in fixing it -- I've got a bunch of c-modules to port ;-) -- but here's my take on the problem: The change was made in revision 1.28 of TestRun.pm, if you want to have a look at it yourself. I have no idea how to fix this in a nice way, short of moving it into a wrapper that runs t/TEST, remembers the exit status, then checks for coredumps afterwards and then exits accordingly. Have fun, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: He answers his own question [was Failing mod_env tests]
On Tue, 28 Aug 2001, Gary Benson wrote: > On Tue, 28 Aug 2001, Ryan Bloom wrote: > > > On Tuesday 28 August 2001 06:21, Gary Benson wrote: > > > On Tue, 28 Aug 2001, Gary Benson wrote: > > > > I'm getting failures on a couple of the mod_env tests, specifically 2 > > > > and > > > > 4, both tests which test UnsetEnv. Has anyone else had this? > > > > > > Ah, I see that Doug fixed a bug here in httpd-2.0. Is there any chance of > > > this fix appearing in 1.3.x? > > > > It is incredibly unlikely. I've backported the fix to 1.3.20 and filed it as a change-request. In case any of you feel like advocating it then it is PR#8254... Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: Minor update
On Tue, 28 Aug 2001, Justin Erenkrantz wrote: > On Tue, Aug 28, 2001 at 06:25:42PM +0100, Gary Benson wrote: > > > > Hi, > > > > Can I propose that someone remove the .conf files from the .cvsignore in > > perl-framework/t/conf/ and make it ignore *.conf instead? > > You should get commit access to the httpd-test repository. =-) That would be grand :-)
Re: How to make the c-modules run?
On Tue, 28 Aug 2001, Doug MacEachern wrote: > i just made a change so the modules are compiled with -DAPACHEx (1 or > 2) if you're interested in porting. > > you'd just need to remove this line: > #define HTTPD_TEST_REQUIRE_APACHE 2 > > and do things conditionally based on #ifdef APACHE2, #ifdef APACHE1 Thanks! There's a couple of them that I want... Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Minor update
Hi, Can I propose that someone remove the .conf files from the .cvsignore in perl-framework/t/conf/ and make it ignore *.conf instead? Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: Fix for mod_access test
On Tue, 28 Aug 2001, Doug MacEachern wrote:
> On Tue, 28 Aug 2001, Gary Benson wrote:
>
> > Is "my $localhost_name = Apache::TestConfig->default_localhost;" valid?
> > Should you not do this:
> >
> > my $env = Apache::TestConfig->thaw;
> > my $localhost_name = $env->{vars}->{servername};
>
> yeah, just trying to avoid thaw() multiple times.
> my $localhost_name = Apache::TestRequest::vars()->{servername};
>
> would be fine.
>
> Apache::TestRequest caches the thaw so it only happens once per-process.
Okay then, here's the new patch.
G
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Index: t/modules/access.t
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/modules/access.t,v
retrieving revision 1.3
diff -u -r1.3 access.t
--- t/modules/access.t 2001/08/24 18:19:30 1.3
+++ t/modules/access.t 2001/08/28 16:51:55
@@ -9,9 +9,10 @@
## mod_access test
##
+my $localhost_name = Apache::TestRequest::vars()->{servername};
my @localhost = (
'from all',
-'from localhost',
+"from $localhost_name",
'from 127.0.0.1',
'from 127.0',
'from 127.0.0.1/255.255.0.0',
@@ -26,8 +27,8 @@
plan tests => (@order * @allow * @deny * 2) + (@order * @allow),
test_module 'access';
-my $env = Apache::TestConfig->thaw;
-my $dir = "$env->{vars}->{t_dir}/htdocs/modules/access/htaccess";
+my $dir = Apache::TestRequest::vars()->{t_dir};
+$dir .= "/htdocs/modules/access/htaccess";
sub write_htaccess {
my $conf_str = shift;
@@ -58,8 +59,8 @@
## denying by default
if ($allow =~ /^from 127/
-|| $allow =~ /^from localhost$/
-|| $allow =~ /^from all$/) {
+|| $allow eq "from $localhost_name"
+|| $allow eq 'from all') {
## if we are explicitly allowed, its ok
print "expecting access.\n";
@@ -85,8 +86,8 @@
## allowing by default
if ($deny =~ /^from 127/
-|| $deny =~ /^from localhost$/
-|| $deny =~ /^from all$/) {
+|| $deny eq "from $localhost_name"
+|| $deny eq 'from all') {
## if we are denied explicitly
## its not ok
@@ -120,8 +121,8 @@
## allowing by default
if ($allow =~ /^from 127/
-|| $allow =~ /^from localhost$/
-|| $allow =~ /^from all$/) {
+|| $allow eq "from $localhost_name"
+|| $allow eq 'from all') {
## we are explicitly allowed
## so it is ok.
@@ -129,8 +130,8 @@
ok GET_OK "/modules/access/htaccess/index.html";
} elsif ($deny =~ /^from 127/
-|| $deny =~ /^from localhost$/
-|| $deny =~ /^from all$/) {
+|| $deny eq "from $localhost_name"
+|| $deny eq 'from all') {
## if we are not explicitly allowed
## and are explicitly denied,
@@ -152,8 +153,8 @@
## denying by default
if ($deny =~ /^from 127/
-|| $deny =~ /^from localhost$/
-|| $deny =~ /^from all$/) {
+|| $deny eq "from $localhost_name"
+|| $deny eq 'from all') {
## if we are explicitly denied,
## we get no access.
@@ -161,8 +162,8 @@
ok !GET_OK "/modules/access/htaccess/index.html";
} elsif ($allow =~ /^from 127/
-|| $allow =~ /^from localhost$/
-|| $allow =~ /^from all$/) {
+|| $allow eq "from $localhost_name"
+|| $allow eq 'from all') {
## if we are not explicitly denied
## and are explicitly allowed,
Re: Fix for mod_access test
On Tue, 28 Aug 2001, Doug MacEachern wrote:
> On Tue, 28 Aug 2001, Gary Benson wrote:
>
> > The tests for mod_access fail if 127.0.0.1 does not resolve as "localhost"
> > (mine resolves as "localhost.localdomain"). This patch fixes it.
>
> excellent! however, your patch did not apply for me, maybe you needed to
> cvs up first? the first two hunks applied with offset, so that would seem
> to be the case.
> i added your code to determine localhost to Apache::TestConfig, so you can
> say:
>
> my $localhost_name = Apache::TestConfig->default_localhost;
>
> if you could resubmit against the current version using that method, that
> would be great. thanks.
Is "my $localhost_name = Apache::TestConfig->default_localhost;" valid?
Should you not do this:
my $env = Apache::TestConfig->thaw;
my $localhost_name = $env->{vars}->{servername};
instead?
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Configuration collision
Hi, I've found a clash between the tests modules/vhost_alias and modules/alias which is causing vhost_alias tests to fail. I'm not at all sure whether it should be failing or not, but this is my take on what is happening: For example, look at this excerpt from "t/TEST -v modules/vhost_alias": | [VirtualScriptAlias test] | expected: ->test cgi for www.vha-test.com<- | actual: -> | | 404 Not Found | | Not Found | The requested URL /cgi-bin/test-cgi.sh was not found on this server. | <- | not ok 2 This _should_ have executed @SERVERROOT@/modules/vhost_alias/www.vha-test.com/test-cgi.sh, but looking in the error_log, we find this: | [Tue Aug 28 16:12:33 2001] [error] [client 127.0.0.1] \ | script not found or unable to stat: \ | /home/gary/work/httpd-test/perl-framework/t/htdocs/modules/alias/bin In t/conf/extra.conf.in, mod_alias section, we have this line: | ScriptAliasMatch /cgi-(.*) @SERVERROOT@/htdocs/modules/alias/$1 which has intercepted the call. Is this just failing because I'm using Apache 1.3, or does it fail on httpd-2.0 as well? Any suggestions as to what to do about it? Cheers, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Patch to make vhost_alias.t mkdir() properly
This was silently failing to make the directories on my box (according to
the camel book, the second, MODE, argument to mkdir is mandatory)
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Index: t/modules/vhost_alias.t
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/modules/vhost_alias.t,v
retrieving revision 1.1
diff -u -r1.1 vhost_alias.t
--- t/modules/vhost_alias.t 2001/08/27 22:55:39 1.1
+++ t/modules/vhost_alias.t 2001/08/28 15:16:53
@@ -18,7 +18,12 @@
local $vars->{port} = $config->port('mod_vhost_alias');
## test environment setup ##
-mkdir "htdocs/modules/vhost_alias" unless -e "htdocs/modules/vhost_alias";
+my $mode = oct('755');
+unless( -e "htdocs/modules/vhost_alias" ) {
+mkdir("htdocs/modules/vhost_alias", $mode)
+ or die "can't mkdir htdocs/modules/vhost_alias: $!";
+}
+
my @d = ();
foreach (@vh) {
my @part = split /\./, $_;
@@ -31,7 +36,7 @@
} else {
$d .= "_";
}
-mkdir $d or die "cant mkdir $d: $!";
+mkdir($d, $mode) or die "cant mkdir $d: $!";
$d .= "/";
## %1.4 ##
@@ -40,7 +45,7 @@
} else {
$d .= substr($part[0], 3, 1);
}
-mkdir $d or die "cant mkdir $d: $!";
+mkdir($d, $mode) or die "cant mkdir $d: $!";
$d .= "/";
## %-2 ##
@@ -49,7 +54,7 @@
} else {
$d .= "_";
}
-mkdir $d or die "cant mkdir $d: $!";
+mkdir($d, $mode) or die "cant mkdir $d: $!";
$d .= "/";
## %2+ ##
@@ -57,7 +62,7 @@
$d .= $part[$i];
$d .= "." if $part[$i+1];
}
-mkdir $d or die "cant mkdir $d: $!";
+mkdir($d, $mode) or die "cant mkdir $d: $!";
## save directory for later deletion ##
push (@d, $d);
@@ -69,7 +74,7 @@
## create directories for VirtualScriptAlias tests ##
$d = "htdocs/modules/vhost_alias/$_";
-mkdir $d or die "cant create $d: $!";
+mkdir($d, $mode) or die "cant create $d: $!";
push(@d, $d);
$d .= "/";
Re: How to make the c-modules run?
On Tue, 28 Aug 2001, Stas Bekman wrote: > On Tue, 28 Aug 2001, Gary Benson wrote: > > > On Tue, 28 Aug 2001, Stas Bekman wrote: > > > > > On Tue, 28 Aug 2001, Gary Benson wrote: > > > > > > > Hi, > > > > > > > > When I run the perl test script a number of tests are skipped. I think > > > > this is something to do with the fact that the stuff in c-modules never > > > > gets built -- my c-modules/Makefile looks like this: > > > > > > > > | MAKE = make > > > > | clean: > > > > | > > > > | all: > > > > | > > > > > > > > Should I be doing something special to make the c-modules get built? > > > > The only notable error I ever see is that "apxs -q BINDIR" fails twice > > > > whilst configuring the server. I don't know if this is an Apache 2.x > > > > thing > > > > since I'm using 1.3.20, but if it is could someone please advise me as > > > > to > > > > where it should point. > > > > > > Try the latest cvs, rbb has committed my patch a few hours ago. > > > > > > e.g. it works now: > > > > > > % /home/stas/httpd-2.0/bin/apxs -q BINDIR > > > /home/stas/httpd-2.0/bin > > > > But this is for 2.0; what is the 1.3 equivalent of the BINDIR? SBINDIR? > > Mine is built statically so I cannot test, but from looking at apxs in > 1.3, yes, it's SBINDIR. Okay, thanks. I can see I'm going to have to checkout a copy of 2.0, if only to check the breaking tests against it ;-) BTW, is anyone on this list trying to use httpd-test on 1.3, or am I on my own here? Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: How to make the c-modules run?
On Tue, 28 Aug 2001, Stas Bekman wrote: > On Tue, 28 Aug 2001, Gary Benson wrote: > > > > > Hi, > > > > When I run the perl test script a number of tests are skipped. I think > > this is something to do with the fact that the stuff in c-modules never > > gets built -- my c-modules/Makefile looks like this: > > > > | MAKE = make > > | clean: > > | > > | all: > > | > > > > Should I be doing something special to make the c-modules get built? > > The only notable error I ever see is that "apxs -q BINDIR" fails twice > > whilst configuring the server. I don't know if this is an Apache 2.x thing > > since I'm using 1.3.20, but if it is could someone please advise me as to > > where it should point. > > Try the latest cvs, rbb has committed my patch a few hours ago. > > e.g. it works now: > > % /home/stas/httpd-2.0/bin/apxs -q BINDIR > /home/stas/httpd-2.0/bin But this is for 2.0; what is the 1.3 equivalent of the BINDIR? SBINDIR?
Re: He answers his own question [was Failing mod_env tests]
On Tue, 28 Aug 2001, Ryan Bloom wrote:
> On Tuesday 28 August 2001 06:21, Gary Benson wrote:
> > On Tue, 28 Aug 2001, Gary Benson wrote:
> > > I'm getting failures on a couple of the mod_env tests, specifically 2 and
> > > 4, both tests which test UnsetEnv. Has anyone else had this?
> >
> > Ah, I see that Doug fixed a bug here in httpd-2.0. Is there any chance of
> > this fix appearing in 1.3.x?
>
> It is incredibly unlikely.
>
> Ryan
In case you want it, here's my patch to disable the failing tests under
Apache 1.x. I'm not sure if it should be comitted or not -- is it The
Right Thing to disable tests that don't work in some versions? I don't
know, at any rate.
Gary
Index: t/modules/env.t
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/modules/env.t,v
retrieving revision 1.3
diff -u -r1.3 env.t
--- t/modules/env.t 2001/08/24 01:17:45 1.3
+++ t/modules/env.t 2001/08/28 13:40:05
@@ -3,6 +3,7 @@
use Apache::Test;
use Apache::TestRequest;
+use Apache::TestConfig;
##
## mod_env tests
@@ -15,6 +16,12 @@
'type' => '(none)',
'nothere' => '(none)'
);
+
+my $env = Apache::TestConfig->thaw;
+if( $env->{server}->{rev} == 1 ) {
+delete $test{type};
+delete $test{nothere};
+}
plan tests => (keys %test) * 1, test_module('env', 'include');
He answers his own question [was Failing mod_env tests]
On Tue, 28 Aug 2001, Gary Benson wrote: > I'm getting failures on a couple of the mod_env tests, specifically 2 and > 4, both tests which test UnsetEnv. Has anyone else had this? Ah, I see that Doug fixed a bug here in httpd-2.0. Is there any chance of this fix appearing in 1.3.x?
Failing mod_env tests
Hi again, I'm getting failures on a couple of the mod_env tests, specifically 2 and 4, both tests which test UnsetEnv. Has anyone else had this? Gary PS Apache/1.3.20 [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
How to make the c-modules run?
Hi, When I run the perl test script a number of tests are skipped. I think this is something to do with the fact that the stuff in c-modules never gets built -- my c-modules/Makefile looks like this: | MAKE = make | clean: | | all: | Should I be doing something special to make the c-modules get built? The only notable error I ever see is that "apxs -q BINDIR" fails twice whilst configuring the server. I don't know if this is an Apache 2.x thing since I'm using 1.3.20, but if it is could someone please advise me as to where it should point. Cheers, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Fix for mod_access test
Hi all,
The tests for mod_access fail if 127.0.0.1 does not resolve as "localhost"
(mine resolves as "localhost.localdomain"). This patch fixes it.
I changed the regexp matches to explicit equals where possible, since
changing /^from localhost$/ to /^from $localhost_name$/ could hide all
kinds of problems when there are dots in the hostnames.
Oh, and it needs the Socket package to access the constant AF_INET...
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Index: t/modules/access.t
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/modules/access.t,v
retrieving revision 1.2
diff -u -r1.2 access.t
--- t/modules/access.t 2001/08/08 17:53:10 1.2
+++ t/modules/access.t 2001/08/28 09:56:40
@@ -4,14 +4,18 @@
use Apache::Test;
use Apache::TestRequest;
use Apache::TestConfig;
+use Socket;
##
## mod_access test
##
+my $localhost_addr = pack('C4', 127, 0, 0, 1);
+my $localhost_name = gethostbyaddr($localhost_addr, AF_INET);
+
my @localhost = (
'from all',
-'from localhost',
+"from $localhost_name",
'from 127.0.0.1',
'from 127.0',
'from 127.0.0.1/255.255.0.0',
@@ -47,8 +51,8 @@
## denying by default
if ($allow =~ /^from 127/
-|| $allow =~ /^from localhost$/
-|| $allow =~ /^from all$/) {
+|| $allow eq "from $localhost_name"
+|| $allow eq 'from all') {
## if we are explicitly allowed, its ok
ok GET_OK "/modules/access/htaccess/index.html";
@@ -71,8 +75,8 @@
## allowing by default
if ($deny =~ /^from 127/
-|| $deny =~ /^from localhost$/
-|| $deny =~ /^from all$/) {
+|| $deny eq "from $localhost_name"
+|| $deny eq 'from all') {
## if we are denied explicitly
## its not ok
@@ -102,16 +106,16 @@
## allowing by default
if ($allow =~ /^from 127/
-|| $allow =~ /^from localhost$/
-|| $allow =~ /^from all$/) {
+|| $allow eq "from $localhost_name"
+|| $allow eq 'from all') {
## we are explicitly allowed
## so it is ok.
ok GET_OK "/modules/access/htaccess/index.html";
} elsif ($deny =~ /^from 127/
-|| $deny =~ /^from localhost$/
-|| $deny =~ /^from all$/) {
+|| $deny eq "from $localhost_name"
+|| $deny eq 'from all') {
## if we are not explicitly allowed
## and are explicitly denied,
@@ -131,16 +135,16 @@
## denying by default
if ($deny =~ /^from 127/
-|| $deny =~ /^from localhost$/
-|| $deny =~ /^from all$/) {
+|| $deny eq "from $localhost_name"
+|| $deny eq 'from all') {
## if we are explicitly denied,
## we get no access.
ok !GET_OK "/modules/access/htaccess/index.html";
} elsif ($allow =~ /^from 127/
-|| $allow =~ /^from localhost$/
-|| $allow =~ /^from all$/) {
+|| $allow eq "from $localhost_name"
+|| $allow eq 'from all') {
## if we are not explicitly denied
## and are explicitly allowed,
Re: mod_access?
On Fri, 24 Aug 2001, Doug MacEachern wrote: > On Fri, 24 Aug 2001, Gary Benson wrote: > > > | 127.0.0.1 slippy localhost localhost.localdomain > > > > will fail. It's the next thing on my list of things to fix, and will > > probably get done on Tuesday if nobody else has done it before... > > that would be cool. same problem had bitten me. we could just open/parse > /etc/hosts and warn if localhost is not first. or did you have something > else in mind? I was planning to have a look at how apache resolved 127.0.0.1...
Re: mod_access?
(I think, but am not sure, that: | 127.0.0.1 localhost.localdomain localhost will fail as well)
Re: mod_access?
On Fri, 24 Aug 2001, Cliff Woolley wrote: > I'm getting failures in the mod_access tests: > > Failed Test Status Wstat Total Fail Failed List of failed > --- > modules/access. 408 31 7.60% 4, 20-21, 24, 26, 28, 30, 38, > 55, > 72, 89, 106-107, 123-124, 141, > 154, 168, 170, 175, 192, 209, > 226, 277, 290, 304, 306, 311, > 328, 345, 362 > > These have always failed for me, though Doug tells me they work for him. > It's probably a configuration issue somehow. Any ideas? I do have an > entry for localhost in my /etc/hosts file, btw. The entry for localhost must be the _first_ entry on the line, ie | 127.0.0.1 localhost localhost.localdomain is fine, but: | 127.0.0.1 slippy localhost localhost.localdomain will fail. It's the next thing on my list of things to fix, and will probably get done on Tuesday if nobody else has done it before... Later, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Date problems in expires.t?
Hi all, My build has suddenly started failing modules/expires.t test number two. I've think I've _almost_ nailed it, but paperwork is beckoning and I'm probably not going to be able to finish fixing it. So, if anyone else does notice the problem, hopefully this will be a head start for them: The failing test relies on the assumption that "10 years, 6 months, 2 weeks, 3 days, 12 hours, 30 minutes and 19 seconds" (in t/conf/expires.conf.in) is _always_ equal to 332,256,619 seconds (in t/modules/expires.t). I don't think that this is always the case -- I think it varies depending on exactly _when_ you calculate it from. Have fun with that one, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: starting 'writing tests' doc?
I have no problems with writing some docs once I start writing tests. I'm away for the rest of this week, though, so don't expect anything soon... Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ] On Mon, 13 Aug 2001, Stas Bekman wrote: > Hey guys, what do you think about starting a document that explains how to > write tests for the perl-framework. Using the existing tests as an example > is cool, but having a well thought-out doc would make it easier for other > people to write more tests. At the end of the day we get a better > coverage. > > John and Gary, do you think you will have some time to share some of your > expertise as you acquire it? Once we get the doc done, it'd be nice to > start pitching to other developers to write tests, resulting in less work > for the rest of us :) > > Eventually this doc, should become one of the chapters in the soon to be > started 'core mod_perl developer guide' as outlined here: > http://forum.swarthmore.edu/epigone/modperl/ginthandswang > > Your help is very appreciated. > > _ > Stas Bekman JAm_pH -- Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide http://perl.apache.org/guide > mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ > http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ > >
Re: Ensure paths for EAPI exist
On Fri, 10 Aug 2001, Doug MacEachern wrote: > thanks, looks good, applied. Thank you, Gary
Re: Fix for php func5 test
You're welcome... On Fri, 10 Aug 2001, john sachs wrote: > oh, cool thanks! > > On Fri, Aug 10, 2001 at 01:59:50PM +0100, Gary Benson wrote: > + > + For some reason, not all builds of PHP send output from shutdown functions > + to the error log. This patch makes damn sure that the message goes there. > + > + Gary > [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
RE: Changes to server config: opinions wanted
On Fri, 10 Aug 2001, Geoffrey Young wrote: > > > -Original Message- > > From: Gary Benson [mailto:[EMAIL PROTECTED] > > Sent: Friday, August 10, 2001 6:06 AM > > To: [EMAIL PROTECTED] > > Subject: Changes to server config: opinions wanted > > > > Hi all, > > > > I've been comparing httpd-test/perl-framework with our > > prototype in-house > > apache tester, and the main difference I've found has been > > that our tests > > carry what configuration directives they need inside the .t > > files; there > > is no extra.conf. This makes the tests more self-contained, > > and has the > > advantage that it allows each test to be carried out in different > > `contexts' -- the same test can be run with its directives in the main > > configuration, in a vhost or in .htaccess files. > > > > [Basically, each test calls the function UseConfigurationDirectives(), > > which generates the configuration and SIGHUPs httpd. There is also a > > method for tests to specify contexts in which they may/may > > not be run.] > > > > I'm quite happy to port this functionality to httpd-test -- it isn't a > > massive change -- but before I start (in earnest) I'd like to know if > > anybody thinks it would break anything. > > are you suggesting removing the extra.conf functionality, or making it > either/or? > > extra.conf is extremely convenient... > > --Geoff Very definitely either/or at the moment. That way I can implement it, and if it _does_ break something it can be easily removed. Gary
Fix for php func5 test
For some reason, not all builds of PHP send output from shutdown functions
to the error log. This patch makes damn sure that the message goes there.
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Index: t/htdocs/php/func5.php
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/htdocs/php/func5.php,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 func5.php
--- t/htdocs/php/func5.php 2001/07/30 19:37:14 1.1.1.1
+++ t/htdocs/php/func5.php 2001/08/10 12:55:15
@@ -2,7 +2,7 @@
function foo()
{
-print "foo() has been called.\n";
+error_log("foo() has been called.", 0);
}
register_shutdown_function("foo");
Index: t/php/func5.t
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/php/func5.t,v
retrieving revision 1.3
diff -u -r1.3 func5.t
--- t/php/func5.t 2001/08/09 17:24:43 1.3
+++ t/php/func5.t 2001/08/10 12:55:15
@@ -18,9 +18,6 @@
## open error_log and verify the last line is:
## foo() has been called.
-##
-## this is kind of lame and may not work...i dont know how php is
-## SUPPPOSED to work in this situation...
my $error_log = "$env->{vars}->{t_logs}/error_log";
open(ERROR_LOG, $error_log);
Ensure paths for EAPI exist
Hi all,
Another patch...
If you have mod_ssl's EAPI compiled in, then Apache trys to write files to
a location defined in EAPI_MM_CORE_PATH. If this path does not exist then
httpd can't start and TestServer::start fails.
You can't override this path with configuration directives; you just have
to live with whatever it's set to. This patch ensures that the path exists.
Hope it's ok,
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Index: Apache-Test/lib/Apache/TestConfig.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.14
diff -u -r1.14 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm2001/08/07 16:18:32 1.14
+++ Apache-Test/lib/Apache/TestConfig.pm2001/08/10 11:52:40
@@ -5,7 +5,8 @@
use constant WIN32 => $^O eq 'MSWin32';
-use File::Spec::Functions qw(catfile abs2rel splitdir);
+use File::Spec::Functions qw(catfile abs2rel splitdir
+ catdir file_name_is_absolute);
use Cwd qw(fastcwd);
use Apache::TestConfigPerl ();
@@ -155,6 +156,7 @@
$self->configure_apxs;
$self->configure_httpd;
$self->inherit_config; #see TestConfigParse.pm
+$self->configure_httpd_eapi; #must come after inherit_config
$self->{hostport} = $self->hostport;
@@ -201,6 +203,25 @@
my $sem = catfile $vars->{t_logs}, 'apache_runtime_status.sem';
unless (-e $sem) {
$self->{clean}->{files}->{$sem} = 1;
+}
+}
+
+sub configure_httpd_eapi {
+my $self = shift;
+my $vars = $self->{vars};
+
+#deal with EAPI_MM_CORE_PATH if defined.
+if (defined($self->{httpd_defines}->{EAPI_MM_CORE_PATH})) {
+my $path = $self->{httpd_defines}->{EAPI_MM_CORE_PATH};
+
+#ensure the directory exists
+my @chunks = splitdir $path;
+pop @chunks; #the file component of the path
+$path = catdir @chunks;
+unless (file_name_is_absolute $path) {
+$path = catdir $vars->{serverroot}, $path;
+}
+$self->gendir($path);
}
}
Changes to server config: opinions wanted
Hi all, I've been comparing httpd-test/perl-framework with our prototype in-house apache tester, and the main difference I've found has been that our tests carry what configuration directives they need inside the .t files; there is no extra.conf. This makes the tests more self-contained, and has the advantage that it allows each test to be carried out in different `contexts' -- the same test can be run with its directives in the main configuration, in a vhost or in .htaccess files. [Basically, each test calls the function UseConfigurationDirectives(), which generates the configuration and SIGHUPs httpd. There is also a method for tests to specify contexts in which they may/may not be run.] I'm quite happy to port this functionality to httpd-test -- it isn't a massive change -- but before I start (in earnest) I'd like to know if anybody thinks it would break anything. I can see the tests taking a bit longer to run, but would it, for example, make the smoke-tests less valid? Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: perl-framework/t/php/func5.t failure
Thanks.
On Thu, 9 Aug 2001, john sachs wrote:
> ah.
> i see where this is going.
> i will make the fix.
> -j
>
> On Thu, Aug 09, 2001 at 06:06:41PM +0100, Gary Benson wrote:
> +
> + What does "httpd -V | grep DEFAULT_ERRORLOG" say in your setup?
> +
> + On Thu, 9 Aug 2001, john sachs wrote:
> +
> + > the test finds my error log ok...
> + >
> + > On Thu, Aug 09, 2001 at 05:39:20PM +0100, Gary Benson wrote:
> + > +
> + > + Does the test itself work correctly for you, though? I have to have my
> + > + patched version for it to be able to find the error_log.
> + > +
> + > + Gary
> + > +
> + > + On Thu, 9 Aug 2001, john sachs wrote:
> + > +
> + > + [snip]
> + > + > that text was getting dumped into the error_log with the build of
> + > + > PHP/4.0.4pl1 i had. but apparently that may not be correct. it boils
> + > + > down to i dont really know what the expected behavior is for this
> + > + > testcase. if anyone does know, id love to have that info.
> + > + > -j
> + > + >
> + > + > On Thu, Aug 09, 2001 at 05:08:51PM +0100, Gary Benson wrote:
> + > + > +
> + > + > + Hi all,
> + > + > +
> + > + > + Test 2 of 2 in t/php/func5.t does not correctly locate the logfile
> -- I
> + > + > + don't know if it is just my setup or what. Anyway, the patch below
> makes
> + > + > + the test use the same variable that is used during generation of
> + > + > + t/conf/httpd.conf in Apache-Test/lib/Apache/TestConfig.pm.
> + > + > +
> + > + > + Even now I have it correctly finding the logfile, it still doesn't
> work --
> + > + > + PHP just isn't logging the entry it is expecting to find. Has
> anybody else
> + > + > + had this problem?
> + > + > +
> + > + > + Gary
> + > + > +
> + > + > + [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG
> 60E8793A ]
> + > + > +
> + > + > +
> + > + > + Index: perl-framework/t/php/func5.t
> + > + > + ===
> + > + > + RCS file: /home/cvspublic/httpd-test/perl-framework/t/php/func5.t,v
> + > + > + retrieving revision 1.2
> + > + > + diff -u -r1.2 func5.t
> + > + > + --- t/php/func5.t 2001/07/30 19:50:45 1.2
> + > + > + +++ t/php/func5.t 2001/08/09 15:59:06
> + > + > + @@ -5,6 +5,7 @@
> + > + > + use Apache::TestRequest;
> + > + > + use Apache::TestConfig;
> + > + > + use ExtModules::TestEnv;
> + > + > + +use File::Spec::Functions qw(catfile);
> + > + > +
> + > + > + plan tests => 2, \&ExtModules::TestEnv::has_php4;
> + > + > +
> + > + > + @@ -23,7 +24,7 @@
> + > + > + ## this is kind of lame and may not work...i dont know how php is
> + > + > + ## SUPPPOSED to work in this situation...
> + > + > +
> + > + > + -my $error_log = $env->{httpd_defines}->{DEFAULT_ERRORLOG};
> + > + > + +my $error_log = catfile $env->{vars}->{t_logs}, "error_log";
> + > + > + open(ERROR_LOG, $error_log);
> + > + > + my @log = ;
> + > + > + $result = pop @log;
> + > + > +
> + > + > +
> + > + > +
> + > + >
> + > +
> + > + [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
> + > +
> + > +
> + > +
> + >
> +
> + [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
> +
>
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: perl-framework/t/php/func5.t failure
What does "httpd -V | grep DEFAULT_ERRORLOG" say in your setup?
On Thu, 9 Aug 2001, john sachs wrote:
> the test finds my error log ok...
>
> On Thu, Aug 09, 2001 at 05:39:20PM +0100, Gary Benson wrote:
> +
> + Does the test itself work correctly for you, though? I have to have my
> + patched version for it to be able to find the error_log.
> +
> + Gary
> +
> + On Thu, 9 Aug 2001, john sachs wrote:
> +
> + [snip]
> + > that text was getting dumped into the error_log with the build of
> + > PHP/4.0.4pl1 i had. but apparently that may not be correct. it boils
> + > down to i dont really know what the expected behavior is for this
> + > testcase. if anyone does know, id love to have that info.
> + > -j
> + >
> + > On Thu, Aug 09, 2001 at 05:08:51PM +0100, Gary Benson wrote:
> + > +
> + > + Hi all,
> + > +
> + > + Test 2 of 2 in t/php/func5.t does not correctly locate the logfile -- I
> + > + don't know if it is just my setup or what. Anyway, the patch below makes
> + > + the test use the same variable that is used during generation of
> + > + t/conf/httpd.conf in Apache-Test/lib/Apache/TestConfig.pm.
> + > +
> + > + Even now I have it correctly finding the logfile, it still doesn't work
> --
> + > + PHP just isn't logging the entry it is expecting to find. Has anybody
> else
> + > + had this problem?
> + > +
> + > + Gary
> + > +
> + > + [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
> + > +
> + > +
> + > + Index: perl-framework/t/php/func5.t
> + > + ===
> + > + RCS file: /home/cvspublic/httpd-test/perl-framework/t/php/func5.t,v
> + > + retrieving revision 1.2
> + > + diff -u -r1.2 func5.t
> + > + --- t/php/func5.t 2001/07/30 19:50:45 1.2
> + > + +++ t/php/func5.t 2001/08/09 15:59:06
> + > + @@ -5,6 +5,7 @@
> + > + use Apache::TestRequest;
> + > + use Apache::TestConfig;
> + > + use ExtModules::TestEnv;
> + > + +use File::Spec::Functions qw(catfile);
> + > +
> + > + plan tests => 2, \&ExtModules::TestEnv::has_php4;
> + > +
> + > + @@ -23,7 +24,7 @@
> + > + ## this is kind of lame and may not work...i dont know how php is
> + > + ## SUPPPOSED to work in this situation...
> + > +
> + > + -my $error_log = $env->{httpd_defines}->{DEFAULT_ERRORLOG};
> + > + +my $error_log = catfile $env->{vars}->{t_logs}, "error_log";
> + > + open(ERROR_LOG, $error_log);
> + > + my @log = ;
> + > + $result = pop @log;
> + > +
> + > +
> + > +
> + >
> +
> + [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
> +
> +
> +
>
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: a few notes regarding httpd-test
On Fri, 10 Aug 2001, Stas Bekman wrote: > On Thu, 9 Aug 2001, Ryan Bloom wrote: > > > On Thursday 09 August 2001 05:10, Stas Bekman wrote: > > > * 'cvs co -c' doesn't include httpd-test module, only apachetest, which > > > includes Apache-Test only. > > > > We don't keep `cvs co -c` up to date. Brian believes this encourages > > people to check out everything all at once, which puts an undue strain > > on the CVS server. > > Is it possible to mirror the repositories via rsync if they are needed > only in the read-only mode? So this will remove the strain from the master > repository. Then we can advertise the mirrors and not the master > repository urn for anonymous CVS and disable anonymous CVS on the master > rep? I'm told that "rsync -avz cvs.apache.org::httpd-test-cvs httpd-test-cvs" works... Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: perl-framework/t/php/func5.t failure
Does the test itself work correctly for you, though? I have to have my
patched version for it to be able to find the error_log.
Gary
On Thu, 9 Aug 2001, john sachs wrote:
[snip]
> that text was getting dumped into the error_log with the build of
> PHP/4.0.4pl1 i had. but apparently that may not be correct. it boils
> down to i dont really know what the expected behavior is for this
> testcase. if anyone does know, id love to have that info.
> -j
>
> On Thu, Aug 09, 2001 at 05:08:51PM +0100, Gary Benson wrote:
> +
> + Hi all,
> +
> + Test 2 of 2 in t/php/func5.t does not correctly locate the logfile -- I
> + don't know if it is just my setup or what. Anyway, the patch below makes
> + the test use the same variable that is used during generation of
> + t/conf/httpd.conf in Apache-Test/lib/Apache/TestConfig.pm.
> +
> + Even now I have it correctly finding the logfile, it still doesn't work --
> + PHP just isn't logging the entry it is expecting to find. Has anybody else
> + had this problem?
> +
> + Gary
> +
> + [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
> +
> +
> + Index: perl-framework/t/php/func5.t
> + ===
> + RCS file: /home/cvspublic/httpd-test/perl-framework/t/php/func5.t,v
> + retrieving revision 1.2
> + diff -u -r1.2 func5.t
> + --- t/php/func5.t 2001/07/30 19:50:45 1.2
> + +++ t/php/func5.t 2001/08/09 15:59:06
> + @@ -5,6 +5,7 @@
> + use Apache::TestRequest;
> + use Apache::TestConfig;
> + use ExtModules::TestEnv;
> + +use File::Spec::Functions qw(catfile);
> +
> + plan tests => 2, \&ExtModules::TestEnv::has_php4;
> +
> + @@ -23,7 +24,7 @@
> + ## this is kind of lame and may not work...i dont know how php is
> + ## SUPPPOSED to work in this situation...
> +
> + -my $error_log = $env->{httpd_defines}->{DEFAULT_ERRORLOG};
> + +my $error_log = catfile $env->{vars}->{t_logs}, "error_log";
> + open(ERROR_LOG, $error_log);
> + my @log = ;
> + $result = pop @log;
> +
> +
> +
>
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
perl-framework/t/php/func5.t failure
Hi all,
Test 2 of 2 in t/php/func5.t does not correctly locate the logfile -- I
don't know if it is just my setup or what. Anyway, the patch below makes
the test use the same variable that is used during generation of
t/conf/httpd.conf in Apache-Test/lib/Apache/TestConfig.pm.
Even now I have it correctly finding the logfile, it still doesn't work --
PHP just isn't logging the entry it is expecting to find. Has anybody else
had this problem?
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Index: perl-framework/t/php/func5.t
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/php/func5.t,v
retrieving revision 1.2
diff -u -r1.2 func5.t
--- t/php/func5.t 2001/07/30 19:50:45 1.2
+++ t/php/func5.t 2001/08/09 15:59:06
@@ -5,6 +5,7 @@
use Apache::TestRequest;
use Apache::TestConfig;
use ExtModules::TestEnv;
+use File::Spec::Functions qw(catfile);
plan tests => 2, \&ExtModules::TestEnv::has_php4;
@@ -23,7 +24,7 @@
## this is kind of lame and may not work...i dont know how php is
## SUPPPOSED to work in this situation...
-my $error_log = $env->{httpd_defines}->{DEFAULT_ERRORLOG};
+my $error_log = catfile $env->{vars}->{t_logs}, "error_log";
open(ERROR_LOG, $error_log);
my @log = ;
$result = pop @log;
Re: Skipped tests
On Thu, 9 Aug 2001, Doug MacEachern wrote:
> On Thu, 9 Aug 2001, Gary Benson wrote:
>
> > | skip !&ExtModules::TestEnv::has_php4, GET_BODY("/php/add.php") eq '6';
>
> that only skips one test in a test file, so if you plan 60 php tests in a
> single file, you have to test that condition 60 times. not good.
> Apache::Test::plan lets you skip every test in a file in one shot.
Fair enough.
Skipped tests
In httpd-test's perl-framework tests, Apache::Test::plan is a wrapper
around Test::plan. Apache::Test::plan allows you to have a condition as
the last argument of the plan call; if the condition is not met, the test
is skipped. A test which will only be run if we have php4 looks like this:
| plan tests => 1, \&ExtModules::TestEnv::has_php4;
|
| my $result = GET_BODY "/php/add.php";
| ok $result eq '6';
Test also has the facility to define tests which can be conditionally
skipped. Here you say:
| plan tests => 1
|
| skip !&ExtModules::TestEnv::has_php4, GET_BODY("/php/add.php") eq '6';
[the first argument to Test::skip being skip_this_test]
Why, then, the duplication of functionality in Apache::Test? Is it just an
oversight, or is there something else going on that I haven't realised?
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: t/modules/rewrite tweaking
On Thu, 9 Aug 2001, Stas Bekman wrote:
> On Thu, 9 Aug 2001, Gary Benson wrote:
>
> > On Thu, 9 Aug 2001, Stas Bekman wrote:
> >
> > > Some methods of extreme programming suggest writing tests even before
> > > the code have been written
> >
> > I tried this once, for the lexical parser in a desktop calculator program
> > I wrote. It is a really liberating experience, and leads to greater
> > experimentation.
>
> the only problem is that usually to write some more advanced tests, you
> actually need to have some working code, since you have to debug the test
> itself.
>
> So I think that if you have this approach you write only the descriptions
> of the tests. Is that how you've done this?
The testing engine was fairly simple: it created an instance of the lexer
class, ran the test input through it and printed out a representation of
the list of tokens that the parser returned.
The tests were much more simple to construct that those in perl-framework,
but mine were unit tests rather than functional tests. The distinction is
important -- anyone who doesn't know the difference should skim through
http://c2.com/cgi/wiki?UnitTests and http://c2.com/cgi/wiki?FunctionalTests
I've attached the array of tests that I used, so that you can get an
idea of what I mean (but feel free to ignore it =))
What generally happens is that the tests evolve with the code. I wrote a
very basic lexer and wrote some tests for it. I added some more tokens to
the lexer, I added tests for those tokens.
The beauty of it all was that a few days later I realised that I had a
problem with the lexer -- the state machine that drove it couldn't cope
with something I wanted to do. After changing the state machine, the
original stuff was processed in a totally different way but the end result
should have been the same. The tester was a phenomenal help during the
changeover.
Once all the tests worked, I _knew_ that:
1. What I wanted the lexer to do was completely covered by the tests
2. The tests worked
and therefore:
3. The lexer did exactly what I wanted it to do.
What I was testing was a very small piece of code, so it was simple for me
to acheive this kind of certainty. To do the same for Apache will not be
a trivial task. It will be better if we can reach the stage where people
write tests for the modules as they write the modules, but we have some
catching up to do first.
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
my @tests=
(
### Very basic tests =
###
"","0 items\n",
" \f\n\r\t\xb","0 items\n",
"", "RCalcSeparator\n" x 3,
"hello world", "RCalcString: `hello'\nRCalcString: `world'\n",
###
Test the various commands ###
###
# Command tests are grouped into groups with similar usage; for
# example rm, lock and unlock all have identical command line
# formats, so a test performed on one should be performed on all
# three.
### EXIT and QUIT tests ==
###
# Check they are recognised.
#
"exit", "RCalcCommand: $commands{'RC_COMMAND_EXIT'}\n",
"quit", "RCalcCommand: $commands{'RC_COMMAND_EXIT'}\n",
"\texit\n ","RCalcCommand: $commands{'RC_COMMAND_EXIT'}\n",
"\tquit\n ","RCalcCommand: $commands{'RC_COMMAND_EXIT'}\n",
# Check that they bin out if followed by anything.
#
"exit;",$errors{'EXIT_USAGE'},
"quit;",$errors{'QUIT_USAGE'},
"\texit\n ;", $errors{'EXIT_USAGE'},
"\tquit\n ;", $errors{'QUIT_USAGE'},
"exit ; exit", $errors{'EXIT_USAGE'},
"quit ; quit", $errors{'QUIT_USAGE'},
"exit exit",$errors{'EXIT_USAGE'},
"quit quit",$errors{'QUIT_USAGE'},
### MAN, HELP and ? tests
###
# Check they are recognised. Man will bomb out since its argument is mandatory.
#
"help", "RCalcCommand: $commands{'RC_COMMAND_HELP'}\n",
"?","RCalcCommand: $commands{'RC_COMMAND_HELP'}\n",
"man", $errors{'MAN_USAGE'},
# Check that the topics are recognised.
#
"help topic",
"RCalcCommand: $commands{'RC_COMMAND_HELP'}
RCalcString: `topic'
",
"? topic",
"RCalcCommand: $commands{'RC_COMMAND_HELP'}
RCalcString: `topic'
&quo
Re: t/modules/rewrite tweaking
On Thu, 9 Aug 2001, Stas Bekman wrote: > Some methods of extreme programming suggest writing tests even before > the code have been written I tried this once, for the lexical parser in a desktop calculator program I wrote. It is a really liberating experience, and leads to greater experimentation. If you have tests for everything that can go wrong (this being the difficult bit), rather than saying "I think this change works: it doesn't _seem_ to break anything", you merely run the tests over it and _know_ that it hasn't broken anything.
Re: License status
On Wed, 8 Aug 2001, Doug MacEachern wrote: > On Wed, 8 Aug 2001, Gary Benson wrote: > > > > > What license are these tests released under? I'm presuming they are under > > the ASL... > > yes, i've added a copy of the LICENSE to the top-level directory. Just spotted it. Thanks for merging my patch as well...
License status
What license are these tests released under? I'm presuming they are under the ASL...
Improvement to httpd version detection
Hi all,
The code that parses "httpd -v" fails when the first item in the server
version line is not "Apache/x.y.z". This affects Stronghold (which reports
itself as "Stronghold/n.m Apache/x.y.z (Unix)") and possible other things
as well.
Anyway, here is a patch to fix it. It looks for the "Apache/" in the
server version string and returns that. If this isn't found then it
reverts to the previous behaviour and returns the first element of server
version.
Hope it's suitable,
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Index: perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm,v
retrieving revision 1.4
diff -u -r1.4 TestConfigParse.pm
--- perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm2001/05/08
05:17:241.4
+++ perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm2001/08/08
12:38:55
@@ -226,7 +226,13 @@
while (<$v>) {
next unless s/^Server\s+version:\s*//i;
chomp;
-$version = (split)[0];
+my @parts = split;
+foreach (@parts) {
+next unless /^Apache\//;
+$version = $_;
+last;
+}
+$version or $version = $parts[0];
last;
}
Re: Belated introduction
On Tue, 7 Aug 2001, Justin Erenkrantz wrote: > Welcome. =-) There are no stupid questions... That's always nice... > Are you looking for something that does more functional testing or load > testing? Definitely functional testing at the moment. We have a prototype that someone wrote several years ago, which has been picking up dust ever since then. It seems that it is very similar to httpd-test/perl-framework, so it makes sense to use that instead.
Belated introduction
I suppose that I should have introduced myself to you all before my first post, but I had a head full of code and I forgot :-] So here goes: I've just started working for Red Hat, with Mark Cox and Joe Orton (amongst others), and I'm looking at replacing their prototype live testing thing with httpd-test. I'm going to be writing a bunch of tests which will hopefully get merged into httpd-test, if you like them. I'm currently getting up to speed with the internals of Apache, and trying very hard not to ask stupid questions, so please be considerate if I suddenly ask something stupid ;-) Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: Apache::BuildConfig
On Tue, 7 Aug 2001, Doug MacEachern wrote: > On Tue, 7 Aug 2001, Gary Benson wrote: > > > I've been trying to get httpd-test up and running; could someone please > > point me in the direction of the module Apache::BuildConfig? > > that is generated by modperl-2.0. it is optional for httpd-test and is > only used as a hint to locate apxs. you can help the tests find it by > putting the path to apxs in your PATH or define APXS in your enviornment > or run 't/TEST apxs /path/to/apxs' Okay, thanks.
Apache::BuildConfig
Hi all, I've been trying to get httpd-test up and running; could someone please point me in the direction of the module Apache::BuildConfig? Thanks in advance, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
