Re: [MP2] Apache::Reload date bug
Ron Savage wrote: On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote: perl -le 'warn(foo\n)' You got the quotes wrong for MS Windows, so I ran it twice: C:\Backupperl -le warn(qq|foo\n|) foo C:\Backupperl -le 'warn(foo\n)' well, you've got the idea, right. Perhaps someone on win32 can try to debug the behavior that you saw. I can't reproduce it on my linux box. __ 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: Building mod-perl 2 for cygwin
Steve Baldwin wrote: OK, I've rebuilt my perl using the following options ... ./Configure -de -Duse64bitint -Doptimize=-O2 -Dman3ext=3pm (to try to keep as similar as possible to packaged perl, but without the threads stuff). I also tried with simply ./Configure -des With exactly the same result. and if you build with -Dusethreads? Now, make (of mod-perl) gives the following errors ... modperl_env.lo(.text+0x89e):modperl_env.c: variable '_PL_vtbl_env' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. : Creating library file: libmod_perl.dll.a mod_perl.lo(.text+0x2f9):mod_perl.c: undefined reference to `_apr_pool_cleanup_null' mod_perl.lo(.text+0x2fe):mod_perl.c: undefined reference to `_apr_pool_cleanup_register' mod_perl.lo(.text+0x4e9):mod_perl.c: undefined reference to `_ap_log_error' mod_perl.lo(.text+0x52b):mod_perl.c: undefined reference to `_ap_mpm_query' : modperl_directives.lo(.text+0x4e7):modperl_directives.c: more undefined references to `_apr_pstrcat' follow collect2: ld returned 1 exit status perlld: *** system() failed to execute gcc -shared -o cygperl5_8_0.dll -Wl,--out-implib=libmod_perl.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \ -L/usr/local/lib mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo modperl_module.lo modperl_svptr_table.lo modperl_const.lo modperl_constants.lo modperl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo -L/usr/local/lib /usr/local/lib/perl5/5.8.0/cygwin/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/5.8.0/cygwin/CORE -lperl -lcrypt -lutil make[1]: *** [mod_perl.so] Error 1 make[1]: Leaving directory `/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl' make: *** [modperl_lib] Error 2 Here's my new output from perl -V ... [mod_perl-1.99_08]$ perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=cygwin, osvers=1.3.19(0.7132), archname=cygwin uname='cygwin_nt-5.1 au-stb-mobile 1.3.19(0.7132) 2003-01-23 21:31 i686 unkn own unknown cygwin ' config_args='-de -Duse64bitint -Doptimize=-O2 -Dman3ext=3pm' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=unde f useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing', optimize='-O2', cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing' ccversion='', gccversion='3.2 20020927 (prerelease)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize =4 alignbytes=8, prototype=define Linker and Libraries: ld='ld2', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /usr/lib /lib libs=-lgdbm -ldb -lcrypt -lutil perllibs=-lcrypt -lutil libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under cygwin Compiled at Feb 18 2003 20:15:28 %ENV: CYGWIN= @INC: /cygdrive/d/perldev /usr/local/lib/perl5/5.8.0/cygwin /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/cygwin /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl . -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, 17 February 2003 8:58 PM To: Steve Baldwin Cc: [EMAIL PROTECTED] Subject: Re: Building mod-perl 2 for cygwin Steve Baldwin wrote: Thanks very much for your reply Stas. Pardon my ignorance, but are you saying I need to rebuild Perl with different options. Unfortunately (at least for a time being) yes. The version of Perl I'm using is the packaged one I installed with the cygwin install utility. If this is the case, could you please a little more information as to the arguments you recommend to build a version of Perl that works fine 'standalone', as well as embedded (which I presume is the case with mod-perl) if that is possible. Currently mod_perl 2.0 supports the multiple Perl interpreters only if perl has been built with -Dusethreads. This may change
Re: help with Apache::DB
giorgos zervas wrote: hi all, i am using Apache::DB to debug my mod_perl handlers and altough the debugger seems to be working fine it won't display the source code next to the current line being debugged. for example: DB10 r scalar context return from CODE(0x8d7101c): - undef Apache::DB::CODE(0x8d7101c)(/usr/local/lib/perl/5.6.1/Apache/DB.pm:35): 35: next to the line starting with 35: the 35th line of source code should be displayed. however this doesn't happen either with my modules or the ones from CPAN. i even thought it might me a font problem and tried to use different terminals and font combinations but none of them worked for me. has anyone else encountered a similar problem? I haven't seen such a thing, but do you see a similar problem if you debug from the command line (certainly something similar but that doesn't require mod_perl). http://perl.apache.org/docs/1.0/guide/debug.html#Introduction_to_the_Perl_Debugger __ 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: [mp2] $r-server-server_hostname() compatibility?
Nick Tonkin wrote:
On Wed, 19 Feb 2003, Stas Bekman wrote:
Nick Tonkin wrote:
Does anyone know the equivalent directive for
$r-server()-server_hostname()
it's right there:
use Apache::Server;
$r-server-server_name;
oops, a typo, should be: $r-server-server_hostname
Well, it doesn't work as advertised, I think.
package NPT::MyTest;
use strict;
use warnings;
use Apache::RequestRec;
use Apache::RequestUtil;
use Apache::Server;
sub handler {
my $r = shift;
warn $r-server-server_name;
return 200;
}
1;
~
[Tue Feb 18 15:08:58 2003] [error] [client 192.168.0.33] Can't locate
object method server_name via package Apache::Server at
/home/nick/perl/NPT/MyTest.pm line 14.
- nick
--
__
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: [mp2] send_http_header() can't be called before the responsephase
Nick Tonkin wrote:
Hey,
I have a handler that is called like this:
Location /authenticate
sethandler perl-script
PerlHandler WM::Auth::Auth
/Location
the handler returns like this:
return logon_form($r);
logon_form starts like this:
sub logon_form {
my $r = shift;
$r-status(Apache::OK);
$r-content_type('text/html');
$r-send_http_header;
[...]
This throws the error:
send_http_header() can't be called before the response phase
I've posted a tentative solution to the dev list.
__
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: Program received signal SIGBUS, Bus error. 0x80b2953 in ap_unescape_url()
Richard Clarke wrote: I'm using FreeBSD 4.7 Release. perl 5.6.1 Mod_Perl/Apache Latest libapreq 1.1. Doesn't seem like an apreq problem. It happens in the modperl function. Any chance you can rebuild mod_perl with debug mode enabled (PERL_DEBUG=1), so we can see the arguments and file/linenumbers? See: http://perl.apache.org/docs/1.0/guide/debug.html#PERL_DEBUG_1_Build_Option Program received signal SIGBUS, Bus error. 0x80b2953 in ap_unescape_url () (gdb) bt #0 0x80b2953 in ap_unescape_url () #1 0x8084094 in XS_Apache_unescape_url () #2 0x8102623 in Perl_pp_entersub () #3 0x80fcf4e in Perl_runops_standard () #4 0x80c0266 in perl_call_sv () #5 0x80c004a in perl_call_sv () #6 0x807c6ba in perl_call_handler () #7 0x807bfc0 in perl_run_stacked_handlers () #8 0x807b083 in perl_translate () #9 0x8098863 in ap_cleanup_method_ptrs () #10 0x80988ca in ap_translate_name () #11 0x80adf00 in ap_some_auth_required () #12 0x80ae47e in ap_process_request () #13 0x80a4db7 in ap_child_terminate () #14 0x80a4f79 in ap_child_terminate () #15 0x80a50f2 in ap_child_terminate () #16 0x80a5724 in ap_child_terminate () #17 0x80a5f84 in main () #18 0x8061f4d in _start () (gdb) quit I'm performing unescape_uri() in a PerlTransHandler. This works perfectly well on my Linux libapreq 1.0 box, so I'll try 1.0 instead. I remember there was some discussion about 1.1 segv's when it was announced but a quick search told me these were aimed at either 5.8 or file uploads. Anyone got any suggestions whilst I go try libapreq 1.0 Richard. -- __ 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: [MP2] Apache::Reload date bug
Randy Kobes wrote: On Wed, 19 Feb 2003, Stas Bekman wrote: Ron Savage wrote: On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote: perl -le 'warn(foo\n)' You got the quotes wrong for MS Windows, so I ran it twice: C:\Backupperl -le warn(qq|foo\n|) foo C:\Backupperl -le 'warn(foo\n)' well, you've got the idea, right. Perhaps someone on win32 can try to debug the behavior that you saw. I can't reproduce it on my linux box. With my ActivePerl 8xx compatible perl-5.8, sticking in a warn(foo\n); inside a simple handler that uses Apache::Reload just output foo in the error log, with no timestamp nor client reported, as expected. I'm wondering though if this is coming from one of the custom modules used - in the log === [Sun Feb 16 23:49:41 2003] -e: Apache::Reload: Can't locate C:/Perl/site/lib//CGI/Explorer.pm === the message from Apache::Reload: warn(Apache::Reload: Can't locate $file\n), next unless defined $mtime amd $mtime; has a '-e:' in front, suggesting perhaps that another module is contributing to this entry. Can you make up a stripped-down version that exhibits this behaviour? I thought of that too, but wasn't sure if this is something special to win32. Could it be that the logs get interleaved? __ 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: Program received signal SIGBUS, Bus error. 0x80b2953 in ap_unescape_url()
Richard Clarke wrote: Stas, Doesn't seem like an apreq problem. It happens in the modperl function. Any chance you can rebuild mod_perl with debug mode enabled (PERL_DEBUG=1), so we can see the arguments and file/linenumbers? See: http://perl.apache.org/docs/1.0/guide/debug.html#PERL_DEBUG_1_Build_Option Program received signal SIGBUS, Bus error. 0x80b445b in ap_unescape_url (url=0x8162e89 ) at util.c:1609 1609url[x] = '\0'; (gdb) bt #0 0x80b445b in ap_unescape_url (url=0x8162e89 ) at util.c:1609 #1 0x8085c20 in XS_Apache_unescape_url (cv=0x8227b0c) at Apache.c:931 much better ;) [...] Its worth noting that the same function runs fine in a contenthandler, just not in the transhandler. Since you don't show what the real code that fails, I can only offer to plug the hole in ap_unescape_url on the mod_perl side. I'll report the bug to the httpd-dev list. Index: src/modules/perl/Apache.xs === RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v retrieving revision 1.125 diff -u -r1.125 Apache.xs --- src/modules/perl/Apache.xs 6 Jul 2001 20:33:35 - 1.125 +++ src/modules/perl/Apache.xs 19 Feb 2003 05:04:04 - @@ -659,7 +659,9 @@ char *string CODE: -unescape_url(string); +/* ap_unescape_url segfaults when is passed */ +if (string string[0] != '\0') +unescape_url(string); RETVAL = string; OUTPUT: __ 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
cvs commit: modperl Changes
stas2003/02/18 18:38:22
Modified:src/modules/perl perl_config.c
.Changes
Log:
Make sure to start perl, if it's not running, before processing Perl*
directives, with threaded perl and PERL_STACKED_HANDLERS=0
Revision ChangesPath
1.115 +9 -5 modperl/src/modules/perl/perl_config.c
Index: perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.114
retrieving revision 1.115
diff -u -r1.114 -r1.115
--- perl_config.c 24 Mar 2002 22:51:04 - 1.114
+++ perl_config.c 19 Feb 2003 02:38:21 - 1.115
@@ -437,6 +437,13 @@
}
#endif
+#define STARTUP_PERL_IF_NOT_RUNNING \
+if(!PERL_RUNNING()) { \
+perl_startup(parms-server, parms-pool); \
+require_Apache(parms-server); \
+MP_TRACE_g(fprintf(stderr, mod_perl: calling perl_startup()\n)); \
+}
+
#ifdef PERL_STACKED_HANDLERS
CHAR_P perl_cmd_push_handlers(char *hook, PERL_CMD_TYPE **cmd, char *arg, pool *p)
@@ -456,16 +463,13 @@
}
#define PERL_CMD_PUSH_HANDLERS(hook, cmd) \
-if(!PERL_RUNNING()) { \
-perl_startup(parms-server, parms-pool); \
-require_Apache(parms-server); \
-MP_TRACE_g(fprintf(stderr, mod_perl: calling perl_startup()\n)); \
-} \
+STARTUP_PERL_IF_NOT_RUNNING \
return perl_cmd_push_handlers(hook,cmd,arg,parms-pool)
#else
#define PERL_CMD_PUSH_HANDLERS(hook, cmd) \
+STARTUP_PERL_IF_NOT_RUNNING \
mp_preload_module(arg); \
cmd = arg; \
return NULL
1.661 +6 -2 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.660
retrieving revision 1.661
diff -u -r1.660 -r1.661
--- Changes 28 Jan 2003 00:30:22 - 1.660
+++ Changes 19 Feb 2003 02:38:21 - 1.661
@@ -10,6 +10,10 @@
=item 1.27_01-dev
+Make sure to start perl, if it's not running, before processing Perl*
+directives, with threaded perl and PERL_STACKED_HANDLERS=0 [Stas
+Bekman]
+
Add Apache::Module to Bundle::Apache [Stas Bekman]
use $Config{'installstyle'} instead of hardcoded 'lib', to handle
@@ -19,8 +23,8 @@
prevent segfaults in mod_perl_mark_where() when a sub can't get
resolved [Gerald Richter [EMAIL PROTECTED]]
-Need to load B::Terse/TerseSize if it wasn't loaded yet in that child
-before using it. [Dan Sully [EMAIL PROTECTED]]
+Apache::Status: Need to load B::Terse/TerseSize if it wasn't loaded
+yet in that child before using it. [Dan Sully [EMAIL PROTECTED]]
document the server_root_relative() method [Stas Bekman [EMAIL PROTECTED]]
cvs commit: modperl-2.0/xs/maps modperl_functions.map
stas2003/02/17 01:03:17
Modified:.Changes
lib/Apache compat.pm
src/modules/perl modperl_callback.c modperl_callback.h
modperl_handler.c
t/htdocs .cvsignore
t/modperl .cvsignore
t/response/TestCompat apache.pm
todo api.txt
xs/ModPerl/Util ModPerl__Util.h
xs/maps modperl_functions.map
Added: t/response/TestModperl current_callback.pm
Log:
- implement Apache::current_callback
- $r-current_callback goes into Apache::compat, since now we have a way
too many callbacks unrelated to $r
- add some tests
Revision ChangesPath
1.125 +4 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.124
retrieving revision 1.125
diff -u -r1.124 -r1.125
--- Changes 12 Feb 2003 23:42:23 - 1.124
+++ Changes 17 Feb 2003 09:03:16 - 1.125
@@ -10,6 +10,10 @@
=item 1.99_09-dev
+implement Apache::current_callback + $r-current_callback goes into
+Apache::compat, since now we have a way too many callbacks unrelated
+to $r [Stas]
+
Add Apache::compat methods: $r-connection-auth_type and
$r-connection-user (requires 'PerlOptions +GlobalRequest') + tests
[Stas]
1.78 +4 -0 modperl-2.0/lib/Apache/compat.pm
Index: compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- compat.pm 12 Feb 2003 23:42:23 - 1.77
+++ compat.pm 17 Feb 2003 09:03:16 - 1.78
@@ -125,6 +125,10 @@
die $err if $err;
}
+sub current_callback {
+return Apache::current_callback();
+}
+
package Apache::Constants;
use Apache::Const ();
1.54 +2 -0 modperl-2.0/src/modules/perl/modperl_callback.c
Index: modperl_callback.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_callback.c,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- modperl_callback.c29 Jan 2003 01:04:33 - 1.53
+++ modperl_callback.c17 Feb 2003 09:03:16 - 1.54
@@ -172,6 +172,8 @@
break;
};
+modperl_callback_current_callback_set(desc);
+
/* XXX: deal with {push,set}_handler of the phase we're currently in */
/* for now avoid the segfault by not letting av-nelts grow if
* somebody push_handlers to the phase we are currently in, but
1.22 +9 -0 modperl-2.0/src/modules/perl/modperl_callback.h
Index: modperl_callback.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_callback.h,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- modperl_callback.h21 Feb 2002 01:45:34 - 1.21
+++ modperl_callback.h17 Feb 2003 09:03:16 - 1.22
@@ -10,6 +10,15 @@
#define ap_hook_fixup ap_hook_fixups
#define ap_hook_logap_hook_log_transaction
+#define modperl_callback_current_callback_sv \
+get_sv(Apache::__CurrentCallback, TRUE)
+
+#define modperl_callback_current_callback_set(desc) \
+sv_setpv(modperl_callback_current_callback_sv, desc)
+
+#define modperl_callback_current_callback_get() \
+SvPVX(modperl_callback_current_callback_sv)
+
int modperl_callback(pTHX_ modperl_handler_t *handler, apr_pool_t *p,
request_rec *r, server_rec *s, AV *args);
1.16 +1 -1 modperl-2.0/src/modules/perl/modperl_handler.c
Index: modperl_handler.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_handler.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- modperl_handler.c 1 Jan 2003 03:45:54 - 1.15
+++ modperl_handler.c 17 Feb 2003 09:03:16 - 1.16
@@ -175,7 +175,7 @@
}
#define set_desc(dtype) \
-MP_TRACE_a_do(if (desc) *desc = modperl_handler_desc_##dtype(idx))
+if (desc) *desc = modperl_handler_desc_##dtype(idx)
#define check_modify(dtype) \
if ((action MP_HANDLER_ACTION_GET) rcfg) { \
1.2 +1 -0 modperl-2.0/t/htdocs/.cvsignore
Index: .cvsignore
===
RCS file: /home/cvs/modperl-2.0/t/htdocs/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- .cvsignore26 Feb 2002 19:09:10 - 1.1
+++ .cvsignore17
cvs commit: modperl-2.0/xs/maps apache_functions.map
stas2003/02/17 01:49:05 Modified:xs/maps apache_functions.map Log: by removing previous section (with functions that have moved elsewhere), the 'guess' functionality went broken. Correct by adding an explicit MODULE declaration. Revision ChangesPath 1.62 +1 -1 modperl-2.0/xs/maps/apache_functions.map Index: apache_functions.map === RCS file: /home/cvs/modperl-2.0/xs/maps/apache_functions.map,v retrieving revision 1.61 retrieving revision 1.62 diff -u -r1.61 -r1.62 --- apache_functions.map 24 Jan 2003 07:39:29 - 1.61 +++ apache_functions.map 17 Feb 2003 09:49:05 - 1.62 @@ -211,7 +211,7 @@ ap_walk_config ap_process_config_tree -PACKAGE=guess +MODULE=Apache::Filter PACKAGE=guess ~ap_add_output_filter ~ap_add_input_filter -ap_add_input_filter_handle
mp2 heads up with Apache::Reload
For those who started working with mp2 and found themselves unable to use Apache::Reload for connection filters and protocol handlers, I'm happy to tell you that the cvs version now supports Apache::Reload in the PerlPreConnectionHandler phase, which happens as early as possible. The updated docs are here: http://perl.apache.org/docs/2.0/api/Apache/Reload.html Let us know if you experience any problems with it. And make sure to read: http://perl.apache.org/docs/2.0/user/handlers/protocols.html#PerlPreConnectionHandler for potential nuances... __ 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: Building mod-perl 2 for cygwin
Steve Baldwin wrote: Thanks very much for your reply Stas. Pardon my ignorance, but are you saying I need to rebuild Perl with different options. Unfortunately (at least for a time being) yes. The version of Perl I'm using is the packaged one I installed with the cygwin install utility. If this is the case, could you please a little more information as to the arguments you recommend to build a version of Perl that works fine 'standalone', as well as embedded (which I presume is the case with mod-perl) if that is possible. Currently mod_perl 2.0 supports the multiple Perl interpreters only if perl has been built with -Dusethreads. This may change in the future, or may be not. For now please build with: ./Configure -des -Dusethreads [...] or (assuming that perl automatically turns on this option, which I doubt): ./Configure -des -Uusemultiplicity [...] I think if you build by yourself, all you need is: ./Configure -des (-des picks all the defaults) what's important is that when your perl has been built, it should either have: usethreads=define useithreads=define usemultiplicity=define or usethreads=undef useithreads=undef usemultiplicity=undef in the output of: % perl -V | grep usethreads -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, 17 February 2003 4:03 PM Cc: Steve Baldwin; [EMAIL PROTECTED] Subject: Re: Building mod-perl 2 for cygwin We can take two approaches, patch all the places in the code where perl context is set explicitly to use #ifdef MULTIPLICITY, rather than #ifdef USE_THREADS. Or we can refuse to build mod_perl if MULTIPLICITY is enabled without the threads. Of course the first solution is more favorable for users. I've played a bit with various options and it seems that it's going to be a big trouble to support MULTIPLICITY without USE_THREADS. My suggestion for now is to either rebuild with -Uusemultiplicity or -Dusethreads (less preferred if you don't need threads, but need speed). README.cygwin says: =item * C-Dusemultiplicity Multiplicity is required when embedding Perl in a C program and using more than one interpreter instance. This works with the Cygwin port. Though I can't see that this is a required option. __ 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 -- __ 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: How to find out if mod_perl is running
Gazi, Nasser (London) wrote: I have a very simple question (please excuse me if it is too simple). I need to find out if of one of my Linux servers is running mod_perl, and if so, which version it is running. Any suggestions as to how I can do this? Use the guide: http://perl.apache.org/docs/1.0/guide/install.html#How_can_I_tell_whether_mod_perl_is_running_ __ 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: is moderator/admin available?
George Valpak wrote: Hey, is there a moderator available that can get the list admin to stop the madness of endless repeats? I'm not a moderator, but if you post to [EMAIL PROTECTED], you will receive the information you are looking for. __ 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: Apache::DBI and mod_perl 2
[EMAIL PROTECTED] wrote: Any plans to make Apache::FakeRequest work well enough to make this possible? There are plans. Here is an entry from modperl-2.0/todo/api.txt: Apache::FakeRequest: since APR can be used outside of httpd, and we can alloc request_rec and similar structures, it should be possible to bootstrap an inside-httpd interface and outside-httpd interface. its not really worthwhile looking at until APR actually installs its *.so or *.a libraries somewhere apxs can find them. and, there's a bunch of util functions (e.g. URI stuff) that is supposed to move from httpd into apr-util. As for mod_perl 1.0, I'm not sure, but if you can make it useful that would be cool. __ 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: Semi-complicated question: modifying the content of a requestbefore passing to CGI?
Seldo wrote: Okay, so here's what I need to do: 1. Receive a request to a given URI, X 2. Based on that URI, change certain values with the request (e.g. change the names or values of variables posted by the user, modify the x-www-form-urlencoded data, whatever...) 3. Translate the URI to a new URI (one of a number of CGI programs) 4. Execute that CGI (such that the CGI runs in an environment with variables and posted data modified as per step 2 ) I'm running mod_perl 2.0 with Apache 2.0.x, and the documentation of these sorts of features: http://perl.apache.org/docs/2.0/api/Apache/RequestUtil.html ...is sort of incomplete. Whoopsie. We have very few hands, so coding is of a higher priority. Most of the API docs from 1.0 apply to 2.0. Almost all differrences are documented here: http://perl.apache.org/docs/2.0/user/compat/compat.html If something is missing, please post patches. Help with 2.0 docs is very welcome. My fault for being all bleeding-edge, right? Here's what I've got so far: 1. Can do. I can write a PerlTransHandler that catches the URI 2. Don't know how to do. The 1.0 documentation mentions the header_in() method which can apparently set headers in the request as well as get them. I can't find this method in the 2.0 documentation, does it or an equivalent exist? http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_header_in_ And is there anything similar for the PUT/POST type data? what do you mean? check the above URL. 3. Can do. This bit is no problem. 4. Don't know how to do. How do you tell the server to execute a file using CGI protocol? Is this even possible? You don't need to do anything. Just configure your mod_cgi as usual, and once you've changed $r-filename to point to the location of cgi, Apache will take care of it. (I assume that you want the cgis to be run by mod_cgi, not mod_perl) The above method, assuming it's possible to do the two things I asked about, will work fine. If it doesn't work, then I'll be forced to make my PerlTransHandler re-implement CGI, which isn't *that* hard but sounds like a fairly stupid idea when the server does it already. But even in the case, I need to know how to set environment variables for CGI on a per-execution basis. Any help greatly appreciated, this project is now due in a week and I'm beginning to feel great big stormclouds of doom closing in :-) Your task is pretty trivial, so you should be fine. Seldo. P.S. I only recently noticed that Stas, who helped me out with my last question, is listed as the author/maintainer of the 2.0 documentation. Cool! :-) Hopefully this will change asap and other people will take over varous documents. __ 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: problem with mod_perl1.27 perl5.8/apa1.3.27
Dmitri Dmitrienko wrote: Hello, I got following problem when compiled mod_perl 1.27 for Apache 1.3.27 and perl 5.8 for Win32 platform: Constants.xs(158) : error C2065: 'errno' : undeclared identifier after few hours of jumping around compiler I realized that #include errno.h should be commented out in perl.h. Then everything became good. Please tell me is anybody experienced anything like I did ? Is there any official workaround ? BTW, everything was ok with perl 5.6.0... What's 'perl -V' for you? 5.8.0 (as shown in the topic) not 'perl -v', but 'perl -V'. Posters can save a lot of their and our time by following these guidelines when asking for help: 1.0 - related: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems 2.0 - related: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems Both linked from the 'shortcuts' menu! __ 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: modperl segfault with threaded Perl 5.8
Pavel Hlavnicka wrote:
Ok, here is a complete backtrace (after a nice couple of hours observing
the compilation progress... :)
Can you please share the details of what you have changed, that allowed you to
get the args and line numbers/file names? Why didn't you have them in the
original report (I want this to be documented).
#0 0x4003e32d in Perl_gv_fetchpv (my_perl=0x0,
nambeg=0x80c68a7 Apache::Server::AutoPreLoad, add=0, sv_type=4)
at gv.c:646
#1 0x4003726b in Perl_get_sv (my_perl=0x0,
name=0x80c68a7 Apache::Server::AutoPreLoad, create=0) at perl.c:1712
#2 0x08058c40 in mp_preload_module (name=0xbfff93e8) at perl_config.c:428
The key here is my_perl=0x0, an attempt to call into perl was made
before it was started. Since you didn't provide the details requested
at:
http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
(in particular build arguments) I'm doing a wild guesswork, assuming
that you have built without PERL_STACKED_HANDLERS=1 (or
EVERYTHING=1). So if my guess was correct, does the following patch
fixes the problem with the threaded perl?
Index: src/modules/perl/perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.114
diff -u -r1.114 perl_config.c
--- src/modules/perl/perl_config.c 24 Mar 2002 22:51:04 - 1.114
+++ src/modules/perl/perl_config.c 18 Feb 2003 03:20:52 -
@@ -466,6 +466,11 @@
#else
#define PERL_CMD_PUSH_HANDLERS(hook, cmd) \
+if(!PERL_RUNNING()) { \
+perl_startup(parms-server, parms-pool); \
+require_Apache(parms-server); \
+MP_TRACE_g(fprintf(stderr, mod_perl: calling perl_startup()\n)); \
+} \
mp_preload_module(arg); \
cmd = arg; \
return NULL
__
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: [Question] Prototype Mismatch for Base64 under RunPerl
[EMAIL PROTECTED] wrote: OS: Windows2000 Apache: 1.3.27 ModPerl: 1.27_01-dev I have a script that ran perfectly well when not run under ModPerl but have recently tried to run it under modperl using the RunPerl module. It still seems to run OK, however my error log now seems to being filled with the following error messages ... Prototype mismatch: sub Apache::ROOT::MSS_2dcgi::documents_2ecgi::encode_base64 vs ($;$) at c:/NMS/Perl/lib/Exporter.pm line 57. Prototype mismatch: sub Apache::ROOT::MSS_2dcgi::documents_2ecgi::decode_base64 vs ($) at c:/NMS/Perl/lib/Exporter.pm line 57. The errors are connected with the MIME::Base64 module when it defines the external subroutine names. The relevant section of my conf file is ... Alias /MSS-cgi/C:/NMS/MSSWeb/cgi-bin/ Alias /MSS-js/ C:/NMS/MSSWeb/includes/ Alias /MSS-images/ C:/NMS/MSSWeb/images/ Location /MSS-cgi AllowOverride None Order allow,deny Allow from all SetHandler perl-script PerlHandler Apache::PerlRun Options +ExecCGI PerlSendHeader On /Location I've searched all potential areas on the net with no success. Can anyone here assist ? While working on the potential areas you must have missed some real resources ;) Usually the search path is simple: 1. perl.apache.org/docs/ 2. http://perl.apache.org/maillist/modperl.html#Searchable_Archives failing to find anything at [1], I went to [2] and here you go: http://marc.theaimsgroup.com/?l=apache-modperlw=2r=1s=Prototype+mismatchq=b In particular this reply from Perrin seems to be most helpful: http://marc.theaimsgroup.com/?l=apache-modperlm=100515176231857w=2 And since you haven't posted the information we ask for: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems I'm guessing that you are using perl 5.6.0 which may be the reason for the problem. __ 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: Is Sys::Signal still needed?
Bill Moseley wrote: Searching the archives I don't see much discusson of Sys::Signal. Is it still needed to restore sig handlers? with older mod_perl versions? http://perl.apache.org/docs/1.0/guide/debug.html#Debugging_Signal_Handlers___SIG_FOO__ __ 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
cvs commit: modperl-2.0/lib/Apache Reload.pm
stas2003/02/16 16:54:49 Modified:lib/Apache Reload.pm Log: - get rid of dependency on mod_perl 1.0 (Apache-gensym) - require 1.99 Revision ChangesPath 1.6 +4 -3 modperl-2.0/lib/Apache/Reload.pm Index: Reload.pm === RCS file: /home/cvs/modperl-2.0/lib/Apache/Reload.pm,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- Reload.pm 29 Nov 2002 05:36:56 - 1.5 +++ Reload.pm 17 Feb 2003 00:54:49 - 1.6 @@ -3,6 +3,8 @@ use strict; use warnings FATAL = 'all'; +use mod_perl 1.99; + our $VERSION = '0.08'; require Apache::RequestUtil; @@ -60,9 +62,8 @@ my $touch_mtime = (stat($TouchFile))[9] || return 1; return 1 unless $touch_mtime $TouchTime; $TouchTime = $touch_mtime; -my $sym = Apache-gensym; -open($sym, $TouchFile) || die Can't open '$TouchFile': $!; -$TouchModules = $sym; +open my $fh, $TouchFile or die Can't open '$TouchFile': $!; +$TouchModules = $fh; chomp $TouchModules; }
Re: Apache::DBI and mod_perl 2
Chris Faust wrote: Hey Helmut, Yes, I'm sure its Apache::DBI - when I try to check for it directly via perl -MModule::Name, I get the error.. Where is a copy paste from the command line. [chrisf@web1 chrisf]$ perl -MApache::DBI -e 0 Can't locate Apache/Constants.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 [...] Also remember, that you can't test modules that require mod_perl to run from the command line. You'd have the same result with mod_perl 1.0 __ 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: [mp2] Free to Wrong Pool
Lee Goddard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: MD5 Sometimes I get: [Sat Feb 15 19:14:25 2003] -e: Free to wrong pool 464d8e0 not 466f8c0 at C:/PhotoWebServer/Perl/site/lib//Commerce/PhotoWebServer/Core.pm line 4404, DATA line 290. [Sat Feb 15 19:14:27 2003] [notice] Parent: child process exited with status 3221225477 -- Restarting. GNU tar version 1.11.2 And sometimes I get: [Sat Feb 15 19:20:10 2003] [notice] Parent: child process exited with status 3221225477 -- Restarting. The exit status value is consistent. This is whilst using Apache server version Apache/2.0.43 (Win32) mod_perl/1.99_08-dev Perl/v5.8.0 After each 'restart' there is less and less memory available. The problem is caused by a fault in the ImageMagick module, which crashes when trying to read a specific image. Is this a mod_perl issue? If so, is this a known issue? If not, is there something I can do ... ? The error message is coming from ImageMagick, so something goes wrong there. The Apache child process doesn't segfault, though. May be this has anything to do with signals in perl 5.8.0 being postponed and not delivered immediately? If so you could give it a try with -DPERL_OLD_SIGNALS (passed to ./configure followed by 'make make install'). If you can reduce the code that reproduces the problem, you may want to try with mod_cgi, just to know whether the problem is caused specifically in the mod_perl 2.0 env. __ 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: Building mod-perl 2 for cygwin
Steve Baldwin wrote:
I've got Apache2 installed and as far as I can tell, it is functional.
I'm trying to build mod-perl from source (as I couldn't find any
binaries for cygwin). When I initially ran the command :
perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
I got errors telling me it couldn't find cygdb-3.1.dll, which I
eventually tracked down to Apache::TextConfig::open_cmd. I commented
out the line :
local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
and the errors went away (it was clearing $ENV{PATH} which I think was
causing the error).
We need to explicitly set $ENV{PATH} to be able to start a process under -T
(see perlsec). We could hardcode the path of the value, but that would be
different for each platform. What the normal value of PATH on your system? Is
this something standard that other cygwin users can rely on?
However, when I run 'make', I get the following ...
[mod_perl-1.99_08]$ make
cd src/modules/perl make -f Makefile.modperl
make[1]: Entering directory
`/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl'
gcc -I/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl
-I/cygdrive/d/Downloads/mod_perl-1.99_08/xs -I/usr/local/apache2/include
-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing
-I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE -DMOD_PERL -O2 \
-c mod_perl.c mv mod_perl.o mod_perl.lo
mod_perl.c: In function `modperl_shutdown':
mod_perl.c:10: `my_perl' undeclared (first use in this function)
mod_perl.c:10: (Each undeclared identifier is reported only once
mod_perl.c:10: for each function it appears in.)
mod_perl.c: In function `modperl_hook_post_config':
mod_perl.c:498: `my_perl' undeclared (first use in this function)
mod_perl.c: In function `modperl_response_handler_cgi':
mod_perl.c:771: `my_perl' undeclared (first use in this function)
make[1]: *** [mod_perl.lo] Error 1
make[1]: Leaving directory
`/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl'
make: *** [modperl_lib] Error 2
The key is:
[mod_perl-1.99_08]$ perl -V
[...]
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=define
You don't have threads enabled, but you do have multiplicity enabled. I
thought that this problem could be workarounded with this:
Index: src/modules/perl/modperl_perl_includes.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl_includes.h,v
retrieving revision 1.17
diff -u -r1.17 modperl_perl_includes.h
--- src/modules/perl/modperl_perl_includes.h25 Nov 2002 01:31:00 -
1.17
+++ src/modules/perl/modperl_perl_includes.h17 Feb 2003 04:14:48 -
@@ -42,6 +42,19 @@
# endif
#endif
+/* If perl was compiled with MULTIPLICITY and/or
+ * PERL_IMPLICIT_CONTEXT, but no USE_ITHREADS, for mod_perl 2.0 it's
+ * the same as no multiplicity at all. This is to simplify the #ifdef
+ * logic of handling the perl context switching */
+#ifndef USE_ITHREADS
+#ifdef PERL_IMPLICIT_CONTEXT
+#undef PERL_IMPLICIT_CONTEXT
+#endif
+#ifdef MULTIPLICITY
+#undef MULTIPLICITY
+#endif
+#endif
+
#include EXTERN.h
#include perl.h
#include XSUB.h
but unfortunately this won't work, as certain PL_ variables aren't defined
without defined(MULTIPLICITY), while they are defined in the perl core
library. I suppose there are many other problems with this approach.
We can take two approaches, patch all the places in the code where perl
context is set explicitly to use #ifdef MULTIPLICITY, rather than #ifdef
USE_THREADS. Or we can refuse to build mod_perl if MULTIPLICITY is enabled
without the threads. Of course the first solution is more favorable for users.
But may I ask why do you have MULTIPLICITY enabled? Is it required for cygwin
perl (fork emulation?)
__
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: Building mod-perl 2 for cygwin
We can take two approaches, patch all the places in the code where perl context is set explicitly to use #ifdef MULTIPLICITY, rather than #ifdef USE_THREADS. Or we can refuse to build mod_perl if MULTIPLICITY is enabled without the threads. Of course the first solution is more favorable for users. I've played a bit with various options and it seems that it's going to be a big trouble to support MULTIPLICITY without USE_THREADS. My suggestion for now is to either rebuild with -Uusemultiplicity or -Dusethreads (less preferred if you don't need threads, but need speed). README.cygwin says: =item * C-Dusemultiplicity Multiplicity is required when embedding Perl in a C program and using more than one interpreter instance. This works with the Cygwin port. Though I can't see that this is a required option. __ 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: Server returns nothing (solved)
Viljo Marrandi wrote: Hello, Yes, use strict; was in all modules, this makes it even more interesting, doesn't it? use warnings; ? __ 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: [OT?] Win32 permissions puzzler
Alessandro Forghieri wrote:
[...]
use Bar qw($foo);
if($foo) {
...
Global symbol $foo requires explicit package name at
use vars qw($foo);
use Bar qw($foo);
or with 5.6+
our $foo;
use Bar qw($foo);
See:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Using_Global_Variables_and_Sharing_Them_Between_Modules_Packages
__
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: modperl segfault with threaded Perl 5.8
Pavel Hlavnicka wrote: Hi all, recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled Apache 1.3.27 with mod_perl 1.27 from source. Now if I run Apache is works until I configure some location with mod_perl and PerlHandler like this: Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all /Location If PerlHandler line is commented out, the server starts fine. Here is the backtrace of 'httpd -X' #0 0x4003cfa0 in Perl_gv_fetchpv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #1 0x40035635 in Perl_get_sv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #2 0x08056b78 in mp_preload_module () #3 0x08056e32 in perl_cmd_handler_handlers () #4 0x08078a35 in invoke_cmd () #5 0x08078e3b in ap_handle_command () #6 0x08078ec2 in ap_srm_command_loop () #7 0x0807c6a8 in urlsection () #8 0x080783ef in invoke_cmd () #9 0x08078e3b in ap_handle_command () #10 0x08078ec2 in ap_srm_command_loop () #11 0x0807ceb3 in virtualhost_section () #12 0x080783ef in invoke_cmd () #13 0x08078e3b in ap_handle_command () #14 0x08078ec2 in ap_srm_command_loop () #15 0x08079651 in ap_process_resource_config () #16 0x08079f2f in ap_read_config () #17 0x0808466c in main () #18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Has anyone seen it before? and... here is what my perl says: This is perl, v5.8.0 built for i386-linux-thread-multi Many thanks in advance, and sorry if I overlooked something basic. Your trace is not as useful as it could be, because it neither shows the arguments nor the line numbers in the source code. I suggest to debug it with gdb, set breakpoint in perl_cmd_handler_handlers and step through to see what's wrong. If you don't know how to debug see: http://perl.apache.org/docs/1.0/guide/debug.html#Debugging_when_Server_Crashes_on_Startup_before_Writing_to_Log_File_ and previous sections as well, though you don't need Apache::DB since the problem doesn't happen during the request. p.s. What app did you get this trace with? It'd be helpful to update the bug reporting section to explain how to get a more useful trace. The one that includes symbols, arguments and line numbers. __ 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: Apache::Module installation issues
dorian wrote: i'm not sure that this is an actual problem with Apache::Module itself, but it seems to stem from mod_perl distribution's mod_perl.h here: #ifdef PERL_THREADS #define _INCLUDE_APACHE_FIRST #endif #ifdef _INCLUDE_APACHE_FIRST #include apache_inc.h #endif the perl i built against was the stock debian/i386/unstable 5.8.0 which has ithreads built in, although i had similar results with a source-built copy on solaris9/sparc. the mod_perl version is 1.27. i found that if i explicitly prepended the include for apache_inc.h in the xs, the module appeared to build successfully. strangely enough, the -DPERL_THREADS was being passed into the build, which to my knowledge should have activated the include but i suppose i must be missing something. i notice that the module hasn't been updated since 1999, is there a replacement for its functionality that i don't know about? I don't remember what was the outcome of the patch I've posted a long time ago. I sent it after having the same problem. Index: src/modules/perl/mod_perl.h === RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.h,v retrieving revision 1.116 diff -u -r1.116 mod_perl.h --- src/modules/perl/mod_perl.h 23 May 2002 04:35:16 - 1.116 +++ src/modules/perl/mod_perl.h 14 Feb 2003 04:45:37 - @@ -72,11 +72,8 @@ #endif #ifdef PERL_THREADS -#define _INCLUDE_APACHE_FIRST -#endif - -#ifdef _INCLUDE_APACHE_FIRST #include apache_inc.h +#define _INCLUDE_APACHE_FIRST #endif #include EXTERN.h __ 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
cvs commit: modperl-2.0 Changes
stas2003/02/12 15:42:23
Modified:lib/Apache compat.pm
.Changes
Added: t/compat conn_authen.t
t/response/TestCompat conn_authen.pm
Log:
Add Apache::compat methods: $r-connection-auth_type and
$r-connection-user (requires 'PerlOptions +GlobalRequest') + tests
Revision ChangesPath
1.1 modperl-2.0/t/compat/conn_authen.t
Index: conn_authen.t
===
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestRequest;
plan tests = 1, \have_lwp;
my $location = /TestCompat::conn_authen;
ok GET_OK $location, username = 'dougm', password = 'foo';
1.1 modperl-2.0/t/response/TestCompat/conn_authen.pm
Index: conn_authen.pm
===
package TestCompat::conn_authen;
# simply check that we can retrieve:
# $r-connection-auth_type
# $r-connection-user
# both records don't exist in 2.0 conn_rec and therefore require
# 'PerlOptions +GlobalRequest' to retrieve those via Apache-request
use strict;
use warnings FATAL = 'all';
use Apache::TestUtil;
use Apache::Test;
use Apache::compat ();
use Apache::Constants qw(OK REMOTE_HOST);
sub handler {
my $r = shift;
my($rc, $sent_pw) = $r-get_basic_auth_pw;
return $rc if $rc != Apache::OK;
my $auth_type = $r-connection-auth_type || '';
die auth_type is '$auth_type', should be 'Basic'
unless $auth_type eq 'Basic';
my $user = $r-connection-user || '';
die user is '$user', while expecting 'dougm'
unless $user eq 'dougm';
OK;
}
1;
__DATA__
require valid-user
AuthType Basic
AuthName simple
SetHandler modperl
PerlOptions +GlobalRequest
PerlAuthenHandler TestCompat::conn_authen
PerlResponseHandler Apache::TestHandler::ok1
1.77 +7 -0 modperl-2.0/lib/Apache/compat.pm
Index: compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- compat.pm 31 Jan 2003 04:37:06 - 1.76
+++ compat.pm 12 Feb 2003 23:42:23 - 1.77
@@ -530,5 +530,12 @@
return Apache::DECLINED;
}
+package Apache::Connection;
+
+# auth_type and user records don't exist in 2.0 conn_rec struct
+# 'PerlOptions +GlobalRequest' is required
+sub auth_type { Apache-request-auth_type }
+sub user { Apache-request-user }
+
1;
__END__
1.124 +4 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.123
retrieving revision 1.124
diff -u -r1.123 -r1.124
--- Changes 7 Feb 2003 02:58:30 - 1.123
+++ Changes 12 Feb 2003 23:42:23 - 1.124
@@ -10,6 +10,10 @@
=item 1.99_09-dev
+Add Apache::compat methods: $r-connection-auth_type and
+$r-connection-user (requires 'PerlOptions +GlobalRequest') + tests
+[Stas]
+
Several issues resolved with parsing headers, including making work
the handlers calling $r-content_type() and not sending raw headers,
when the headers scanning is turned on. Lots of tests added to
Re: mod_perl 2.0 question about $r-connection-auth_type
Brian Millett wrote: Hi, I've just about got the Apache::AuthCookieDBI to work with Apache 2.0.44 mod_perl 1.99_09-dev, but I ran into a problem with the $r-connection object not having auth_type or user defined. The $r-auth_type work just fine. Are these the same reference? What should I look for, or use? They don't live in the connection record in 2.0, only in the request record. I've added Apache::compat methods for backwards compatibility. Notice that you need to set up: PerlOptions +GlobalRequest for that location. Either use the latest modperl-2.0 cvs or apply this patch to get the functionality: http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=104509336821414w=2 Also the online docs were updated (pending automatic update) __ 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: compile apache with mod_perl
Jozwiak, Paul wrote: Does anyone know why I keep getting: [Wed Feb 12 10:35:03 2003] [notice] child pid 312 exit signal Segmentation Fault (11) in my error_log? I have tried rebuilding the machine, installing older versions of apache, different C compilers, changing my mod_perl versions and still get this message every time I try to surf to the machine I just setup. When I start apache, it appears to start but when I surf to it, I get Page Cannot be displayed. This is a list of modules I install prior to compiling apache with mod_perl: You need to get the core backtrace and you will know right away what causes the problem. See: http://perl.apache.org/docs/2.0/devel/debug/c.html#Getting_the_core_File_Dumped http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ 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: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Geoffrey Young wrote: OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. I can't remember whether you modeled Cooker after PerlRun or RegistryNG. the current logic in RegistryNG represents a recent change and is my fault http://marc.theaimsgroup.com/?l=apache-modperl-devm=101240123609773w=2 basically, I was trying to fix pretty much what we're talking about but might have gotten it wrong. we probably ought to just follow the 1.0 Registry formula, since I can't remember anybody complaining about it in recent memory. that is, if we're going to have one version - see my other email for thoughts on having two versions of Registry :) I don't see what's wrong with your change, it brings things to be more consistent with Registry.pm. I've modeled the RegistryCooker after PerlRun.pm/RegistryNG.pm, but referring to Registry.pm when unsure. In any case, let's leave 1.0 alone (those who need it changed, can subclass RegistryNG) and work out a good 2.0. Re: ModPerl::RegistryCooker and its subclasses, you have to come forward and send tests that don't work as expected and we will act accordingly. My goal is to have an exhaustive test suite for registry scripts, because I'm sick of running my in-head built-in mod_perl ;) That includes lots of edge cases, for various error cases and such. Currently we have 34 tests, but more are needed. 206ok 404ok 500ok basic..ok closureok perlrun_requireok redirect...ok special_blocks.ok All tests successful. Files=8, Tests=34, 11 wallclock secs ( 6.80 cusr + 0.80 csys = 7.60 CPU) __ 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: RAW_ARGS question
Yuriy Syrota wrote: Hello. I want my modperl2 module to process RAW_ARGS configuration directives like this. AxMediaType screen AxStyleName #default AxAddProcessor text/xsl /styles/webpage_screen.xsl /AxStyleName AxStyleName printable AxAddProcessor text/xsl /styles/webpage_printable.xsl /AxStyleName /AxMediaType There is no example in the documentation how to implement it, could anybody give me such example? Indeed, there is none, but there is at least one in the mod_perl source, written in C, see: src/modules/modperl_cmd.c:MP_CMD_SRV_DECLARE(perl) and probably a few more in the httpd source. Since you are working on implementing it, if you can contribute such an example to the documentation, that would be grand! Thank you. __ 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: cmd_data analogous
Yuriy Syrota wrote:
Hello.
The command_rec structure in Apache has a useful field named cmd_data.
Is there an analogous field in the @APACHE_MODULE_COMMANDS from
mod_perl2?
Yup, it's called 'data'
src/modules/perl/modperl_module.c:705
/* no default if undefined */
if (!(errmsg = modperl_module_cmd_fetch(aTHX_ obj, data, val))) {
info-cmd_data = apr_pstrdup(p, SvPV(val, len));
}
Since I was porting the existing docs and this field didn't exist in 1.0, I've
missed it.
A documentation patch and a small test (just extend one of the
t/response/TestDirective/perlloadmodule*) is very appreciated.
__
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: Fw: Has Apache::Cookie been ported to mod_perl-2 yet?
Charles O. McElhose Jr. wrote: Thanks, is there any word on when this may happen? Subscribe to the apreq-dev list to stay up to date with the recent developments http://httpd.apache.org/apreq/ meanwhile use CGI::Cookie if you work with mod_perl 2.0. __ 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: mod_perl Installation and Configuration (fwd)
But I am not sure whether I have installed and configured properly. Can anyone help me and also give a sample file What Ged suggested is essential, but here is a direct link to get you going: http://perl.apache.org/docs/1.0/guide/getwet.html plus http://perl.apache.org/docs/1.0/guide/install.html#How_can_I_tell_whether_mod_perl_is_running_ __ 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: What is lastest stable version of mod_perl? newbie question.
Nick Tonkin wrote: [...] I am not aware that you _need_ perl 5.8 to compile the latest apache and mod_perl... You need 5.8 only to work with threaded mpm (Apache 2.0) and mod_perl 1.99_08. http://perl.apache.org/docs/2.0/user/install/install.html#Prerequisites __ 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: Fw: [Perl] how to static link mod_perl 2 into apache 2.0
Issac Goldstand wrote: Forwarding this from another list, because it's more appropriate here :-) - Original Message - *From:* Ron Gidron mailto:[EMAIL PROTECTED] *Sent:* Monday, February 10, 2003 3:48 PM *Subject:* [Perl] how to static link mod_perl 2 into apache 2.0 I am trying to install a Mason based system. This package requires mod_perl statically linked and not as a DSO. for this new installation I decided to test Apache 2.0 and mod_perl 2.0. I downloaded the source for both packages and I am able to configure and make / make test /make install for both without problems however when I issue the command apachectl -l I don't see any reference to mod_perl. I have tried playing with the ./configure options for apache (--enable-perl etc) but nothing seams to get me to where I need to go, this is getting quite frustrating... does anyone have any tips? have any of you installed this configuration before, do you happen to remember the order of steps you took? At this point only DSO is supported by 2.0. What's wrong with using DSO? The package requires mod_perl to be statically linked, but it talks about mod_perl-1.0. I'd first check with Mason folks whether 2.0 is supported at all. __ 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: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. __ 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: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
David Dick wrote: [...] The only thing that messed me up was when running a script with mod_cgi, you can return your own status codes and apache will happily go along with it. However, when you run the same script under mod_perl's Apache::Registry, you suddenly get Apache::Registry second guessing the script and adding to the script, something that for (especially) USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just ended up writing my own version of Apache::Registry that always returns OK, which works for my purposes and therefore I'm content. The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says; If the developer just does straight out weird stuff and messes with $r-status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me? Personally I don't see how is it possible to accomodate everybody in the same handler. Because the requirements are conficting and second guessing is working in 99% but breaks for 1%, causing torn out hairs. Perhaps having two different sub-classes which do things differently is the right way to go. The default should follow the course of the least surprise and accomplish what it was designed for in first place: emulate mod_cgi, while giving the speed benefits. The other sub-class should pitch towards developers that use registry, for scripts which are expected to behave differently from mod_cgi. Looks like that's what we have under mod_perl 1.0. Apache::Registry and Apache::PerlRun/RegistryNG behave differently and one should choose between the two according to their needs. Even though the overall implementation is different for a different reason (make a sub-classable registry). __ 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: test failed; ... t/httpd.conf
Vicki, you are obviously missing some build steps. How about starting from scratch again following the guide and get this frustration over? Thousands of people have simply followed the instructions at: http://perl.apache.org/docs/1.0/guide/getwet.html#Installing_mod_perl_in_Three_Steps and it just worked for them. 99.% that it'll work for you too ;) More details can be found at: http://perl.apache.org/docs/1.0/guide/install.html Hope it works out for you this time. __ 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: test failed; ... t/httpd.conf
Vicki Brown wrote: At 12:34 +1100 2003-02-09, Stas Bekman wrote: Vicki, you are obviously missing some build steps. Obviously :/ How about starting from scratch again following the guide and get this frustration over? Sadly, I started from scratch the first time. Thousands of people have simply followed the instructions at: http://perl.apache.org/docs/1.0/guide/getwet.html#Installing_mod_perl_in_Three_Steps Those are the same steps I have been following. I reiterate: Following the instructions in INSTALL-apaci (essentially identical to the web page you supplied above) I ran perl Makefile.PL APACHE_PREFIX=/usr/local/apache \ APACHE_SRC=../apache_1.3.26/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 make make test The latter did many things (meaning printed many bytes of make output, cc stuff, and cp commands to the screen...) and eventually complained Syntax error on line 3 of /ad4/ENV/common/src/WWW/mod_perl-1.27/t/conf/httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration So, obviously, I needed to do a make clean in the apache tree... OK. I did that. In fact, I downloaded a newer version of Apache. I also added the configure options I used to build Apache last time. Then I tried again: perl Makefile.PL APACHE_PREFIX=/usr/local/apache \ APACHE_SRC=../apache_1.3.27/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 \ APACI_ARGS='--server-uid=www \ --server-gid=www \ --with-perl=/usr/bin/perl \ --with-layout=Apache \ --enable-module=most \ --enable-shared=max \ --enable-module=auth_db \ --enable-module=mmap_static \ --activate-module=src/modules/perl/libperl.a \ --enable-shared=perl \ --disable-module=auth_dbm \ --disable-rule=EXPAT \ ' Now I get (at the end of the make test) ../apache_1.3.27/src/httpd: not found This would seem to indicate that the 1 2 3 step process doesn't build Apache (as it claims: If your goal is just to build and install Apache 1.3 with mod_perl out of their source trees and have no special interests in further adjusting or enhancing Apache... the following... builds Apache statically with mod_perl, installs Apache under /path/to/install/of/apache/ and mod_perl into the site_lib hierarchy of your existing Perl installation. All in one step.) Ideas appreciated... In the meantime, I will add a 4th step and configure Apache by hand. what happens if you do: cd ../apache_1.3.27/src make cd - make test -- __ 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: test failed; ... t/httpd.conf
Vicki Brown wrote: At 14:05 +1100 2003-02-09, Stas Bekman wrote: what happens if you do: cd ../apache_1.3.27/src make At this point, I get a probably harmless note and a make error. I ran: configure \ --server-uid=www \ --server-gid=www \ --with-perl=/usr/bin/perl \ --with-layout=Apache \ --enable-module=most \ --enable-shared=max \ --enable-module=auth_db \ --enable-module=mmap_static \ --activate-module=src/modules/perl/libperl.a \ --disable-module=auth_dbm \ --disable-rule=EXPAT I may have things wrong with the shared libraries. My instructions for the package I ultimately want to run (Bricolage) tell me to build mod_perl in statically, not as a DSO. So I removed --enable-shared=perl The configure worked except I got a complaint: Note (probably harmless): No library found for -lbind Suggestions for solving this would be appreciated. In my experience, things that are 'probably harmless often bite anyway. You don't have libbind installed (neither do I), I see that src/Configure has: *-BeOS*) PLATOSVER=`uname -r` case $PLATOSVER in 5.0.4*) OS=BeOS BONE LIBS=-lbind -lsocket -lbe -lroot CFLAGS=$CFLAGS -DBONE ;; *) and you seem to be on FreeBSD, no BeOS. The make then ran to here: gcc -c -I../.. -I/usr/local/lib/perl5/5.6.1/i386-freebsd/CORE -I../../os/unix -I../../include -funsigned-char -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -I/usr/local/include `../../apaci` -fpic -DSHARED_MODULE mod_auth_db.c mv mod_auth_db.o mod_auth_db.lo mod_auth_db.c: In function `get_db_pw': mod_auth_db.c:175: warning: passing arg 2 of pointer to function from incompatible pointer type mod_auth_db.c:175: warning: passing arg 4 of pointer to function makes pointer from integer without a cast mod_auth_db.c:175: too few arguments to function *** Error code 1 Stop in /ad4/ENV/common/src/WWW/apache_1.3.27/src/modules/standard. can you normally build Apache (without mod_perl) when --enable-module=auth_db is in? Sigh. This was following the mod_perl instructions in the _Apache_ INSTALL file, which say to configure mod_perl make make install ... configure Apache of course, you have just overwritten the mod_perl install. make make install Said instructions leave out the test steps entirely, which doesn't give me warm fuzzies anywhere... when you complete building mod_perl (static) enabled httpd, you should be able to see it: % apache_1.3.27/src/httpd -l | grep mod_perl mod_perl.c __ 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: httpd chroot 3.2 mod_perl
[EMAIL PROTECTED] wrote: Hi, I have the following error while running mod_perl chrooted which I would appreciate suggestions. [Sat Feb 8 08:58:30 2003] [error] Can't locate Apache/Test.pm in @INC (@INC contains: /var/www/lib/perl +/var/www/lib/perl/Apache [...] . /var/www/) at (eval 299) line 3 during global destruction. [Sat Feb 8 08:58:30 2003] [error] Undefined subroutine Apache::Test::handler called at PerlHandler subroutine +`Apache::Test' line 1 during global destruction. ls -la /var/www/lib/perl/Apache total 10 drwxr-xr-x 2 root daemon 512 Feb 8 09:05 . drwxr-xr-x 3 root daemon 512 Feb 8 09:05 .. -r--r--r-- 1 root daemon 7822 Feb 8 08:44 Test.pm Because there is Apache::Test from the test suite (which doesn't have a function called 'handler') installed under @INC, and it probably happens to get loaded before your Apache::Test. Rename your package and it'll probably just work. [p.s. it's a good practice not to hit reply on another thread's message, but to start a new mail when you start a new thread, otherwise you mess up the previous thread and the current one.] __ 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
cvs commit: modperl-2.0/src/modules/perl modperl_filter.c
stas2003/02/07 20:36:35
Modified:src/modules/perl modperl_filter.c
Log:
use a faster way to check whether we need to use a truncated buffer,
strlen on an 8k buffer is not cool.
Revision ChangesPath
1.52 +2 -1 modperl-2.0/src/modules/perl/modperl_filter.c
Index: modperl_filter.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- modperl_filter.c 7 Feb 2003 02:49:01 - 1.51
+++ modperl_filter.c 8 Feb 2003 04:36:35 - 1.52
@@ -25,7 +25,8 @@
* XXX: if buf wasn't 'const char *buf' we could simply do
* buf[len] = '\0'
*/
-if (len strlen(buf)) {
+/* MP_IOBUFSIZE is the size of wb-outbuf */
+if (buf == wb-outbuf len MP_IOBUFSIZE) {
work_buf = (char *)apr_pcalloc(wb-pool, sizeof(char*)*len);
memcpy((void*)work_buf, buf, len);
}
cvs commit: modperl-2.0/ModPerl-Registry/t/conf extra.conf.in
stas2003/02/06 15:57:08 Modified:ModPerl-Registry/t/conf extra.conf.in Log: add ScriptAlias so we can do tests against mod_cgi Revision ChangesPath 1.9 +2 -0 modperl-2.0/ModPerl-Registry/t/conf/extra.conf.in Index: extra.conf.in === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/conf/extra.conf.in,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- extra.conf.in 24 Dec 2002 01:51:40 - 1.8 +++ extra.conf.in 6 Feb 2003 23:57:08 - 1.9 @@ -35,6 +35,8 @@ Alias /registry_oo_conf/ @ServerRoot@/cgi-bin/ Alias /perlrun/ @ServerRoot@/cgi-bin/ +ScriptAlias /cgi-bin/ @ServerRoot@/cgi-bin/ + PerlModule ModPerl::RegistryBB Location /registry_bb PerlOptions +GlobalRequest
cvs commit: modperl-2.0/ModPerl-Registry Makefile.PL
stas2003/02/06 16:08:34
Modified:ModPerl-Registry Makefile.PL
Log:
enable SMOKE script creation for ModPerl-Registry
Revision ChangesPath
1.7 +4 -0 modperl-2.0/ModPerl-Registry/Makefile.PL
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/Makefile.PL,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Makefile.PL 14 May 2002 15:57:14 - 1.6
+++ Makefile.PL 7 Feb 2003 00:08:34 - 1.7
@@ -5,6 +5,7 @@
use lib map {($_, ../$_) } qw(lib Apache-Test/lib);
use ModPerl::MM ();
+use Apache::TestSmokePerl ();
# enable 'make test|clean'
use Apache::TestMM qw(test clean);
@@ -19,6 +20,9 @@
# accept the configs from comman line
Apache::TestMM::filter_args();
Apache::TestMM::generate_script('t/TEST');
+
+# t/SMOKE
+Apache::TestSmokePerl-generate_script;
ModPerl::MM::WriteMakefile(
NAME = 'ModPerl::Registry',
cvs commit: modperl-2.0/ModPerl-Registry/lib/ModPerl RegistryCooker.pm
stas2003/02/06 16:12:25 Modified:ModPerl-Registry/lib/ModPerl RegistryCooker.pm Log: always return the run's return status if it's not Apache::OK Revision ChangesPath 1.31 +5 -7 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm Index: RegistryCooker.pm === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- RegistryCooker.pm 5 Feb 2003 04:06:27 - 1.30 +++ RegistryCooker.pm 7 Feb 2003 00:12:25 - 1.31 @@ -159,15 +159,13 @@ return $rc unless $rc == Apache::OK; } -# handlers shouldn't set $r-status but return it +# handlers shouldn't set $r-status but return it, so we reset the +# status after running it my $old_status = $self-[REQ]-status; my $rc = $self-run; -my $new_status = $self-[REQ]-status; - -# only if the script has changed the status, reset to the old -# status and return the new status -return $old_status != $new_status -? $self-[REQ]-status($old_status) +my $new_status = $self-[REQ]-status($old_status); +return ($rc == Apache::OK $old_status != $new_status) +? $new_status : $rc; }
cvs commit: modperl-2.0/ModPerl-Registry/t/cgi-bin runtime_error_n_status_change.pl runtime_error_plus_body.pl runtime_error.pl
stas2003/02/06 16:15:39
Modified:ModPerl-Registry/t .cvsignore 500.t
ModPerl-Registry/t/cgi-bin runtime_error.pl
Added: ModPerl-Registry/t/cgi-bin runtime_error_n_status_change.pl
runtime_error_plus_body.pl
Log:
add several more tests which explore various situations when runtime
errors happen
Revision ChangesPath
1.3 +1 -0 modperl-2.0/ModPerl-Registry/t/.cvsignore
Index: .cvsignore
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- .cvsignore18 Oct 2001 04:25:12 - 1.2
+++ .cvsignore7 Feb 2003 00:15:39 - 1.3
@@ -1,3 +1,4 @@
logs
htdocs
TEST
+SMOKE
1.3 +44 -4 modperl-2.0/ModPerl-Registry/t/500.t
Index: 500.t
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/500.t,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- 500.t 23 Jan 2003 01:12:01 - 1.2
+++ 500.t 7 Feb 2003 00:15:39 - 1.3
@@ -5,7 +5,21 @@
use Apache::TestUtil;
use Apache::TestRequest qw(GET);
-plan tests = 3;
+plan tests = 6;
+
+{
+# the script changes the status before the run-time error happens,
+# this status change should be ignored
+my $url = /registry/runtime_error_n_status_change.pl;
+my $res = GET($url);
+#t_debug($res-content);
+ok t_cmp(
+500,
+$res-code,
+500 error on runtime error (when the script changes the status),
+ );
+}
+
{
@@ -20,6 +34,21 @@
}
{
+my $url = /registry/missing_headers.pl;
+my $res = GET($url);
+#t_debug($res-content);
+ok t_cmp(
+500,
+$res-code,
+500 error on missing HTTP headers,
+ );
+}
+
+{
+# since we have a runtime error before any body is sent, mod_perl
+# has a chance to communicate the return status of the script to
+# Apache before headers are sent, so we get the code 500 in the
+# HTTP headers
my $url = /registry/runtime_error.pl;
my $res = GET($url);
#t_debug($res-content);
@@ -31,12 +60,23 @@
}
{
-my $url = /registry/missing_headers.pl;
+# even though we have a runtime error here, the scripts succeeds
+# to send some body before the error happens and since by that
+# time Apache has already sent the headers, they will include
+# 200 OK
+my $url = /registry/runtime_error_plus_body.pl;
my $res = GET($url);
#t_debug($res-content);
ok t_cmp(
-500,
+200,
$res-code,
-500 error on missing HTTP headers,
+200, followed by a runtime error,
+ );
+
+# the error message is attached after the body
+ok t_cmp(
+qr/some body.*The server encountered an internal error/ms,
+$res-content,
+200, followed by a runtime error,
);
}
1.2 +3 -0 modperl-2.0/ModPerl-Registry/t/cgi-bin/runtime_error.pl
Index: runtime_error.pl
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/cgi-bin/runtime_error.pl,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- runtime_error.pl 23 Jan 2003 01:12:01 - 1.1
+++ runtime_error.pl 7 Feb 2003 00:15:39 - 1.2
@@ -1,2 +1,5 @@
+# this script sends no body at all, and since the error happens
+# the script will return 500
+
print Content-type: text/plain\n\n;
print no_such_func();
1.1
modperl-2.0/ModPerl-Registry/t/cgi-bin/runtime_error_n_status_change.pl
Index: runtime_error_n_status_change.pl
===
my $r = shift;
$r-status(404);
$r-send_http_header('text/plain');
$r-print(no_such_func());
1.1
modperl-2.0/ModPerl-Registry/t/cgi-bin/runtime_error_plus_body.pl
Index: runtime_error_plus_body.pl
===
# this script sends some body before the error happens,
# so 200 OK is expected, followed by an error
print Content-type: text/plain\n\n;
print some body;
print no_such_func();
cvs commit: modperl-2.0/ModPerl-Registry/t/cgi-bin runtime_error_n_status_change.pl status_change.pl
stas2003/02/06 16:23:31
Modified:ModPerl-Registry/t/cgi-bin runtime_error_n_status_change.pl
status_change.pl
Log:
don't use the 1.x compat api
Revision ChangesPath
1.2 +1 -1
modperl-2.0/ModPerl-Registry/t/cgi-bin/runtime_error_n_status_change.pl
Index: runtime_error_n_status_change.pl
===
RCS file:
/home/cvs/modperl-2.0/ModPerl-Registry/t/cgi-bin/runtime_error_n_status_change.pl,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- runtime_error_n_status_change.pl 7 Feb 2003 00:15:39 - 1.1
+++ runtime_error_n_status_change.pl 7 Feb 2003 00:23:31 - 1.2
@@ -1,4 +1,4 @@
my $r = shift;
$r-status(404);
-$r-send_http_header('text/plain');
+$r-print(Content-type: text/plain\n\n);
$r-print(no_such_func());
1.2 +1 -1 modperl-2.0/ModPerl-Registry/t/cgi-bin/status_change.pl
Index: status_change.pl
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/cgi-bin/status_change.pl,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- status_change.pl 7 Feb 2003 00:13:40 - 1.1
+++ status_change.pl 7 Feb 2003 00:23:31 - 1.2
@@ -1,3 +1,3 @@
my $r = shift;
$r-status(404);
-$r-send_http_header('text/plain');
+$r-print(Content-type: text/plain\n\n);
cvs commit: modperl-2.0/ModPerl-Registry/t closure.t
stas2003/02/06 16:40:32
Modified:ModPerl-Registry/t closure.t
Log:
correct the explanation
Revision ChangesPath
1.6 +3 -2 modperl-2.0/ModPerl-Registry/t/closure.t
Index: closure.t
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/closure.t,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- closure.t 22 May 2002 05:40:48 - 1.5
+++ closure.t 7 Feb 2003 00:40:32 - 1.6
@@ -118,9 +118,10 @@
sub sleep_and_touch_file {
my $file = shift;
-# need to wait at least 1 whole sec, so -M will notice the
+# need to wait at least 1 whole sec, so utime() will notice the
# difference. select() has better resolution than 1 sec as in
-# sleep()
+# sleep() so we are more likely to have the minimal waiting time,
+# while fullfilling the purpose
select undef, undef, undef, 1.00; # sure 1 sec
my $now = time;
utime $now, $now, $file;
cvs commit: modperl-2.0/ModPerl-Registry/t closure.t
stas2003/02/06 16:51:08 Modified:ModPerl-Registry/t closure.t Log: spel Revision ChangesPath 1.7 +1 -1 modperl-2.0/ModPerl-Registry/t/closure.t Index: closure.t === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/closure.t,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- closure.t 7 Feb 2003 00:40:32 - 1.6 +++ closure.t 7 Feb 2003 00:51:08 - 1.7 @@ -121,7 +121,7 @@ # need to wait at least 1 whole sec, so utime() will notice the # difference. select() has better resolution than 1 sec as in # sleep() so we are more likely to have the minimal waiting time, -# while fullfilling the purpose +# while fulfilling the purpose select undef, undef, undef, 1.00; # sure 1 sec my $now = time; utime $now, $now, $file;
cvs commit: modperl-2.0/src/modules/perl modperl_filter.c
stas2003/02/06 18:30:53
Modified:src/modules/perl modperl_filter.c
Log:
we have no choice but to truncate wb-outbuf to the size of 'len'. All
kind of weird problems pop-up when the previous request was proper and the
current request has messed up with headers, because
modperl_cgi_header_parse (actually the ap_scan_script_header_err_strs)
will get things messed up because it expects a buffer with real data only.
Revision ChangesPath
1.50 +24 -23modperl-2.0/src/modules/perl/modperl_filter.c
Index: modperl_filter.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- modperl_filter.c 7 Feb 2003 00:07:42 - 1.49
+++ modperl_filter.c 7 Feb 2003 02:30:52 - 1.50
@@ -8,11 +8,28 @@
apr_bucket_alloc_t *ba = (*wb-filters)-c-bucket_alloc;
apr_bucket_brigade *bb;
apr_bucket *bucket;
-
+const char *work_buf = buf;
+
if (wb-header_parse) {
request_rec *r = wb-r;
const char *bodytext = NULL;
-int status = modperl_cgi_header_parse(r, (char *)buf, bodytext);
+int status;
+/*
+ * since wb-outcnt is persistent between requests, if the
+ * current response is shorter than the size of wb-outcnt
+ * it may include data from the previous request at the
+ * end. When this function receives a pointer to
+ * wb-outbuf as 'buf', modperl_cgi_header_parse may
+ * return that irrelevant data as part of 'bodytext'. So
+ * to avoid this risk, we create a new buffer of size 'len'
+ * XXX: if buf wasn't 'const char *buf' we could simply do
+ * buf[len] = '\0'
+ */
+if (len strlen(buf)) {
+work_buf = (char *)apr_pcalloc(wb-pool, sizeof(char*)*len);
+memcpy((void*)work_buf, buf, len);
+}
+status = modperl_cgi_header_parse(r, (char *)work_buf, bodytext);
wb-header_parse = 0; /* only once per-request */
@@ -26,32 +43,16 @@
/* XXX: bodytext == NULL here */
return status;
}
-
-if (!bodytext) {
+else if (!bodytext) {
return APR_SUCCESS;
}
-else {
-len -= (bodytext - buf);
-buf = bodytext;
-/*
- * since wb-outbuf is persistent between requests, if the
- * current response is shorter than the size of wb-outbuf
- * it may include data from the previous request at the
- * end. When this function receives a pointer to
- * wb-outbuf as 'buf', modperl_cgi_header_parse may
- * return that irrelevant data as part of 'bodytext'. So
- * to avoid this risk, we check whether there is any real
- * data to send and if not return.
- */
-if (!len) {
-return APR_SUCCESS;
-}
-}
-
+
+len -= (bodytext - work_buf);
+work_buf = bodytext;
}
bb = apr_brigade_create(wb-pool, ba);
-bucket = apr_bucket_transient_create(buf, len, ba);
+bucket = apr_bucket_transient_create(work_buf, len, ba);
APR_BRIGADE_INSERT_TAIL(bb, bucket);
MP_TRACE_f(MP_FUNC, buffer length=%d\n, len);
cvs commit: modperl-2.0/ModPerl-Registry/t/cgi-bin content_type.pl
stas2003/02/06 18:49:01
Modified:src/modules/perl modperl_filter.c
ModPerl-Registry/t basic.t
Added: ModPerl-Registry/t/cgi-bin content_type.pl
Log:
if the handler sets the content-type, don't parse the headers because
there most likely there will be none
Revision ChangesPath
1.51 +3 -3 modperl-2.0/src/modules/perl/modperl_filter.c
Index: modperl_filter.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- modperl_filter.c 7 Feb 2003 02:30:52 - 1.50
+++ modperl_filter.c 7 Feb 2003 02:49:01 - 1.51
@@ -10,13 +10,13 @@
apr_bucket *bucket;
const char *work_buf = buf;
-if (wb-header_parse) {
+if (wb-header_parse !wb-r-content_type) {
request_rec *r = wb-r;
const char *bodytext = NULL;
int status;
/*
- * since wb-outcnt is persistent between requests, if the
- * current response is shorter than the size of wb-outcnt
+ * since wb-outbuf is persistent between requests, if the
+ * current response is shorter than the size of wb-outbuf
* it may include data from the previous request at the
* end. When this function receives a pointer to
* wb-outbuf as 'buf', modperl_cgi_header_parse may
1.9 +53 -42modperl-2.0/ModPerl-Registry/t/basic.t
Index: basic.t
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/basic.t,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- basic.t 6 Jan 2003 10:39:43 - 1.8
+++ basic.t 7 Feb 2003 02:49:01 - 1.9
@@ -13,58 +13,69 @@
my @aliases = sort keys %modules;
-plan tests = @aliases * 4 + 1;
+plan tests = 2;
+#plan tests = @aliases * 4 + 2;
-# very basic compilation/response test
-for my $alias (@aliases) {
-my $url = /$alias/basic.pl;
-
-ok t_cmp(
-ok,
-GET_BODY($url),
-$modules{$alias} basic cgi test,
-);
-}
-
-# test non-executable bit
-for my $alias (@aliases) {
-my $url = /$alias/not_executable.pl;
-
-ok t_cmp(
-403 Forbidden,
-HEAD($url)-status_line(),
-$modules{$alias} non-executable file,
-);
-}
-
-# test environment pre-set
-for my $alias (@aliases) {
-my $url = /$alias/env.pl?foo=bar;
+## very basic compilation/response test
+#for my $alias (@aliases) {
+#my $url = /$alias/basic.pl;
+
+#ok t_cmp(
+#ok,
+#GET_BODY($url),
+#$modules{$alias} basic cgi test,
+#);
+#}
+
+## test non-executable bit
+#for my $alias (@aliases) {
+#my $url = /$alias/not_executable.pl;
+
+#ok t_cmp(
+#403 Forbidden,
+#HEAD($url)-status_line(),
+#$modules{$alias} non-executable file,
+#);
+#}
+
+## test environment pre-set
+#for my $alias (@aliases) {
+#my $url = /$alias/env.pl?foo=bar;
+
+#ok t_cmp(
+#foo=bar,
+#GET_BODY($url),
+#$modules{$alias} mod_cgi-like environment pre-set,
+#);
+#}
+
+## require (actually chdir test)
+#for my $alias (@aliases) {
+#my $url = /$alias/require.pl;
+
+#ok t_cmp(
+#it works,
+#GET_BODY($url),
+#$modules{$alias} mod_cgi-like environment pre-set,
+#);
+#}
+# test method handlers
+{
+my $url = /registry_oo_conf/env.pl?foo=bar;
ok t_cmp(
foo=bar,
GET_BODY($url),
-$modules{$alias} mod_cgi-like environment pre-set,
-);
-}
-
-# require (actually chdir test)
-for my $alias (@aliases) {
-my $url = /$alias/require.pl;
-
-ok t_cmp(
-it works,
-GET_BODY($url),
-$modules{$alias} mod_cgi-like environment pre-set,
+ModPerl::Registry-handler mod_cgi-like environment pre-set,
);
}
-# test method handlers
+# test mod_perl api usage
{
-my $url = /registry_oo_conf/env.pl?foo=bar;
+my $url = /registry/content_type.pl;
ok t_cmp(
-foo=bar,
+ok,
GET_BODY($url),
-ModPerl::Registry-handler mod_cgi-like environment pre-set,
+\$r-content_type('text/plain'),
);
}
1.1 modperl-2.0/ModPerl-Registry/t/cgi-bin/content_type.pl
Index: content_type.pl
===
my $r = shift;
$r-content_type('text/plain');
$r-print('ok');
cvs commit: modperl-2.0 Changes
stas2003/02/06 18:58:30 Modified:.Changes Log: log the recent changes Revision ChangesPath 1.123 +5 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.122 retrieving revision 1.123 diff -u -r1.122 -r1.123 --- Changes 5 Feb 2003 04:06:27 - 1.122 +++ Changes 7 Feb 2003 02:58:30 - 1.123 @@ -10,6 +10,11 @@ =item 1.99_09-dev +Several issues resolved with parsing headers, including making work +the handlers calling $r-content_type() and not sending raw headers, +when the headers scanning is turned on. Lots of tests added to +exercise different situations. [Stas] + warn on using -T in ModPerl::Registry scripts when mod_perl is not running with -T [Stas]
Re: Disabling TransHandler
Stathy G. Touloumis wrote:
Our sysadmin was attempting to disable a TransHandler for a virtual host
using a directive that he used in the past. I wasn't aware of such a
directive and was further stumped when I saw it :
PerlSetVar authsession false
He does not remember where he got this from but it seems to work. Any
ideas as to why this would disable a TransHandler? Where does it come
from and what mod_perl code uses it?
The only TransHandler on this site makes no references to using any
configuration variables set this way.
I suppose you had PerlPostReadRequestHandler which was doing:
my $auth = $r-dir_config('authsession');
$r-set_handlers(PerlTransHandler = sub { return OK })
if $auth eq 'false';
this is not a magic internal feature ;)
__
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: mod_perl 1.27 intermittent Segmentation Faults
Michael A Musta wrote: I am getting sporadic segmentation faults with mod_perl 1.27. A look at the core dump always shows: Any chance you can set your debugger to show the real arguments and not only the addresses? That might help to see where the problem is. e.g., mod_perl_sent_header expects only two args. for example here is a snippet from another core dump, generated with gdb: #0 0x40750515 in mpxs_Apache__RequestRec_send_http_header (r=0x8156490, type=0x0) at /mnt/tmpfs/modperl-2.0/xs/Apache/Response/Apache__Response.h:26 #1 0x40751de3 in XS_Apache__RequestRec_send_http_header (my_perl=0x80c9ce8, cv=0x81a5160) at Response.xs:137 - lwp# 1 / thread# 1 0008b37c mod_perl_sent_header (360fc0, 997ec, 599394, 326c00, 0, 0) + 18 00241c14 Perl_pp_entersub (31c800, 4a3d60, 4, 1, 0, ff00) + 568 00239dc8 Perl_runops_standard (326c00, 1a, c0, 328c00, 37fd08, 59bba0) + 30 001e8928 S_call_body (ffbef078, 0, 326c00, 40, 81010100, ff00) + 5c 001e8398 Perl_call_sv (599394, 4d2cd4, 18, 392ed0, 326c00, 557178) + 250 001e8138 Perl_call_method (2e9790, 0, 0, 329000, 64, 4d2cd4) + 18 0023b720 Perl_pp_print (4d2cd0, 0, 4d2cd0, 1, 4d2cdc, 4d2cd8) + 1cc 00239dc8 Perl_runops_standard (326c00, 326c00, ffbef2dc, 1, 0, 5af328) + 30 001e8928 S_call_body (ffbef358, 0, 326400, 35e598, 326c00, ff00) + 5c 001e8624 Perl_call_sv (0, 4d2cd0, 326c00, 2b6580, 0, 2d) + 4dc 0008d760 perl_call_handler (3b73dc, 55cea8, 0, 2b6538, 0, ff00) + 5bc 0008cf4c perl_run_stacked_handlers (2b5b30, 55cea8, 38a384, 0, 0, 425078) + 1d0 0008c1bc perl_access (55cea8, 8c0f4, 323684, f72cc, 0, 424c98) + c8 000f2c00 run_method (55cea8, 1b, 1, 0, 2f575354, 2f636769) + 88 000f2cf0 ap_check_access (55cea8, 2cdf70, 2cdc00, 2cc1c1, 45, 65) + 1c 00112750 process_request_internal (55cea8, 0, 2c0, 0, ec00, 1) + 2dc 00112be0 ap_process_request (55cea8, c8, 55cea8, ffbef738, ffbef748, 0) + 3c 00105674 child_main (0, 1034c4, 103400, ff13b1e0, ff135910, ff12efc0) + 978 00105a28 make_child (32b378, 0, 3e4282ab, 0, 10, ff02b404) + 1a4 00105b4c startup_children (1, 0, 1, 307000, 6c6f6700, 6c6f6700) + b4 00106580 standalone_main (2, ffbef9fc, 0, 0, ff23b01c, 2cbb68) + 2fc 001071f4 main (2, ffbef9fc, ffbefa08, 326464, 0, 0) + 548 0004599c _start (0, 0, 0, 0, 0, 0) + 5c So, it is always happening at the 'mod_perl_sent_header'. Sometimes it can take hours before a segmention fault occurs. Sometimes it is immediate. Every time I get the core dump, the location is the same--mod_perl_sent_header. -- __ 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
article: The Apache of the Future
Here is an article on Apache 2.0 adoption trend http://www.newsfactor.com/perl/story/20572.html __ 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: Newbie advice required
Seldo wrote: Hello everyone - I'm in the unfortunate position of being needing to write an Apache 2.0 module using mod_perl 2.0, while being simultaneously new to both mod_perl, the Apache API, and perl itself. I guess I'm a glutton for punishment, or something. (Did I mention this is all on Win32?) You forgot to add to unfortunate facts that both mod_perl 2.0 and Apache 2.0 are new and may have bugs ;) But on the other hand you are the fortunate one to be one of the first to embrace the new platform. What doesn't kill you makes you stronger ;) What I want my module to be able to do is to substitute content from various plug-in applications as the response to various URLs. For example, if the user requests www.mydomain.com/app1/file I want app1.exe (or whatever) to retrieve a file / run a database query / do some processing and return some output. Do you say that the actual code resides in the database? So you want to fool Apache as if the code existed on the filesystem? Or does your database returns paths to the real files? Importantly, I *then* want the rest of Apache to treat this file as if it had come from the file system, e.g. it it's a .php file I still want PHP to handle it, if there are any other handlers assigned I still want them to handle it. In short, this substitution has to be completely transparent. (This should be possible by returning Apache::DECLINED, but it doesn't seem to work like that, see below) Now, I know it's possible to configure Apache with app1.exe as a handler for /app1, etc.. What I'm creating is a single module that handles *all* URLs (i.e. handles /), and manages the mapping itself. So far, I think the best way to do this is to create a URI translation handler module which will simply use $r-uri() to call the application with whatever data and parameters it needs. You mean PerlTransHandler, right? You are on the right track then. First question: 1. Is this really the best way to supply the server with content that comes from elsewhere than simply the file system? I've written a simple translator which can return .html files, but if I set the uri to a .php file the server seems to go into a loop (I've been unable to diagnose what's actually happening). 2. Why would setting $r-uri() to a .php file be any different to the rest of the server than setting it to a .html file? and finally If you don't have a real file with the content you probably need to rely on output filters. 3. How to ensure that the server treats the output of an application the same as it does a file, i.e. applying all the necessary handlers etc? Assuming that you have a set of filters which do the work, it's easy. e.g. I think php in 2.0 is an output filter, so you should just dynamically insert the php filter when you figure out that the content is php. HTML/text is easy. SSI is a filter, so covered too. What other processors do you need? Any and all advice appreciated, including You fool! This already exists! :-) __ 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: Newbie advice required
Seldo wrote: Whoa, quick turnaround! Oof course, it's 11pm here, but only 6pm where you are I suppose... It's actually 11am, on your tomorrow (PDT+11) ;) I'm living in the future ;) On 05 February 2003, Stas Bekman wrote: SB You forgot to add to unfortunate facts that both mod_perl 2.0 and SB Apache 2.0 are new and may have bugs ;) From what I could tell, doing this with Apache 1.3 is even more daunting, since it didn't really have the concept of filters ironed out. True. [...] SB Assuming that you have a set of filters which do the work, it's SB easy. e.g. I think php in 2.0 is an output filter, so you should SB just dynamically insert the php filter when you figure out that SB the content is php. HTML/text is easy. SSI is a filter, so covered SB too. What other processors do you need? That's the thing. This application has to be flexible: I don't want to have to explicitly support file types; I simply want to supply the server with data that looks like a file and have it treat that data exactly as it would any other file. The simplest way would be to save the extracted data into a file, and set $r-filename to point to that file, and let the Apache core handle that. If you want it to be smarter, but more complex, read on. However, I have a feeling this might be impractical, so alternate suggestions are welcome :-) At this point I feel I should be doing some kind of I-am-a-clueless-newbie dance. I am totally out of my depth, and this project is due in 3 weeks! *bursts into semi-panicked laughter*. Um. Yeah :-) Well, we are all new to this thing so *you* are the one who has to be the inventor. In short, if all possible applications can be invoked as filters you should be all set. text/html: just send it out text/plain: ditto mod_perl: compile the handler (assuming that the code is coming from the db) and configure the handler to be modperl/perl-script or set the PerlResponseHandler to the one you've just compiled exe: save the data in a file, and set $r-filename to it. Apache will do the rest. php: though I haven't tried it, the php filter probably accepts its code as an input to a filter. you have to check that though. __ 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: Newbie advice required [some further info]
Seldo wrote:
I mentioned that I don't think there's a way to practically supply
arbitrary data to Apache that looks like its coming from the
filesystem. The other way I thought of is this:
$r-uri() can map one URI to another. This means that a request to
www.mydomain.com/app1/site/page.php
could be remapped by my module to call app1.exe /site/page.php (i.e.
using the remainder of the path as a parameter to determine what data
to supply. This works, but it means extension-based handlers like PHP
probably won't be activated -- how can I get around that, short of
manually coding support for every requested file type?
Have you configured your server to run .php files by php?
Also, the following code used as a PerlTransHandler sends the server
into what looks like an endless loop:
package Seldo::MaskURI;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::Const -compile = qw(DECLINED);
sub handler {
my $r = shift;
$r-uri(/bob.php);
return Apache::DECLINED;
}
1;
The code is supposed to perform the (nonsensical) task of returning
bob.php no matter what URL the server is given. If .php is changed
to .html it works, but as I say, having it as .php throws it for
six. Anybody know why? It's possible there's something really obvious
wrong -- like I said, I barely know perl, far less mod_perl.
Does it work for other handlers? e.g.:
$r-uri(/perl/bob.pl);
assuming that you have /perl configured to run ModPerl::Registry?
Does a request to /bob.php works fine if requested directly (when you don't
have your PerlTransHandler installed?
__
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
cvs commit: modperl-2.0/ModPerl-Registry TODO
stas2003/02/04 20:06:28
Modified:.Changes
ModPerl-Registry/lib/ModPerl RegistryCooker.pm
ModPerl-Registry TODO
Log:
warn on using -T in ModPerl::Registry scripts when mod_perl is not
running with -T
Revision ChangesPath
1.122 +7 -4 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.121
retrieving revision 1.122
diff -u -r1.121 -r1.122
--- Changes 4 Feb 2003 06:52:15 - 1.121
+++ Changes 5 Feb 2003 04:06:27 - 1.122
@@ -10,10 +10,13 @@
=item 1.99_09-dev
-perl 5.7.3+ has a built-in ${^TAINT} to test whether running under
--(T|t). Backport ${^TAINT} for mod_perl running under 5.6.0-5.7.3,
-(what used to be $Apache::__T. $Apache::__T is available too, but
-deprecated. [Stas]
+warn on using -T in ModPerl::Registry scripts when mod_perl is not
+running with -T [Stas]
+
+perl 5.7.3+ has a built-in ${^TAINT} to test whether it's running
+under -(T|t). Backport ${^TAINT} for mod_perl running under
+5.6.0-5.7.3, (what used to be $Apache::__T. $Apache::__T is available
+too, but deprecated. [Stas]
add PerlChildExitHandler implementation [Stas]
1.30 +4 -5 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
Index: RegistryCooker.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- RegistryCooker.pm 18 Jan 2003 02:04:32 - 1.29
+++ RegistryCooker.pm 5 Feb 2003 04:06:27 - 1.30
@@ -552,10 +552,9 @@
my %switches = (
'T' = sub {
-# XXX: need to have $Apache::__T set by the core on PerlSwitches -T
-# Apache::warn(T switch is ignored, ,
-#enable with 'PerlSwitches -T' in httpd.conf\n)
-# unless $Apache::__T;
+ Apache::warn(-T switch is ignored, .
+enable with 'PerlSwitches -T' in httpd.conf\n)
+ unless ${^TAINT};
;
},
'w' = sub { use warnings;\n },
@@ -574,7 +573,7 @@
last if substr($s,0,1) eq -;
for (split //, $s) {
next unless exists $switches{$_};
- $prepend .= {$switches{$_}};
+ $prepend .= $switches{$_}-();
}
}
${ $self-[CODE] } =~ s/^/$prepend/ if $prepend;
1.12 +0 -2 modperl-2.0/ModPerl-Registry/TODO
Index: TODO
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/TODO,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- TODO 29 Dec 2002 10:11:49 - 1.11
+++ TODO 5 Feb 2003 04:06:27 - 1.12
@@ -14,8 +14,6 @@
### missing features ###
-- need to port $Apache::__T, to test against when user supplies -T flag.
-
- port Apache::PerlRunXS
- replace the local implementation of slurp_filename() and finfo(),
Re: cgi and mod_perl-1.26, Apache-1.27, perl-5.8.0, FreeBSD failwith 'The document contained no data'
Lee Goddard wrote: I don't know: you're doing this: print Content-type: text/plain\n\n; print Hello World\n; Does it (probably not) make any difference if you do a full CRLF, as perldoc perlop: For example, most networking protocols expect and prefer a CR+LF (\015\012 or \cM\cJ) for line terminators, and although they often accept just \012, they seldom tolerate just \015. If you get in the habit of using \n for networking, you may be burned some day. SB Apache already fixes up \n\n to the right thing. What it really does SB is identifying the Content-type: header, and then adds the terminating SB by itself, because it really sends other headers, before adding an SB empty new line. So it shouldn't matter if you say \r\n\r\n or just SB \n\n, unless there is a bug. So if Apache (mod_perl) adds this to his script, even though it is not a mod_perl script, then shouldn't he be calling it from a Location that isn't mod_perl enabled...? Sorry, just getting into this Apache module thing The script sends the header, which could be multiline and terminates it with an empty new line. By saying 'PerlSendHeader On' you tell mod_perl to parse the headers (which is actually done by an apache functions) and separate them from the body. Apache then adds other headers (Server token, Date, etc) and sends the response as if it was a mod_perl module. Think of Apache::Registry and friends as mod_cgi on mushrooms. __ 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: Problem Building 1.99_08 on OpenBSD
John Eisenschmidt wrote: OpenBSD 3.2 Perl 5.6.1 I'm trying to build MP 1.99_08 for Apache 2.0.44, and I'm not quite sure where I'm messing up. Apache built fine, building the config for MP went fine: jweisen@kaitain$ sudo perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1 ... *** mod_perl dso library will be built as mod_perl.so *** mod_perl static library will be built as mod_perl.a *** You'll need to add the following to httpd.conf: *** LoadModule perl_module modules/mod_perl.so But the actual make doesn't go so well: jweisen@kaitain$ sudo make ... ranlib: mod_perl.so: Inappropriate file type or format *** Error code 1 Stop in /usr/local/src/mod_perl-1.99_08/src/modules/perl (line 149 of Makefile.modperl). *** Error code 1 Stop in /usr/local/src/mod_perl-1.99_08 (line 459 of Makefile). I dug back a couple months in the mailing lists and I'm not seeing anything applicable. Any help would be appreciated. Actually there were several reports of a similar failure for mod_perl 2.0 and even more for mod_perl 1.0. It looks like you've snipped too much and you don't show what are the unresolved symbols, which seems to be the cause of the error: ranlib: mod_perl.so: Inappropriate file type or format __ 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: handling of the trailing slash
kris nelson wrote: Apache/1.3.26 + mod_perl/1.27 I've noticed that Apache alone appears to differ from one of my modules running under mod_perl in its handling of trailing slashes. I'm wondering if this is expected behavior and, if so, why? (Maybe this is obvious...) For example: the file news.html exists in /var/www/html/. I issue four requests to Apache alone, one for /news.html, one for /news, one for /news/ and one for /news.html/, and then the same four requests again, this time under mod_perl. The second time, under mod_perl, I use a basic little module that simply records the value of $r-filename to the error log and then sends the contents of the file to the browser (after opening it with Apache::File, similar to the Ch. 4 Eagle book instructions). (No directory called /var/www/html//news exists, nor are there any symlinks involved.) Here's a table of the results: Apache --- /news.html /news /news/ /news.html/ 200 200 404 404 200 means success, data displayed was from news.html. The error log showed that /news.html/ was not found in the case of the 404s. Apache+mod_perl --- /news.html /news /news/ /news.html/ 200 200 200 200 200 means success, data displayed was from news.html, error_log recorded /var/www/html/news.html in all cases as the value of $r-filename (thanks to my little Perl module logging this value for me). In the cases of /news/ and /news.html/, my relative image links broke (for hopefully obvious reasons). Is this expected behavior? Why? I would expect Apache and Apache+mod_perl to behave similarly. Am I missing something obvious? (Probably...) It's hard to guess what your relevant configuration is. Care to send in the mod_perl and Apache sections? Including things like Multiviews Options, DirectoryIndex, etc. Basically it all comes to the following logic: mod_perl sections inherit all the default Apache settings unless you've overriden them. And this is true for any other module, be it mod_perl or not. __ 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: Different modules, same names, random results
David Dick wrote:
this is probably evil, and apologies to those who have seen suspiciously
familiar code before, but is this possible?
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
}
sub handler {
delete $INC{'Site.pm'};
# mess with @INC
require Site;
return (Apache::Registry::handler(@_));
}
a simpler way is to do:
do Site.pm;
though you forgot to call the import, when removing use, so you do:
do Site.pm;
Site-import(whatever);
and if you use:
use warnings;
you probably want to add:
no warnings 'redefine';
END { }
1;
that would allow you to keep perl resident, keep the cgi-scrip resident
and simply reload a small? configuation perl module each time.
(i think?) :)
indeed. This is discussed here:
http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs
__
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: Different modules, same names, random results
Pinunki wrote:
[...]
I have tried using Apache::Register and
Apache::PerlRun but am having problems due to the fact
that each web site refers to their own copy of my
module called Site.pm (to contain functions, global
variables etc). The problem is that the my scripts get
confused and use variables from the other site's
modules randomly.
[...]
If your module which has an indentical name but different contents and it
never calls functions and accesses variables by prefixing the module name
(e.g. Site::foo and $Site::bar), i.e. everything is exported, you could hack
Apache::Registry to compile the different files into different package names
and do the importing for you. Here is the proof of concept (untested!) code.
All it does, is reading the file (Site.pm in your case), prepending the string
'package foo_bar_tar_lib1_Site_pm;'
to the contents of the file, compiling the module via eval and then calling
import() to import all the stuff as it did before. Notice that you do have to
change your scripts to call the trickery my_use().
(Alternatively you could try to play with aliasing of the namespaces, instead
of mangling the file contents, but this could introduce problems...)
my_script.pl:
-
my @imports();
Apache::Registry::my_use('Site.pm', @imports);
Site.pm
---
# no package declaration!
# the rest is as usual Exporter, vars, subs
# blah, blah
1;
Registry.pm
---
package Apache::Registry;
# the normal Registry stuff ...
# then the extra stuff:
use File::Spec::Functions;
sub my_use {
my($module, @import) = @_;
my $file = catfile Apache-request-filename, $module;
my $namespace = make_namespace($file);
compile($namespace, $file) or die failed to compile: $@;
$namespace-import(@import);
}
sub make_namespace {
my ($path) = @_;
$path =~ s/([^A-Za-z0-9_])/sprintf(_%2x, unpack(C, $1))/eg;
# make sure that the sub-package doesn't start with a digit
$path =~ s/^(\d)/_$1/;
return $path;
}
sub compile {
my ($namespace, $file) = @_;
open my $fh, $file;
local $/;
my $data = $fh;
close $fh;
{ eval package $namespace;\n $data; }
return $@ ? 0 : 1;
}
1;
__
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: Possible bug with a 206 Partial Response
David Dick wrote:
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably extend this to a more general solution. :)
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT = 206;
}
sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}
END { }
1;
When I've tried to run your test script under ModPerl::Registry
(mp2.0) I was surprised to learn that it worked just fine. So far I
was fixing the porting bugs ;) I've added your test script to the
ModPerl::Registry test suite.
We better fix it in the 1.0 core. But before that we need to be clear of how
the return codes should be handled, because the currect three implementations
all diverge when it comes to handling the return codes/execution status.
In order to simplify the logic, assuming that the script was
successfully executed and inlining some code, the 3 different registry
implementations resemble the following:
Apache::Registry does:
my $old_status = $r-status;
eval { {$cv}($r, @_) };
return $r-status($old_status);
Apache::PerlRun/RegistryNG do:
my $old_status = $r-status;
eval { {$cv}($r, @_) };
$r-status($old_status);
return OK;
ModPerl::RegistryCooker does:
# handlers shouldn't set $r-status but return it
my $old_status = $self-[REQ]-status;
eval { {$cv}($r, @_) };
my $new_status = $self-[REQ]-status;
# only if the script has changed the status, reset to the old
# status and return the new status
return $old_status != $new_status
? $self-[REQ]-status($old_status)
: OK;
If I'm correct both Apache::PerlRun and Apache::Registry will have
problems in certain situations if we agree that ModPerl::Registry has
the correct logic for handling the execution status. If you can tell
otherwise please give me a test script that doesn't work under
ModPerl::Registry.
But in your particular example, Dick, if you configure the
script to run under Apache::RegistryNG, does it work? If not, that's where the
difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if
it wasn't changed by the script.
__
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
cvs commit: modperl-2.0/lib/Apache Status.pm
stas2003/02/03 23:00:52 Modified:lib/Apache Status.pm Log: of course we don't have 2.00 yet, use 1.99 Revision ChangesPath 1.6 +1 -4 modperl-2.0/lib/Apache/Status.pm Index: Status.pm === RCS file: /home/cvs/modperl-2.0/lib/Apache/Status.pm,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- Status.pm 28 Jan 2003 07:27:48 - 1.5 +++ Status.pm 4 Feb 2003 07:00:52 - 1.6 @@ -9,10 +9,7 @@ # when used with 'no warnings' it still barks on redefinining the # constants - - -# XXX -# use mod_perl 2.0; +use mod_perl 1.99; use Apache::RequestRec (); use Apache::RequestUtil ();
Re: $^T
Perrin Harkins wrote: H Jayakumar wrote: In windows mod_perl-beta2 print $^T; returns the same value again and again That is correct behavior. The $^T variable contains the time that the current program (i.e. apache) started running. If you want the current time, use time() instead. If the beginning of the request is good enough, $r-request_time is better, as it saves a system call. http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlPostReadRequestHandler __ 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: cgi and mod_perl-1.26, Apache-1.27, perl-5.8.0, FreeBSD failwith 'The document contained no data'
Lee Goddard wrote: [...] I don't know: you're doing this: print Content-type: text/plain\n\n; print Hello World\n; Does it (probably not) make any difference if you do a full CRLF, as perldoc perlop: For example, most networking protocols expect and prefer a CR+LF (\015\012 or \cM\cJ) for line terminators, and although they often accept just \012, they seldom tolerate just \015. If you get in the habit of using \n for networking, you may be burned some day. Apache already fixes up \n\n to the right thing. What it really does is identifying the Content-type: header, and then adds the terminating by itself, because it really sends other headers, before adding an empty new line. So it shouldn't matter if you say \r\n\r\n or just \n\n, unless there is a bug. __ 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
cvs commit: modperl-2.0/lib/ModPerl Code.pm
stas2003/02/02 17:18:15
Modified:lib/ModPerl Code.pm
Log:
fix the indentation for the autogenerated files
Revision ChangesPath
1.90 +1 -1 modperl-2.0/lib/ModPerl/Code.pm
Index: Code.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- Code.pm 11 Jan 2003 03:20:54 - 1.89
+++ Code.pm 3 Feb 2003 01:18:15 - 1.90
@@ -62,7 +62,7 @@
my $scfg_get = 'MP_dSCFG(parms-server)';
my $dcfg_get = $scfg_get;\n .
- 'modperl_config_dir_t *dcfg = (modperl_config_dir_t *)dummy';
+ 'modperl_config_dir_t *dcfg = (modperl_config_dir_t *)dummy';
my %directive_proto = (
PerSrv = {
cvs commit: modperl-2.0/src/modules/perl modperl_config.c
stas2003/02/02 22:40:33
Modified:.Changes
src/modules/perl modperl_config.c
Added: t/hooks cleanup.t
t/hooks/TestHooks cleanup.pm
Log:
PerlCleanupHandler implementation + tests
Revision ChangesPath
1.119 +8 -1 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.118
retrieving revision 1.119
diff -u -r1.118 -r1.119
--- Changes 31 Jan 2003 03:15:24 - 1.118
+++ Changes 3 Feb 2003 06:40:33 - 1.119
@@ -10,8 +10,15 @@
=item 1.99_09-dev
+add PerlCleanupHandler implementation + test [Stas]
+
+Apache::Test now can run 'make test' under 'root', without permission
+problems (e.g. when files need to be written), it'll chown all the
+files under t/ to the user chosen to run the server with, before
+running the tests and will restore the permissions at the end. [Stas]
+
die when Apache-request returns nothing ('PerlOptions -GlobalRequest'
-or 'SetHandler modperl' [Stas]
+or 'SetHandler modperl') [Stas]
New Apache::Directive methods: as_hash(), lookup() + tests + docs
[Philippe M. Chiasson [EMAIL PROTECTED]]
1.1 modperl-2.0/t/hooks/cleanup.t
Index: cleanup.t
===
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::TestRequest;
use File::Spec::Functions qw(catfile catdir);
my $vars = Apache::Test::config-{vars};
my $dir = catdir $vars-{documentroot}, hooks;
my $file = catfile $dir, cleanup;
plan tests = 2;
{
# this registers and performs cleanups, but we test whether the
# cleanup was run only in the next sub-test
my $location = /TestHooks::cleanup;
my $expected = 'ok';
my $received = GET_BODY $location;
ok t_cmp($expected, $received, register req cleanup);
}
{
# this sub-tests checks that the cleanup stage was run successfully
# since Apache destroys the request rec after the logging has been
# finished, we have to give it some time to get there
# and fill in the file. (wait 0.25 .. 5 sec)
my $t = 0;
select undef, undef, undef, 0.25
until -e $file -s _ == 10 || $t++ == 20;
unless (-e $file) {
t_debug(can't find $file);
ok 0;
}
else {
open my $fh, $file or die Can't open $file: $!;
my $received = $fh || '';
close $fh;
my $expected = cleanup ok;
ok t_cmp($expected, $received, verify req cleanup execution);
# XXX: while Apache::TestUtil fails to cleanup by itself
unlink $file;
}
}
1.1 modperl-2.0/t/hooks/TestHooks/cleanup.pm
Index: cleanup.pm
===
package TestHooks::cleanup;
# test various ways to push handlers
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use File::Spec::Functions qw(catfile catdir);
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Const -compile = qw(OK DECLINED);
sub get_file {
catdir Apache::Test::config-{vars}-{documentroot}, hooks, cleanup;
}
sub handler {
my $r = shift;
$r-content_type('text/plain');
$r-print('ok');
$r-push_handlers(PerlCleanupHandler = \cleanup2);
return Apache::OK;
}
sub cleanup1 {
my $r = shift;
#warn cleanup CALLED\n;
t_write_file(get_file(), cleanup);
return Apache::OK;
}
sub cleanup2 {
my $r = shift;
#warn cleanup2 CALLED\n;
t_append_file(get_file(), ok);
return Apache::OK;
}
1;
__DATA__
NoAutoConfig
Location /TestHooks::cleanup
SetHandler modperl
PerlCleanupHandler TestHooks::cleanup::cleanup1
PerlResponseHandler TestHooks::cleanup
/Location
/NoAutoConfig
1.62 +4 -1 modperl-2.0/src/modules/perl/modperl_config.c
Index: modperl_config.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.c,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- modperl_config.c 1 Jan 2003 03:45:54 - 1.61
+++ modperl_config.c 3 Feb 2003 06:40:33 - 1.62
@@ -278,6 +278,7 @@
apr_status_t modperl_config_request_cleanup(pTHX_ request_rec *r)
{
+apr_status_t retval;
MP_dRCFG;
if (rcfg-pnotes) {
@@ -285,7 +286,9 @@
rcfg-pnotes = Nullhv;
}
-return APR_SUCCESS;
+retval = modperl_callback_per_dir
Re: about @INC and handlers directory
Iñaki Martínez wrote: Hi!!! Well this is my firts post in this list... I have a server with several domains which each of them has its own handlers, subroutines and there are several common subrutines. What i want to do it is organize the directory structure, so: /modperl/domain_1/ /modperl/domain_2/ /modperl/domain_3/ /modperl/domain_n/ /modperl/common/ Inside of each one, the handler and subroutines of each domain. The the handlers are: PerlHandler domain_1 ... PerlHandler domain_n to use the common subroutines: common::subroutine_n Now my questions: 1) is this directory structure correct??? 2) can it be improve??? 3) security matters? 4) IMPORTANT: how to set the @INC and where any help, tips, URL are welcome The URL is: http://perl.apache.org/docs/ If you have commons subs, you should be fine as long as they live in the files with declared packages. See: http://perl.apache.org/docs/1.0/guide/porting.html#Script_s_name_space Having a separate @INC for each domain is not possible under mod_perl 1.0 (it does work under 2.0), though there are workarounds which may be inadequate for a heavily loaded server. http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ __ 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: [ANNOUNCE] Apache::PAR 0.10
Nathan Byrd wrote: Version 0.10 of Apache::PAR is now available on CPAN at the following location: http://www.cpan.org/authors/id/N/NB/NBYRD/ This version of Apache::PAR now includes preliminary support for both mod_perl 1.x and 2.x environments natively (without Apache::compat). Note, however, this does not guarantee that any modules, registry scripts, etc packaged with Apache::PAR will work under both 1.x and 2.x - wouldn't that be slick. :-) Also, with this version I have continued to use Apache::test for the module testing framework, so make test does not work out of the box under mod_perl 2.x, although it does run with some changes to the generated httpd.conf file (I am hoping to offer a patch for this to the Apache::test author soon). I doubt that would be useful, because the next release of 1.x (where Apache::test resides) won't happen any time soon, and you can't know what other changes will happen in mp2. Instead, include the whole Apache::Test framework (from mod_perl's cvs!) in the distro, and use it. Once it's released on CPAN, you can simply add it as a prerequisite and remove from the distro. It's also very important for people to start using Apache::Test everywhere, so we can sort out the problems and missing features and release it on CPAN asap. __ 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: [patch] Changes to RegistryCooker for subclassing
Nathan Byrd wrote:
All,
To begin with, should proposed mod_perl patches go to
[EMAIL PROTECTED]? The documentation seemed a little unclear in this
case (I decided to play it safe since I didn't run across any messages
on the dev list from outside developers.)
[EMAIL PROTECTED] would be the right place. Also help with the doc would be
*very* appreciated, I've started to write the initial doc, but it's a far away
from being useful.
When I was converting Apache::PAR to work with mod_perl 2.x, one problem
I had was with the way in which ModPerl::RegistryCooker stores member
data. Any subclass of ModPerl::RegistryCooker (in my case, for
Apache::PAR::RegistryCooker) that need to store their own module data
have a problem - they need to pick an array element to store their data
in. Because of the way in which ModPerl::RegistryCooker works
currently, that means hardcoding an array index (because not all array
members are created in new or init). Thus, in
Apache::PAR::RegistryCooker I have a line similar to the following:
use constant PARDATA = 8;
This is not optimal, especially since this has already changed in the
CVS version of RegistryCooker since I started working on it - luckily,
to less members, not more :-)
I propose a change to RegistryCooker.pm so that member data is always
defined in the init sub, so that I could change the above line to
something more like:
use constant PARDATA = -1;
and in my handler, push a new element on after new has been called.
This would keep future changes to the RegistryCooker script from
potentially breaking other modules which must store their own data as
well.
Below is a (small) patch to the CVS version of RegistryCooker.pm to do
this. Down side is that if new member data is added, it would then also
need to be added to the init sub.
If you want to extend the object itself, what we can do is to provide a class
method which will return the current size of the object. I suggest a method,
so sub-classes can be further sub-classable.
package A;
use constant SIZE = 5;
sub object_size { SIZE }
package B;
use constant EXTRA_SIZE = 2;
use base qw(A);
sub object_size { SUPER::object_size + EXTRA_SIZE);
package C;
use constant EXTRA_SIZE = 2;
use base qw(B);
sub object_size { SUPER::object_size + EXTRA_SIZE);
etc...
of course here we cast in stone the implementation of the object as an ARRAY,
which is not so cool.
Alternatively we can provide a function to create accessor methods, which will
transparently handle internal changes.
We could also use the 'fields' pragma, but than we get married to the hash
internals, though apparently an optimized compiled time one. We need it
working for 5.6.1+, is it working fine with 5.6.1?
Pseudohashes are certainly out of question.
__
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
cvs commit: modperl-2.0/lib/Apache Build.pm
stas2003/01/31 23:39:43
Modified:lib/Apache Build.pm
Log:
- create MKPATH make variable as we are going to use it more than once
there is no need to test for the existance of the path, before calling
mkpath(), it does no harm if the dir already exists
- use the MKPATH variable
Revision ChangesPath
1.110 +3 -3 modperl-2.0/lib/Apache/Build.pm
Index: Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.109
retrieving revision 1.110
diff -u -r1.109 -r1.110
--- Build.pm 14 Dec 2002 17:29:34 - 1.109
+++ Build.pm 1 Feb 2003 07:39:43 - 1.110
@@ -1052,14 +1052,14 @@
MODPERL_PIC_OBJS = $(MODPERL_O_PIC_FILES) $(MODPERL_XS_O_PIC_FILES)
+MKPATH = $(MODPERL_PERLPATH) -MExtUtils::Command -e mkpath
+
all: lib
lib: $(MODPERL_LIB)
install:
- $(MODPERL_PERLPATH) -e exit ! -d qq{$(MODPERL_AP_LIBEXECDIR)} || \
- $(MODPERL_PERLPATH) -MExtUtils::Command \
- -e mkpath $(MODPERL_AP_LIBEXECDIR)
+ @$(MKPATH) $(MODPERL_AP_LIBEXECDIR)
$(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \
$(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
Re: [ANNOUNCE] libapreq-1.1 is out
Matt Sergeant wrote: On Thursday, Jan 30, 2003, at 22:36 Europe/London, Stas Bekman wrote: Matt, Apache::Test may not work when run under root, because Apache won't let you start the server as 'User root' so it tries to use 'nobody' or something else as the username the server runs under, which of course has no perms to access files created by root and hence the problem. I suppose the solution is to chown all the autogenerated files to that chosen user and then the issue will be resolved. Meanwhile please try to run the test suite as non-root. That's not enough. Ever tried to run an apache docroot from a directory that the parent directory is not rx by nobody? Doesn't work. It works now with Apache::Test. It chowns all files under the docroot if run under 'root'. Give it a run. But Apache::Request is not yet using Apache::Test. Once it switches to it, it'll transparently work. __ 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: [mp2] +Parent and -Mblib breaks AuthDBI and apache
Christopher Hicks wrote: On Thu, 30 Jan 2003, Stas Bekman wrote: Christopher Hicks wrote: Is there any equivalent to PerlVINC under mod_perl 2? Yes, and it's a built-in solution, rather than a hack: http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ That had me very hopeful, but upon trying it PerlOptions +Parent +SetupEnv PerlSwitches -Mblib=/www/ires-demo/ I continue to get: Cannot find blib even in /www/ires-demo/../../../../.. BEGIN failed--compilation aborted. perl_parse: No such file or directory Ah, that should have been -Mlib, I'll fix that. blib is for testing of unistalled builds. I've read the blib man page a few times and tried to discern what directory structure is expected from looking at a few MakeMaker-based modules, but nothing seems to help. There's a directory in /www/ires-demo/perllib that's a working perl modules directory. It works in several cgi and command line scripts via use lib. Pointing -Mblib directly at the perllib directory and the directory above it do no good. Putting a symlink from lib to perllib also did no good. The other fun was that the previously working AuthDBI is now no longer found with +Parent. This happens regardless of the presense of -Mblib. you need 'PerlModule Apache2' per +Parent, because you get a completely new Perl interpreter, which has a pristine @INC. I'll fix the doc. Alternatively you can use '+Clone', which inherits @INC and other things. I've looked for the t/REPORT script that's planned to be installed in the future. but Red Hat doesn't seem kind enough to include it, so I'll try to provide salient details: [root@dot conf]# rpm -qa | egrep 'mod_perl|httpd|perl-5' perl-libwww-perl-5.65-2 mod_perl-1.99_05-3 perl-5.8.0-55 httpd-2.0.40-11 It's probably a good idea to get the latest mod_perl and httpd, since *many* bugs were fixed and new features added since then. __ 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: [MP2] bug report startup and XML::LibXML
[EMAIL PROTECTED] wrote: Hi ! and as suggested : LIBXML2.DLL VERSION 2.4.26 XML::LibXML version 1.52 I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux and it works just fine. I tested it with libxml2-2.4.23 and XML::LibXML 1.52 and it still segfaults. I can't reproduce the problem, and just looking at the source doesn't click anything. May be try posting your research to p5p? __ 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: Randy Kobe's mod_perl2 all-in-one binary
Lee Goddard wrote: SB It's normal that code loading Apache::* modules doesn't work from the command SB line. This is because it requires mod_perl to be loaded into the program, SB which is not there when run from the command line. I did try with use mod_perl, but it makes no difference. I meant the server with mod_perl loaded. Certainly use mod_perl doesn't make any difference. There is Apache::FakeRequest that tries to emulate the mod_perl env, but it's very incomplete. Hopefully in 2.0 it'll be much better. Not a problem, any more, just curious. Cool. __ 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
cvs commit: modperl-2.0 Makefile.PL
stas2003/01/30 16:52:22 Modified:.Makefile.PL Log: use a portable $(MAKE) instead of just 'make' Revision ChangesPath 1.91 +1 -1 modperl-2.0/Makefile.PL Index: Makefile.PL === RCS file: /home/cvs/modperl-2.0/Makefile.PL,v retrieving revision 1.90 retrieving revision 1.91 diff -u -r1.90 -r1.91 --- Makefile.PL 23 Jan 2003 05:16:30 - 1.90 +++ Makefile.PL 31 Jan 2003 00:52:21 - 1.91 @@ -460,7 +460,7 @@ $(PASSENV) \ $(FULLPERL) -I$(INST_ARCHLIB) -I$(INST_LIB) \ t/TEST - cd ModPerl-Registry make test + cd ModPerl-Registry $(MAKE) test test :: pure_all run_tests test_clean EOF
cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
stas2003/01/30 20:20:20
Modified:src/modules/perl modperl_global.c modperl_global.h
xs/Apache/RequestUtil Apache__RequestUtil.h
xs/tables/current/ModPerl FunctionTable.pm
Log:
expose modperl_global_request (needed in external apps written in XS )
Revision ChangesPath
1.7 +24 -0 modperl-2.0/src/modules/perl/modperl_global.c
Index: modperl_global.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_global.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- modperl_global.c 22 May 2002 18:53:33 - 1.6
+++ modperl_global.c 31 Jan 2003 04:20:20 - 1.7
@@ -26,6 +26,30 @@
MpReqSET_GLOBAL_REQUEST_On(rcfg);
}
+/* get/set */
+request_rec *modperl_global_request(pTHX_ SV *svr)
+{
+request_rec *cur = NULL;
+apr_status_t status = modperl_tls_get_request_rec(cur);
+
+if (status != APR_SUCCESS) {
+/* an internal problem */
+Perl_croak(aTHX_ failed to retrieve the request object);
+}
+
+if (!cur) {
+/* wrong configuration */
+Perl_croak(aTHX_ Global $r object is not available. Set:\n
+ \tPerlOptions +GlobalRequest\nin httpd.conf);
+}
+
+if (svr) {
+modperl_global_request_obj_set(aTHX_ svr);
+}
+
+return cur;
+}
+
void modperl_global_request_obj_set(pTHX_ SV *svr)
{
/* XXX: support sublassing */
1.4 +2 -0 modperl-2.0/src/modules/perl/modperl_global.h
Index: modperl_global.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_global.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- modperl_global.h 4 May 2001 05:49:19 - 1.3
+++ modperl_global.h 31 Jan 2003 04:20:20 - 1.4
@@ -18,6 +18,8 @@
void modperl_global_request_cfg_set(request_rec *r);
+request_rec *modperl_global_request(pTHX_ SV *svr);
+
void modperl_global_request_set(request_rec *r);
void modperl_global_request_obj_set(pTHX_ SV *svr);
1.17 +2 -19 modperl-2.0/xs/Apache/RequestUtil/Apache__RequestUtil.h
Index: Apache__RequestUtil.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/RequestUtil/Apache__RequestUtil.h,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- Apache__RequestUtil.h 31 Jan 2003 03:15:23 - 1.16
+++ Apache__RequestUtil.h 31 Jan 2003 04:20:20 - 1.17
@@ -85,25 +85,8 @@
static MP_INLINE
request_rec *mpxs_Apache_request(pTHX_ SV *classname, SV *svr)
{
-request_rec *cur = NULL;
-apr_status_t status = modperl_tls_get_request_rec(cur);
-
-if (status != APR_SUCCESS) {
-/* an internal problem */
-Perl_croak(aTHX_ failed to retrieve the request object);
-}
-
-if (!cur) {
-/* wrong configuration */
-Perl_croak(aTHX_ Global $r object is not available. Set:\n
- \tPerlOptions +GlobalRequest\nin httpd.conf);
-}
-
-if (svr) {
-modperl_global_request_obj_set(aTHX_ svr);
-}
-
-return cur;
+/* ignore classname */
+return modperl_global_request(aTHX_ svr);
}
static MP_INLINE
1.104 +14 -0 modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm
Index: FunctionTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -r1.103 -r1.104
--- FunctionTable.pm 29 Jan 2003 03:56:00 - 1.103
+++ FunctionTable.pm 31 Jan 2003 04:20:20 - 1.104
@@ -1494,6 +1494,20 @@
'args' = []
},
{
+'return_type' = 'request_rec *',
+'name' = 'modperl_global_request',
+'args' = [
+ {
+'type' = 'PerlInterpreter *',
+'name' = 'my_perl'
+ },
+ {
+'type' = 'SV *',
+'name' = 'svr'
+ }
+]
+ },
+ {
'return_type' = 'SV *',
'name' = 'modperl_dir_config',
'attr' = [
Re: libgtop gone?
--- Stas Bekman [EMAIL PROTECTED] wrote: Mithun Bhattacharya wrote: Tried compilling libgtop on a server without X and got the following. The error message seems to be self explanatory. So give the configure the --without-gnome parameter, what's the big deal? My sincere apologies to Mithun, I've certainly misread his helpful post as an ignorant question :( __ 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: Randy Kobe's mod_perl2 all-in-one binary
[...] Yes, I understand that, which is what confused me. Funny thing is that it (my startup.pl) works from Apache, just not from the command line -- I presume there's something going into @INC I don't know about. It's normal that code loading Apache::* modules doesn't work from the command line. This is because it requires mod_perl to be loaded into the program, which is not there when run from the command line. __ 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: [mp2]
Lee Goddard wrote: Can't locate object method server_root_relative via package Apache at C:/Perl/site/lib/Apache/compat.pm line 68. Also it may mean that you haven't loaded Apache::ServerUtil, in which this method resides. __ 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: mod_perl and mod_cgi problems
Magnar Stav Johanssen wrote: Sending you a piece of my httpd.conf file: [...] looks fine to me. Have you tried looking in the archives? I have found: http://marc.theaimsgroup.com/?l=apache-modperlw=2r=1s=libthread+panicq=b Well, I've used google.com alot, but maybe I didn't push the magic button! No need to google, pick your favorite archive from: http://perl.apache.org/maillist/modperl.html#Searchable_Archives (hint: linked from the menu) In particular: http://marc.theaimsgroup.com/?l=apache-modperlm=91763462706496w=2 For testing I've tuned down my MaxServers to 5 so I easier can trace httpd. In production MaxServers has been tuned for its amount of Memory! http://marc.theaimsgroup.com/?l=apache-modperlm=97363770902299w=2 The latest Linker patch are installed on the server... In that case I hope that somebody else who's on Solaris could step in and help. __ 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: [mp2]
Stas Bekman wrote: Lee Goddard wrote: Can't locate object method server_root_relative via package Apache at C:/Perl/site/lib/Apache/compat.pm line 68. Also it may mean that you haven't loaded Apache::ServerUtil, in which this method resides. no, no, Apache::compat loads it, so it's not 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: [ANNOUNCE] libapreq-1.1 is out
Joe Schaefer wrote: Matt Sergeant [EMAIL PROTECTED] writes: On 28 Jan 2003, Joe Schaefer wrote: libapreq-1.1 is now available on CPAN, and also through the Apache website at http://www.apache.org/dist/httpd/libapreq/libapreq-1.1.tar.gz Failed badly to install for me. First of all it won't install via the CPAN shell as root because the test harness tries to deliver files from what becomes a root-owned directory, and it won't do that. The test suite was lifted directly from mod_perl. Are you able to able to test/install mod_perl using the same approach? Joe, I thought you've reverted to use the old test suite? Matt, Apache::Test may not work when run under root, because Apache won't let you start the server as 'User root' so it tries to use 'nobody' or something else as the username the server runs under, which of course has no perms to access files created by root and hence the problem. I suppose the solution is to chown all the autogenerated files to that chosen user and then the issue will be resolved. Meanwhile please try to run the test suite as non-root. __ 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: [mp2] POD
Thanks again, Randy. I did see those docs, but was confused by the prose. If you find things unclear, please post a patch to improve them. Thanks. __ 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: [ANNOUNCE] libapreq-1.1 is out
Matt Sergeant wrote: [...] It would help to know your platform details. We tried to eliminate all segfaults related to perl-5.8.0, but in the process we may have introduced new ones. perl 5.00503 on RH 6.2 and mod_perl 1.26 IIRC. The segfault was during the file upload tests. And the backtrace is ...? __ 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: [ANNOUNCE] libapreq-1.1 is out
Joe Schaefer wrote: Stas Bekman [EMAIL PROTECTED] writes: Joe, I thought you've reverted to use the old test suite? I did, sorry for the confusion. The test suite in 1.1 is based on Apache::test, not Apache::Test. In any case we need to solve this problem for Apache::Test. I'll take care of 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: cgi and mod_perl-1.26, Apache-1.27, perl-5.8.0, FreeBSD failwith 'The document contained no data'
George Savvides wrote:
Hi all,
I am having problems running cgi scripts under mod_perl. I
realise that this question has been asked before but I have not
been able to find a reference to this particular behaviour in the
manuals or newsgroups.
Problem summary
---
Scripts running under mod_perl fail. Netscape returns the popup
'The document contained no data'
Nothing is printed in the browser window. Scripts that use the
mod_perl api work OK.
Example scripts
---
The cgi script below fails.
#!/usr/bin/perl -w
print Content-type: text/plain\n\n;
print Hello World\n;
The mod_perl api script below works.
my $r = Apache-request;
$r-content_type(text/plain);
$r-send_http_header;
$r-print(Hello World);
Script configuration
Alias /perlbin ${TOP}/perlbin
PerlModule Apache::Registry
Location /perlbin
SetHandler perl-script
Perlhandler Apache::Registry
Options +ExecCGI
allow from all
PerlSendHeader On
/Location
Machine config
--
The cgi script fails on this box:
FreeBSD 4.5-RELEASE-p23
Apache/1.3.27
perl-5.8.0
mod_perl-1.26
The same cgi script with the same script config works fine on
this one:
FreeBSD 4.5-RELEASE-p23
Apache/1.3.20
perl-5.005_03
mod_perl-1.26
It looks as if the CGI script is not returning its stdout to the
browser but I can't for the life of me see why. Any help would
be very much appreciated.
What has error_log to say about this? Do you have the file perms right?
__
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: Help installing mod_perl-1.99_08
Casey Songer wrote: This is probably a stupid question, but I've been searching the documentation for 3 or 4 hours now and I still can't get mod_perl to install. I have mod_perl installed under apache 1.3.26 and have been running that with great success for a couple years, but I am trying to upgrade to apache 2.0.44 with mod_perl 1.99_08. I can get mod_perl to compile, but I can't get apache to include mod_perl when compiling. Here are the steps I tried (trying to follow the steps in the installation documentation): cd httpd-2.0.44 ./configure --enable-ssl --enable-rewrite cd ../mod_perl-1.99_08 perl Makefile.PL MP_AP_PREFIX=/usr/local/src/httpd-2.0.44 MP_INST_APACHE2=1 MP_USE_STATIC=1 make make install cd ../httpd-2.0.40/modules ln -s /usr/local/src/mod_perl-1.99_08/src/modules/perl/ perl cd .. ./config.nice --enable-perl make make install When I do httpd -l mod_perl isn't listed, should it be? I also get errors for things in my apache configuration scripts like PerlHandler and PerlRequire, which I assume means that mod_perl isn't installed. I have read through http://perl.apache.org/docs/2.0/user/intro/start_fast.html and http://perl.apache.org/docs/2.0/user/install/install.html and the docs that came with mod_perl. I apologize if I am missing something obvious here, but any help would be extremely appreciated, including links to more documentation that I can read. What you are missing is that Apache has to be built and installed first. I'll stress that in the docs. __ 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: mod_perl and mod_cgi problems
@(none) @genuity.no wrote: Thanks! I've actually made some kind of progress on this case... I've found a workaround... I don't fully like it, so if anyone got a sugestion for aprovement, please tell me! This was the problem area in my old httpd.conf: (...) AddHandler cgi-script .cgi IfModule mod_perl.c AddHandler perl-script .mpl PerlHandler Apache::Registry /IfModule I've converted it into this: IfModule mod_perl.c AddHandler perl-script .cgi PerlHandler Apache::PerlRun PerlSetVar PerlRunOnce On /IfModule IfModule mod_perl.c AddHandler perl-script .mpl PerlHandler Apache::Registry /IfModule This works fine, but it will only work for perl-scripts and not for shell-scripts. Well, to bad! For the perl-script part it actually runs faster! Apache don't need to fork any new processes to compile the cgi... If I add the following line to my httpd.conf: AddHandler cgi-script .sh This will most likely (not tested) fail like .cgi did when I used cgi-script-handler in apache... So the problem aren't solved yet! Any particular reason for using AddHandler and not SetHandler? __ 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: [MP2] bug report startup and XML::LibXML
[EMAIL PROTECTED] wrote:
Hi
here is a revised complete report bug
and as suggested :
LIBXML2.DLL VERSION 2.4.26
XML::LibXML version 1.52
I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux and it works
just fine.
[...]
output ok but apache segfault
---
here is a complete debug trace (this one is certified exact)
---
source in perl5.8.0\sv.c line 4020
[...]
void
Perl_sv_setpvn(pTHX_ register SV *sv, register const char *ptr,
register STRLEN len)
{
register char *dptr;
SV_CHECK_THINKFIRST(sv); line that makes the segfault
if (!ptr) {
(void)SvOK_off(sv);
return;
}
[...]
Perl_sv_setpvn(interpreter * 0x00d84344, sv * 0xabababab, const
char * 0x28194f90 `string', unsigned int 0) line 4020 + 3 bytes
Perl_sv_vsetpvfn(interpreter * 0x00d84344, sv * 0xabababab,
this looks suspicious as address: 0xabababab, as you have traced it. So it
could be a bug in the ActiveState's perl or is it a standard one?
const char * 0x2818fac0 `string', unsigned int 20, char * *
0x0006efe4, sv * * 0x, long 0, char * 0x) line
7629 + 20 bytes
Perl_vmess(interpreter * 0x00d84344, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1096 + 40 bytes
Perl_vcroak(interpreter * 0x00d84344, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1241 + 17 bytes
Perl_croak(interpreter * 0x00d84344, const char * 0x2818fac0
`string') line 1350 + 17 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x0006f6e8,
clone_params * 0x0006fdf0) line 9297 + 26 bytes
Though the good thing is that it happens on croak (something went wrong). So
perhaps you can check why does it happen in first place. I'd at the above frame.
__
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: [ANNOUNCE] libapreq-1.1 is out
Nathan Byrd wrote: [...] Matt, Apache::Test may not work when run under root, because Apache won't let you start the server as 'User root' so it tries to use 'nobody' or something else as the username the server runs under, which of course has no perms to access files created by root and hence the problem. I suppose the solution is to chown all the autogenerated files to that chosen user and then the issue will be resolved. Meanwhile please try to run the test suite as non-root. [...] I've run into the same problem while testing with Apache::PAR. Unfortunately, I don't think chown'ing the files will work (at least in my case), because the directory itself (/root/.cpanplus on my box) isn't accessible from a non-root user. I haven't worked on a solution yet, but I was thinking the best thing to do might be to create a temp directory (maybe with a prompt for the directory to create it under) from the generated Makefile in the start_httpd section and copy any content (and then remove it in kill_httpd) Maybe this would be a good feature to add to the Apache::test and Apache::Test modules? I've already committed a solution for Apache::Test that should work on all Unices, pending a test on win32. Here is the commit that includes the change and the logic: http://marc.theaimsgroup.com/?l=apache-test-cvsm=104397443526605w=2 At least on Unix mod_perl-2.0 now has no problems running 'make test' as root. As for Apache::test, I'm not familiar with it, so perhaps someone who is, can backport that above patch to 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: [mp2] no PerlVINC?
Christopher Hicks wrote: Is there any equivalent to PerlVINC under mod_perl 2? Yes, and it's a built-in solution, rather than a hack: http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ __ 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
