cvs commit: modperl-2.0/src/modules/perl modperl_util.c modperl_util.h
dougm 02/05/23 15:18:48
Modified:src/modules/perl modperl_util.c modperl_util.h
Log:
add modperl_perl_sv_setref_uv function
Revision ChangesPath
1.42 +8 -0 modperl-2.0/src/modules/perl/modperl_util.c
Index: modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- modperl_util.c19 May 2002 02:10:13 - 1.41
+++ modperl_util.c23 May 2002 22:18:47 - 1.42
-164,6 +164,14
return sv;
}
+/* XXX: sv_setref_uv does not exist in 5.6.x */
+MP_INLINE SV *modperl_perl_sv_setref_uv(pTHX_ SV *rv,
+const char *classname, UV uv)
+{
+sv_setuv(newSVrv(rv, classname), uv);
+return rv;
+}
+
apr_pool_t *modperl_sv2pool(pTHX_ SV *obj)
{
apr_pool_t *p = NULL;
1.33 +3 -0 modperl-2.0/src/modules/perl/modperl_util.h
Index: modperl_util.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.h,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- modperl_util.h13 May 2002 03:17:54 - 1.32
+++ modperl_util.h23 May 2002 22:18:47 - 1.33
-59,6 +59,9
MP_INLINE SV *modperl_ptr2obj(pTHX_ char *classname, void *ptr);
+MP_INLINE SV *modperl_perl_sv_setref_uv(pTHX_ SV *rv,
+const char *classname, UV uv);
+
apr_pool_t *modperl_sv2pool(pTHX_ SV *obj);
char *modperl_apr_strerror(apr_status_t rv);
cvs commit: modperl-2.0/lib/ModPerl WrapXS.pm
dougm 02/05/23 15:19:52
Modified:lib/ModPerl WrapXS.pm
Log:
UV is better than IV for apr_os_thread_t
Revision ChangesPath
1.44 +1 -0 modperl-2.0/lib/ModPerl/WrapXS.pm
Index: WrapXS.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/WrapXS.pm,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- WrapXS.pm 23 May 2002 00:43:35 - 1.43
+++ WrapXS.pm 23 May 2002 22:19:52 - 1.44
-521,6 +521,7
'Apache::RequestRec' = 'T_APACHEOBJ',
'apr_time_t' = 'T_APR_TIME',
'APR::Table' = 'T_HASHOBJ',
+'APR::OS::Thread' = 'T_UVOBJ',
);
sub write_typemap {
cvs commit: modperl-2.0/t/conf modperl_extra.pl
dougm 02/05/23 15:40:48
Modified:lib/APR XSLoader.pm
lib/Apache XSLoader.pm
src/modules/perl mod_perl.c modperl_perl_includes.h
t/conf modperl_extra.pl
Log:
better workaround for 5.6.x DynaLoader vs. XSLoader issue
Revision ChangesPath
1.3 +0 -1 modperl-2.0/lib/APR/XSLoader.pm
Index: XSLoader.pm
===
RCS file: /home/cvs/modperl-2.0/lib/APR/XSLoader.pm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- XSLoader.pm 16 Apr 2002 23:29:18 - 1.2
+++ XSLoader.pm 23 May 2002 22:40:47 - 1.3
-3,7 +3,6
use strict;
use warnings FATAL = 'all';
-use DynaLoader (); #XXX workaround for 5.6.1 bug
use XSLoader ();
BEGIN {
1.3 +0 -1 modperl-2.0/lib/Apache/XSLoader.pm
Index: XSLoader.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/XSLoader.pm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- XSLoader.pm 16 Apr 2002 23:29:18 - 1.2
+++ XSLoader.pm 23 May 2002 22:40:47 - 1.3
-3,7 +3,6
use strict;
use warnings FATAL = 'all';
-use DynaLoader (); #XXX workaround for 5.6.1 bug
use XSLoader ();
BEGIN {
1.118 +8 -0 modperl-2.0/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.117
retrieving revision 1.118
diff -u -r1.117 -r1.118
--- mod_perl.c23 May 2002 17:30:26 - 1.117
+++ mod_perl.c23 May 2002 22:40:47 - 1.118
-119,6 +119,14
newCONSTSUB(PL_defstash, Apache::MPM_IS_THREADED,
newSViv(scfg-threaded_mpm));
+
+#ifdef MP_PERL_5_6_x
+/* make sure DynaLoader is loaded before XSLoader
+ * to workaround bug in 5.6.1 that can trigger a segv
+ * when using modperl as a dso
+ */
+modperl_require_module(aTHX_ DynaLoader, FALSE);
+#endif
}
static void modperl_xs_init(pTHX)
1.12 +5 -1 modperl-2.0/src/modules/perl/modperl_perl_includes.h
Index: modperl_perl_includes.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl_includes.h,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- modperl_perl_includes.h 11 May 2002 18:55:41 - 1.11
+++ modperl_perl_includes.h 23 May 2002 22:40:47 - 1.12
-40,7 +40,11
#include perl.h
#include XSUB.h
-#if (PERL_REVISION == 5) (PERL_VERSION == 6) (PERL_SUBVERSION == 1)
+#if (PERL_REVISION == 5) (PERL_VERSION == 6)
+# define MP_PERL_5_6_x
+#endif
+
+#if defined(MP_PERL_5_6_x) (PERL_SUBVERSION == 1)
# define MP_PERL_5_6_1
#endif
1.16 +3 -0 modperl-2.0/t/conf/modperl_extra.pl
Index: modperl_extra.pl
===
RCS file: /home/cvs/modperl-2.0/t/conf/modperl_extra.pl,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- modperl_extra.pl 18 May 2002 02:14:47 - 1.15
+++ modperl_extra.pl 23 May 2002 22:40:47 - 1.16
-1,3 +1,6
+use Socket (); #test DynaLoader vs. XSLoader workaround for 5.6.x
+use IO::File ();
+
use Apache2 ();
use ModPerl::Util (); #for CORE::GLOBAL::exit
cvs commit: modperl-2.0/src/modules/perl mod_perl.c
dougm 02/05/23 16:01:55 Modified:src/modules/perl mod_perl.c Log: pp_srefgen workaround should be applied to 5.6.x not just 5.6.1 Revision ChangesPath 1.119 +1 -1 modperl-2.0/src/modules/perl/mod_perl.c Index: mod_perl.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v retrieving revision 1.118 retrieving revision 1.119 diff -u -r1.118 -r1.119 --- mod_perl.c23 May 2002 22:40:47 - 1.118 +++ mod_perl.c23 May 2002 23:01:55 - 1.119 -42,7 +42,7 apr_pool_t *p = MP_boot_data.p; \ server_rec *s = MP_boot_data.s -#if defined(USE_ITHREADS) defined(MP_PERL_5_6_1) +#if defined(USE_ITHREADS) defined(MP_PERL_5_6_x) # define MP_REFGEN_FIXUP #endif
cvs commit: modperl-2.0/lib/Apache Build.pm
dougm 02/05/23 16:36:31
Modified:lib/Apache Build.pm
Log:
leave out libperl dep if it isnt found in the properl place
Revision ChangesPath
1.93 +9 -5 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.92
retrieving revision 1.93
diff -u -r1.92 -r1.93
--- Build.pm 23 May 2002 02:35:19 - 1.92
+++ Build.pm 23 May 2002 23:36:31 - 1.93
-940,11 +940,15
print $fh $self-canon_make_attr(lib_$type, $libs{$type});
}
-print $fh $self-canon_make_attr('libperl',
- join '/',
- $self-perl_config('archlibexp'),
- 'CORE',
- $self-perl_config('libperl'));
+my $libperl = join '/',
+ $self-perl_config('archlibexp'), 'CORE', $self-perl_config('libperl');
+
+#this is only used for deps, if libperl has changed, relink mod_perl.so
+#not all perl dists put libperl where it should be, so just leave this
+#out if it isn't in the proper place
+if (-e $libperl) {
+print $fh $self-canon_make_attr('libperl', $libperl);
+}
for my $method (qw(ccopts ldopts inc)) {
print $fh $self-canon_make_attr($method, $self-$method());
cvs commit: modperl-2.0/t/response/TestModperl methodname.pm
dougm 02/05/23 19:33:06
Modified:src/modules/perl modperl_mgv.c
t/response/TestModperl methodname.pm
Log:
if Class-method syntax is used for a Perl*Handler, the :method
attribute is not required (and we had been segfaulting without it)
Revision ChangesPath
1.17 +4 -3 modperl-2.0/src/modules/perl/modperl_mgv.c
Index: modperl_mgv.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_mgv.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- modperl_mgv.c 18 May 2002 01:49:37 - 1.16
+++ modperl_mgv.c 24 May 2002 02:33:06 - 1.17
-303,9 +303,10
if ((gv = gv_fetchmethod(stash, handler_name)) (cv = GvCV(gv))) {
if (CvFLAGS(cv) CVf_METHOD) { /* sub foo : method {}; */
MpHandlerMETHOD_On(handler);
-if (!handler-mgv_obj) {
-modperl_mgv_new_name(handler-mgv_obj, p, HvNAME(stash));
-}
+}
+
+if (MpHandlerMETHOD(handler) !handler-mgv_obj) {
+modperl_mgv_new_name(handler-mgv_obj, p, HvNAME(stash));
}
handler-attrs = (U32)MP_CODE_ATTRS(cv);
1.2 +2 -1 modperl-2.0/t/response/TestModperl/methodname.pm
Index: methodname.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestModperl/methodname.pm,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- methodname.pm 18 May 2002 02:07:42 - 1.1
+++ methodname.pm 24 May 2002 02:33:06 - 1.2
-10,7 +10,8
use TestModperl::method ();
-sub response : method {
+#no : method attribute required when - config syntax is used
+sub response {
TestModperl::method::handler(_);
}
cvs commit: modperl-2.0 Changes
dougm 02/05/23 19:47:01
Modified:.Changes
Log:
update Changes
Revision ChangesPath
1.12 +32 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- Changes 19 May 2002 11:41:53 - 1.11
+++ Changes 24 May 2002 02:47:01 - 1.12
@@ -10,7 +10,39 @@
=item 1.99_02-dev
+added Apache::MPM_IS_THREADED constant
+
+added compat function for Apache::Constants::SERVER_VERSION
+
+added Apache::Constants::export stub for compat
+
+added noop stubs for timeout functions removed from 2.0:
+$r-{soft,hard,reset,kill}_timeout
+
+turned on PerlOptions +GlobalRequest by default for perl-script handler
+unless it is explicitly turned off with PerlOptions -GlobalRequest
+
+added APR::OS::thread_current function
+
+added support for 1.x $r-subprocess_env functionality
+
+added support for $r-push_handlers(PerlHandler = ...)
+
+added support for $r-proxyreq to detect proxy requests
+
+$r-content_type($val) now calls ap_set_content_type underneath
+
add the err_header_out() wrapper to Apache::compat + corresponding tests
+[Stas Bekman]
+
+fix $r-dir_config lookup of values set in the server context
+
+added Apache::REDIRECT shortcut constant
+
+various fixes for method handlers
+
+use Apache::ServerUtil in Apache::compat so Apache-server works in compat
+mode [Dave Rolsky [EMAIL PROTECTED]]
add Apache::Util::unescape_uri alias to Apache::unescape_url in Apache::compat
cvs commit: modperl-2.0/xs typemap
dougm 02/05/23 21:42:57
Modified:xs typemap
Log:
need to use modperl version of sv_setref_uv, since it doesn't exist in
5.6.x
Revision ChangesPath
1.8 +1 -1 modperl-2.0/xs/typemap
Index: typemap
===
RCS file: /home/cvs/modperl-2.0/xs/typemap,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- typemap 23 May 2002 22:19:34 - 1.7
+++ typemap 24 May 2002 04:42:57 - 1.8
-18,7 +18,7
sv_setnv($arg, (NV)($var / APR_USEC_PER_SEC));
T_UVOBJ
- sv_setref_uv($arg, \${ntype}\, (UV)$var);
+ modperl_perl_sv_setref_uv(aTHX_ $arg, \${ntype}\, (UV)$var);
##
INPUT
cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
dougm 02/05/23 22:13:08
Modified:xs/tables/current/ModPerl FunctionTable.pm
Log:
sync
Revision ChangesPath
1.68 +26 -1 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.67
retrieving revision 1.68
diff -u -r1.67 -r1.68
--- FunctionTable.pm 22 May 2002 16:30:40 - 1.67
+++ FunctionTable.pm 24 May 2002 05:13:07 - 1.68
-2,7 +2,7
# !!
# ! WARNING: generated by ModPerl::ParseSource/0.01
-# ! Wed May 22 09:10:46 2002
+# ! Thu May 23 22:06:43 2002
# ! do NOT edit, any changes will be lost !
# !!
-3171,6 +3171,31
{
'type' = 'const char *',
'name' = 'name'
+ }
+]
+ },
+ {
+'return_type' = 'SV *',
+'name' = 'modperl_perl_sv_setref_uv',
+'attr' = [
+ '__inline__'
+],
+'args' = [
+ {
+'type' = 'PerlInterpreter *',
+'name' = 'my_perl'
+ },
+ {
+'type' = 'SV *',
+'name' = 'rv'
+ },
+ {
+'type' = 'const char *',
+'name' = 'classname'
+ },
+ {
+'type' = 'UV',
+'name' = 'uv'
}
]
},
Re: Strange subrequest dir_config issue
Matt Sergeant wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is just a heads up on something I've not seen documented in either the
Eagle book or in the Cookbook (at least not that I can find).
If you create a subrequest via $r-lookup_file(), the per_dir_config entry
doesn't seem to be created. If you use $r-lookup_uri(), it's fine. This can
be an issue for people with complex applications and configurations trying to
find out why $sub-dir_config() might not be returning what they expect.
Took me a while to figure this one out - just thought others might like to
know.
well, I hadn't thought about it until now, but actually that makes sense to me (as
it's
early in the morning here :)
mod_perl just uses r-per_dir_config for $r-dir_config, so it's relying on Apache's
merging behavior wrt lookup_file() and lookup_uri(). one of the things that
lookup_uri()
does that lookup_file() does not do is call location_walk, which merges per-directory
configs.
I think this makes sense, since a single file can be served by multiple Location
containers, and with lookup_file() you're essentially telling Apache that you already
know
the filename (sans the translation phase) and you don't really need to know how it
relates
to the incoming URI. both lookup_file() and lookup_uri() call the File and
Directory
merging routines, so I would expect that calling lookup_file() on files governed by
those
directives would merge just fine.
actually, I ran the below test against my perl-bin/ and cgi-bin/ setups (where
perl-bin is
a Location + Alias and cgi-bin is a Directory + ScriptAlias) and it works as I
suspected.
does this help?
--Geoff
use Apache::Constants qw(OK);
use strict;
my $r = shift;
#my $sub = $r-lookup_file('/usr/local/apache/perl-bin/env.pl');
my $sub = $r-lookup_uri('/perl-bin/env.pl');
$r-send_http_header('text/plain');
print $r-uri, :\n;
$sub-dir_config-do(sub {
my ($field, $value) = _;
print $field = $value\n;
1;
});
return OK;
Re: login.pl not sending cookies via POST?
(I haven't re-tested Apache::AuthCookieDBI.) I have no idea why POST _doesn't_ work, mind you... For what it's worth, my setup with AuthCookieDBI works just fine with POST. -Fran
Re: mod_perl benchmarking (was Re: documenting SetHandler perl-script|modperl)
At 16:41 23.05.2002, David Jacobs wrote: I've had trouble benchmarking some of my mod_perl scripts on my desktop. The http_load tool we usually use (all under RedHat) works fine with static pages or CGI, but when I use it on mod_perl scripts I get a byte count wrong error. This could be because of something unexpected in the header, or perhaps mod_perl doesn't like to be benchmarked? It makes no sense to me either :( What tools do you all use to benchmark web page performace? This should be discussed on the mod_perl users list. See the performance docs, http://perl.apache.org/release/docs/1.0/guide/performance.html And especially the section on Benchmarking applications: http://perl.apache.org/release/docs/1.0/guide/performance.html#Benchmarking_Applications -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: login.pl not sending cookies via POST?
On Thu, May 23, 2002 at 11:21:31AM -0400, Fran Fabrizio wrote: (I haven't re-tested Apache::AuthCookieDBI.) I have no idea why POST _doesn't_ work, mind you... For what it's worth, my setup with AuthCookieDBI works just fine with POST. I agree that is _should_; I've written such things before. My setup is on a Cobalt XTR server, and the vendor's made some _weird_ decisions... But, thanks for the feedback... -Fran -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path
[RFC] Apache::DigestAPI
hi all... I wanted to present Apache::DigestAPI as an RFC. the module can be downloaded here for trials: http://www.modperlcookbook.org/~geoff/modules/Apache-DigestAPI-0.01.tar.gz basically, Apache::DigestAPI is a release of Recipe 13.8 in the Cookbook - a simple API for supporting Digest authentication a la mod_digest.c from the Apache distribution. it follows the same path as the API for Basic authentication that mod_perl supports natively, providing an API so that you can authenticate using something other than the default flat-file method provided by auth_digest. keep in mind that the current implementation doesn't work with MSIE, so you'll have to use something like Opera or Konqueror (or mozilla now, I hear?) to play around with it. you can find the entire RFC for Digest authentication here (if you're interested): ftp://ftp.isi.edu/in-notes/rfc2617.txt included with Apache::DigestAPI is a subclass called Apache::DigestAPI::Session. it is an interesting but experimental interface that attempts to use the nonce part of the Digest authentication scheme to store a unique session identifier (instead of in, say, a cookie). it is experimental because I'm still playing with the interface, digesting RFC 2617, looking for possible security holes, and (in general) seeing if it can actually work like I think it can. but it is there if anyone is interested in playing around with it for fun and folly. anyway, the manpages are pretty sparse for the moment, but I plan on fixing them up before a real release. if anyone is interested in the original explanantion of the code from the book who doesn't already have it, you can see Recipe 13.8 here: http://www.modperlcookbook.org/chapters/13.8.pdf --Geoff
Re: [RFC] Apache::DigestAPI
Hello, GYApache::DigestAPI is a release of Recipe 13.8 in the Cookbook - a simple GYAPI for supporting Digest authentication a la mod_digest.c from the GYApache distribution. I think this is a great idea. I'm a huge fan of digest authentication as a simple basic authentication replacement, and many modern clients now support it. One comment, why the odd name? Shouldn't it be Apache::AuthDigest or similar? Every library is an API so it seems kind of odd to call it Apache::DigestAPI. GYkeep in mind that the current implementation doesn't work with MSIE, so GYyou'll have to use something like Opera or Konqueror (or mozilla now, I GYhear?) to play around with it. MSIE does do digest authentication that works with mod_digest.c. And Mozilla past 0.9.7 should do digest authentication. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: [RFC] Apache::DigestAPI
Andrew Ho wrote: Hello, GYApache::DigestAPI is a release of Recipe 13.8 in the Cookbook - a simple GYAPI for supporting Digest authentication a la mod_digest.c from the GYApache distribution. I think this is a great idea. I'm a huge fan of digest authentication as a simple basic authentication replacement, and many modern clients now support it. One comment, why the odd name? Shouldn't it be Apache::AuthDigest or similar? Every library is an API so it seems kind of odd to call it Apache::DigestAPI. well, it's an API in that it doesn't do anything for you except provide an API. meaning, I'd expect Apache::AuthDigest to work as so: PerlAuthenHandler Apache::AuthDigest all this module does is provide methods that parallel $r-get_basic_auth_pw() and $r-note_basic_auth_failure - you need to use the methods yourself to build an actual authentication mechanism. GYkeep in mind that the current implementation doesn't work with MSIE, so GYyou'll have to use something like Opera or Konqueror (or mozilla now, I GYhear?) to play around with it. MSIE does do digest authentication that works with mod_digest.c. And Mozilla past 0.9.7 should do digest authentication. are you sure? I can't get it to work right now using MSIE 5.00.31. in fact, I can confirm that Apache sends the 401, but MSIE doesn't even display a dialogue box. Opera works just fine. when I was researching this for the book, it was my understanding that MSIE requires parameters not supplied by mod_digest.c (such as qop) for it's implementation. some old threads on new-httpd on mod_auth_digest.c pointed me in this direction, IIRC. then there was this recent article: http://www.eweek.com/article/0,3658,s=702a=24177,00.asp which, even though it seemed to confirm what I had found out, suprised me somewhat, since I figured it was old news that MSIE and Apache's standard (for lack of a better term) Digest implementation didn't play nice together... --Geoff
Re: [RFC] Apache::DigestAPI
Hello, GYwell, it's an API in that it doesn't do anything for you except provide GYan API. meaning, I'd expect Apache::AuthDigest to work as so: GY GYPerlAuthenHandler Apache::AuthDigest GY GYall this module does is provide methods that parallel GY$r-get_basic_auth_pw() and $r-note_basic_auth_failure - you need to GYuse the methods yourself to build an actual authentication mechanism. I just commented this because it would make more sense to me as someone looking to implement digest authentication in Perl if an Apache::AuthDigest module existed which WAS useable directly as a PerlAuthenHandler (with a configuration API identical or similar to mod_digest.c), and the API came bundled with it if you wanted to use it directly. I could imagine there being a different namespace (I want the methods, so I use Apache::AuthDigest::API), or Deep Perl Magick (when I use Apache::AuthDigest::API in a handler or an Apache::Registry script, $r-note_basic_auth_failure() suddenly just works because someone mucked with Apache's namespace), or some permutation thereof (when I have Apache::AuthDigest as a PerlAuthenHandler, $r-note_basic_auth_failure() just works in any associated mod_perl handlers or scripts). That would mean that you could just download one package, with a name one would expect when asking the question how can I implement digest authentication in a mod_perl enabled server without recompiling Apache? On a totally different note, I can't seem to get this module to load properly at build time: % perl Makefile.PL % make % perl -Mblib -MApache::DigestAPI -e0 Can't locate loadable object for module Apache::DigestAPI in @INC (@INC contains: /home/andrew/install/pm/Apache-DigestAPI-0.01/blib/arch /home/andrew/install/pm/Apache-DigestAPI-0.01/blib/lib /usr/libdata/perl5/i386-openbsd/5.6.1 /usr/local/libdata/perl5/i386-openbsd/5.6.1 /usr/libdata/perl5 /usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/local/lib/perl5/site_perl .) at -e line 0 This is on OpenBSD 3.1, with Perl 5.6.1. After installing the module anyway and trying it inside mod_perl itself, I get a similar error in the server error_log: [Thu May 23 14:21:30 2002] [error] Can't locate loadable object for module Apache::DigestAPI in @INC (@INC contains: /home/andrew/pm/Zeuscat-Addressbook/blib/arch /home/andrew/pm/Zeuscat-Addressbook/blib/lib /usr/local/encap/mod_perl-1.26/lib/site_perl/5.6.1/i386-openbsd /usr/libdata/perl5/i386-openbsd/5.6.1 /usr/local/libdata/perl5/i386-openbsd/5.6.1 /usr/libdata/perl5 /usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/local/lib/perl5/site_perl . /home/andrew/httpd/ /home/andrew/httpd/lib/perl) at /var/www/htdocs/zeuscat.com/andrew/test/digest/digest.pl line 9 Compilation failed in require at /var/www/htdocs/zeuscat.com/andrew/test/digest/digest.pl line 9. BEGIN failed--compilation aborted at /var/www/htdocs/zeuscat.com/andrew/test/digest/digest.pl line 9. I also note that during building, I end up with a Session.so in blib/arch, but after doing make install, Session.so disappears. There is also an DigestAPI.xs that gets copied into blib/lib/Apache, which seems fishy. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
DBI modperl_2 Segmentation fault
hi sorry, my english dont is good ;) i have one big problem, i using apache2, modperl2 and perl 5.6.1 Apache/2.0.37-dev (Unix) mod_perl/1.99_02-dev Perl/v5.6.1 when i add this line in httpd.conf PerlModule DBI or Perlrequire startup.conf startup.conf: use DBI; 1; if i use it, httpd don't start, i receive this error: /usr/local/apache-2.0/bin/apachectl: line 192: 32646 Segmentation fault (core dumped) $HTTPD /usr/local/apache-2.0/bin/apachectl start: httpd could not be started :// i test in perl 5.7.3 and other versions of modperl 2 and httpd 2 if i try use DBI; in any file.pl and request via http i dont receve any problem :/ problem is, why DBI crash apache ? thanks nattis
Re: DBI modperl_2 Segmentation fault
sounds like the XSLoader vs. DynaLoader issue which only exists in 5.6.x. try updating modperl-2.0-cvs, there is a better workaround in there for the issue now.
Re: [RFC] Apache::DigestAPI
Andrew Ho wrote: Hello, GYwell, it's an API in that it doesn't do anything for you except provide GYan API. meaning, I'd expect Apache::AuthDigest to work as so: GY GYPerlAuthenHandler Apache::AuthDigest GY GYall this module does is provide methods that parallel GY$r-get_basic_auth_pw() and $r-note_basic_auth_failure - you need to GYuse the methods yourself to build an actual authentication mechanism. I just commented this because it would make more sense to me as someone looking to implement digest authentication in Perl if an Apache::AuthDigest module existed which WAS useable directly as a PerlAuthenHandler (with a configuration API identical or similar to mod_digest.c), and the API came bundled with it if you wanted to use it directly. hmmm. ok, lemme think on that. in general, I don't think there are many mod_perl modules out there that re-implement default Apache functionality, so it was never my intent to redo mod_digest in Perl. also, all of the other Apache::Auth* modules seem to be specific authentication schemes (Raduis, SMB, DBI, etc). what I was trying to do was create a way for people to be able to do the same thing for Digest auth, since there is no way now. hence the API designation - I'm really just extending the mod_perl API proper here... I could imagine there being a different namespace (I want the methods, so I use Apache::AuthDigest::API), ok. or Deep Perl Magick (when I use Apache::AuthDigest::API in a handler or an Apache::Registry script, $r-note_basic_auth_failure() suddenly just works because someone mucked with Apache's namespace), or some permutation thereof (when I have Apache::AuthDigest as a PerlAuthenHandler, $r-note_basic_auth_failure() just works in any associated mod_perl handlers or scripts). yucko. personally I hate action-at-a-distance behaviors. That would mean that you could just download one package, with a name one would expect when asking the question how can I implement digest authentication in a mod_perl enabled server without recompiling Apache? On a totally different note, I can't seem to get this module to load properly at build time: % perl Makefile.PL % make % perl -Mblib -MApache::DigestAPI -e0 I'll look more closely at this tomorrow, but I don't expect that would ever work, as note_digest_auth_failure() is really part of the Apache API (stolen via XS) and needs a real request object. try $ make test and see if the live tests (via Apache::Test) work. (a good time to check out the httpd-test project, no? :) Can't locate loadable object for module Apache::DigestAPI in INC (INC contains: /home/andrew/install/pm/Apache-DigestAPI-0.01/blib/arch /home/andrew/install/pm/Apache-DigestAPI-0.01/blib/lib /usr/libdata/perl5/i386-openbsd/5.6.1 /usr/local/libdata/perl5/i386-openbsd/5.6.1 /usr/libdata/perl5 /usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/local/lib/perl5/site_perl .) at -e line 0 This is on OpenBSD 3.1, with Perl 5.6.1. After installing the module anyway and trying it inside mod_perl itself, I get a similar error in the server error_log: [Thu May 23 14:21:30 2002] [error] Can't locate loadable object for module Apache::DigestAPI in INC (INC contains: /home/andrew/pm/Zeuscat-Addressbook/blib/arch /home/andrew/pm/Zeuscat-Addressbook/blib/lib /usr/local/encap/mod_perl-1.26/lib/site_perl/5.6.1/i386-openbsd /usr/libdata/perl5/i386-openbsd/5.6.1 /usr/local/libdata/perl5/i386-openbsd/5.6.1 /usr/libdata/perl5 /usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/local/lib/perl5/site_perl . /home/andrew/httpd/ /home/andrew/httpd/lib/perl) at /var/www/htdocs/zeuscat.com/andrew/test/digest/digest.pl line 9 Compilation failed in require at /var/www/htdocs/zeuscat.com/andrew/test/digest/digest.pl line 9. BEGIN failed--compilation aborted at /var/www/htdocs/zeuscat.com/andrew/test/digest/digest.pl line 9. hmm. I'll take a look. I have no problem using it from either Apache::Test or my local installation, but I may have missed something simple. I'm on linux, fwiw. try copying the config in t/conf/extra.conf.in and see if that works - you may need to pre-load the module specifically via PerlModule and not a use in startup.pl... I also note that during building, I end up with a Session.so in blib/arch, but after doing make install, Session.so disappears. There is also an DigestAPI.xs that gets copied into blib/lib/Apache, which seems fishy. I have no idea on either count - I'm trusting ExtUtils::MakeMaker entirely here, which is really a pot of black magic. anyway, as I said, I'll look more into it tomorrow. thanks for the feedback, though. much
Carp interaction with mod_perl
How does the Carp module interact with mod_perl? Is there a built-in catch for croak or does it actually kill the child process, for instance? Thanks, Christian - Christian Gilmore Technology Leader GeT WW Global Applications Development IBM Software Group
Re: compatibility problem
On Wed, 22 May 2002, Doug MacEachern wrote:
On Thu, 23 May 2002, Jie Gao wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 15349)]
0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134
134 if (!symbol-hash) {
(gdb) bt
#0 0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134
#1 0x403103ed in modperl_callback (handler=0x83dcd68, p=0x83d3438, r=0x83d3470,
s=0x80d1540, args=0x8131110)
at modperl_callback.c:19
this is with modperl-2.0 from cvs? if you have a simple test case to
reproduce, that would help. looks related to method handlers based on
your stacktrace.
I have found the following:
In httpd.conf:
Directory /export/softwares # Document root.
Options All
AllowOverride All
Order allow,deny
allow from all
/Directory
Segmentation fault happens when accessing /export/softwares/data, a
subdirectory which does not have an .htaccess file itself, but a
subdirectory of which has an .htaccess file containing:
IndexOptions FancyIndexing NameWidth=* ScanHTMLTitles IconsAreLinks
PerlAuthenHandler XXX::AuthCookieHandler-authen
PerlAuthzHandler XXX::AuthCookieHandler-authz
AuthType XXX
AuthName XXX
PerlSetVar AuthenLoginPageLocation 'https://xxx.xxx.xxx.xx/login.cgi'
PerlSetVar VirtualServerName xxx.xxx.xxx.xxx.
PerlSetVar AuthCookieDebug 0
PerlSetVar TimeOut 10
require group /export/softserv/acl/nero
ErrorDocument 403 /server_response/software_403.html
Changing AllowOverride All to AllowOverride None does not incur
a Segmentation fault.
The .htaccess file might have a problem, but having a problem accessing
the parent directory makes it very hard to debug.
Regards,
Jie
[mp2] Building with Perl 5.6.1 dies
Hi, sorry if this has already been discussed, just point me to archives then. I'm building a last night CVS checkout of mod_perl 2 against a last night CVS checkout of apache 2 and Per 5.6.1. Here's what happens: morris@melchior:/usr/src/modperl-2.0 perl Makefile.PL MP_APXS=/home/httpd2/bin/apxs Reading Makefile.PL args from ARGV MP_APXS = /home/httpd2/bin/apxs Configuring Apache/2.0.37-dev mod_perl/1.99_02-dev Perl/v5.6.1 [snip: writing a lot of makesfiles, all seems well] morris@melchior:/usr/src/modperl-2.0 make cd src/modules/perl make make: don't know how to make /usr/libdata/perl5/i386-openbsd/5.6.1/CORE/libperl.so.6.1. Stop in /usr/src/modperl-2.0/src/modules/perl. *** Error code 2 Dies at the first make command... Error in the makefile? Perl too old? I have no idea, clue me in. Thanks in advance, Axel Andersson
Re: compatibility problem
On Fri, 24 May 2002, Jie Gao wrote: Segmentation fault happens when accessing /export/softwares/data, a subdirectory which does not have an .htaccess file itself, but a subdirectory of which has an .htaccess file containing: hmm. you might want to try building modperl with MP_DEBUG=1 and configure 'PerlTrace all' in httpd.conf which might give some clues to what the problem is.
Re: Proxied mod_perl server problem
upgrade to cvs version of apache on the proxy. cvs version solveds this problem.
best regards,
On Mon, May 13, 2002 at 06:57:07PM +1000, Ian Macdonald wrote:
Hi All.
I'm setting up a new server and wish to run two Apache configurations,
one vanilla and one mod_perl. I've configured pretty much according to
Stas' excellent guide, using the rewrite module to push the perl
requests to the second (ie mod_perl) server.
Versions; HP-UX 10.20, Apache 1.3.24, mod_perl 1.26.
It's _nearly_ working, but I'm getting one weird piece of behaviour
which looks to me like the sort of problem someone with more experience
will recognise very swiftly; when I request a perl script via the
mod_perl-enabled locations, the content is preceded by a hex number,
which corresponds very closely to the size of the content, and then a
blank line, as shown below:
4e9
PID = 3282
DOCUMENT_ROOT=/opt/web_root/html
GATEWAY_INTERFACE=CGI-Perl/1.1
etc.
The browser displays the wait cursor for about 15 seconds and then
follows the content (which is correct) with another blank line and then
a zero:
...
SERVER_SOFTWARE=Apache/1.3.24 (Unix) mod_perl/1.26
TZ=EST-10EDT
0
The script works correctly from the command line, or if the mod_perl
server port is accessed directly from the browser, or if the mod_perl
server is started without proxying enabled.
This looks to me as if two parts of the system are contributing the same
header information, or if two protocol layers are being added in the
wrong order, or something like that.
Thanks for any tips.
Ian Macdonald
[EMAIL PROTECTED]
Here's the rewrite config chunk from the main apache:
RewriteEngine On
RewriteLogLevel0
RewriteRule ^proxy:.* - [F]
RewriteRule ^/perl/(.*) http://%{HTTP_HOST}:8200/perl/$1 [P,L]
RewriteRule ^/cgi-perl/(.*) http://%{HTTP_HOST}:8200/cgi-perl/$1 [P,L]
ProxyPassReverse / http://%{HTTP_HOST}/
Here's the /perl/ location config from the mod_perl apache
Location /perl/*.pl
SetHandler perl-script
PerlHandler Apache::Registry
Options -Indexes ExecCGI
PerlSendHeader On
/Location
--
Pedro Melo Cunha - [EMAIL PROTECTED]
Novis Telecom, S.A. - Dir. Rede - ISP http://www.novis.pt/
Edifício Novis - Estrada da Outurela, 118 - 2795-606 Carnaxide
tel: +351 21 0104340 - fax: +351 21 0104301
cvs commit: modperl/lib/Apache Status.pm
dougm 02/05/23 09:00:59
Modified:lib/Apache Status.pm
Log:
make it possible to configure the registry cache via
Apache::Status-registry_cache(\%cache);
Revision ChangesPath
1.25 +15 -2 modperl/lib/Apache/Status.pm
Index: Status.pm
===
RCS file: /home/cvs/modperl/lib/Apache/Status.pm,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- Status.pm 31 Mar 2000 18:19:48 - 1.24
+++ Status.pm 23 May 2002 16:00:59 - 1.25
-1,7 +1,7
package Apache::Status;
use strict;
-$Apache::Status::VERSION = '2.02';
+$Apache::Status::VERSION = '2.03';
my %is_installed = ();
my $Is_Win32 = ($^O eq MSWin32);
-180,13 +180,26
\@retval;
}
+my $RegistryCache;
+
+sub registry_cache {
+my($self, $cache) = _;
+
+if ($cache) {
+$RegistryCache = $cache;
+}
+
+$RegistryCache || $Apache::Registry;
+}
+
sub status_rgysubs {
my($r,$q) = _;
my(retval);
local $_;
my $uri = $r-uri;
+my $cache = __PACKAGE__-registry_cache;
push retval, bClick on package name to see its symbol table/bp\n;
-foreach (sort keys %{$Apache::Registry}) {
+foreach (sort keys %$cache) {
push retval,
qq(a href=$uri?$_$_/a\n),
br;
