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/ ]
[bug] 404 served instead of 401
Hi, I found a bug whereby Apache 1.3.22 inconsistently handles the interaction between aliases to non-existant paths and authentication. If the alias is specified as an absolute path then a 401 is always served, but if the alias is a relative path then in some cases a 404 will be served. I don't see this as a security threat -- an attacker could see that you are dozy and have specified non-existant paths doesn't really instill fear -- but it nevertheless is leaking information which it probably shouldn't. To test it for yourselves, take one apache-1.3.22 tarball, configure, make and make install. I did it in /usr/local/apache, so you'll probably want to sed the patch if you try it somewhere else. $ cd /usr/local/apache $ patch -p0 httpd.conf.patch # attached $ mv htdocs/manual . $ ln -s nowhere htdocs/broken $ bin/apachectl start Finally, run test.sh. An annotated version of its output is as follows: * Not an alias and not present in the docroot http://localhost:8080/Xmanual 401 http://localhost:8080/Xmanual/ 401 * Alias to an existing path http://localhost:8080/0manual 401 http://localhost:8080/0manual/ 401 * Aliases to non-existant relative paths http://localhost:8080/1manual 401 http://localhost:8080/1manual/ 404 http://localhost:8080/2manual 404 http://localhost:8080/2manual/ 404 http://localhost:8080/3manual 404 http://localhost:8080/3manual/ 404 http://localhost:8080/4manual 401 http://localhost:8080/4manual/ 404 * Aliases to non-existant absolute paths http://localhost:8080/5manual 401 http://localhost:8080/5manual/ 401 http://localhost:8080/6manual 401 http://localhost:8080/6manual/ 401 http://localhost:8080/7manual 401 http://localhost:8080/7manual/ 401 http://localhost:8080/8manual 401 http://localhost:8080/8manual/ 401 * Aliases to a relative path to a broken symlink http://localhost:8080/9manual 401 http://localhost:8080/9manual/ 404 http://localhost:8080/Amanual 404 http://localhost:8080/Amanual/ 404 http://localhost:8080/Bmanual 404 http://localhost:8080/Bmanual/ 404 http://localhost:8080/Cmanual 401 http://localhost:8080/Cmanual/ 404 * Aliases to an absolute path to a broken symlink http://localhost:8080/Dmanual 401 http://localhost:8080/Dmanual/ 401 http://localhost:8080/Emanual 401 http://localhost:8080/Emanual/ 401 http://localhost:8080/Fmanual 401 http://localhost:8080/Fmanual/ 401 http://localhost:8080/Gmanual 401 http://localhost:8080/Gmanual/ 401 I don't know whether you'd prefer it to return a 401 or a 404 (it follows the alias, but the new path isn't valid, and if the new path isn't valid then why apply directory stuff to it?) Personally I prefer returning a 401, but that's not my choice to make. Either way, the fact that it is inconsistent is not good. Cheers, and Merry Christmas, Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ] --- conf/httpd.conf.default Fri Dec 21 14:37:10 2001 +++ conf/httpd.conf Fri Dec 21 15:13:10 2001 @@ -293,6 +293,10 @@ Directory / Options FollowSymLinks AllowOverride None +AuthName user access +AuthType Basic +AuthUserFile conf/htpasswd +Require valid-user /Directory # @@ -549,6 +553,26 @@ Allow from all /Directory +# A bunch of aliases with which to test the problem +# +Alias /0manual/ /usr/local/apache/manual/ +Alias /1manual/ manual/ +Alias /2manual manual/ +Alias /3manual manual +Alias /4manual/ manual +Alias /5manual/ /usr/local/apache/not/a/path/ +Alias /6manual /usr/local/apache/not/a/path/ +Alias /7manual /usr/local/apache/not/a/path +Alias /8manual/ /usr/local/apache/not/a/path +Alias /9manual/ broken/ +Alias /Amanual broken/ +Alias /Bmanual broken +Alias /Cmanual/ broken +Alias /Dmanual/ /usr/local/apache/htdocs/broken/ +Alias /Emanual /usr/local/apache/htdocs/broken/ +Alias /Fmanual /usr/local/apache/htdocs/broken +Alias /Gmanual/ /usr/local/apache/htdocs/broken + # This Alias will project the on-line documentation tree under /manual/ # even if you change the DocumentRoot. Comment it if you don't want to # provide access to the on-line documentation. test.sh Description: Bourne shell script
Re: [bug] 404 served instead of 401
On Fri, 21 Dec 2001, Rodent of Unusual Size wrote: Gary Benson wrote: I found a bug whereby Apache 1.3.22 inconsistently handles the interaction between aliases to non-existant paths and authentication. If the alias is specified as an absolute path then a 401 is always served, but if the alias is a relative path then in some cases a 404 will be served. I don't recall that we ever supported, nor even suggested that we supported, 'relative' file paths for aliases. To what would they be relative? The docroot, I suppose. But in that case, if we don't support them then should we not be returning 500s instead of 401s and 404s? 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
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: 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 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 = $(PERL_ARCHLIB)/Config.pm $(PERL_INC)/config.h
# Where to put things:
INST_LIBDIR = $(INST_LIB)
INST_ARCHLIBDIR = $(INST_ARCHLIB)
INST_AUTODIR
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: Apache 1.3.21 tag and roll
On Fri, 7 Sep 2001, Bill Stoddard wrote: I'd like to tag and roll Apache 1.3.21. Anyone have anything they would like to get in first? Is there any chance of merging the mod_env bugfix patch from PR#8254? Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
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
Location /random_chunk
@@ -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 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: 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 ]
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 ]
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?
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 ] +
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: 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: 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 ]
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: 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: 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/
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: 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: 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'
,
man topic,
RCalcCommand: $commands{'RC_COMMAND_HELP'}
RCalcString: `topic'
,
# Check that space works.
#
help topic\t,
RCalcCommand: $commands{'RC_COMMAND_HELP'}
RCalcString: `topic'
,
? topic \n,
RCalcCommand: $commands{'RC_COMMAND_HELP'}
RCalcString: `topic'
,
man topic,
RCalcCommand: $commands{'RC_COMMAND_HELP'}
RCalcString: `topic'
,
# Check that multiple topics get reprimanded.
#
help topic topic,$errors{'HELP_USAGE'},
? topic topic, $errors{'QMARK_USAGE'},
man topic topic, $errors{'MAN_USAGE'},
# Check that semicolons work.
#
help topic; exit,
RCalcCommand: $commands{'RC_COMMAND_HELP'}
RCalcString: `topic'
RCalcSeparator
RCalcCommand: $commands
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 = ERROR_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: 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.
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.
