mod_log_config cookie buglet
hi all :)
a co-worker and I were just adding some functionality to an internal
httpd module when we noticed that mod_log_config misbehaves when logging
cookie values...
in short, we have a cookie FOO and were adding a cookie CLIENT_FOO. in
the log format we used
%{FOO}C\t%{CLIENT_FOO}C
but the log spit out FOO for both values. yucko.
it turns out to be mod_log_config's log_cookie() function, where
ap_strstr_c() is used to find the cookie names. it seems that whichever
cookie is first in the incoming header is the one that gets logged,
provided that the name of one cookie is contained in the name of another.
anyway, I guess this bug has been around forever (though I haven't
looked beyond 2.2) but I have a feeling it's gone unnoticed because
people might expect similar values for similarly named cookies. in our
case, FOO was a decrypted version of CLIENT_FOO so the results were
radically different in format and the bug was immediately visible
(though not immediately obvious in source :)
anyway, sorry we don't have a patch for you :)
--Geoff
(who isn't subscribed anymore, so please CC me :)
set_define() warnings
hi all :)
the new set_define() function currently has some unused variables, so it
won't compile with -Werror
patch attached.
--Geoff
Index: server/core.c
===
--- server/core.c (revision 549098)
+++ server/core.c (working copy)
@@ -1098,8 +1098,6 @@
const char *optarg)
{
char **newv;
-void *sconf = cmd-server-module_config;
-core_server_config *conf = ap_get_module_config(sconf, core_module);
const char *err = ap_check_cmd_context(cmd,
GLOBAL_ONLY);
Re: Bug Report - uploads truncated
I'm cross-posting this to apreq-dev - since you're using Apache::Request
and it seems to be behaving differently using mp1 versus mp2, the apreq
folks will be in a better position to comment on the behavior.
--Geoff
Miles Crawford wrote:
I posted this to the Firefox guys as well, because I believe it may be
an issue with their browser, but even if it isn't a mod_perl issue
perhaps you guys have insights I could use to help fill out the bug
report I filed with them?
Perl version v5.8.5 for Apache/1.3.33 (Unix) mod_ssl/2.8.23 OpenSSL/0.9.8
mod_perl/1.29
When posting a file to the following CGI, as demonstrated at the
provided URL,
larger files get truncated. An example file that truncates is located at:
http://mcrawfor.surge.eplt.washington.edu/mcrawfor/frank_lloyd.pdf
Notice that this file is about 4mb, but when uploaded through the
following CGI
using Firefox 2 on Windows, it is truncated to roughly 2.5mb.
If you look at the truncated files in a hex editor, there is a strange
similarity in the point the file is truncated:
truncated point:
00274fe0: d6 4c 64 b7 c9 f5 c1 3f e3 4f a2 8a 28 a2 8a 28
.Ld?.O..(..(
00274ff0: a2 8a 28 a2 8a 2b cd 3f 68 9f 0f f8 c3 c6 1f --
..(..+.?h..-
valid file:
00274fe0: d6 4c 64 b7 c9 f5 c1 3f e3 4f a2 8a 28 a2 8a 28
.Ld?.O..(..(
00274ff0: a2 8a 28 a2 8a 2b cd 3f 68 9f 0f f8 c3 c6 1f 0a
..(..+.?h...
00275000: 75 cf 04 f8 2f 41 4d 46 f7 c4 16 af 66 cc f7 89
u.../AMFf...
All the files I checked are cut off right before a 0a byte that rolls
over to the next round filesize.
I have checked this with Firefox 1.5 and 2.0 on a variety of platforms,
and have only seen it using Firefox 2.0 on Windows posting to mod_perl
1. mod_perl 2 doesn't seem to have this problem.
_
#!/usr/bin/perl
my $r = shift;
use Apache::Request;
my $apr = Apache::Request-new($r);
my $handle = $apr-upload('upload')-fh();
open STORE, stored;
while( my $line = $handle){
print STORE $line;
}
close STORE;
print Content-type: text/plain\n\n. `du 'stored'`;
__
Reproducible: Always
Steps to Reproduce:
1. Upload the sample file to the provided URL or CGI script using
Firefox 2.0
on Windows
2.Check the Uploaded filesize.
3.
Actual Results:
Only part of the file is uploaded.
Expected Results:
The whole file should be uploaded ;)
I'm setting the severity to major considering the large number of
mod_perl 1.3
applications in production use - Here at the University of Washington we
are
getting more and more complaints about this as people upgrade to FF 2.0
Thanks!
-Miles
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RELEASE CANDIDATE]: Apache-Test-1.29-RC3
Steve Hay wrote: Philip M. Gollucci wrote: A release candidate for Apache-Test 1.29-rc3 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc3.tar.gz looks good on apache 2.2.2, perl 5.8.8 +1 --Geoff
Re: Custom Listen statement in perl-framework (Was: Re: [VOTE] 2.2.2 Candidate)
Sander Temme wrote: On Apr 23, 2006, at 9:37 AM, Paul Querna wrote: Sander Temme wrote: FreeBSD bagheera.sandla.org. 6.1-RC FreeBSD 6.1-RC #3: Fri Apr 21 08:35:33 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/ src/sys/GENERIC i386 Testsuite currently unusable, hangs on: t/protocol/nntp-likeok 1/10 This seems to be a local issue. Anyone else seeing this happen on FreeBSD? No crashes on minotaur which is also FreeBSD. I will advise when the 72 hour window is up. AFAIK, This test fails on all FreeBSD machines. Adding the following to the config file for this test should fix it: AcceptFilter nntp none Listen 119 nntp (Or whatever port it is running on) Actually, the port is determined on the fly by the testsuite, all the configuration language available in the mod_nntp_like.c file is the following: #if CONFIG_FOR_HTTPD_TEST VirtualHost mod_nntp_like NNTPLike On /VirtualHost IfModule @ssl_module@ VirtualHost mod_nntp_like_ssl NNTPLike On SSLEngine On /VirtualHost /IfModule #endif The slightly perverted VirtualHost statement seems to be converted by the testsuite into a combination of: Listen 0.0.0.0:8530 VirtualHost _default_:8530 ServerName localhost.localdomain:8530 NNTPLike On /VirtualHost that's all accurate. So my question, especially to the perl-framework gurus, is how do I add a custom configuration option to that Listen statement? so, you want something like this eventually Listen 0.0.0.0:8530 nntp AcceptFilter nntp none VirtualHost _default_:8530 ... ? I don't think you can currently do that with the framework. I might be able to work up something like Listen mod_nntp_like nntp so that the mod_nntp_like would expand out to match the way we do the vhost sections (though it's adding yet more black magic). it might take me a while to get around to it, but I could probably work on it soonish is there no other way to handle this config wise? --Geoff
Re: Custom Listen statement in perl-framework (Was: Re: [VOTE] 2.2.2 Candidate)
resending to all the interested lists... Sander Temme wrote: On Apr 23, 2006, at 9:37 AM, Paul Querna wrote: Sander Temme wrote: FreeBSD bagheera.sandla.org. 6.1-RC FreeBSD 6.1-RC #3: Fri Apr 21 08:35:33 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/ src/sys/GENERIC i386 Testsuite currently unusable, hangs on: t/protocol/nntp-likeok 1/10 This seems to be a local issue. Anyone else seeing this happen on FreeBSD? No crashes on minotaur which is also FreeBSD. I will advise when the 72 hour window is up. AFAIK, This test fails on all FreeBSD machines. Adding the following to the config file for this test should fix it: AcceptFilter nntp none Listen 119 nntp (Or whatever port it is running on) Actually, the port is determined on the fly by the testsuite, all the configuration language available in the mod_nntp_like.c file is the following: #if CONFIG_FOR_HTTPD_TEST VirtualHost mod_nntp_like NNTPLike On /VirtualHost IfModule @ssl_module@ VirtualHost mod_nntp_like_ssl NNTPLike On SSLEngine On /VirtualHost /IfModule #endif The slightly perverted VirtualHost statement seems to be converted by the testsuite into a combination of: Listen 0.0.0.0:8530 VirtualHost _default_:8530 ServerName localhost.localdomain:8530 NNTPLike On /VirtualHost that's all accurate. So my question, especially to the perl-framework gurus, is how do I add a custom configuration option to that Listen statement? so, you want something like this eventually Listen 0.0.0.0:8530 nntp AcceptFilter nntp none VirtualHost _default_:8530 ... ? I don't think you can currently do that with the framework. I might be able to work up something like Listen mod_nntp_like nntp so that the mod_nntp_like would expand out to match the way we do the vhost sections (though it's adding yet more black magic). it might take me a while to get around to it, but I could probably work on it soonish is there no other way to handle this config wise? --Geoff
[ANNOUNCE] Apache-Test 1.28
The URL http://people.apache.org/~geoff/Apache-Test-1.28.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.28.tar.gz size: 149856 bytes md5: 76ca771bb9d36b6215e7f418a7fd5e9a --Geoff Changes since 1.27: add need_imagemap() and have_imagemap() to check for mod_imap or mod_imagemap [ Colm MacCarthaigh ] shortcuts like need_cgi() and need_php() no longer spit out bogus skip messages [Geoffrey Young] Adjust Apache::TestConfig::untaint_path() to handle relative paths that don't start with /. [Stas] If perlpath is longer than 62 chars, some shells on certain platforms won't be able to run the shebang line, so when seeing a long perlpath use the eval workaround [Mike Smith [EMAIL PROTECTED]] Location of the pid file is now configurable via the command line -t_pid_file option [Joe Orton] remove the mod_perl.pm entry from %INC after Apache::Test finishes initializing itself. because both mp1 and mp2 share the entry, leaving it around means that Apache::Test might prevent later modules from loading the real mod_perl module they're interested in, leading to bad things [Geoffrey Young] use which(cover) to find the cover utility from Devel::Cover and run it only if found. [Stas] Devel::Cover magic is now fully integrated. no more modperl_extra.pl or extra.conf.in fiddling - 'make testcover' should be all you need to do now [Geoffrey Young] Implemented a magic @NextAvailablePort@ to be used in config files to automatically allocate the next available port [Stas] Adjust Apache::TestConfig::add_inc to add lib/ in separate call to lib::-import at the very end of @INC manipulation to ensure it'll be on top of @INC. For some reason lib has changed to add directories in a different order than it did before. [Stas]
Re: [RT] what's the roadmap?
I think that's a good idea, so long as [EMAIL PROTECTED] can withstand the occasional question about our perl glue. Someday I'd actually like to see trunk/glue/perl moved over to mod_perl's trunk, and our C code folded into httpd somehow, but that may take some time doing. in principle I don't mind this idea, and we can certainly consider taking the perl glue under the mod_perl project. I guess the more difficult part would be in deciding how to package things so that it's the least complex for the end user. --Geoff
Re: perl-framework, Makefile.PL with -apxs gives error.
2. perl Makefile.PL -apxs /home/sris/projects/ers-3-0-2/apache2.0/bin/apxs 3. make 4. t/TEST OUTPUT [EMAIL PROTECTED]:~/projects/temp/httpd-test/perl-framework$ t/TEST [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/sris/projects/temp/httpd-test/perl-framework/t/TEST Use of uninitialized value in concatenation (.) or string at /home/sris/projects/temp/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm line 407. well the error is a symptom of something gone awry higher up, notably the inability of Apache-Test to find httpd. if you specify -apxs then essentially $ path/to/apxs -q bindir needs to point to the directory that contains the httpd binary. if it doesn't, or you have a really wacky configuration, just use -httpd instead and you should be ok. HTH --Geoff
[RELEASE CANDIDATE] Apache-Test 1.28
we are pleased to announce a new release candidate for the Apache-Test distribution. http://people.apache.org/~geoff/Apache-Test-1.28-dev.tar.gz please give it a whirl and report back success or failure. prior to the 1.26 release it was discovered that Apache-Test didn't play nice with boxes that had both mp1 and mp2 installed. we thought we had the problem licked but apparently we didn't, so this release contains another try. if you're running mod_perl and can't do both $ perl Makefile.PL -httpd /path/to/httpd-1.X/bin/httpd and $ perl Makefile.PL -httpd /path/to/httpd-2.X/bin/httpd and have 'make test' choose and run against the proper httpd version something is very wrong. hopefully it's all fixed now, but if you experience any problems please report them. --Geoff Changes since 1.27: add need_imagemap() and have_imagemap() to check for mod_imap or mod_imagemap [ Colm MacCarthaigh ] shortcuts like need_cgi() and need_php() no longer spit out bogus skip messages [Geoffrey Young] Adjust Apache::TestConfig::untaint_path() to handle relative paths that don't start with /. [Stas] If perlpath is longer than 62 chars, some shells on certain platforms won't be able to run the shebang line, so when seeing a long perlpath use the eval workaround [Mike Smith [EMAIL PROTECTED]] Location of the pid file is now configurable via the command line -t_pid_file option [Joe Orton] remove the mod_perl.pm entry from %INC after Apache::Test finishes initializing itself. because both mp1 and mp2 share the entry, leaving it around means that Apache::Test might prevent later modules from loading the real mod_perl module they're interested in, leading to bad things [Geoffrey Young] use which(cover) to find the cover utility from Devel::Cover and run it only if found. [Stas] Devel::Cover magic is now fully integrated. no more modperl_extra.pl or extra.conf.in fiddling - 'make testcover' should be all you need to do now [Geoffrey Young] Implemented a magic @NextAvailablePort@ to be used in config files to automatically allocate the next available port [Stas] Adjust Apache::TestConfig::add_inc to add lib/ in separate call to lib::-import at the very end of @INC manipulation to ensure it'll be on top of @INC. For some reason lib has changed to add directories in a different order than it did before. [Stas]
Re: [RELEASE CANDIDATE] Apache-Test 1.28
Mark Galbreath wrote: I'm drawing a blank for those following only dev@httpd.apache.org, and thus may be unaware of what Apache-Test is, here's the deal... Apache-Test http://perl.apache.org/Apache-Test/ is the engine that drives the perl-framework http://svn.apache.org/viewcvs.cgi/httpd/test/trunk/perl-framework/ which is part of the httpd project. the perl-framework used to have its own mailing list that received these release-based announcements, but recently that list was dissolved and perl-framework discussion brought to [EMAIL PROTECTED] I thought it was appropriate to continue announcing releases here since many of the httpd developers use Apache-Test and without some kind of announcement here they wouldn't know of new releases. but if the perl-framework savvy folks on [EMAIL PROTECTED] don't want to receive A-T release-type announcements in the future that's fine by me, too. --Geoff
Re: [proposal] remove [EMAIL PROTECTED]
Justin Erenkrantz wrote: On Fri, Dec 16, 2005 at 12:04:56AM -0800, Justin Erenkrantz wrote: I'd like to propose shutting down [EMAIL PROTECTED] and move it all back under [EMAIL PROTECTED] The traffic on [EMAIL PROTECTED] list doesn't justify a separate list, and the Apache-Test code is now property of the Apache::Perl PMC, so discussions of that are now elsewhere too. All that's really left is just httpd's test cases (which really should be done in view of [EMAIL PROTECTED] anyway) and flood (which, like mod_mbox, might get more lovin' if any posts on it moved to [EMAIL PROTECTED]). Any objections? If no one screams, I'll do it next week. -- justin Posts to test-dev@httpd.apache.org will trigger a bounce like: --- Apache::Test discussions have now moved to [EMAIL PROTECTED] All other work is now on [EMAIL PROTECTED] Please post accordingly. Thanks! excellent, thanks justin :) --Geoff
Re: [proposal] remove [EMAIL PROTECTED]
Justin Erenkrantz wrote: I'd like to propose shutting down [EMAIL PROTECTED] and move it all back under [EMAIL PROTECTED] The traffic on [EMAIL PROTECTED] list doesn't justify a separate list, and the Apache-Test code is now property of the Apache::Perl PMC, so discussions of that are now elsewhere too. All that's really left is just httpd's test cases (which really should be done in view of [EMAIL PROTECTED] anyway) and flood (which, like mod_mbox, might get more lovin' if any posts on it moved to [EMAIL PROTECTED]). Any objections? If no one screams, I'll do it next week. +1 it would be nice if rather than alias [EMAIL PROTECTED] to [EMAIL PROTECTED] the message bounced with some kind of informational message about the new breakdown - we still get A-T questions directed toward [EMAIL PROTECTED] for people who haven't figured out the proper place yet, and I'm just not paying as much attention to [EMAIL PROTECTED] as I used to or ought... --Geoff
Re: [proposal] remove [EMAIL PROTECTED]
Justin Erenkrantz wrote: I'd like to propose shutting down [EMAIL PROTECTED] and move it all back under [EMAIL PROTECTED] The traffic on [EMAIL PROTECTED] list doesn't justify a separate list, and the Apache-Test code is now property of the Apache::Perl PMC, so discussions of that are now elsewhere too. All that's really left is just httpd's test cases (which really should be done in view of [EMAIL PROTECTED] anyway) and flood (which, like mod_mbox, might get more lovin' if any posts on it moved to [EMAIL PROTECTED]). Any objections? If no one screams, I'll do it next week. +1 it would be nice if rather than alias [EMAIL PROTECTED] to [EMAIL PROTECTED] the message bounced with some kind of informational message about the new breakdown - we still get A-T questions directed toward [EMAIL PROTECTED] for people who haven't figured out the proper place yet, and I'm just not paying as much attention to [EMAIL PROTECTED] as I used to or ought... --Geoff
Re: Authz refactoring discussion
Justin Erenkrantz wrote: --On December 6, 2005 11:04:13 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Good, then I am +1 on the authz providers only returning AUTHZ_GRANTED or AUTHZ_DENIED. I don't see a need for anything else. FWIW, I do see a case for returning 'uh-oh, an error occurred'. I'm planning on reviewing the rest next weekish, as I've written a few auth provider hooks and I'm interested in seeing what happens to them with all of this. but here I'll agree - an error condition is nice to have. additonally, though, chaining providers together with DECLINED conditions is really useful. I haven't looked closely enough to see whether this can be accomodated, but it's nice to have and returning DENIED isn't intuitive in this case. fwiw --Geoff
Re: PHP testing - problem with php libraries loading
Chris Shiflett wrote: Hi Filin, I've tride a lot of variants and I even think that IfModule @PHP_MODULE@ php_admin_value extension_dir /usr/lib/php4/ /IfModule _should_ work - but it doesn't! I don't know why :( (I tried both t/extra.conf.in and t/conf/extra.conf.in) The latter is the correct place. You might try getting rid of the conditional statement, just to see if that's the problem. hmm, that's a good point. t/conf/extra.conf.in only affects php tests that run inside the server, such as t/response/TestAPI/foo.php. if you're using t/foo.php-style tests then settings in t/conf/extra.conf.in don't apply. guess we need to figure out how to do that... --Geoff
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
or wathever. Killing AuthtType is good in that it propably lets you combine different Accesses with Auth much cleaner. Dw Good point. After thinking about it, it seems that AuthType could be eliminated completely. The authentication type is already implied by the use of the directives AuthBasicProvider, AuthDigestProvider or any other AuthXXXProvider that may come along in the future. Does anybody see a need to keep AuthType around at all under the new authentication architecture? I'm going a few rounds at the moment with a user that's confused between ap_auth_type(r) and r-ap_auth_type, and why ap_auth_type(r) needs to be set at all if he's writing his own non-basic-non-digest authentication scheme. making the authtype indigenous to the provider mechanisms make a decent amount of sense to me. --Geoff
Re: PHP testing - problem with php libraries loading
cc'ing chris :) I think a line in the t/conf/php.ini: extension_dir = ./ means that php seeks libraries in the current directory, while those libraries are in the /usr/lib/php4/. hmm, could be. chris would know better. Thereby I have 2 questions: 1) Why it is necessary to have a special php.ini for testing? for the same reason that Apache-Test maintains all its own configuration files, really - consistency, principle of least surprise, and so on. think of it like this... say you have code that works one system and doesn't work on another. the problem turns out to be that your php.ini file contains a crucial difference, but one you didn't think was crucial. if your tests relied on the installed php.ini file then you'd have the exact same problem on each box when running the tests, on one box it would fail and on one box it would pass. this is Very Bad from a testing point of view - tests should create a very specific environment in which to exercise your code, one where all the variables are known. using our own php.ini file (and own httpd.conf, etc) means that the described circumstance would never happen - the tests would pass on both systems letting you know immediately that your production environment is _not_ the same as your testing environment. and that is Good from a testing point of view. 2) How can I test (in a sane manner) php code with functions from dynamic libraries? I don't know the specifics, but to alter any php.ini setting you would create t/conf/extra.conf.in and use a php variable to override the default settings in php.ini I've tried to copy mysql.so in the current directory, in all meanings of current which I could imagine but without any success. I've successfully tried to modify the Apache::TestConfigPHP so that it generates now 'extension_dir=/usr/lib/php4/', but I don't think it is a good solving... no, anything you need to override you can do locally from t/extra.conf.in, such as IfModule @PHP_MODULE php_extension_dir /usr/lib/php4/ /IfModule or somesuch - I'm not really a php guy :) chris has links to the sample tarball where you can see tricks like this in action. unfortunately we haven't had the free tuits to document it as well as we would have liked. but then again, nobody seemed to be using the php side of things but us. so, welcome - we hope you like it :) --Geoff
Re: mod_access vs mod_authz_host
Justin Erenkrantz wrote: --On November 3, 2005 4:54:08 PM + Nick Kew [EMAIL PROTECTED] wrote: Just to elaborate on that, it's the name I'm not happy about. I'm perfectly happy with the /modules/aaa/ classification. The problem is that mod_access does not indicate the purpose of the module. I agree. access to what? What is access? if it were anyone else I'd answer those ;) mod_authz_host is by far the best representation of what the module does and how it specifically fits into our module classifications. you really think so? I think it's mistakenly given an authz namespace, giving users the impression it steps in after authentication, or does something else specifically based on r-user. at least any users who have bothered to wrap their heads around the entire aaa idiom and phase separations. So, if you are going to complain about the name, please come up with helpful suggestions rather than having us revert to an ambiguous name. I suggested mod_access_host, which I think fits into the current hierarchy rather nicely. then we could potentially have slots formod_access_cookie, mod_access_useragent, or whatever else people generally use the access phase for. mod_authz_host feels terribly misleading... --Geoff
Re: mod_access vs mod_authz_host
Nick Kew wrote: On Thursday 03 November 2005 16:37, Brad Nicholes wrote: But it does handle access control which kind of puts in the category of authz vs. anywhere else. So can mod_rewrite and others, but that doesn't make it mod_authz_url! Perhaps mod_load_average should be called mod_authz_busy ? In terms of its role, mod_access is not an authz module, for the reasons mentioned in my previous post. Unless you can suggest some much stronger reason it should be? what about mod_access_host? that would give us mod_access_*, mod_authn_*, and mod_authz_* modules corresponding to the different aaa hooks... --Geoff
Re: Cryptic error when LWP isn't available
Justin Erenkrantz wrote: httpd-test gives a really cryptic error message when LWP isn't installed: Use of uninitialized value in concatenation (.) or string at .../Apache-Test/lib/Apache/TestHarness.pm line 121. Be nice if we could fix that. It seems that $_ is trounced by $self-run_t(). My perl-fu doesn't have an elegant solution other than saving $_ before run_t() and then restoring it after. After I did that, I got the 'LWP isn't available' warnings. *light bulb* Once I installed LWP, the error disappeared for whatever reason. Does anyone with perl-fu have a real solution? I'll figure one out sometime today or tomorrow. thanks for reporting it :) --Geoff
Re: getting config file in TestConfigParse.pm
If $file does exist, then the
if (! -e $file -e $default_conf) {
}
is ignored, but the
else {
}
will be followed; in my case, on Win32, it overwrote the correct,
exisiting $file with
$file = catfile $root, $default_conf;
blarg, sorry about that.
which didn't exist. The following patch:
looks good.
--Geoff
Re: svn commit: r290157 - /httpd/test/trunk/perl-framework/c-modules/test_ssl/mod_test_ssl.c
So with 2.1.7 $r-ext_lookup(2.16.840.1.113730.1.13) should return This Is A Comment for any SSL vhost in the test suite if it works properly. excellent! thanks so much for the info. --Geoff
Re: svn commit: r290157 - /httpd/test/trunk/perl-framework/c-modules/test_ssl/mod_test_ssl.c
+#ifdef HAVE_SSL_EXT_LOOKUP
if (!ext_lookup) {
ap_rputs(ssl_ext_lookup not available, r);
return OK;
}
hey, speaking of this ext_lookup, can you give me an example of what this
function does? in Apache::SSLLookup I've added perl glue for this method,
and right now I've got 2 forms:
my $client_foo = $r-ext_lookup($something, 1);
my $server_foo = $r-ext_lookup($something);
but I really could never figure out what to glean from the generated ssl
certificates to test against, what to pass as $something, etc.
ideas?
--Geoff
Re: style update part III
-my ($self, $user, $uid, $gid) = @_; +my($self, $user, $uid, $gid) = @_; eew, the mod_perl style guide doesn't really say that, does it? that's awful. --Geoff
Re: ApacheCon Europe and http://httpd.apache.org/test/
Philip M. Gollucci wrote: Jim Martinez wrote: Who maintains http://httpd.apache.org/test/ ? There's a image on it that reads ApacheCon Europe 2005 that links to the ApacheCon US 2005 (via a redirect). ApacheCon Europe 2005 was, according to the web site, held around July 18th, 2005. Most likely the image should be changed to something applicable for ApacheCon US 2005 (maybe a nonexistent logo). looks like that link isn't part of test/ proper, but rather part of the global httpd site nav - it also shows up on /, for example. anyway, I think that the folks who really spend the time on httpd.apache.org design will fix it when they find some tuits. I believe anyone that is an httpd committer can change it. I think that's right. speaking of which, the real Apache-Test homepage is here http://perl.apache.org/Apache-Test/ anyone looking for something to contribute back might spend some time sprucing it up - IIRC there is already an infrastructure in place to support Apache-Test/api Apache-Test/user/perl Apache-Test/user/php etc --Geoff
Re: ApacheCon Europe and http://httpd.apache.org/test/
I saw that.. The link of perl.apache.org is blank though right ? I'm not quite with the program yet... what do you mean? httpd.apache.org/test links to perl.apache.org/Apache-Test. --Geoff
[ANNOUNCE] Apache-Test 1.26
The URL http://people.apache.org/~geoff/Apache-Test-1.26.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.26.tar.gz size: 147976 bytes md5: 0626e18f95e36b61b035e7485295128e --Geoff Changes since 1.25: make sure mp2 loading doesn't make it impossible to complete mp1 runs. [Matt Sergeant, Geoffrey Young] add Apache::TestConfigParrot and Apache::TestRunParrot to support mod_parrot server-side testing [Geoffrey Young] update -withtestmore action to properly work with newer versions of Test::Builder [Geoffrey Young]
Re: Missing Features of htdigest.c
Well, maybe I explained it bad, so I'll try again: ok :) In 2.1, the AAA was totally restructured, to separate the algorithm (BASIC or DIGEST or whatever) from the storage (FILE or DBM or a database), and to open the full matrix of options to users. However, even if it was done in the server (which I didn't check), it was. there is no way to use it, please don't spread FUD like that. of course you can use it, and I'm sure many people have and will continue to do so. because the supporting programs have never fixed or changed to support it: Nothing was added to dbmmanage or to htdbm or to htpasswd to support different algorithms, or at least DIGEST. Moreover, the only program which still supports DIGEST - htdigest - does almost nothing - no DBM, no database support, and even the minimal features - such as non-interactive mode (-b) so other programs or CGIs can call it - are not supported. ok, I wasn't aware that the majority of people were using these tools interactively to manage users like that. at least not on a large scale. at least not those that really, really wanted to move to digest :) but ok, if that's true then sure - we ought to support digest from these tools... or come up with a better way. so, to that end, to the rest of the developers here's my offer: I'll write an htpasswd replacement that will - allow for management of users using Basic or Digest algorithms - allow for varying data stores - allow for varying user algorithms (mixing of Basic and Digest in the same store, for example) - support (as best I can) existing options from existing support files - whatever else it ought to do it will, of course, be in perl - if people are really just shell'ing out to a binary from a CGI then there's no real reason it _needs_ to be in C. at least that I can see :) anyway, that's the offer. if others like it and can see integrating it then I'll do it. if not, I won't, and no harm done. --Geoff
Re: Unable to run t/ssl tests.
William A. Rowe, Jr. wrote: Well now; rm -rf t , and svn up, gives me the original error attempting to create 'serial', a 'serial.old' lingers during the config phase. after nuking t/ make sure to nuke ~/.apache-test (or whatever it is on win32) and run with APACHE_TEST_NO_STICKY_PREFERENCES=1 from now on to make sure that things aren't lingering around when they shouldn't. other than that, I'll have a look on monday, but I'm not a win32 guy :) --Geoff
Re: Apache::Test v1.25 error - Can't use string (Test::Builder)
Too late to run INIT block at C:/Perl/site/lib/Devel/Cover.pm line 153. Too late to run CHECK block at C:/Perl/site/lib/Devel/Cover.pm line 155. don't worry about those. The only interesting line in t/logs/error_log is: [Mon Jul 18 14:32:40 2005] [error] [client 127.0.0.1] failed to resolve handler `TestMore::testmorepm': Can't dup STDERR: Bad file descriptor at C:/Perl/lib/Test/Builder.pm line 1218. that looks like it's out of my control. maybe randy has more insights? waiting 60 seconds for server to start: .Syntax error on line 382 of C:/code/htt pd-test/perl-framework/t/conf/extra.conf: Invalid command 'DAVLockDB', perhaps mis-spelled or defined by a module not incl uded in the server configuration If I comment out the webdav section from t/conf/extra.conf.in, the tests can run (with errors, but that's another matter). odd, since those directives are in a IfModule mod_dav.c block, so I wouldn't think it would hit those directives without being able to process them. hmm... does t/conf/httpd.conf (which is autogenerated) have something like Loadmodule dav_module mod_dav.dll Addmodule mod_dav.c ? or maybe mod_dav is compiled in statically but is incomplete? maybe Dav On is missing? sorry, but I'm not a dav user, so I don't know the gory details of that module. --Geoff
Re: [VOTE] mod_ftp for HTTP Server Project
Jim Jagielski wrote: Now that Covalent has released it's ERS 3.0 distribution, mod_ftp is now officially offered for donation/incubation/graduation to the ASF. sounds like fun The entire code-base, including Perl test scripts for inclusion in httpd-test, is available and ready for donation into the ASF svn repos. if help, mentoring, or other foo is needed on the httpd-test front I'm more than willing to donate whatever time or assistance is needed. I therefore Call A Vote on whether we should support mod_ftp for inclusion into the Incubator and if we should accept mod_ftp upon graduation from the Incubator. +1 --Geoff
Re: Apache::Test v1.25 error - Can't use string (Test::Builder) as a HASH ref
Stas Bekman wrote: Geoffrey Young wrote: Now, this looks like a bug. The T::B-reset method expects an object, Apache::Test calls it as a class method. I allow for the possibility that I've completely misunderstood everything--or even just some things. well, it's not exactly a bug - it looks like Test::Builder changed reset() from a class method to an object method since that code was written. I guess I'll need to fix that :) Or may be just move the branch that bundles T-M in into the trunk? This problem has been fixed in that branch if I remember correctly. well, I want to run that branch through a battery of tests before we go and merge it into trunk - I, for one, have quite a bit of testing code that relies on proper Test::More support, so if that all ends up working we're probably good to go. has this issue been resolved yet? http://marc.theaimsgroup.com/?l=apache-modperl-test-devm=111512322421210w=2 --Geoff
Re: Apache::Test v1.25 error - Can't use string (Test::Builder) as a HASH ref
Now, this looks like a bug. The T::B-reset method expects an object, Apache::Test calls it as a class method. I allow for the possibility that I've completely misunderstood everything--or even just some things. well, it's not exactly a bug - it looks like Test::Builder changed reset() from a class method to an object method since that code was written. I guess I'll need to fix that :) --Geoff
[ANNOUNCE] Apache-Test 1.22
we are pleased to announce the latest Apache-Test release, 1.22. the important change to note for this release is that mod_perl support is incompatible with mod_perl versions 1.999_21 and earlier. in other words if you are a mod_perl user only upgrade to this release if you also plan to upgrade to mod_perl 2.0-RC5 (1.999_22). users of the other parts of the distribution (TestRun, TestRunC, TestRunPHP) should be unaffected. now for the details... The URL http://people.apache.org/~geoff/Apache-Test-1.22.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.22.tar.gz size: 144807 bytes md5: e62ddf036ae8ab69bf52f20336a656bb --Geoff Changes since 1.21: IMPORTANT this version of Apache-Test does not completely configure mod_perl for mod_perl versions 1.99_21 or earlier. Please read the below changes carefully. *** remove Apache::TestConfig::modperl_2_inc_fixup(). Apache-Test is no longer Apache2.pm aware - it will not configure mod_perl support to look in Apache2/ automatically. [joes] Add support for mp2's Apache:: - Apache2:: rename [joes] The URL http://people.apache.org/~geoff/Apache-Test-1.22.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.22.tar.gz size: 144807 bytes md5: e62ddf036ae8ab69bf52f20336a656bb
Re: [ANNOUNCE] Apache-Test 1.22
Stas Bekman wrote: Geoffrey Young wrote: we are pleased to announce the latest Apache-Test release, 1.22. the important change to note for this release is that mod_perl support is incompatible with mod_perl versions 1.999_21 and earlier. by earlier Geoff meant 1.99_xx .. 1.999_20 (the mp2-tobe versions). It doesn't affect mod_perl1 users. yes, quite sorry about that :) --Geoff
[ANNOUNCE] Apache-Test 1.21
The URL http://cvs.apache.org/~geoff/Apache-Test-1.21.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.21.tar.gz size: 144796 bytes md5: dc8b26adc5717e94435479604e74fdfc Changes since 1.20: fix Apache::TestConfig (was missing 'use lib' before using lib::import) [William McKee [EMAIL PROTECTED]] TestConfigPerl will now configure mod_perl last, giving mod_perl highest priority throughout the httpd lifecycle. [Geoffrey Young] Apache::TestConfig::untaint_path needs to remove empty entries in the PATH list, since -T considers those tainted too. [Stas] add Apache::TestHarnessPHP which allows for running client-side scripts via php instead of perl. [Geoffrey Young]
[RELEASE CANDIDATE] Apache-Test 1.21
a release candidate for Apache-Test 1.21 is now available. http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. --Geoff Changes since 1.20: fix Apache::TestConfig (was missing 'use lib' before using lib::import) [William McKee [EMAIL PROTECTED]] TestConfigPerl will now configure mod_perl last, giving mod_perl highest priority throughout the httpd lifecycle. [Geoffrey Young] Apache::TestConfig::untaint_path needs to remove empty entries in the PATH list, since -T considers those tainted too. [Stas] add Apache::TestHarnessPHP which allows for running client-side scripts via php instead of perl. [Geoffrey Young]
Re: Multiple AAA providers
This functionality would be useful for more than just LDAP: you might want
to use two different flat file databases, or maybe you want to auth
someone in LDAP and someone else in SQL.
This is really an AAA-wide question rather than an LDAP specific question.
Anyone know how difficult this would be to do in the current AAA structure?
I think we just need another status besides
typedef enum {
AUTH_DENIED,
AUTH_GRANTED,
AUTH_USER_FOUND,
AUTH_USER_NOT_FOUND,
AUTH_GENERAL_ERROR
} authn_status
something like AUTH_DECLINED, which would mean that the current provider is
passing on doing the checking. code that into the provider loop and you're
done.
I can find the time to do this probably this week if justin or the other
provider authors think it's a good idea.
--Geoff
Re: Multiple AAA providers
This solves the problem for multiple providers, but the problem isn't solved for where the same provider is used twice, for example: - If user is present in file A or file B - If user is present in directory A or directory B hmm... isn't this kind of thing really up to the provider itself? I would think that the provider would need to be intelligent enough to understand when to iterate over directories or files and when not to. There are two options to this: - Teach each provider how to handle multiple instances of itself (sounds like too much duplication) - Introduce a concept like this: Auth ldap-provider-A # LDAP stuff for LDAP server A /Auth Auth ldap-provider-B # LDAP stuff for LDAP server B /Auth AuthBasicProvider ldap-provider-A ldap-provider-B while I don't claim to have more than a cursory understanding of ldap, I would think these cases could be handled by extending the current situation a bit. for instance, for the file provider something like AuthBasicProvider file AuthFileName file1 file2 if AuthFileName were ITERATE mod_authn_file would know that it should not return AUTH_USER_NOT_FOUND until it has checked all the files present. or somesuch off the top of my head. are there situations specific to ldap that would make some variant of this difficult or unacceptable? I'm just trying to get a better feel for why the exception you raise isn't an issue for providers to locally figure out themselves. --Geoff
Re: Multiple AAA providers
To fill out the example of the Auth container to better illustrate what I mean, you might have this: Auth ldap-acc-activedirectory require ldap-group cn=Accounting,ou=Groups,ou=XXX AuthLDAPBindDN cn=Mail,dc=XXX AuthLDAPBindPassword blah1 LDAPTrustedMode SSL AuthLDAPURL ldaps://xxx.co.za/dc=xxx,dc=co,dc=za?uid?sub AuthLDAPRemoteUserIsDN on /Auth Auth ldap-eng-activedirectory require ldap-group cn=Engineering,ou=Groups,ou=YYY AuthLDAPBindDN cn=Mail,dc=YYY AuthLDAPBindPassword blah2 LDAPTrustedMode SSL AuthLDAPURL ldaps://yyy.co.za/dc=yyy,dc=co,dc=za?uid?sub AuthLDAPRemoteUserIsDN on /Auth AuthBasicProvider ldap-acc-activedirectory ldap-eng-activedirectory yeah, ok, I can see what you mean :) but a configuration like that doesn't strike me as something easily done with the current set of tools. but I'm sure that someone more familiar has a different opinion. alright, so we have two issues then - see if we can't provide some kind of configuration grouping like this - allow providers to fall through to eachother via a declined mechanism am I capturing it? --Geoff
Re: Multiple AAA providers
AUTH_USER_NOT_FOUND acts as AUTH_DECLINED. The auth modules loop until it runs out of providers or it receives something other than AUTH_USER_NOT_FOUND. -- justin duh. I saw that but was reading the logic wrong. thanks :) --Geoff
Re: Actively Promoting Apache 2
Paul Querna wrote: Ian Holsman wrote: Also I would start discussing with some of the other 1.3-only module writers out there on how to port their stuff to 2.0, or port it for them. There are not many left now Just those mod_perl guys, and they are at 1.99.9. I think you left off a few significant digits there. ;) --Geoff
Re: [PATCH] tracking active request phase
Jeff Trawick wrote: On Mon, 28 Feb 2005 08:39:06 -0600, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Wow :) That would be extraordinarily useful. Any hope the scheme would be extensible, so a module such as cgi or rewrite could show more specific Phases? I'm leaning towards having completely accurate info maintained by the core, and arbitrary modules would need to use a separate mechanism to provide more info. on a somewhat related note, I started down a different-but-similar-enough path some time ago: http://marc.theaimsgroup.com/?l=apache-httpd-devm=108693011011443w=2 while the idea fizzled from lack of interest/review, the idea I had was to eventually rewrite mod_info so that it used a generic mechanism like the one in the patch (albeit with more API methods, and so on). it seems that the proper hook-level API could accomplish both what I wanted to do as well as what jeff and bill would like to see. and that would be great :) so, in case it is of help with jeff's immediate itch, there it is. if not, that's ok too :) --Geoff
Re: [Fwd: MODERATE for modperl-cvs@perl.apache.org]
I've approved joe as a poster. Geoff, why the moderation hits the modperl-cvs /at/ perl.apache.org list? I dunno. ask set these up. pinging ask now :) Also it looks that commits to A-T go to two lists: To: [EMAIL PROTECTED], modperl-cvs@perl.apache.org any special reason? I didn't do it. I'll ping justin. fixed - thanks justin :) --Geoff
Re: Apache-Test subdirectory has moved
yay, php docs at perl.apache.org :) they may be more popular, but I think we still win when it comes to open-source altruism :) sure. but what I'm hoping to accomplish is a more coherent set of documentation for Apache-Test that transcends what we've done (and documented well) over in mod_perl-land. so shuffling things about would help that I think. you? I'm all for it! cool. I'm going to spend some time over the next few days trying to get this situated, then. should there be Apache-Test/dist too? or should the CPAN distribution be sufficient? we can do that, although http://search.cpan.org/dist/Apache-Test/ is just as good. but if we want to mirror the way we do mod_perl then we can have dist/ as well, no problem. also we may want to add a /Apache-Test/snapshot for svn-impaired users. that's a good idea. I'll see if I can find the snapshot scripts or talk to whoever I need to to get that setup. --Geoff
Re: loading mod_perl first?
This solution looks good to me, but should be mod_embperl.c instead of Embperl.c. well, I went to the embperl site and added this to my httpd.conf LoadModule embperl_module /tmp/Embperl.so and things worked out as expected [ debug] /tmp/Embperl.so is already absolute [ debug] /tmp/Embperl.so successfully resolved to existing file /tmp/Embperl.so [ debug] Found: embperl_module = Embperl.c [ debug] Skipping LoadModule of Embperl.c is this not a correct setup? or it is for apache2 and not apache 1.3? --Geoff
Re: [Fwd: MODERATE for modperl-cvs@perl.apache.org]
Stas Bekman wrote: Folks committing to A-T, please don't forget to subscribe to the new lists: [EMAIL PROTECTED] [EMAIL PROTECTED] I think I mentioned that before, but it never hurts :) I've approved joe as a poster. Geoff, why the moderation hits the modperl-cvs /at/ perl.apache.org list? I dunno. ask set these up. Also it looks that commits to A-T go to two lists: To: [EMAIL PROTECTED], modperl-cvs@perl.apache.org any special reason? I didn't do it. I'll ping justin. --Geoff
Re: The use of CORE_PRIVATE
Bojan Smojver wrote: if I rely on what's below CORE_PRIVATE, am I setting myself up for a disaster when those things change without notice? I think the answer to this is similar to the old line if you need to ask how much it costs you can't afford it. ;) --Geoff
Re: Apache-Test subdirectory has moved
Stas Bekman wrote: Geoffrey Young wrote: the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test what this means for you is that you need to manually adjust your checkout $ rm -rf Apache-Test/ $ svn update ugh, rm is not a good idea if you have modified files in it. should svn switch somehow do the trick instead? it probably should but it doesn't. just copy your modified files to someplace safe, do the update, then move then back. --Geoff
Re: Apache-Test subdirectory has moved
Also Geoff please don't forget to update the documentation. Both inside the module and at perl.apache.org docs. Thanks. I couldn't find any mentions of the location of the repository outside of README-SVN. do you know of others? additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. --Geoff
Re: preload modules at sever startup
Jim Martinez wrote:
Hi,
I'm looking for some suggestions for a library problem with Apache::Test,
which I'm using to develop a web application.
Hope this is the place to ask.
better [EMAIL PROTECTED] now, but that list was just created yesterday :)
Using Apache 1 and Mod perl 1, how can I preload perl modules at server
startup?
My extra.conf.in contains something like this:
PerlModule Foo::Bar
Location /a
SetHandler perl-script
PerlHandler Foo::Bar::myhandler
/Location
make test fails. The apache server won't start because it can't find
Foo::Bar, needed by the line PerlModule Foo::Bar
if you can move it to t/lib/Foo/Bar.pm Apache-Test will pick it up.
In the link below, I read about PerlSwitches [EMAIL PROTECTED]@/../lib
http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup
Is PerlSwitches for MP2 only?
yes. an equivalent in mp1 might be to do this in extra.conf.in
Perl
use lib qw(@ServerRoot@/../lib)
/Perl
or without the Perl sections from modperl_extra.pl.in, which is equivalent
to startup.pl but with @var@ substitution. you can use modperl_extra.pl if
you don't need substitution.
keep in mind that if you go this route you will probably need to change
extra.conf.in to extra.last.conf.in so that it is loaded _after_ your
startup.pl. see the bottom of the generated httpd.conf to see what I mean.
In the link above I'd call the root development directory
/path/to/Apache-Amazing, just so that you understand what I mean by root
development directory. Here is a listing of the root development
directory:
CVS/ Changes MANIFEST MANIFEST.OLD MANIFEST_maybe META.yml Makefile
Makefile.PL README blib/ docs/ lib/ pm_to_blib t/
Of course Foo::Bar is in lib/Foo/Bar.pm (until Apache::Test moves it to
blib/ )
If I set PERL5LIB to the root development directory, the make test runs
fine (well it shows me my programming errors is what I mean).
Should I create a starup.pl file that does something like:
BEGIN { use lib @[EMAIL PROTECTED]/lib }
Then and add lines to extra.conf.in to run startup.pl.
Or is there a better way? A hard coded path won't work in my situation
(which is why I use the @ServerRoot@).
no, that's the idea. you just need to use the magic files :)
HTH
--Geoff
Re: loading mod_perl first?
may be we should be more flexible right away and use the same approach Apache uses, i.e. have each custom module a say for its insertion priority. So we could add mod_perl as middle module and give other modules an opportunity to load themselves before (first/very_first or after (last/very_last) mod_perl or some other module. It really shouldn't be mod_perl centric as more and more non-perl projects start to use A-T. well, I think this is kinda a mod_perl problem, since we're only talking about TestConfigurePerl and it's special treatment of mod_perl. if you use TestConfig or TestConfigPHP then the modules are just inherited from httpd.conf (mod_perl included) in the order in which they appear there, which is typically what the user wants. in general, I think it is atypical that one apache module depends on another module being loaded before it itself can load. that is, in a LoadModule sense - sure, lots of things depend on mod_perl, but they use PerlModule not LoadModule. embperl seems to be the exception to this. axkit would be the only other I could think of but I just verified that it uses PerlModule as well. So instead of printing the modules right away they could be assembled into an array which will be then resorted the way the user wants. e.g.: add_foo(, before = mod_perl.c); add_foo(, after = qw[mod_perl.c mod_proxy.c]); or have those before/after/last/first/etc encoded in the API instead... well, I think that for the most part inheriting order from httpd.conf is sufficient, at least for the moment, but we can always create a larger API later when time allows. for the moment, though, I think I'm happy to make an exception for embperl within TestConfigPerl. at least until somebody complains :) --Geoff
Re: loading mod_perl first?
Christopher H. Laco wrote:
Geoffrey Young wrote:
in general, I think it is atypical that one apache module depends on
another
module being loaded before it itself can load. that is, in a LoadModule
sense - sure, lots of things depend on mod_perl, but they use
PerlModule not
LoadModule. embperl seems to be the exception to this. axkit would
be the
only other I could think of but I just verified that it uses
PerlModule as well.
Don't the new 2.x proxy modules have the same type of dependency?
mod_proxy_connect, mod_proxy_http and mod_proxy_ftp require mod_proxy,
but I've never tried loading them out of order to see if they fail.
yeah, that seems to be the case. and apparently there are some things that
may require mod_dav as well.
but generally this isn't an issue, since we inherit the order, as well as
module location, from httpd.conf. of course, if mod_dav wanted to use
Apache-Test for its own development it wouldn't inherit from httpd.conf but
would create its own TestConfigDav.pm class to handle things for it.
what makes mod_perl unique in this circumstance is that we are making
exception for Embperl, which is really a third party module that we have no
control over - anybody can have a custom mod_foo that depends on mod_perl or
any other module, but that doesn't mean we need to account for it in
Apache-Test land.
anyway, I'm starting to think that the best solution is like the one I've
attached here, at least for the moment. what this means is that people with
Embperl in their httpd.conf won't have problems, while people wanting to
explicitly test Embperl will have to do what everyone else needs to do -
subclass TestConfig.pm and determine the module loading order themselves.
--Geoff
Index: TestRunPerl.pm
===
--- TestRunPerl.pm (revision 153110)
+++ TestRunPerl.pm (working copy)
@@ -35,6 +35,9 @@
# Apache::TestConfigPerl already configures mod_perl.so
Apache::TestConfig::autoconfig_skip_module_add('mod_perl.c');
+
+# skip over Embperl.so - it's funky
+Apache::TestConfig::autoconfig_skip_module_add('Embperl.c');
}
sub configure_modperl {
Index: TestConfigPerl.pm
===
--- TestConfigPerl.pm (revision 153110)
+++ TestConfigPerl.pm (working copy)
@@ -94,10 +94,7 @@
debug $msg;
}
-# modules like Embperl.so need mod_perl.so to be loaded first,
-# so make sure that it's loaded before files inherited from the
-# global httpd.conf
-$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+$self-preamble(IfModule = '!mod_perl.c', $cfg);
}
Re: Apache-Test subdirectory has moved
if you don't find any with grep, then there are none. So we should add one then :) :) yes, now that it's officially ours we should do more to publicise it. additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. I see that you added test/ but it's probably not the most intuitive naming. I think perl.apache.org/Apache-Test/ is more sensible. that's cool. additionally I think we should have subdirectories for each of the supported languages /Apache-Test/perl /Apache-Test/php /Apache-Test/parrot (someday soon) and so on. in fact, it was the need for a home for php-related docs and whatnot that prompted this move in the first place ;) And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? yes, specifically under /Apache-Test/perl was what I was going to suggest. And of course links to it need to be adjusted too, to reflect the new location. (and Apache/README and other docs, like .pm files) yes. and probably a rewrite rule should be added too for those who link directly to that URL. http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup good idea. from an .htaccess file or do we do that in the core httpd.conf? of course we could avoid all that, by keeping the tutorial where it is, and just add a link from config.cfg to it. sure. but what I'm hoping to accomplish is a more coherent set of documentation for Apache-Test that transcends what we've done (and documented well) over in mod_perl-land. so shuffling things about would help that I think. you? --Geoff
loading mod_perl first?
hi all...
in TestConfigPerl we have this logic and comment
# modules like Embperl.so need mod_perl.so to be loaded first,
# so make sure that it's loaded before files inherited from the
# global httpd.conf
$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
what this does is load mod_perl.so ahead of all other modules, giving it
least priority. there are a few problems I see with this
- in 1.3 this is a _very_ untypical setup - mod_perl.so needs to be loaded
last so that it gets first crack at each phase.
- in 2.X order doesn't matter due to the new hooking API, but it _does_
matter for overriding directives. that is, you can't load mod_perl.so first
and get first crack at _directive_ parsing.
anyway, I guess what I'm saying is that 99% of the time we want mod_perl to
have the highest priority, but we do the exact opposite with Apache-Test,
which is probably ungood.
now, in all fairness to embperl I don't want to just yank this out without
giving gerald some alternative. however, I think it's a bad idea to create
a test environment that doesn't accurately represent the most common case.
so, here are some possible solutions...
- historically I think this was introduced before we had
extra.last.conf.in functionality. gerald, does using that file help you?
- we could provide for an extra argument to configure_libmodperl() which
would place mod_perl.so first instead of the (new) default of last. this
would allow folks like embperl to do something like
package My::TestConfigurePerl;
our @ISA = qw(Apache::TestConfigurePerl);
sub configure_libmodperl { shift-SUPER::configure_libmodperl(1) }
and have things work the way they did before. patch attached.
thoughts?
--Geoff
Index: lib/Apache/TestConfigPerl.pm
===
--- lib/Apache/TestConfigPerl.pm (revision 152675)
+++ lib/Apache/TestConfigPerl.pm (working copy)
@@ -29,6 +29,8 @@
sub configure_libmodperl {
my $self = shift;
+my $first = shift;
+
my $server = $self-{server};
my $libname = $server-version_of(\%libmodperl);
my $vars = $self-{vars};
@@ -94,10 +96,17 @@
debug $msg;
}
-# modules like Embperl.so need mod_perl.so to be loaded first,
-# so make sure that it's loaded before files inherited from the
-# global httpd.conf
-$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+if ($first) {
+# modules like Embperl.so need mod_perl.so to be loaded first,
+# so make sure that it's loaded before files inherited from the
+# global httpd.conf
+$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+}
+else {
+# the default for most mod_perl installations - give mod_perl
+# highest priority by loading it last.
+$self-preamble(IfModule = '!mod_perl.c', $cfg);
+}
}
Apache-Test subdirectory has moved
the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test what this means for you is that you need to manually adjust your checkout $ rm -rf Apache-Test/ $ svn update to get the perl-framework running smoothly again. if you have any problems with access or permissions, just let me know and we'll get it sorted out. part of the reason we did this migration was to separate testing activities from the development of the Apache-Test engine. to that end, two new mailings lists were created: [EMAIL PROTECTED] [EMAIL PROTECTED] so, if you want to follow Apache-Test development you will want to subscribe to one or both of those mailing lists via sending an empty email to [EMAIL PROTECTED] [EMAIL PROTECTED] although I suspect that we will all be following [EMAIL PROTECTED] as well, the use of the new dev list is encouraged for ongoing discussions directly related to Apache-Test. --Geoff
Re: [PATCH] set username from certificates at a more appropriate time
Joe Orton wrote: I presume this fixes #31418? Your patch makes sense to me. I could argue that it could even be done *before* the SSLRequire checking, such that the username is logged appropriately even if an SSLRequire triggers a 403, but I doubt that matters much. fwiw that's the route that the auth providers took when we last looked at this - make it possible to log the user, with the understanding that the user might not have passed the auth process so may be completely bogus. --Geoff
Re: svn commit: r148889 - /httpd/test/trunk/perl-framework/t/conf/ssl/ssl.conf.in /httpd/test/trunk/perl-framework/t/ssl/fakeauth.t
Geoff, removing the SSLRequire line is right, it doesn't really matter though... ok, done. thanks for the input. --Geoff
Re: svn commit: r148889 - /httpd/test/trunk/perl-framework/t/conf/ssl/ssl.conf.in /httpd/test/trunk/perl-framework/t/ssl/fakeauth.t
So Geoff is saying, you must try and at the next line you must also succeed. With SSLVerifyClient optional, the semantics would be instead Don't bother to insist for a certificate, but if user forgot it, give him flaming death. Considered inappropriate :-) i'm no expert here - I took the SSLRequire line from the test case on httpd-dev, while all the other tests use SSLVerifyClient so I kept it without really understanding things at all. http://marc.theaimsgroup.com/?l=apache-httpd-devm=110685418427430w=2 so, are you saying that can remove SSLVerifyClient here and all is ok? all I wanted was to exercise FakeBasicAuth + mod_auth_anon. --Geoff
Re: FakeBasicAuth - a howto anywhere?
I made the change, and it now works, thanks! Is it possible to fix mod_authn_anon? How hard is the bug to fix? Not that hard. If nobody beats me, I'm going to make it over the weekend. It's because conf-anyuserid is not checked in the provider when no further user id is configured. I added a test for this to the perl-framework - t/ssl/fakeauth.t. it currently passes based on the Anonymous dummy * fix you suggested, but should be easy to modify based on whatever behavior it is supposed to have. ping me if you need help. --Geoff
Re: Apache2 / mod_perl1 confusion
Gavin Carr wrote: On Fri, Jan 21, 2005 at 09:26:53AM -0500, Geoffrey Young wrote: I'm trying to test a C module against both apache2 and apache1. apache1 is working beautifully, but when I attempt to reconfigure for apache2 (stock FC1), A::T (1.20) keeps complaining about finding mod_perl 1. I'm doing: ./TEST -clean ./TEST -apxs /usr/sbin/apxs -conf when I run tests against both apache 1 and apache 2 I generally 'make realclean' and then re- perl Makefile.PL -apxs... and it works just fine. if you look in t/TEST you'll probably see your old -apxs path in there. well, that is, if you specified -apxs when building your Makefile :) Since this is a C module I'm actually just using a static TEST like this: #!/usr/bin/perl use strict; use warnings FATAL = 'all'; use Apache::TestRunPerl; Apache::TestRunPerl-new-run(@ARGV); since it's just a C module and you don't need mod_perl you should change that Apache::TestRunPerl to just Apache::TestRun. that should make A-T use the inherited mod_perl from httpd.conf instead of hunting around for it. straight out of one of the A::T tutorials. you should check out the code from the tutorial I gave at ApacheCon. the code is here http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2004/test-driven-development-code.tar.gz and the tutorial slides are here http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2004/test-driven-development.pdf pay particular attention to mod_example_ipc-install in the code tarball. basically, put your C module in c-modules following the pattern you'll see there (filenames and directory names and declarations are important). then let Perl manage t/TEST and the Makefile for you using makefile. No change with APACHE_TEST_NO_STICKY_PREFERENCES=1, and I don't have a ~/.apache-test at all. Nothing actually ends up in t/conf after the -conf run either - it looks like it's just bailing out. hmm, that's odd. Any further suggestions of where to look? Might be perl debugger time ... I would start with copying the workflow I outline in the tarball I mentioned above. it's a bit different than what you're doing now, so it may feel strange, but give it a whirl and see if it works. then you can decide if you like it or not :) HTH --Geoff
Re: t/TEST -start-httpd -port=34343
http://perl.apache.org/docs/general/testing/testing.html#Parallel_Testing Here's what I see when I run t/TEST -start-httpd -port=34343 yeah, this is where Apache-Test gets confusing... it's '-port 34343' not '-port=34343'. same with '-port select'. this is different than, say '-trace=debug' where the = is required... basically, the first set of options from t/TEST -help use an equal sign and are part of Apache::TestRun. the second set _do not_ use an equal sign and are part of Apache::TestConfig. gotta love legacy decisions :) --Geoff
Re: A-T: httpd.conf.in
I think we should implement it, since if someone is very unhappy about the autogenerated httpd.conf they can supply their custom httpd.conf.in that feels like a lot of work to me - like making A-T respect the Port setting from httpd.conf.in, because that's what they would expect. I think that -httpd_conf, -httpd_conf_extra, and extra.conf.in should be more than enough for the vast majority of people. so +1 for just removing it from the README, but if you want to make it work, feel free. --Geoff
Re: Apache-Test
Stas Bekman wrote:
Geoffrey Young wrote:
In which case we need to remove the custom patterns we have added so
far?
hmm, did we actually add any, or just make the regex a bit more loose? I
can't recall.
can you see how Apache-PREFORK-AdvancedExtranetServer/2.0.52 matches 1?
That's because our code is completely broken, since this is bogus:
# Apache-AdvancedExtranetServer/1.3.29 (Mandrake Linux/1mdk)
($self-{rev}) ||= $self-{version} =~ m|^Apache.*?/(\d)\.|;
# IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Unix)
($self-{rev}) ||= $self-{version} =~ m|^.*?Apache.*?/(\d)\.|;
it always matches 1. It should be:
# Apache-AdvancedExtranetServer/1.3.29 (Mandrake Linux/1mdk)
($self-{rev}) ||= ($self-{version} =~ m|^Apache.*?/(\d)\.|);
# IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Unix)
($self-{rev}) ||= ($self-{version} =~ m|^.*?Apache.*?/(\d)\.|);
we have noticed that bug, since those patterns were written when testing
1.3 and of course it has matched 1 :)
yeah, I wish I had noticed before - it's a major gripe of mine that ||=
wrecks that match idiom.
Let's try first with a relaxed /x.y.zz, before we add yet another env var.
ok.
--Geoff
Re: [A-T patch] changing should_skip_module to support regex skip patterns
Stas Bekman wrote: As you can see from the email below, some modules embed a version number in the module 'mod_fastcgi-2.4.2-AP20.dll'. Our should_skip_module only matches an exact name. The patch at the end of this email extends the functionality to support regex skip arguments. Let me know if you have any objections to this change. +1 +$name =~ s/\.(s[ol]|dll)$/.c/; #mod_info.so = mod_info.c +$name =~ s/\.dll$/.c/; #mod_info.so = mod_info.c ? --Geoff
Re: How to change ap_document_root variable from a apache2 module ?
This can be done quite safely in Apache1, by the way. I don't believe it can. Code? Well, since you don't need to worry about thread safety as long as you set it on every request, or reset it after each request you are fine. Something like: foo-old = ap_document_root(r); conf = ap_get_module_config(s-module_config, core_module); conf-ap_document_root = new; ap_register_cleanup(r-pool, foo, my_cleanup, ap_null_cleanup); Then set it back to foo-old in my_cleanup(). fwiw, we follow this exact logic in mod_perl for Apache 1.3 as well. And yes, I agree it is a hack to change anything in the core_module on a per-request basis, but there are a lot of things that are very useful hacks in Apache1 right. IIRC the inability to formally manipulate DocumentRoot is one of the things that prevents (or did prevent the last time I looked at it, which was a while ago) mod_vhost_alias and mod_frontpage from playing nice together. that I am hoping to see the richer and more flexible Apache2 API address. it would certainly be nice to do this, but there has always been a little pushback in the past IIRC. the main argument that I remember is the DocumentRoot is considered private to core one, but I'm just not sure how much I believe this - if it were really private we wouldn't offer read access either. does it make sense to perhaps code in an optional function (or somesuch) in 2.2 that core would use to override its own DocumentRoot on a per-request basis? --Geoff
Re: Apache and Application driven Basic Auth
I'm trying to understand whether Apache even supports application driven Basic Authentication. it does, but our ideas of application are very different. more on that later... It seems odd that this should be difficult to do - I've worked with a fair number of Web Servers over the yaers and this the first time I've run into a situation where the Web Server does not auto negotiate the protocol when enabled in a directory. But then most other Windows Web Servers use the built-in OS security to manage directory level authentication. it does, just not where you want it to be. All the discussion I've seen so far seems to center around authenticating against resources in the file system, which works as expected. But Basic Auth as a protocol is not bound to the file system. So my question is how do I make Apache pass through all requests to my application *and* authenticate the applications Basic Auth negotiation when I ask for it with a 401 header? for apache, authentication and content are distinctly separate. you want to place both in the content phase (your application) but apache's default authentication mechanism just doesn't work that way. Apache does all that but only against its files, not against application generated requests. With my Application generated requests it basically interjects itself but doesn't process or forward the browser's Auth information. So you get a situation where there's no hook. the hook is called the authen phase. This is a fairly common task in Web applications... I get the feeling Apache can't do this at least not without writing custom auth (which would be preferred anyway, I think you've got it :) but this is a generic tool and people want use Web Server integrated security from their own applications). if you want to control security from within your own, content-only application you can. you just can't use apache's default file-based user:password mechanism (mod_auth) - it's simply too late in the request for that to happen. I do apologize for my ignorance on Apache - as stated this is not my primary tool and that's why I'm asking g. I've spent a fair amount of time trying to google info on this subject but I've come up pretty much blank. I'm more than happy to dig if there are any pointers where to look. What I've found in the docs and via Google all deals with file based permissions... you might understand apache a bit better by trying one of the books that discuss the apache request cycle. just because I know it's decent, you can try this: http://www.modperlcookbook.org/chapters/part3.pdf while it discusses the perl interface to the apache apu instead of the C interface, the concepts are the same. HTH --Geoff
Re: Apache and Application driven Basic Auth
ok, it just hit me that my last response was probably too academic for your needs. this part escaped me... Apache does all that but only against its files, not against application generated requests. Anyway if I do this inside of my directory tag: All requests are going through and my Auth requests for 401 Authentication are not validated and fail. Directory is a filesystem-based container, but it is only one of several ways to configure your server. see also Location and LocationMatch for URI-based configuration and even Files and FilesMatch for filename-based configuration. between all of them, and a basic understanding of how the different containers merge, you can effectively apply the Require directive only to the parts of the configuration that you want. see http://httpd.apache.org/docs/sections.html for some helpful guidelines. --Geoff
Re: Apache and Application driven Basic Auth
AuthType Basic AuthUserFile d:\server\users\passwords.txt Is there anything I'm missing here? I think you need a Require directive http://httpd.apache.org/docs/mod/core.html#require HTH --Geoff
Re: Apache and Application driven Basic Auth
Rick Strahl wrote: Thanks Geoff, I think you need a Require directive Yes I do g... but as soon as I put a Require in there it tries to validate every request into the directory. yes it does :) This is not what's requried. I need conditional authentication that's generated through the application. I can do this with my own implementation of course, but it seems Apache should allow me to do this under program control. IIS handles this no problem... Apache isn't IIS :) There's an update to where I'm at here: http://west-wind.com/weblog/posts/1211.aspx I now at least have Authentication working, but it's still not what I'd like to see for the app server with users getting the ability to simply ask for auth from within the application by sending a 401 header. that isn't how Apache works, really. or http for that matter. you can send a 401 response/WWW-Authenticate header to your browser, and the browser will send an appropriate Authorization header, but on the next request. _that_ incoming request needs to be authenticated, and the way apache does that is via the authen/authz phases. without the Require directive those phases won't be run, so no authentication will take place. so, typically what you need to do for conditional authentication is apply the Require directive to enable authentication, then _disable_ auth for the requests that don't require it. one way is to use the Satisfy directive with the Any option and code your access phase according to your specifications. anyway, at this point the conversation doesn't really belong on [EMAIL PROTECTED] since this is a developer list and you're having a user/config issue. you might want to try #apache on irc.freenode.net for more pointers. HTH --Geoff
Re: A-T: testmore failures
so you are looking at encountering other problems, as you try to run modperl tests without using a correct environment. yeah, you're right. or something else needs to be done with t/more. yes. well, with Apache/Test.pm actually. this should be more helpful: Index: lib/Apache/Test.pm === --- lib/Apache/Test.pm (revision 122981) +++ lib/Apache/Test.pm (working copy) @@ -75,7 +75,7 @@ Test::More-import(@testmore); \Test::More::plan; -} or die -withtestmore error: $@; +} or print 1..0 # skipped: -withtestmore error [EMAIL PROTECTED] exit; # clean up arguments to export_to_level shift; of course, that will rely on a recent fix to mod_perl svn :) or not worry about it at all - t/more isn't in the MANIFEST, so it will only be a problem for people like us. I mean, we can spend tuits mucking around with it, but I don't think it's all that important, since -withtestmore is marked as useful but experimental anyway. Why not put it in a separate test suite then? That should be an easy thing to do, and Apache-Test already includes additional test suites since a few days. sure, that's fine. --Geoff
Re: A-T: testmore failures
the problem is simple - A-T's test suite doesn't use Apache::TestRunPerl, so all the special stuff needed by modperl is not used. So it picks the default module it finds (if any). in this case it picks the wrong mod_perl.so, and the server side ends up running under a different perl. yeah, well... it's not _my_ fault that the test checks for Test::More and mod_perl but the embedded mod_perl.so isn't the same :) So I think the only solution to this is enforce that A-T tests require installed modperl. I wouldn't want to do that - people other than mod_perl folks are using this and I wouldn't want to effectively say the tests can't be run unless you're using mod_perl, loser. or something else needs to be done with t/more. or not worry about it at all - t/more isn't in the MANIFEST, so it will only be a problem for people like us. I mean, we can spend tuits mucking around with it, but I don't think it's all that important, since -withtestmore is marked as useful but experimental anyway. --Geoff
Re: mod_ssl exported functions?
Torsten Foertsch wrote: Hi, I am writing a mod_perl module that makes mod_ssl optional functions accessible via perl. I have currently implemented ssl_is_https() and ssl_var_lookup() which is enough for my needs. for the record, this interface is/was already available for perl on CPAN, so you didn't need to go uploading another interface. For the sake of completeness I am wondering if ssl_engine_disable() and ssl_proxy_enable() need to be interfaced. But I don't know what they are good for. I think the utility of these in perl depend on how much we are going to be able to configure mod_proxy from other-than-mod_proxy land, which is kinda up in the air at the moment. but that's just a 30 second inspection opinion... this discussion probably belongs on the mod_perl list anyway. --Geoff
Re: SVN release methodology : svn copy
svn copy https://svn.apache.org/.../trunk \ https://svn.apache.org/.../tags/1.17 (optionally with an -r to peg at specific revision, I guess) Yes, that's probably what we will have to end up doing in the future. if you can find the time, can you please make sure the RELEASE file is up to date so that the next person to release Apache-Test has no trouble doing the right thing? thanks :) --Geoff
Re: Apache-Test/Makefile.PL r105822
doesn't seem to be right. sub is a compile time directive, so putting it in a conditional doesn't prevent from it being compiled: indeed. guess I wasn't thinking, which seems to be happening lots lately. Moreover it now introduces a warning in mp2 build Subroutine MY::libscan redefined at ./Makefile.PL line 148. ugh. so we need to do the usual ugly workaround for MM :( usual? Can you fix those? I can do it if you don't have the time. well, I don't really have the time, but since it's my problem I'll take care of it. that is, if you can tell me exactly what needs to be done - I would probably just put the if logic inside the sub, but I suspect there needs to be more than that for mod_perl's sake? --Geoff
Re: svn commit: r111386 - /httpd/httpd/trunk/CHANGES /httpd/httpd/trunk/include/httpd.h /httpd/httpd/trunk/modules/http/http_protocol.c
add response code 226 constant (HTTP_IM_USED) and status line (226 IM Used). PR 31128. As I emailed when this patch and issue was originally opened, I thought this patch was unnecessary. I'll pull it out if you want, but I thought it sounded like a decent enough idea and there was at least one other committer who agreed. after garrett pinged us again I didn't see any negative feedback so I went ahead. the whole thread is here. http://marc.theaimsgroup.com/?t=10954409272r=1w=2 looking back, it doesn't seem like you had a strong opinion against it initially, but if you do now that's fine. We don't implement this status code so there is no need for us to be able to have it in our default list. well, isn't that true of a limited number of existing codes, such as (two I picked at random) HTTP_ACCEPTED and HTTP_UNPROCESSABLE_ENTITY? And, it's trivial for a third-party module to return custom status codes. that's fair. If we actually implemented RFC 3229, I would feel differently. well, I guess it depends on whether the goal is to help (for some definition of help) support official HTTP variants (if indeed that's what 3229 is), or just for things we actually take the time to implement fully. anyway, like I said, I'll pull it out if you feel strongly about it, no biggie. having some discussion here is better than the lack thereof there was before :) --Geoff
Re: svn commit: r111386 - /httpd/httpd/trunk/CHANGES /httpd/httpd/trunk/include/httpd.h /httpd/httpd/trunk/modules/http/http_protocol.c
I will veto it. -1. I consider 3229 to be harmful to HTTP and do not wish to support it in the current form. Folks can still implement it with extensions if needed. the change was backed out as r111432 --Geoff
Re: need to require Cwd 2.06 for A-T
Stas Bekman wrote: Stas Bekman wrote: I know we tried to avoid external dependencies, but Cwd coming with 5.6.x is unusable under -T. At the moment this breaks some mp2 tests (the problem comes from A-T, which indirectly invokes Cwd::cwd via File::Spec's rel2abs. I've tried to code a workaround, but it doesn't work and it's a bad idea to get it working since it's very OS specific. (_backtick_pwd is the problem). so we probably have no choice but require Cwd 2.06 if it's only breaking mp2 tests then those tests should probably have plan tests = $n, need_min_module_version(Cwd = 2.06); instead of requiring an external dependency for the entire framework. not that I'm against external dependencies, but we should only require an external dependency when the codebase itself requires it. that is, it is your tests that need a higher Cwd, not Apache-Test proper. --Geoff
Re: svn commit: r109235 - /httpd/test/trunk/perl-framework/Apache-Test/t/redirect.t
-plan tests = 6, need_module('mod_alias.c') need_lwp;
+plan tests = 6, need need_module('mod_alias.c'), need_lwp;
^
?
:)
--Geoff
Re: extending t_cmp to handle !t_cmp?
Am I correct to say that Test::More is in the core for all but 5.6.1 the required minimum by mp2? yes, but see below - we would have further version restrictions if we chose to make T::M the engine for the entire mp2 test suite. so if we make a dependency on Test::More only the 5.6.1 users will have to figure out how to get this module before they can start building modperl? they shouldn't need the dependency to build mod_perl, only to test it :) If we agree to go with the switch to T::M, do we have sufficient functionality with T::M shipped with 5.8.0 for example? i.e. is 5.6.1 the only perl version that we need to require users to do an extra operation or do we require a specific T::M version, in which case many other distros are affected? to use Test::More for server side tests (a la t/response/foo.pm) we need at least version 0.49, which was not even in 5.8.5. client tests can use any version of T::M as far as I know. so really, if you want unlike() (or whatever) you would need to do that on a per-test basis. otherwise you would essentially be preventing a large portion of the userbase from running the test suite as a whole. I'm not entirely convinced this is unacceptable, but I'm sure you are, so I'll give in here :) anyway, in the end I guess I wouldn't suggest moving to T::M entirely just yet. but if you want to use it occasionally within certain tests I think that's fine. I understand that Test::More's behavior is preferrably at run time, yeah, that's the issue for me - t_cmp() prints out too much cruft when everything is just fine. since it prints out the data only when there are problems. But how do you develop a new test if you have no way to force Test::More to print the compared values? I just trust is() - if you develop tests first then it always fails until you get things right :) That's the only reason why I prefer t_cmp() to is(). I can see that. --Geoff
Re: extending t_cmp to handle !t_cmp?
anyway, in the end I guess I wouldn't suggest moving to T::M entirely just yet. but if you want to use it occasionally within certain tests I think that's fine. Of course another alternative is to bundle a sufficient version of T::M under t/. that's an idea. so long as it's not installed with 'make install'. or indexed by cpan either, I suppose. yeah, that's the issue for me - t_cmp() prints out too much cruft when everything is just fine. agreed, and we could certainly change that to match T::M's behavior, *but* I still want to be able to force it to print the verbose output even when everything is fine. yeah, that's a good idea. I prefer to first see the output and then write the comparison test than the other way around. I don't understand why T::M doesn't allow an option to force the verbose output. I dunno the politics here, but it might make for a nice enhancement. I'll look into it. --Geoff
Re: extending t_cmp to handle !t_cmp?
Stas Bekman wrote: Stas Bekman wrote: Of course another alternative is to bundle a sufficient version of T::M under t/. that's an idea. so long as it's not installed with 'make install'. or indexed by cpan either, I suppose. anything living under t/ is not installed on 'make install' and not scanned by PAUSE. The only request is to do that after mp2.0 is out. agreed. no sense in messing with that now. --Geoff
Re: mod_comment
Justin Erenkrantz wrote: --On Monday, November 29, 2004 10:41 AM -0800 Greg Stein [EMAIL PROTECTED] wrote: but we were not allowed to remove features. Removing the fp from the API would have disabled this feature in mod_perl, among others. I can't tell you how often I've been bitten personally by mod_perl trying to reparse our configuration because of this 'feature.' It needs to go away big time. sorry, but I'm not following. can you guys be specific (code wise) about what is supposed to be forbidden? my only knowledge of mod_perl using that file pointer is when implementing Foo containers where we (of course) need to know what is between the opening and closing markers. but in that respect, we are no different from any other module that wants to implement a RAW_ARGS directive... --Geoff
Re: mod_comment
but in that respect, we are no different from any other module that wants to implement a RAW_ARGS directive... Hardly. RAW_ARGS takes a single line of text. No file pointer. That line could come from anywhere. yeah, ok. I _meant_ create your own Foo container, which I guess is the typical (though certainly not only) use for RAW_ARGS :) The container stuff takes a file pointer and reads arbitrary amounts of input from the file. There is no way that the core parser can snarf up the text and pass that block to you [independent of the fp] since the syntax could be arbitrary. right, that's the issue. but what's the alternative to reading directly from the file under the current, file-based design? or are you suggesting that nobody but core should be allowed to create Foo blocks? surely mod_perl's Perl containers can't be the only one out there in the wild? --Geoff
Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php
Cliff Woolley wrote: On Tue, 23 Nov 2004, Joe Orton wrote: Discussion of whether or not it's useful to have PHP tests in httpd-test can take place on test-dev@, please send your comments there and I'll follow up. I actually think it's useful to have php tests in our suite, because having a large number of tests for a module as big as php helps to flush out bugs in httpd (and maybe apr). That would be even more the case if php's sapi module for httpd 2.x that worked as a filter were in a reasonable state... now that TestRunPHP and TestConfigPHP are complete, I was considering moving the existing php tests over to this new framework. the advantage is that each individual test would get an ok marker at a granular level, rather than a simple ok that represented, say, 5 tests together in a lump. how does this sound to everyone? I'd probably get to it sometime over the next two weeks, and I'd post a major diff before going forward. --Geoff
Re: Bug #31228
So, uhh, ping? Any comments other than i'm iffy and is there any reason not to add it? +1 (concept; implementation not verified) here too. is this the most recent patch: http://issues.eu.apache.org/bugzilla/attachment.cgi?id=12746 ? if so, I'll try and review the implementation early next week and, save any objections, commit it to 2.1 if it looks ok to everyone. --Geoff
Re: Whitespace strip filter for httpd v2.1
Graham Leggett wrote: Hi all, I have attached a small filter module that strips leading whitespace from text files. This would typically be used to remove the indenting whitespace found inside HTML files, resulting in a significant reduction in network traffic for some sites. I didn't bother to include trailing whitespace removal, as this involved buffering (leading whitespace removal requires no buffering). Comments? this may be outside the scope of the example code, but filters like this probably ought to consider the ETag header. my personal opinion is that because the content will not be exactly the same bitwise as, say, a file on disk, any ETag header should be made weak to be compliant. I think roy didn't agree, but I never really understood his response last time I brought this up. anyway, if you start considering the ETag header, then you need to consider what happens when default-handler returns 304 and short-circuits your filter entirely. in this case the ETag returned would be the strong ETag created by ap_set_etag, even though the cached response was using a weak ETag. so, you would probably want to create a filter_init hook to weaken any ETag. but that ETag would possibly run in vain if your filter doesn't have any whitespace to change, so... anyway, I'm bringing this up only as something to consider - it's a real life problem for me that I have tried several times to figure out within the current filter architecture but have come up short. so, for a simple filter like this to be fully RFC compliant would be a bit help to others that want to apply filters in more complex settings. fwiw --Geoff
Re: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules
what's the replacement for .cvsignore under svn? I can't see where the data in .cvsignore has migrated to. each directory now has properties and one of those properties is which files to ignore. see http://svnbook.red-bean.com/en/1.0/apas06.html for metadata info in general, http://svnbook.red-bean.com/en/1.0/ch07s02.html for property foo, specifically grep for svn:ignore. for other useful cvs to svn migration stuff http://svnbook.red-bean.com/en/1.0/apa.html is helpful if you haven't already seen it. for me, I've found this entirely unintuitive, since I can't seem to find a way to _add_ files to ignore without first gleaning which are currently ignored from .svn/. that is, since there seems to be no propadd option, I'm left with recreating .cvsignore from .svn/dir-props, adding the new file to ignore, then slurping up .cvsignore svn propset. and I always seem to cause some sort of conflict when I want to set properties on . instead of a directory below it. so, if anyone has any pointers here, that would be great :) --Geoff
Re: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules
The .cvsignore properties were automatically added into the svn:ignore properties by cvs2svn when the repos was converted, so when I removed the .cvsignore files that's all I did, nothing else needed tweaking. Great! so Geoff, that means you can drop the .cvsignore files in the mp2 tree I believe? done. --Geoff
ErrorHeader directive and CHANGES
hi all...
we have the following entries in CHANGES under 2.1-dev:
*) Drop the ErrorHeader directive which turned out to be a misnomer.
Instead there's a new optional flag for the Header directive
('always'), which keeps the former ErrorHeader functionality.
[André Malo]
*) mod_headers: Allow 'echo' also for ErrorHeaders. [André Malo]
*) Bring ErrorHeader concept forward from 1.3, so that response
header fields can be set for return even on errors or external
redirects. [Ken Coar]
ErrorHeader appears to have been removed from the 2.0 branch as of 2.0.51.
I guess it depends on how you view CHANGES, but from my pov I would expect
it to just list tangible changes from, say, 2.0.53 to 2.2. since
ErrorHeader won't exist in 2.0.53 (or whatever the most recent release ends
up being) and won't exist in 2.2 maybe removing these from CHANGES
altogether is warranted?
I'm not sure if there are others like this as well, but if I have the chance
I'll scour CHANGES for a similar pattern.
--Geoff
Re: ErrorHeader directive and CHANGES
In this case, I think, no. It's clearly stated in 2.0, that's a backport from the development branch (since it were different changes to the code base). ok. it still feels a little strange to talk about something that was both (re)added and removed between releases, since the net change is no change for the end user, but I'm cool with it :) In most cases it *was* removed from 2.1 change log. :) --Geoff
Re: [NOTICE] Subversion conversion
Sander Striker wrote: Hi, I'm finally taking care of the conversion of httpd-* to SVN. I'll follow up with instructions on how to pull new workingcopies, etc etc. I'm looking for volunteers to actually write a page for developers on where to get SVN and how to check out the sources from the SVN repository. I thought we had discussed httpd-test a while back - something like we couldn't migrate httpd-test to subversion until modperl-2.0 was also migrated to subversion, since a mp2 checkout includes part httpd-test/perl-framework/Apache-Test. personally, I'd rather use subversion for everything, and I can't recall the specifics of the issue, but I thought I'd bring it up in case it makes sense to somebody :) --Geoff
Re: [NOTICE] Subversion conversion
It's just that someone needs to simultaneously move modperl-2.0 to subversion too. And modperl-docs too, since they are checked out into modperl-2.0 check out. As long as this is all done at once there should be no problem. None of these projects had any branching so it shouldn't be a problem. But I've next to zero experience with subversion, so I'm not volunteering to do that. gozer and I can take care of this while we're here. I was waiting on you to agree with the move before we went forward, though. and it looks like your +1. ok, so we're giving sander and justin the ok to lock down cvs until the svn conversion is complete, which may be a day or two. after that, everyone will need to use svn to access mod_perl cvs (with instructions to follow). so, rock on svn. --Geoff
Re: Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
Seems reasonable to do so. 2.0 was our first threaded release - making a threaded MPM by default (if available) for 2.2 seems fine by me. -- justin agreed :) however, something that I heard recently is that if you specify a threaded MPM on a platform that does not support it, the build process silently switches to prefork (or whatever the default is for the platform, I guess) now, I haven't seen this myself, so I don't want to propagate FUD, but if it's true I might suggest that halting the build process is preferable to switching behind the scenes (or even switching with a little warning) - from a support standpoint, I built apache like this... should tell the truth about the build in question. if I'm off my rocker, well, sorry. I'll buy a round at the hackathon to make up for it :) --Geoff
time for Apache-Test 1.16
hi all... with the php hooks pretty much solidified, I would like to release A-T 1.16 before apachecon so that the presentation there is associated with an official release version. I plan on rolling a release candidate early next week, so if there is some work that you want to get into this release, now is the time :) --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm
If I had to guess, this borks anything but gmake. Test for that. I had asked on #asf about this and somebody (I forget who) said that the make manpage on minortaur (some bsd variant) supports ?= as well. from looking at that it seems to be the manpage for pmake, which I guess is some other make variant. so limiting it to gmake at least would seem to wipe out bsd folks. a little digging on my own at the time made it seem like solaris make is really gmake, so between linux, solaris, and bsd a decent case was being made that most unix make variants to support the syntax. of course, that list of 3 was hardly exhaustive :) anyway, this just isn't my area, so I'm happy to defer to others that grok all this SA-type stuff. but if most unix-variants support ?=, or if there is another more universal way to work around the issue, I would hate to see the correct behavior only for unix people using gmake. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm
a little digging on my own at the time made it seem like solaris make is really gmake Well, the way you have it installed perhaps. But attempting this against /usr/ccs/bin/make it most definately blows up. ok. I actually don't have a solaris box to try on - I just went to sun's support site and saw that the manpage for make was gmake (at least the one that google first pointed me toward :) , so between linux, solaris, and bsd a decent case was being made that most unix make variants to support the syntax. of course, that list of 3 was hardly exhaustive :) Hardly. The man page for hpux 11 make makes no mention of ?= nor does AIX 5.1. you are 2 for 5. yeah, not good. Explicitly fails on native make(s) on AIX 5.1, HPUX 11, Solaris 2.6. Please find another solution. well, the solution at the moment is to not have a solution - cvs has been reverted, so unless a real solution can be found it will remain a minor nit. p.s. simple test I used... TERM ?= uberterm all: echo $(TERM) the gmake manual suggests that ?= is equivalent to ifeq ($(origin TEST_VERBOSE), undefined) TEST_VERBOSE = 0 endif so that might make for a good test - the gmake manual didn't speficially say that origin was explicit to it, but then again it didn't mention ?= either :) --Geoff
Re: cvs commit: httpd-2.0/modules/mappers mod_rewrite.c
(though with proxy issues on HEAD mod_rewrite [P] stuff is still completely broken). yeah. if I have the time I'll try to track down exactly the revision that caused this failure so it can also be added to showstoppers, if merely so somebody takes the time to explicitly address it. not sure if I'll be able to get to it before apachecon, though... --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
@
if (my $custom_config_path = custom_config_path()) {
debug loading custom config data from: '$custom_config_path';
$custom_config_loaded++;
+($candidate) = $candidate=~/^(.*)/; # launder for -T
require $custom_config_path;
huh?
something is definitely wrong here - there is no $candidate in the scope of
the current function, so this actually fails with errors.
$ perl Makefile.PL -apxs /apache/2.0/prefork/perl-5.8.5/bin/apxs
Global symbol $candidate requires explicit package name at
lib/Apache/TestConfig.pm line 2080.
--Geoff
