Re: [PATCH] flood and content-type setting
On Sun, Mar 14, 2004 at 05:27:16PM -0800, Aaron Bannert wrote: This sounds reasonable to me, did it ever get committed? I imagine you asked the flood developers but I just did a cvs diff and this patch was not committed. Philippe
Re: testing apache 1.3 on windows
Geoffrey Young wrote:
it all boils down to TestConfigParse::httpd_version()
glad to know it's somewhat identified.
that (or similar foo) will happen when you try to test first against 2.0 and
then against 1.3, regardless of win32 vs unix. at least that's been my
experience.
try first removing $HOME/.apache-test and see if that helps. if so, just
introduced into cvs yesterday was $ENV{APACHE_TEST_NO_STICKY_PREFERENCES}
which, if true, attempts to suppress any and all influence from prior runs.
well, no. there is no .apache-test file anywhere on my windows system.
i did a set APACHE_TEST_NO_STICKY_PREFERENCES=1. i even completely
removed and re-checked out the httpd-test module. but
perl Makefile.PL -apxs K:\Coar\Apache\Server-1.3\bin\apxs.pl
succeeds, as does the nmake following, but
perl t\TEST -config
explodes with the attempt to treat the 1.3 apxs.pl as 2.0, complete
with the same -D APACHE2.
no joy yet..
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
Millennium hand and shrimp!
Re: testing apache 1.3 on windows
On Mon, Mar 15, 2004 at 09:04:32AM -0500, Rodent of Unusual Size wrote: explodes with the attempt to treat the 1.3 apxs.pl as 2.0, complete with the same -D APACHE2. Ken, I had a slightly different variation of sticky preferences problems over the weekend. I found preferences stored in the following two locations: path to your A::T libs\Apache\TestConfigData.pm t\conf\apache_test_config.pm Do you see the preferences set in either of these locations? I too never saw a .apache-test file in my home directory in Windows (XP). HTH, William -- Knowmad Services Inc. http://www.knowmad.com
Re: testing apache 1.3 on windows
also, there apparently is no longer an apxs.pl for 2.0 windows -- so what's the magic Makefile.PL argument to let the test modules be built? in case there was any question, i hate development on windows, i hate libtool, and i think i've discovered a special subtype of 'male pattern baldness' -- call it 'hacker pattern baldness,' comes from pulling your hair out. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: testing apache 1.3 on windows
On Mon, 15 Mar 2004, Rodent of Unusual Size wrote: also, there apparently is no longer an apxs.pl for 2.0 windows -- so what's the magic Makefile.PL argument to let the test modules be built? There is an alpha port of apxs for Win32 for Apache/2.0; grab the script http://perl.apache.org/dist/win32-bin/install_apxs and run it, which will fetch, configure, and install it on your system. in case there was any question, i hate development on windows, i hate libtool, and i think i've discovered a special subtype of 'male pattern baldness' -- call it 'hacker pattern baldness,' comes from pulling your hair out. :) -- best regards, randy kobes
Re: Errors testing under Win32
William McKee wrote: I'm running into a problem when doing testing under Win32 that doesn't happen when testing in Linux or when I run my program in Win32 with Apache2 and modperl (Randy's binary). The error is as follows: [Sun Mar 14 18:02:02 2004] [error] [client 127.0.0.1] Can't locate object method send_cgi_header via package Apache::RequestRec at (eval 93) line 62. have you loaded Apache::Response? I can't find much information at all in the archives or on the web. It doesn't make sense to me why my scripts would work under Apache but not when called with Apache::Test. Any ideas? Any suggestions for tracking this down? I really don't know where to start. Probably because your startup/config setups are different. You loaded 'Apache::Response' in your normal setup, but not in your A-t setup. You should load this and any other required modules from the code that uses it, not at the server startup. (you load at the server startup to speed things up, not as a substitute to the loading from the handler's module). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
William McKee wrote: On Fri, Mar 12, 2004 at 11:17:50PM -0500, William McKee wrote: Just FYI, after moving the libperl.* out of /usr/lib and rebuilding Apache/mp, I'm still having problems with the TestRun.pm module. I'll try building Perl with O2 next. Rebuilt Perl and mod_perl with -O2. But I'm still getting the same Statement unlikely to be reached error message around line 636. I'm going to have to chalk it up to environmental problems for now and move on. Perhaps when I rebuild my Perl setup here, I can do further testing. Thanks for trying all these, William. Now please give us something we can reproduce the problem with. i.e. a tar with a complete setup (and as little code as possible) and we will look at it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
William McKee wrote: On Fri, Mar 12, 2004 at 10:35:08PM -0500, William McKee wrote: Yeah, that's certainly a concern. I'd like to figure out my misconfiguration issue above then will attempt your proposal to nuke all these old installations and start fresh. Well, I'm now seeing this Statement unlikely to be reached error under Windows with a fresh ActivePerl 5.8.3 installation. This is starting to make me think that it has something to do with the way that I'm invoking Apache::Test. This time I'm getting the following additional message before the unlikely to be reached error: [error] failed to resolve handler 'Web::web' My test is t/response/Web/web.pm. I went back to be sure that I hadn't overlooked other errors on my Linux server and found the following message appearing *after* the unlikely to be reached error: [error] Undefined subroutine Web::web::handler called. The handler is there and the test works fine if the die statement in TestRun.pm is commented out. Still doesn't make any sense to me but maybe this addt'l info helps. I'll see about putting together a test case for others to try. Neither to me. Are you sure you get the Statement unlikely to be reached error from the same place? It happens long before the server has started, and failed to resolve handler is an error from the run-time or a server startup. Again, giving us a tar to play with should be helpful. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: testing apache 1.3 on windows
On Mon, 15 Mar 2004, William A. Rowe, Jr. wrote: At 02:51 PM 3/15/2004, you wrote: On Mon, 15 Mar 2004, Rodent of Unusual Size wrote: also, there apparently is no longer an apxs.pl for 2.0 windows -- so what's the magic Makefile.PL argument to let the test modules be built? There is an alpha port of apxs for Win32 for Apache/2.0; grab the script http://perl.apache.org/dist/win32-bin/install_apxs and run it, which will fetch, configure, and install it on your system. Randy ... ready to make a go of integrating into httpd-2.0 build? Bill Sure, Bill - I'd be happy to ... Right now it seems to work OK for external modules (although some cleanup is warranted), but it would need work to be useable within httpd-2.0 itself. -- best regards, randy
Re: Errors testing under Win32
William McKee wrote: On Mon, Mar 15, 2004 at 01:22:20PM -0800, Stas Bekman wrote: have you loaded Apache::Response? No, I wasn't aware that I needed to specify this module. Probably because your startup/config setups are different. You loaded 'Apache::Response' in your normal setup, but not in your A-t setup. Actually, there is no 'PerlModule Apache::Response' directive in my normal setup and I'm not loading an external startup.pl file. Yes, but it could have been loaded indirectly by some module, e.g. CGI.pm or Apache::compat, that you have loaded from httpd.conf. You should load this and any other required modules from the code that uses it, not at the server startup. (you load at the server startup to speed things up, not as a substitute to the loading from the handler's module). OK, I tried adding the PerlModule Apache::Response line to my extra.conf.in file and doing my tests. They ran fine minus a few OS-specific errors. Of course this result begs the question, why do these tests work for testing and production without use'ing 'Apache::Response' in Linux/mp1 (I checked both httpd.conf and startup.pl; neither refer to A::Response) as well as in production in Win32/mp2 (i.e., running apache as usual; even works in single server mode) but fail when tested via A::T? see above. BTW, I tried to find documentation for Apache::Response on CPAN but there's no reference to it. Didn't find anything in the Eagle book or in _mod_perl Developer's Cookbook_. The description at perl.apache.org is To be completed. It was added in mod_perl 2, you won't find it in mentioned in these books. But please read: http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded http://perl.apache.org/docs/2.0/api/index.html is being slowly improved, but it will take a long time till it will get completed unless more people will contribute, since we have just a few hands. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
