Re: cvs commit: httpd-test/perl-framework/t/security CAN-2004-0940.t
On Thu, 28 Oct 2004, Geoffrey Young wrote: I get the following failures on 1.3.32 but not on 1.3.33. t/modules/rewrite.t 222 9.09% 18 20 t/security/CAN-2004-0940.t11 100.00% 1 t/security/CAN-2004-0958.t92 22.22% 1 3 I think these are all recent additions from you. should each of these failures be skipped unless something like ( have_apache(1) have_min_apache_version(1.3.33) ) || ( have_apache(2) have_min_apache_version(2.0.XX) ) I don't think so -- it's detecting an actual legitimate failure. It's not that the test requires a new version to work right, it's that that particular version was broken. No sense obfuscating that fact. --Cliff
Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes
On Mon, 5 Apr 2004 [EMAIL PROTECTED] wrote: stas2004/04/04 21:35:21 Modified:perl-framework/Apache-Test/lib/Apache TestRun.pm TestConfig.pm perl-framework/Apache-Test Changes Log: Don't try to set ulimit unlimited for coredumps on Solaris, unless run as root Submitted by: Rob Kinyon [EMAIL PROTECTED] Um, wait, why is this? I have ulimit -c unlimited in my non-root-user .bashrc on Solaris 8 and it works fine (it worked on other versions as well). The only time it won't let you set it as a normal user that I was aware of was when the system-wide login script has it set to something less than unlimited explicitly ... a normal user can decrease the limit but not increase it. --Cliff
Re: apr_psprintf thread safe?
Where does it say that? httpd uses it extensively, so if it's not, I'd tend to think we'd have noticed by now... --Cliff On Thu, 8 Jan 2004, Donald Doane wrote: Okay, will do that, but it's called in flood_easy_reports::easy_process_stats() and it seems APR documentation implies it is not thread safe. We use a modified version of flood_easy_reports and I'd like to confirm whether or not its use is truly thread safe. Geoffrey Young wrote: Donald Doane wrote: Can someone please confirm whether or not apr_psprintf is thread safe. Thank you. sorry, wrong list. try [EMAIL PROTECTED] --Geoff
Re: apr_psprintf thread safe?
On Thu, 8 Jan 2004, Donald Doane wrote: The following comment is from apr_lib.h: * apr_vformatter does not call out to any other code, it is entirely * self-contained. This allows the callers to do things which are * otherwise unsafe. For example, apr_psprintf uses the scratch * space at the unallocated end of a block, and doesn't actually * complete the allocation until apr_vformatter returns. apr_psprintf * would be completely broken if apr_vformatter were to call anything * that used a apr_pool_t. Similarly http_bprintf() uses the scratch * space at the end of its output buffer, and doesn't actually note * that the space is in use until it either has to flush the buffer * or until apr_vformatter returns. That seems to say to me that apr_psprintf is in fact threadsafe after all. :-) --Cliff
Re: status of the perl-framework
On Mon, 8 Dec 2003, Geoffrey Young wrote: Use of bare to mean is deprecated at modules/include.t line 120. which is probably new to 5.8.2. Interesting. doesn't occur within include.t. So it happens within the framework? hmm, perhaps. I was actually planning on getting down and dirty tomorrow :) but yes, it could be the framework or an interaction between them. Sounds like a cvs conflict marker. --Cliff
Re: status of the perl-framework
On Mon, 8 Dec 2003, Geoffrey Young wrote: Sounds like a cvs conflict marker. duh. that was it. eesh. I only knew that because it happens to me all the time. ;) nbd. --JC
Re: Patch for cookie processing in Flood [...]
On Thu, 23 Oct 2003, Jacek Prucia wrote: then prepare separate patch and post it here. You'll score extra points from our own style purist (Hello Justin ;) ...and hello me, too. ;) --Cliff Style Police Woolley
Re: cvs commit: httpd-test/perl-framework/c-modules/echo_post_chunk mod_echo_post_chunk.c
On Wed, 15 Oct 2003 [EMAIL PROTECTED] wrote: fix link error with apr 1.0 -trailer_header = ap_table_get(r-headers_in, X-Chunk-Trailer); +trailer_header = apr_table_get(r-headers_in, X-Chunk-Trailer); I fixed this in my local tree yesterday but then forgot about it. It actually needs an #ifdef since in Apache 1.3.x it really is ap_table_get. I'll commit that.
Re: LIST
On Thu, 2 Oct 2003, Jeffrey P. Toth wrote: Can someone tell me how to unsubscibe from this list. I have sent emails to all addresses and they are just returned. Thank you. If you'd look in the headers of any message delivered to this list, you'd see: -- list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] -- Ie, just send a message to [EMAIL PROTECTED] . --Cliff
Re: cvs commit: httpd-test/flood config.h.in flood_round_robin.c
On Sun, 7 Sep 2003 [EMAIL PROTECTED] wrote: +if (apr_procattr_create(procattr, rp-pool) != APR_SUCCESS) { +apr_file_printf(local_stderr, +apr_procattr_create failed for '%s'\n, +rp-url[rp-current_url].responsescript); +return APR_EGENERAL; +} Why do all of these return APR_EGENERAL rather than catching the apr_status_t from the function that was called (apr_procattr_create in this case) and returning that? Is this just a flood thing I don't know about? --Cliff
RE: cvs commit: httpd-test/flood config.h.in flood_round_robin.c
is a safe bet. If this looks really obscure considering APR concepts, then please feel free to commit a fix. Fix commited. Please test, since I didn't. :) PS: I also fixed a buglet or two. --Cliff
Re: required changes for APR 1.0
On Thu, 4 Sep 2003, Stas Bekman wrote: it probably doesn't make any difference if older releases won't work with it. +1. As long as the top-of-tree 1.3-dev, 2.0-dev, and 2.1-dev all build and run, that's fine. Older point releases are not an issue.
Re: [patch] have_apache_mpm()
On Wed, 9 Jul 2003, Stas Bekman wrote: plan ..., have_apache2 have_apache_mpm('prefork'); I think this is probably the way to go. If you call have_apache_mpm() and it's apache 1.3, I might have it return an error of some kind, but I wouldn't have it return 'prefork'. --Cliff
Re: are perl-framework apache tests still used?
On Fri, 7 Feb 2003, Stas Bekman wrote: I haven't seen any activity with maintaining tests in a while and I have a bunch of ssl tests failing. I remember Ryan working on a new test suite. What's the current status of things? Should Joe's new php tests be committed? These fail for me: ssl/basicauth.t31 33.33% 2 ssl/http.t 255 65280 22 100.00% 1-2 ssl/proxy.t 1695 2.96% 113-117 ssl/varlookup.t 724 5.56% 38-39 52-53 Glad it's not just me. :) I'm not sure when they broke... there was a big gap in there up until last week when I hadn't run the perl-framework tests in a long time. :-/ Anybody? I'm CC:ing [EMAIL PROTECTED] on this to make sure it's on everyone's radar... followups to test-dev, please. --Cliff
Re: Crypt::SSLeay
Figured it out. It was a bug in Crypt::SSLeay ... not sure how it ever even worked. I'm sending them the following patch: --- SSLeay.xs.orig 2002-08-01 17:43:22.0 -0400 +++ SSLeay.xs 2003-01-29 21:41:17.0 -0500 @@ -109,6 +109,7 @@ SSLeay_add_all_algorithms(); SSL_load_error_strings(); ERR_load_crypto_strings(); + SSL_library_init(); bNotFirstTime = 1; } RAND_seed(buf,sizeof buf); Geeze. Crypt:SSLeay's make test actually passes now, it's amazing. ;) --Cliff
Re: Crypt::SSLeay
On Thu, 30 Jan 2003, William A. Rowe, Jr. wrote: That's actually sorta sad... are they missing CRYPTO_malloc_init as well? [EMAIL PROTECTED]:../build/Crypt-SSLeay-0.45# grep -i CRYPTO_malloc_init * [EMAIL PROTECTED]:../build/Crypt-SSLeay-0.45# Looks that way, yeah... :) --Cliff
Crypt::SSLeay
Has anybody out there managed to get Crypt::SSLeay to do anything but segfault with recent OpenSSL's? I sure can't. As a result, every single SSL test fails for me. --Cliff
RE: Crypt::SSLeay
On Wed, 29 Jan 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: PS : I'm using Perl 5.8 though (I'm not sure if it matters, but I can try on 5.6.1) I'm using Linux, Slackware current, kernel 2.4.20, glibc 2.3.1, openssl 0.9.6h, perl 5.8.0, latest Crypt::SSLeay. --Cliff
Re: [STATUS] (perl-framework) Wed Nov 6 23:45:56 EST 2002
On Thu, 7 Nov 2002, William A. Rowe, Jr. wrote: Guys, some time in the {recent} past, TEST.pl was renamed TEST. Umm it's actually been TEST for as long as I can remember. Here's a partial directory listing of an old copy of httpd-test of mine: -rwxr-xr-x1 jcw5qroot 424 Jun 28 17:14 REPORT -rwxr-xr-x1 jcw5qroot 425 Jun 28 17:14 SMOKE -rwxr-xr-x1 jcw5qroot 484 Jun 28 17:14 TEST I don't recall them ever being TEST.pl, SMOKE.pl, etc. Not that I would mind them changing to *be* TEST.pl et al. /me is confused... --Cliff
Re: rewritemap breakage
On Fri, 31 May 2002, Doug MacEachern wrote: seems that the test suite now requires httpd-2.0-cvs from HEAD? server does not start with 1.3.x or 2.0.36: Syntax error on line 139 of .../t/conf/extra.conf RewriteMap: map file or program not found:/.../t/htdocs/modules/rewrite/append.pl foo Hmph. Well, it definitely won't work with 2.0.36... 2.0.36 was broken in this regard. :) I thought this worked on 1.3.x though. Oh well, no big deal. You can remove that test if you like. --Cliff
inherit_documentroot breakage
Anybody know why this just started happening within the last few days? [EMAIL PROTECTED]:/root/apache/httpd-test/perl-framework$ t/TEST configure() has failed: invalid token: @inherit_documentroot@ in file /root/apache/httpd-test-8/perl-framework/t/conf/extra.conf.in forcing Apache::TestConfig object save run 't/TEST -clean' to clean up before continuing And yes, I've cvs up'ed, make clean'ed, and all that jazz. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: inherit_documentroot breakage
On Tue, 14 May 2002, Doug MacEachern wrote: i just backed out the change from yesterday that caused it, should be ok now. Thanks. I had noticed that commit, but thought maybe there would be some way to fix it by just adjusting extra.conf.in rather than reverting. Oh well, whatever works. :) --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
all the commits ;)
Sorry about the flurry of commit messages... I'm just rearranging t/htdocs a bit to get a more parallel directory structure to make it easier to add other stuff without cluttering up the docroot. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: mod_specweb99
On Wed, 1 May 2002, Greg Ames wrote: If we need to arrange for people without httpd commit to get commit to just httpd-test, we can probably do so... -- justin Do you mean Dirk and I automagically have httpd-test commit access by virtue of being httpd committers? If so, great! Yep! It's a subproject. All core httpd developers are already in avail for httpd-test. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: perl-framework: make test recompiles everything all the time
On Tue, 16 Apr 2002, Stas Bekman wrote: one last question. Should the ssl certificates be recreated on t/TEST -clean (or 'make test')? As they're currently done, they need to be recreated at least *once* in a while, because they're set to expire. That happened on me once when I hadn't cleaned up in a while. But in general, yes, I think they should be cleaned up with t/TEST -clean... I like having a way to throw out all the generated cruft and go back to what's basically the same as you get from CVS. That's just me, though. --Cliff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestSmoke.pm
On 11 Apr 2002 [EMAIL PROTECTED] wrote: stas02/04/11 08:02:26 Modified:perl-framework/Apache-Test/lib/Apache TestSmoke.pm Log: - improved the generated smoke report + +== Summary === +Completion : $completion +Status : $status +Tests run : $self-{total_tests_run} Random iterations made : $self-{total_iterations} +EOM make now reports this: lib/Apache/TestSmoke.pm:373: Unknown command paragraph = Summary === -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On 6 Apr 2002 [EMAIL PROTECTED] wrote: dougm 02/04/05 18:39:31 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: try MP_AP_PREFIX in modperl build config for httpd location hint Doug. DOOD. You're working too hard. GO PARTY! ;) -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-test/perl-framework/t/ssl http.t
On Tue, 2 Apr 2002, Doug MacEachern wrote: this patch does not change anything that i can see, both the old version and new do this: The old version for me was giving a res-code of 200, not 500, because it was sending the http request to port 8529, not 8530. Maybe it's related to the version of LWP I'm using? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: httpd-test negotiation failures.
for index.fu.html # expected: 'index.de.html' # received: 'index.fu.html' not ok 72 # Failed test 72 in modules/negotiation.t at line 71 fail #4 # testing : Explicitly request fu/index.html.en # expected: 200 # received: '200' ok 73 # testing : Explicitly request fu/two/index.en.html # expected: 200 # received: '200' ok 74 # testing : Verify with a default language Accept-Language still obeyed # expected: 'index.html.en' # received: 'index.html.en' ok 75 # testing : Verify with a default language Accept-Language still obeyed (compression on) # expected: 'index.html.en.gz' # received: 'index.html.en.gz' ok 76 # testing : Verify with a default language Accept-Language still obeyed # expected: 'index.en.html' # received: 'index.en.html' ok 77 # testing : Explicitly request fu/index.html.fr # expected: 200 # received: '200' ok 78 # testing : Explicitly request fu/two/index.fr.html # expected: 200 # received: '200' ok 79 # testing : Verify with a default language Accept-Language still obeyed # expected: 'index.html.fr' # received: 'index.html.fr' ok 80 # testing : Verify with a default language Accept-Language still obeyed (compression on) # expected: 'index.html.fr.gz' # received: 'index.html.fr.gz' ok 81 # testing : Verify with a default language Accept-Language still obeyed # expected: 'index.fr.html' # received: 'index.fr.html' ok 82 # testing : Explicitly request fu/index.html.de # expected: 200 # received: '200' ok 83 # testing : Explicitly request fu/two/index.de.html # expected: 200 # received: '200' ok 84 # testing : Verify with a default language Accept-Language still obeyed # expected: 'index.html.de' # received: 'index.html.de' ok 85 # testing : Verify with a default language Accept-Language still obeyed (compression on) # expected: 'index.html.de.gz' # received: 'index.html.de.gz' ok 86 # testing : Verify with a default language Accept-Language still obeyed # expected: 'index.de.html' # received: 'index.de.html' ok 87 # testing : Explicitly request fu/index.html.fu # expected: 200 # received: '200' ok 88 # testing : Explicitly request fu/two/index.fu.html # expected: 200 # received: '200' ok 89 # testing : Verify with a default language Accept-Language still obeyed # expected: 'index.html.fu' # received: 'index.html.fu' ok 90 # testing : Verify with a default language Accept-Language still obeyed (compression on) # expected: 'index.html.fu.gz' # received: 'index.html.fu.gz' ok 91 # testing : Verify with a default language Accept-Language still obeyed # expected: 'index.fu.html' # received: 'index.fu.html' ok 92 # testing : fu has a higher quality rating, so we expect fu # expected: 'index.html.fu' # received: 'index.html.fu' ok 93 # testing : fu has a higher quality rating, so we expect fu # expected: 'index.fu.html' # received: 'index.fu.html' ok 94 # testing : fu has a higher quality rating, so we expect fu # expected: 'index.html.fu.gz' # received: 'index.html.fu.gz' ok 95 # testing : bu has the highest quality but is non-existant, so fr is next best # expected: 'index.html.fr' # received: 'index.html.fr' ok 96 # testing : bu has the highest quality but is non-existant, so fr is next best # expected: 'index.fr.html' # received: 'index.fr.html' ok 97 # testing : bu has the highest quality but is non-existant, so fr is next best # expected: 'index.html.fr.gz' # received: 'index.html.fr.gz' ok 98 FAILED tests 1-3, 24-26, 70-72 Failed 9/98 tests, 90.82% okay Failed Test Status Wstat Total Fail Failed List of Failed modules/negotiation.t 989 9.18% 1-3, 24-26, 70-72 -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
getting t/SMOKE to work
and $old_pid == $self-pid) { -warning old pid file ($old_pid) still exists; +warning(old pid file ($old_pid) still exists); sleep 1; } -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
ssl/varlookup.t
Is this really a bug in httpd, or is it a bug in the test? I think it's a bug in the test that only shows up days 1-9 of the month, but I just thought I'd check before I went and 'fixed' the test. # testing : TIME_YEAR # expected: '2001' # received: '2001' ok 15 # testing : TIME_MON # expected: '12' # received: '12' ok 16 # testing : TIME_DAY # expected: 1 # received: '01' not ok 17 # Failed test 17 in /root/apache/httpd-test/perl-framework/blib/lib/Apache/Test.pm at line 46 fail #17 # testing : TIME_WDAY # expected: 6 # received: '6' ok 18 -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: .htaccess on WIn2000
On Mon, 12 Nov 2001, [iso-8859-1] ??? wrote: Filename in Win2000 cannot start with dot, so we can't create .htaccess. How to solve this problem? Just use some name other than .htaccess in your AccessFileName directive, one that doesn't start with a period. BTW, this mailing list is for issues relating to development of the test suite for Apache. Please direct this type of question to one of the support mailing lists in the future. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.28
On Thu, 8 Nov 2001, Justin Erenkrantz wrote: modules/cgi.t36 33 91.67% 1-4, 6, 8-27, 29-36 ssl/env.t22 16 72.73% 1-5, 12-22 Do these look normal? They've been failing for quite a while now and nobody else that I know of except Aaron seems to have noticed. Those two seem to be related to a stale httpd-test build. Usually a fresh checkout seem to make it work. But, I'll try to check again later this weekend. -- justin Ah, that's one thing I didn't try... I'll re-check-out and see what happens. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Initial version of website up...
On Mon, 17 Sep 2001, Justin Erenkrantz wrote: http://cvs.apache.org/viewcvs.cgi/modperl-docs/src/devel/writing_tests/writing_tests.pod I'm not familiar enough with perl, but is there a way to get a POD file as an HTML file? -- justin There's a utility called pod2html ... :-) --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c mod_include.h
On 2 Sep 2001 [EMAIL PROTECTED] wrote: jerenkrantz01/09/01 18:09:02 Modified:.CHANGES modules/filters mod_include.c mod_include.h Log: Make mod_include check for BYTE_COUNT_THRESHOLD on a per-bucket basis rather than on a per-character basis. A significant amount of time was spent checking the limit. A better place to check for the threshold is when we read the bucket in not as we read each character in the bucket. If a bucket manages to be 200MB, it is not this code's problem as it is a mere filter. I ran this with the mod_include stuff in httpd-test and it looks good from here. The httpd-test mod_include tests are probably insufficient to test this code. They have lots of recursion and check just about all of the imaginable flavors of tag types, but none of them have really BIG content... not even close to big enough to warrant a brigade split. Maybe we should add a test that includes biggish data from the middle of a biggish file? Somewhere around 32k should be sufficient, I'd guess... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
new test request for mod_include
Some subrequest URI fooness we're currently seeing at the HEAD of httpd cannot be detected with the current tests in the framework. They can be seen if you add a test that does an include virtual or include file on a file that's in some other directory than the current one using a relative path. So can someone please add a test or two to the mod_include tests, sticking some file in a subdirectory of t/htdocs/modules/include and trying to include that file from, say, big.shtml in the main directory? Thanks, Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-test/perl-framework/t/htdocs/modules/include/extra inc-bogus.shtml inc-extra1.shtml inc-extra2.shtml
On 31 Aug 2001 [EMAIL PROTECTED] wrote: Index: inc-rfile.shtml === !--#include file=extra/inc-extra1.shtml-- inc-rfile.shtml body Sweet. I was just about to pester somebody to take care of this. While you're at it, can you throw in a test with an absolute path as well? Thanks, Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA