You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Cliff Woolley <cl...@yahoo.com> on 2001/08/31 02:32:07 UTC
Re: 2.0.26?
What's with this?
Failed Test Status Wstat Total Fail Failed List of failed
-------------------------------------------------------------------------------
modules/cgi.t 36 31 86.11% 1-4, 6, 8-25, 29-36
modules/info.t 1 1 100.00% 1
modules/vhost_a 8 8 100.00% 1-8
I'm currently getting lots of "Use of uninitialized value" warnings from
the test harness, so I don't know if this is the tests being broken or the
httpd being broken or both. Anyone else seeing this on HEAD?
Thanks,
Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Aug 30, 2001 at 11:45:09PM -0500, William A. Rowe, Jr. wrote:
> I suggest we handle this as follows; r->uri becomes NULL. If a hook fn doesn't
> like it, it needs to decline. Where we go an reject the URI out of hand, let's
> also test for r->main, and if we have a parent, then let it slide. If we don't
> (we are the main request) we can cough up a 500 if there was a leading slash
> or asterisk on the original uri, or a 400 if there was not.
>
> I've had it (for tonight.) I'll be happy to pick back up anything necessary in
> the morning, and will finish my audit of the overall delta after we pin this
> down. But I would much rather see non-file requests get r->filename of NULL
> (what about mime filename extensions? I don't think they should apply to
> non-files) and r->uri of NULL for truly bogus internal redirects.
>
> I know this will break some 3rd party modules. This is 2.0, and we are working
> to _help_ them avoid the bugtrac reports on their modules. I'd think getting
> this right (in this day and age of the hourly new exploit) is far perferable to
> inconviencing an author with a set of five new rules. {Ok ok... this will get
> documented once decisions are reached!}
+1. Yes, this makes sense to me as I understand it.
Non-file request should definitely get r->filename of NULL. What
do they get right now? Same goes for r->uri. There are lots of
bogus assumptions throughout the code.
However, I disagree with mime filename extensions though. I could
create a handler that serves everything from a database instead of
a file-system. So, the core translate_filename (?) never sets
r->filename. But, there are extensions on the URI that was passed
in - I would make the case that the proper mime mappings apply
(i.e. content-type et al). AIUI, the mime types should apply to
the request not the files. But, I could be 100% wrong here...
I'm thinking of mod_mbox which has a virtual namespace - the
mime mappings should be the *entire* URI not what the r->filename
says it should be - in mod_mbox's case r->filename is the raw mbox
file - the complete URI ends with .html so it should get that as
the content-type. I think content-type should be R->L and handlers
should be L->R evaluation (first match wins).
I believe that there are not that many filters that would intercept
non-filebacked requests anyway (mod_include comes to mind, but that's
all I can think of now). (Lots of handlers though - just not
filters...)
If I knew the code better and had the time to pitch in and help out
with this, I would. I'm getting ready to go on "vacation," so I'm
trying to get some things closed out here before I go... Sorry
I can't be of more help on this... I'll test and try to review
patches though... -- justin
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Cliff Woolley" <cl...@yahoo.com>
Sent: Thursday, August 30, 2001 11:38 PM
> On Thu, 30 Aug 2001, William A. Rowe, Jr. wrote:
>
> > Gut instinct? The "INTERNAL FOONESS" uri's which are now going
> > through <Location> walk, we have to think those through.
>
> You're right:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 20591)]
> ap_getparents (name=0x80e0420 "INTERNALLY GENERATED file-relative req")
> at util.c:488
> 488 name[w++] = name[l++];
> (gdb) bt
> #0 ap_getparents (name=0x80e0420 "INTERNALLY GENERATED file-relative
> req")
> at util.c:488
> #1 0x080e0420 in core_cmds () at eval.c:41
> #2 0x080b9912 in ap_process_request_internal (r=0x8159acc) at
> request.c:152
> #3 0x080bacf4 in ap_sub_req_lookup_file (new_file=0xbfffaf50 "if4.shtml",
> r=0x8155aac, next_filter=0x8156c34) at request.c:1672
I suggest we handle this as follows; r->uri becomes NULL. If a hook fn doesn't
like it, it needs to decline. Where we go an reject the URI out of hand, let's
also test for r->main, and if we have a parent, then let it slide. If we don't
(we are the main request) we can cough up a 500 if there was a leading slash
or asterisk on the original uri, or a 400 if there was not.
I've had it (for tonight.) I'll be happy to pick back up anything necessary in
the morning, and will finish my audit of the overall delta after we pin this
down. But I would much rather see non-file requests get r->filename of NULL
(what about mime filename extensions? I don't think they should apply to
non-files) and r->uri of NULL for truly bogus internal redirects.
I know this will break some 3rd party modules. This is 2.0, and we are working
to _help_ them avoid the bugtrac reports on their modules. I'd think getting
this right (in this day and age of the hourly new exploit) is far perferable to
inconviencing an author with a set of five new rules. {Ok ok... this will get
documented once decisions are reached!}
Bill
Re: 2.0.26?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 30 Aug 2001, William A. Rowe, Jr. wrote:
> Gut instinct? The "INTERNAL FOONESS" uri's which are now going
> through <Location> walk, we have to think those through.
You're right:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 20591)]
ap_getparents (name=0x80e0420 "INTERNALLY GENERATED file-relative req")
at util.c:488
488 name[w++] = name[l++];
(gdb) bt
#0 ap_getparents (name=0x80e0420 "INTERNALLY GENERATED file-relative
req")
at util.c:488
#1 0x080e0420 in core_cmds () at eval.c:41
#2 0x080b9912 in ap_process_request_internal (r=0x8159acc) at
request.c:152
#3 0x080bacf4 in ap_sub_req_lookup_file (new_file=0xbfffaf50 "if4.shtml",
r=0x8155aac, next_filter=0x8156c34) at request.c:1672
#4 0x08067e77 in handle_include (ctx=0x81a02f4, bb=0xbfffd414,
r=0x8155aac,
f=0x8156c1c, head_ptr=0x81b37c8, inserted_head=0xbfffcfb4)
at mod_include.c:794
#5 0x0806a875 in send_parsed_content (bb=0xbfffd414, r=0x8155aac,
f=0x8156c1c)
at mod_include.c:2518
#6 0x0806ae01 in includes_filter (f=0x8156c1c, b=0x8156d4c)
at mod_include.c:2777
#7 0x080b212a in ap_pass_brigade (next=0x8156c1c, bb=0x8156d4c)
at util_filter.c:247
#8 0x080b856a in default_handler (r=0x8155aac) at core.c:3062
#9 0x080a7de6 in ap_run_handler (r=0x8155aac) at config.c:185
#10 0x080a826b in ap_invoke_handler (r=0x8155aac) at config.c:344
#11 0x08080339 in ap_process_request (r=0x8155aac) at http_request.c:286
#12 0x0807c421 in ap_process_http_connection (c=0x81a005c) at
http_core.c:287
#13 0x080b0996 in ap_run_process_connection (c=0x81a005c) at
connection.c:82
#14 0x080a699e in child_main (child_num_arg=0) at prefork.c:829
#15 0x080a6b00 in make_child (s=0x80f034c, slot=0) at prefork.c:865
#16 0x080a6c11 in startup_children (number_to_start=5) at prefork.c:939
#17 0x080a7393 in ap_mpm_run (_pconf=0x80ee9e4, plog=0x8128bb4,
s=0x80f034c)
at prefork.c:1155
#18 0x080abe00 in main (argc=2, argv=0xbffff6c4) at main.c:431
#19 0x40206177 in __libc_start_main (main=0x80abb30 <main>, argc=2,
ubp_av=0xbffff6c4, init=0x80621f8 <_init>, fini=0x80c1130 <_fini>,
rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff6bc)
at ../sysdeps/generic/libc-start.c:129
> > One harmless, unrelated warning during the compile which resulted from the
> > #if 0's you added:
> >
> > request.c:297: warning: `resolve_symlink' defined but not used
>
> That will become used, rather soon (after the next tag.)
Figured it would.
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Cliff Woolley" <cl...@yahoo.com>
Cc: "William Rowe" <wr...@rowe-clan.net>
> On Thu, 30 Aug 2001, Cliff Woolley wrote:
>
> > I was just running the tests from httpd-test (which seems to now be
> > working) in order to post the results here (they were failing miserably),
> > but I see that you just committed a fix. I'll stop my test and do a cvs
> > up. Stay tuned...
>
> It's a helluva lot closer than I've seen it all day I think. That last
> fix definitely helped a LOT. Right now everything seems good except
> mod_include:
Your segfaults prove that up. Something is wrong in URI assignment, I haven't
figured exactly where, but I'm certain it's in the subreq #if 0 /* XXX */'d code.
Gut instinct? The "INTERNAL FOONESS" uri's which are now going through <Location>
walk, we have to think those through.
> One harmless, unrelated warning during the compile which resulted from the
> #if 0's you added:
>
> request.c:297: warning: `resolve_symlink' defined but not used
That will become used, rather soon (after the next tag.)
Re: 2.0.26?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Fri, 31 Aug 2001, Cliff Woolley wrote:
> More details on the mod_include tests that failed, which are essentially
> all the ones involving valid subrequests:
>
> FAILED tests 1, 15, 17-20
> Failed 6/22 tests, 72.73% okay
And from the error log:
[Fri Aug 31 00:18:11 2001] [notice] child pid 10641 exit signal
Segmentation fault (11)
[Fri Aug 31 00:18:13 2001] [notice] child pid 10645 exit signal
Segmentation fault (11)
[Fri Aug 31 00:18:15 2001] [notice] child pid 10649 exit signal
Segmentation fault (11)
[Fri Aug 31 00:18:17 2001] [notice] child pid 10653 exit signal
Segmentation fault (11)
[Fri Aug 31 00:18:19 2001] [notice] child pid 10657 exit signal
Segmentation fault (11)
Backtrace to follow momentarily...
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 30 Aug 2001, Cliff Woolley wrote:
> I was just running the tests from httpd-test (which seems to now be
> working) in order to post the results here (they were failing miserably),
> but I see that you just committed a fix. I'll stop my test and do a cvs
> up. Stay tuned...
It's a helluva lot closer than I've seen it all day I think. That last
fix definitely helped a LOT. Right now everything seems good except
mod_include:
using Apache/2.0.26-dev (threaded MPM)
waiting for server to warm up...ok
server localhost:8529 started (pid=8981)
server localhost:8530 listening (mod_vhost_alias)
server localhost:8531 listening (mod_ssl)
apache/404..........ok
apache/byterange....ok
apache/getfile......ok
apache/post.........ok
apache/rwrite.......ok
apr/uri.............ok
filter/case.........ok
filter/case_in......ok
filter/input_body...ok
modules/access......ok
modules/alias.......ok
modules/cgi.........ok
modules/dav.........skipped test on this platform
modules/dir.........ok
modules/env.........ok
modules/expires.....ok
modules/headers.....ok
modules/include.....ok 22/22FAILED tests 1, 15, 17-20
Failed 6/22 tests, 72.73% okay
modules/info........ok
modules/negotiation.ok
modules/rewrite.....ok
modules/setenvif....ok
modules/status......ok
modules/vhost_alias.ok
ssl/all.............ok
Failed Test Status Wstat Total Fail Failed List of failed
-------------------------------------------------------------------------------
modules/include 22 6 27.27% 1, 15, 17-20
1 test skipped.
server localhost:8529 shutdown (pid=8981)
error running tests (please examine t/logs/error_log)
Failed 1/25 test scripts, 96.00% okay. 6/1685 subtests failed, 99.64%
okay.
More details on the mod_include tests that failed, which are essentially
all the ones involving valid subrequests:
modules/include.....1..22
GET /modules/include/big.shtml
expected:
->hello pass pass pass hello<-
actual:
-><-
not ok 1
# Failed test 1 in modules/include.t at line 73
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14
GET /modules/include/include1.shtml
expected:
->inc-two.shtml body include.shtml body<-
actual:
-><-
not ok 15
# Failed test 15 in modules/include.t at line 73 fail #15
ok 16
GET /modules/include/include3.shtml
expected:
->inc-two.shtml body inc-one.shtml body include.shtml body<-
actual:
-><-
not ok 17
# Failed test 17 in modules/include.t at line 73 fail #17
GET /modules/include/include4.shtml
expected:
->inc-two.shtml body inc-one.shtml body include.shtml body<-
actual:
-><-
not ok 18
# Failed test 18 in modules/include.t at line 73 fail #18
GET /modules/include/include5.shtml
expected:
->inc-two.shtml body inc-one.shtml body inc-three.shtml body
include.shtml body<-
actual:
-><-
not ok 19
# Failed test 19 in modules/include.t at line 73 fail #19
GET /modules/include/include6.shtml
expected:
->inc-two.shtml body inc-one.shtml body inc-three.shtml body
include.shtml body<-
actual:
-><-
not ok 20
# Failed test 20 in modules/include.t at line 73 fail #20
ok 21
ok 22
FAILED tests 1, 15, 17-20
Failed 6/22 tests, 72.73% okay
One harmless, unrelated warning during the compile which resulted from the
#if 0's you added:
request.c:297: warning: `resolve_symlink' defined but not used
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 30 Aug 2001, William A. Rowe, Jr. wrote:
> Unless I made a fatal flaw, this should be it... lets get
> testing/auditing, folks ;)
>
> I had to move the ap_die/decl_die/finalize_request_protocol from
> ap_process_request_internal to make it truly portable. Really a
> straightfoward change, if I've done it right. I'll caution I'm a bit
> tired tonight, so we need to be cautious.
>
> Cliff - you are set up with the test bench :-?
Sorry it's taken me a while to get back on this... had some other work to
take care of.
I was just running the tests from httpd-test (which seems to now be
working) in order to post the results here (they were failing miserably),
but I see that you just committed a fix. I'll stop my test and do a cvs
up. Stay tuned...
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Unless I made a fatal flaw, this should be it... lets get testing/auditing, folks ;)
I had to move the ap_die/decl_die/finalize_request_protocol from ap_process_request_internal
to make it truly portable. Really a straightfoward change, if I've done it right.
I'll caution I'm a bit tired tonight, so we need to be cautious.
Cliff - you are set up with the test bench :-?
Bill
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <de...@httpd.apache.org>
Sent: Thursday, August 30, 2001 7:49 PM
Subject: Re: 2.0.26?
> Ill get the subreq fix in in the next 45 minutes - let's see what disappears.
>
> ----- Original Message -----
> From: "Cliff Woolley" <cl...@yahoo.com>
> To: <de...@httpd.apache.org>
> Cc: <te...@httpd.apache.org>
> Sent: Thursday, August 30, 2001 7:32 PM
> Subject: Re: 2.0.26?
>
>
> >
> > What's with this?
> >
> > Failed Test Status Wstat Total Fail Failed List of failed
> > -------------------------------------------------------------------------------
> > modules/cgi.t 36 31 86.11% 1-4, 6, 8-25, 29-36
> > modules/info.t 1 1 100.00% 1
> > modules/vhost_a 8 8 100.00% 1-8
> >
> >
> > I'm currently getting lots of "Use of uninitialized value" warnings from
> > the test harness, so I don't know if this is the tests being broken or the
> > httpd being broken or both. Anyone else seeing this on HEAD?
> >
> > Thanks,
> > Cliff
> >
> >
> > --------------------------------------------------------------
> > Cliff Woolley
> > cliffwoolley@yahoo.com
> > Charlottesville, VA
> >
> >
> >
>
>
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ill get the subreq fix in in the next 45 minutes - let's see what disappears.
----- Original Message -----
From: "Cliff Woolley" <cl...@yahoo.com>
To: <de...@httpd.apache.org>
Cc: <te...@httpd.apache.org>
Sent: Thursday, August 30, 2001 7:32 PM
Subject: Re: 2.0.26?
>
> What's with this?
>
> Failed Test Status Wstat Total Fail Failed List of failed
> -------------------------------------------------------------------------------
> modules/cgi.t 36 31 86.11% 1-4, 6, 8-25, 29-36
> modules/info.t 1 1 100.00% 1
> modules/vhost_a 8 8 100.00% 1-8
>
>
> I'm currently getting lots of "Use of uninitialized value" warnings from
> the test harness, so I don't know if this is the tests being broken or the
> httpd being broken or both. Anyone else seeing this on HEAD?
>
> Thanks,
> Cliff
>
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
>
>
expect_ok sub?
Posted by Stas Bekman <st...@stason.org>.
Many times we create subtests like this:
print comment
my $expect = ...
my $got = ...
print expect
print got
ok $expect eq $got
and end up with lots of typing. I suggest expect_ok, or just eok():
sub expect_ok{
my ($expect,$received,$comment) = @_;
print "$comment\n" if defined $comment;
print "expected: $expect\n";
print "received: $received\n";
ok($expect eq $received);
}
so for example here is a test from alias.t shrink-wrapped:
## with ScriptAliasMatch ##
eok(
$string,
GET_BODY("/aliascgi-script"),
"verifying ScriptAliasMatch with /aliascgi-script",
);
I think using 'eq' is safe enough for numerical and string comparisons. or
we could make e_num_ok and e_str_ok to use '==' and 'eq' respectively.
some people write tests without printing expect/received strings and when
the test fail, users have to go and do it themselves. Such a wrapper does
this job for the test writers for free.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://localhost/ http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: 2.0.26?
Posted by Stas Bekman <st...@stason.org>.
I'm running HEAD with:
./configure --prefix=$HOME/httpd-2.0 \
--enable-so \
--enable-vhost-alias \
--enable-info \
(enabled just enough to verify your report),
> What's with this?
>
> Failed Test Status Wstat Total Fail Failed List of failed
> -------------------------------------------------------------------------------
> modules/cgi.t 36 31 86.11% 1-4, 6, 8-25, 29-36
works for me.
> modules/info.t 1 1 100.00% 1
works for me
> modules/vhost_a 8 8 100.00% 1-8
this was a partially "broken" test. I've submitted a patch to fix it.
> I'm currently getting lots of "Use of uninitialized value" warnings from
> the test harness, so I don't know if this is the tests being broken or the
> httpd being broken or both. Anyone else seeing this on HEAD?
If you get "Use of uninitialized value" warnings, this means that the test
is not cleanly written. Some variables weren't initialized and used while
undef.
which tests do you have this problem with? please report to the test-dev
list, so their respective owners can fix these.
Thanks.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://localhost/ http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: 2.0.26?
Posted by Stas Bekman <st...@stason.org>.
I'm running HEAD with:
./configure --prefix=$HOME/httpd-2.0 \
--enable-so \
--enable-vhost-alias \
--enable-info \
(enabled just enough to verify your report),
> What's with this?
>
> Failed Test Status Wstat Total Fail Failed List of failed
> -------------------------------------------------------------------------------
> modules/cgi.t 36 31 86.11% 1-4, 6, 8-25, 29-36
works for me.
> modules/info.t 1 1 100.00% 1
works for me
> modules/vhost_a 8 8 100.00% 1-8
this was a partially "broken" test. I've submitted a patch to fix it.
> I'm currently getting lots of "Use of uninitialized value" warnings from
> the test harness, so I don't know if this is the tests being broken or the
> httpd being broken or both. Anyone else seeing this on HEAD?
If you get "Use of uninitialized value" warnings, this means that the test
is not cleanly written. Some variables weren't initialized and used while
undef.
which tests do you have this problem with? please report to the test-dev
list, so their respective owners can fix these.
Thanks.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://localhost/ http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/