Re: [mp2] win2000 + Apache::DBI + Oracle
Perrin Harkins wrote: On Tue, 2003-06-10 at 01:45, Stas Bekman wrote: mp2+winFU => winnt MPM => no forking, only threads => Apache::DBI is useless there. not only useless, but also wasteful, since it's going to do work that has no added value. But how is this any different from separate processes really? Each thread is a separate interpreter with separate globals and this separate Apache::DBI persistent handles. If things are not threadsafe it crashes, but if they are it should work just like it does for multi-process apache, shouldn't it? I think you are right. I was thinking about pooling across threads. If somebody can give it a try and report back (use debug mode to see what happens) that would be the simplest check. connect_on_init() should probably be not used. __ 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] win2000 + Apache::DBI + Oracle
On Tue, 2003-06-10 at 01:45, Stas Bekman wrote: > mp2+winFU => winnt MPM => no forking, only threads => Apache::DBI is useless > there. not only useless, but also wasteful, since it's going to do work that > has no added value. But how is this any different from separate processes really? Each thread is a separate interpreter with separate globals and this separate Apache::DBI persistent handles. If things are not threadsafe it crashes, but if they are it should work just like it does for multi-process apache, shouldn't it? - Perrin
Re: [mp2] win2000 + Apache::DBI + Oracle
Perrin Harkins wrote: On Mon, 2003-06-09 at 21:02, Stas Bekman wrote: Paul Simon wrote: So, according to the docs, http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM, using Apache::DBI doesn't do anything under mp2+windows2000 ... That's correct. Since Apache::DBI does per-process pooling, and apache 2.0 on winFU, runs one process with many threads. So Apache::DBI is useless there. Wait a minute, it's only useless if DBI and DBD::Oracle are not thread safe. Do we know if that's true? Yes, but: mp2+winFU => winnt MPM => no forking, only threads => Apache::DBI is useless there. not only useless, but also wasteful, since it's going to do work that has no added value. Of course I tell all that without ever using winFU, but I don't think this is a wrong assumption if the server doesn't fork. Just to be clear, Apache::DBI stores database handles in globals, which are not shared between threads. This provides persistence. DBI::Pool is a more ambitious idea to allow the handles to be actually shared, providing "pooling" as well as persistence. Once DBI::Pool will be available, Apache::DBI may use it internally, or it may become obsolete altogether. But since you are using Oracle, if I remember correctly DBD::Oracle provides an internal pooling support. I could be wrong, please check the docs. It's called ora_dbh_share. I haven't tried it yet, and probably won't for a bit since I'm not using Oracle at the moment. __ 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] win2000 + Apache::DBI + Oracle
On Mon, 2003-06-09 at 21:02, Stas Bekman wrote: > Paul Simon wrote: > > So, according to the docs, > > http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM, > > using Apache::DBI doesn't do anything under > > mp2+windows2000 ... > > That's correct. Since Apache::DBI does per-process pooling, and apache 2.0 on > winFU, runs one process with many threads. So Apache::DBI is useless there. Wait a minute, it's only useless if DBI and DBD::Oracle are not thread safe. Do we know if that's true? Just to be clear, Apache::DBI stores database handles in globals, which are not shared between threads. This provides persistence. DBI::Pool is a more ambitious idea to allow the handles to be actually shared, providing "pooling" as well as persistence. > But since you are using Oracle, if I remember correctly DBD::Oracle provides > an internal pooling support. I could be wrong, please check the docs. It's called ora_dbh_share. I haven't tried it yet, and probably won't for a bit since I'm not using Oracle at the moment. - Perrin
Re: [mp2] make test fails with 1.99_10-dev sources on redhat
On Mon, 2003-06-09 at 09:55, Haroon Rafique wrote: > Now onto serious stuff. /usr/bin/perl here is the system-wide perl install > that came bundled with Redhat. Just a thought: did you fix the locale on that machine? Most of CPAN won't compile on Red Hat 8 and 9 because of the broken UTF8 locale setting they have. If you haven't already, edit /etc/sysconfig/i18n and change LANG="en_US.UTF-8" to LANG="en_US.ISO8859-1". That fixed many mysterious things for me. - Perrin
ANNOUNCE: Embperl 2.0b9
The URL ftp://ftp.dev.ecos.de/pub/perl/embperl/Embperl-2.0b9.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GR/GRICHTER/Embperl-2.0b9.tar.gz size: 654860 bytes md5: 3a4836d15100feb2bf9c37e9470a1d1d While development has continued all the time, there was a long time no release of Embperl, so it's really overdue. This version fixes a number of bugs and adds a lot of enhancements. My plan is to make the next release the final 2.0. So give it a try, so we can catch as much problems as possible before. Embperl is a system for building dynamic websites with Perl. It gives you the power to embed Perl code in your HTML/XML documents and the ability to build your Web site out of small reusable objects in an object-oriented style. You can also take advantage of all the usual Perl modules, (including DBI for database access) use their functionality and easily include their output in your web pages. Embperl has several features which are especially useful for creating Websites, including dynamic tables, form field processing, URL escaping/unescaping, session handling, caching, xslt transformation and more. See http://perl.apache.org/embperl/ (english) or http://www.ecos.de/embperl/ (german) for more information. Enjoy Gerald Changes since 2.0b8: - libxml now searchs through Embperl search path when includeing external entities, so for example directives searchs files the same way as Execute does under Embperl::Object. - fixed typo in JavaScript code for Form::Validate reported by Axel Beckert - fixed typo in Embperl::Mail reported by Axel Beckert. - fixed small bugs in Embperl::Form::Validate test code reported by Axel Beckert. - charcters 128-160 are now escaped in URLs to avoid problems with Mozilla. - fixed missing escaping of '/' in Embperl::Form::Validate JS routines. Patch from Axel Beckert. - fixed spelling: CACKE_KEY -> CACHE_KEY. Reported by Andre Landwehr. - URL escaping now fully conforms to RFC 2396. This mainly solves some problems where IE interpreted characters in URLs as UTF8. - Embperl::Form::Validate JavaScript code can now handle fieldnames that aren't correct JavaScript identifier. - Fix SIGSEGV when printing to Embperl::LOG before Embperl log file is setup. - Fix problem when session id is given to Embperl, but session management was not setup - Added 'same' validation to check if two fileds have the same input enterd - Fixed memory leak. Patch from Joshua Chamas. - Use MP_AP_PREFIX as source for APache 2. Patch from Paul Dyer. - Fixed a initialisation bug which caused under special conditions a segfault when compiling a select tag. - Fixed compiler warnings and errors when compiling with Perl 5.8.0. - Replaced PL_sv_undef with ep_sv_undef (which is a copy of PL_sv_undef), because storing PL_sv_undef in a Perl 5.8.0 hash is treated as a placeholder and doesn't work as before. - Fixed problem with [$ sub $] when running under Perl 5.8.0. - Fixed problem when STDOUT is tied, because storage has changed in Perl 5.8.0. - Fixed problem when single quote or backslash is inside of option or input value. Bug reported by Saadiq Rodgers-King. - Added [$last$], [$next$], [$redo$] and documented [* next *] etc. - Readdeded missing MailFormTo and added test for it. - Fixed escaping inside of html attributes of Embperl generated tags like input and [$ hidden $]. Reported by Axel Beckert. - checked and selected attributes are now correctly set when values contains entities (e.g. <) - Fixed segfault when cleanup is called to early. Reported by Neil Gunton. - If no name is given for a key, Form::Validate now tries to lookup the correct text via Embperl's gettext method. - Fixed problem with message ids that are Perl keywords. Reported by Jaak. - Added EMBPERL_COOKIE_SECURE option to transfer cookie only over a secure connection. - Added EMBPERL_OUTPUT_MODE that allows to change to XML output, which cause generated tags to contains a closing slash, so they are valid XML/XHTML. - Fixed make test to ignore different idention of newer versions of libxslt. - Added server_addr to the request param object. - Keep spaces and newlines in tag. - Embperl::Mail now encodes all header fields that contains characters between 128 and 255. Use headerencoding parameter to turn of or tell Embperl your charset. - Fixed mod_perl 2 detection when mod_perl is build with MP_INST_APACHE2. - Fixed problem with reseting $escmode, when using print OUT. Reported by David Hull. - Fixed compiling problem on FreeBSD. - Added function XML::Embperl::DOM::iSetText to change name of Tag. Requested by Yatin Chawathe. - EMBPERL_COOKIE_EXPIRES now again accepts relatives times like +2h. - embpexec.pl now correctly takes config values from environment for application object. - Added -type => Integer, IPAd
testing your CPAN modules with Apache::Test and both mod_perl generations
Just in case you didn't know, you can use Apache::Test for testing your code
with both mod_perl generations. It certainly helps to automate the testing.
For example I use the following simple smoker script to run the test suite on
Apache::Peek with different versions of perl and mod_perl.
Kudos to Barrie Slaymaker for the wonderful IPC::Run.
BTW, Philippe has a more advanced smoker (with much better reporting) but he
won't let it to see the light before he makes it perfect ;)
For more info on Apache-Test see Geoff's article:
http://www.perl.com/pub/a/2003/05/22/testing.html
and the online manual:
http://perl.apache.org/docs/general/testing/testing.html
--
#!/usr/bin/perl
use strict;
use warnings;
use IPC::Run qw(run timeout);
use constant TIMEOUT => 5*60;
use constant DEBUG => 0;
$SIG{INT} = sub { report(); exit; };
my %report = (ok => 0, nok => 0, failed => {});
my $test = 0;
while () {
next if /^\s*(#.*|$)/;
chomp;
run_test($_);
}
report();
sub run_test {
my $command = shift;
my @cmds = split /\s*&&\s*/, $command;
$test++;
my $cnt = 0;
my $failed = 0;
for my $cmd (@cmds) {
next unless $cmd =~ /\S/;
$cnt++;
print "[$test.$cnt] $cmd\n";
my @cmd = split /\s+/, $cmd;
my($in, $out, $err);
my $ok = 0;
eval {
$ok = run [EMAIL PROTECTED], \$in, \$out, \$err,
debug => DEBUG, timeout(TIMEOUT);
};
warn "[EMAIL PROTECTED]" if $@;
$ok = 1 if $cmd =~ /make clean/; # ignore 'make clean' errors
unless ($ok) {
print "\n\tFAILURE!\n\n";
print "STDOUT:\n$out\n" if $out;
print "STDERR:\n$err\n" if $err;
push @{ $report{failed}{$command} }, "($cnt) $cmd";
$failed++;
last;
}
if (@cmd == 2 && $cmd[0] eq 'make' && $cmd[1] eq 'test') {
my $result = $out =~ /All tests successful/ ? "OK" : "NOT OK";
print "\n\t$result\n\n";
}
}
$failed ? $report{nok}++ : $report{ok}++;
print "\n", "-" x 40, "\n\n";
}
sub report {
my $format = "%-7s: %3d\n";
printf $format, "Success", $report{ok};
printf $format, "Failure", $report{nok};
print "-" x 16, "\n";
printf $format, "Total", $report{ok}+$report{nok};
my @failed = keys %{ $report{failed} };
if (@failed) {
print join "\n", '',
"Failed commands:", "-" x 16,
map { join("\n\t", $_, @{ $report{failed}{$_}||[] }),"\n"} @failed;
}
}
__DATA__
# need to test all these combinations
### mp2 DSO ###
make clean && /usr/bin/env CCFLAGS="-g" perl-5.6.1 Makefile.PL -httpd
/home/stas/httpd/prefork/bin/httpd -libmodperl
/home/stas/httpd/prefork/modules/mod_perl-5.6.1.so -port select MOD_PERL=2 &&
make && make test
make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.0 Makefile.PL -httpd
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-5.8.0.so -port select
MOD_PERL=2 && make && make test
make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.0-ithread Makefile.PL -httpd
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-5.8.0-ithread.so -port
select MOD_PERL=2 && make && make test
make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.1 Makefile.PL -httpd
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-5.8.1.so -port select
MOD_PERL=2 && make && make test
make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.1-ithread Makefile.PL -httpd
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-5.8.1-ithread.so -port
select MOD_PERL=2 && make && make test
make clean && /usr/bin/env CCFLAGS="-g" perl-blead Makefile.PL -httpd
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-blead.so -port select
MOD_PERL=2 && make && make test
make clean && /usr/bin/env CCFLAGS="-g" perl-blead-ithread Makefile.PL -httpd
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-blead-ithread.so -port
select MOD_PERL=2 && make && make test
### worker 2.0 ###
make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.1-ithread Makefile.PL -httpd
/home/stas/httpd/worker/bin/httpd -libmodperl mod_perl-5.8.1-ithread.so -port
select MOD_PERL=2 && make && make test
### mp1 NON-DSO ###
#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.00503 Makefile.PL -httpd
/home/httpd/httpd_perl/bin/httpd-5.00503 -port select MOD_PERL=1 && make &&
make test
#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.6.1-ithread Makefile.PL -httpd
/home/httpd/httpd_perl/bin/httpd-5.6.1-ithread -port select MOD_PERL=1 && make
&& make test
#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.6.1 Makefile.PL -httpd
/home/httpd/httpd_perl/bin/httpd-5.6.1 -port select MOD_PERL=1 && make && make
test
#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.0-ithread Makefile.PL -httpd
/home/httpd/httpd_perl/bin/httpd-5.8.0-ithread -port select MOD_PERL=1 && make
&& make test
#ok
make clean && /usr/bin/env CCFLAGS="-g" perl-5.8.0 Makefile.PL -httpd
/home/httpd/httpd_perl/bin/httpd-5.8
Re: modules that work with both modperl1 and 2
speeves wrote: Stas Bekman wrote: [...] http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm That did it!!! Thank you so much for your patience and help with all that I am working on here. After I test these changes on modperl 1 tomorrow, I should be able to upload it to CPAN, and it will be ready for prime-time... (fingers crossed ;) ) Based on your porting experience if you have additions/corrections to these two documents: http://perl.apache.org/docs/2.0/user/porting/porting.html http://perl.apache.org/docs/2.0/user/porting/compat.html please submit those here. BTW, I have updated the info on the constants: http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence __ 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: modules that work with both modperl1 and 2
Stas Bekman wrote:
Shannon Eric Peevey wrote:
Perrin Harkins wrote:
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
To answer your original question, Apache::Peek on CPAN now works with
both mod_perl versions. And while it uses separate implementations for
each version, the test suite uses the same code to test both.
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate "use MODULE" lines into the module bases upon which
version of modperl they have installed. Is it possible to use the
BEGIN {} subroutine as this?
You don't need a preprocessor. You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:
if ($mod_perl::VERSION >= 1.99) {
require Apache2::Module;
import Apache2::Module;
} else {
require Apache1::Module;
import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to. That
will make it run before the rest of the code in the current package.
- Perrin
Ok, I'm back... :( Here is the code, modified to use "require":
use mod_perl;
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
# if (!MP2) { use Apache::Constants qw(:common); }
if (MP2) {
require Apache::Const;
import Apache::Access;
require Apache::Access;
import Apache::Access;
require Apache::Connection;
import Apache::Connection;
require Apache::Log;
import Apache::Log;
require Apache::RequestRec;
import Apache::RequestRec;
require Apache::RequestUtil;
import Apache::RequestUtil;
}
You don't need to import anything, since none of these modules import
anything. Just require will do.
Here is the code that is coughing up the error:
102 #Look for user based on UIDAttr
103
104my $attrs = ['dn'];
105 $mesg = $ldap->search(
106 base => $basedn,
107 scope => 'sub',
108 filter => "($uidattr=$user)",
109 attrs => $attrs
110 );
111
112 if (my $error = $mesg->code())
113{
114 $r->note_basic_auth_failure;
115 MP2 ? $r->log_error("user $user: LDAP Connection
Failed: $error",$r->uri) : $r->log_reason("us
er $user: LDAP Connection Failed: $error",$r->uri);
116 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
this should be:
return MP2 ? Apache::HTTP_UNAUTHORIZED :
Apache::Constants::HTTP_UNAUTHORIZED;
and before the handler (at the top of your module) you need to add:
BEGIN {
if (MP2) {
require Apache::Const;
Apache::Const->import(-compile => 'HTTP_UNAUTHORIZED');
}
else {
require Apache::Constants;
Apache::Constants->import('HTTP_UNAUTHORIZED');
}
}
See:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
117}
118
119unless ($mesg->count())
120{
121 $r->note_basic_auth_failure;
122 MP2 ? $r->log_error("user $user: user entry not found
for filter: $uidattr=$user",$r->uri) : $
r->log_reason("user $user: user entry not found for filter:
$uidattr=$user",$r->uri);
123 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
124}
And, here is the error that I am getting in the Apache2 logs, (using
mod_perl 1.99_09)
[Mon Jun 09 13:45:30 2003] [error] user asdf: user entry not found
for filter: uid=asdf/
[Mon Jun 09 13:45:30 2003] [error] [client 127.0.0.1] Can't locate
object method "HTTP_UNAUTHORIZED" via package "Apache::Log" (perhaps
you forgot to load "Apache::Log"?) at
/usr/local/share/perl/5.6.1/Apache/AuthNetLDAP.pm line 123.
As you can see, it is running everything up to the HTTP_UNAUTHORIZED
constant...
If you have any ideas, I would greatly appreciate it. :)
Thanks,
speeves
cws
PS. As a matter of fact, I get the same error when using "use"
instead... (Possibly a screwed perl or mod_perl installation? I'm
running debian woody, apache 2.0.46, perl 5.6.1, mod_perl 1.99_09.)
Hi!
That did it!!! Thank you so much for your patience and help with all
that I am working on here. After I test these changes on modperl 1
tomorrow, I should be able to upload it to CPAN, and it will be ready
for prime-time... (fingers crossed ;) )
Most humbly yours,
speeves
cws
Simple DAV Server?
I'm quite suprised at the limited amount of custom DAV server uses. I mean, here's a protocol for editing content over HTTP, which to me screams as an ideal solution for, say, editing full HTML content within a DB/CMS. I mean, I've been working as Technical Support at a uni for Web Services, and there seems to be these two sides; on one side are the advocates of a file-based system, using any range of HTML editing tools to edit your content (and preferrably some server-side templating for maintaining common look and feel). On the other side is a content management system, which is heavily template structured, with content being chunks of text (or HTML) edited using web forms, or custom editors (eg; in Java). One way of obtaining the advantages of both of these techniques would be to use a DB-driven CMS, but edit the content chunks using a DAV editor. I'd like to write a simple DAV interface to a DB myself, but I'm looking for existing perl modules to make things easier, but I haven't found a heck of a lot along these lines. Most Perl Dav things seem to be more client focussed. Of those that are for server stuff, they seem either overly complicated (eg; Apache::DAV), or fairly immature, and still emphasising filesys structures (eg; HTTP::DAVServer). I suppose what I'm after is an implementation which is easily adaptable to editing data within a DB. I'm considering implementing enough of the HTTP methods to be functional myself, but would rather not bite off more than I have time to chew if there's a nicer solution. Any suggestions? -- . Trevor Phillips - http://jurai.murdoch.edu.au/ . : Web Technical Administrator - [EMAIL PROTECTED] : | IT Services- Murdoch University | >< | On nights such as this, evil deeds are done. And good deeds, of / | course. But mostly evil, on the whole. / \ -- (Terry Pratchett, Wyrd Sisters) /
Re: [mp2] win2000 + Apache::DBI + Oracle
Paul Simon wrote: So, according to the docs, http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM, using Apache::DBI doesn't do anything under mp2+windows2000 ... That's correct. Since Apache::DBI does per-process pooling, and apache 2.0 on winFU, runs one process with many threads. So Apache::DBI is useless there. What is the status of DBI::Pool? I've posted a hard-coded mysql prototype to the dbi-dev list a few months ago. Tim has added the required DBI support recently, but I haven't had a chance to do any work on it since then. If you or anybody else is interested in helping to code DBI::Pool let me know. These modules deal mainly with persistent database connections. Is that correct? That's correct. But since you are using Oracle, if I remember correctly DBD::Oracle provides an internal pooling support. I could be wrong, please check 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
[mp2] win2000 + Apache::DBI + Oracle
So, according to the docs, http://perl.apache.org/docs/2.0/user/performance/mpm.html#Work_with_DataBases_under_Threaded_MPM, using Apache::DBI doesn't do anything under mp2+windows2000 ... What is the status of DBI::Pool? These modules deal mainly with persistent database connections. Is that correct? Paul
Re: PerlOptions Clone/Parent in mp2
Marc M. Adkins wrote: However I think it is possible to make the architecture more flexible to allow pools sharing across specific vhosts, or even location containers (if the scope is set to be only for the handler). e.g. something like: #base server # parameters # parameters PerlUseTiPool A PerlUseTiPool A PerlUseTiPool B PerlUseTiPool B Yeah, that would do it. I don't know how many people will need this, probably not so many. And there might be a sufficient work-around in those rare (?) cases involving multiple Apache instantiations and a proxy server to tie it all together. Something like the high-volume configurations I've seen documented, only with one mod_perl-enhanced server for each TIPool. The code to implement blocks (e.g. ...) in config files is pretty gnarly, too. I know it's already there for , it's one of the places I looked when I was considering doing one of my own and wanted to see an example. The Apache framework is pretty strong for putting in new directives, but not so much for adding new blocks. Actually you can't quite do that in a 3rd party module. Currently the pools are internal to mod_perl. Making this customizable will require adding hooks to the internal tipool mechanism. When I wrote the above pseudo-config I was suggesting an internal support for these. __ 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: PerlOptions Clone/Parent in mp2
> However I think it is possible to make the architecture more > flexible to allow > pools sharing across specific vhosts, or even location containers (if the > scope is set to be only for the handler). e.g. something like: > > #base server > > > # parameters > > > # parameters > > > > PerlUseTiPool A > > > PerlUseTiPool A > > > > PerlUseTiPool B > > > PerlUseTiPool B > Yeah, that would do it. I don't know how many people will need this, probably not so many. And there might be a sufficient work-around in those rare (?) cases involving multiple Apache instantiations and a proxy server to tie it all together. Something like the high-volume configurations I've seen documented, only with one mod_perl-enhanced server for each TIPool. The code to implement blocks (e.g. ...) in config files is pretty gnarly, too. I know it's already there for , it's one of the places I looked when I was considering doing one of my own and wanted to see an example. The Apache framework is pretty strong for putting in new directives, but not so much for adding new blocks. mma
Re: Compling mod_perl as a static module....
Hello again, On Mon, 9 Jun 2003, Forrest Aldrich wrote: > Referring back to my original post, it with the options I specified, the > compile process still insists on compiling mod_perl as a DSO. Even if I > explicitly set USE_DSO=0 -- I wonder if one of the other flags (like > EVERYTHING=1) is triggering the DSO compile. No, I often compile statically with EVERYTHING=1. I don't think we're dealing with a full deck here. Are you quite sure that you're looking at the right executable after you build it? Check the timestamp. Try running it by giving the full pathname and the -l switch for example /home/forrest/src/apache_1.3.27/src/httpd -l or change to the directory that the exewcutable is in and say ./httpd -l (you can do both without being root) and see if the output includes a line mod_perl.c which tells you that mod_perl is compiled in (i.e. compiled statically). 73, Ged.
Re: [mp2] make test fails with 1.99_10-dev sources on redhat
Haroon Rafique wrote:
On Saturday at 9:22am, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote:
SB> I think the issue is very simple: @INC had system libraries dirs
SB> before the freshly build ones, so dumping @INC contents prior to libs
SB> loading should aid the debug. But please use the latest cvs, since
SB> I've messed with @INC a bit recently.
SB>
SB> In parallel, we are planning to verify .so objects that they were
SB> created by the same mod_perl.so to avoid completely this kind of
SB> problems. Well it won't prevent the pickup of wrong libraries, it'll
SB> just scream aloud when this will happen. So your debug is still very
SB> important.
SB>
Seeing that you were answering emails even on a Saturday, I feel guilty
about taking that out of town trip yesterday. Oh well! I think we should
be able to enjoy the little bit of summer that we get here in Canada to
the fullest.
Actually it was Sunday (future!) and it's winter (past?) here in Melbourne ;)
Now onto serious stuff. /usr/bin/perl here is the system-wide perl install
that came bundled with Redhat.
/usr/bin/perl -MApache2 -Mmod_perl -le 'print mod_perl->VERSION'
1.9908
I posted t/REPORT output in the beginning of the thread and can
repost upon request.
no need to
I did a cvs up, and issued:
* /usr/bin/perl Makefile.PL MP_AP_PREFIX=/servers/httpd-2.0.44-pl
* make
* make test
and was greeted by the now familiar output (same as originally reported)
/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -clean
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -clean
sh: line 1: ulimit: core file size: cannot modify limit: Operation not
permitted
APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \
/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -verbose=0
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -verbose=0
sh: line 1: ulimit: core file size: cannot modify limit: Operation not
permitted
/servers/httpd-2.0.44-pl/bin/httpd -d
/home/haroon/src/build/modperl-2.0/t -f
/home/haroon/src/build/modperl-2.0/t/conf/httpd.conf -DAPACHE2
-DPERL_USEITHREADS
using Apache/2.0.44 (prefork MPM)
waiting for server to start: ..[Mon Jun 09 09:38:20 2003] [info] 22
Apache:: modules loaded
[Mon Jun 09 09:38:20 2003] [info] 5 APR:: modules loaded
[Mon Jun 09 09:38:20 2003] [info] base server + 9 vhosts ready to run
tests
[Mon Jun 09 09:38:20 2003] [error] Invalid CODE attribute:
TestFilter::in_init_basic at
/home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm
line 30
BEGIN failed--compilation aborted at
/home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm
line 30.
Compilation failed in require at (eval 35) line 3.
[Mon Jun 09 09:38:20 2003] [error] Can't load Perl module
TestFilter::in_init_basic for server localhost.localdomain:8529,
exiting...
!!!
server has died with status 255 (t/logs/error_log wasn't created, start
the server in the debug mode)
make: *** [run_tests] Error 143
Well, nothing has changed, hasn't it? Now try to figure out which .so gets
loaded and why it is not the locally built one. The module in question is
Apache::Filter
For example change TestFilter/in_init_basic.pm to dump the location of the
Apache::Filter library.
Index: t/filter/TestFilter/in_init_basic.pm
===
RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/in_init_basic.pm,v
retrieving revision 1.2
diff -u -r1.2 in_init_basic.pm
--- t/filter/TestFilter/in_init_basic.pm9 May 2003 03:33:37 - 1.2
+++ t/filter/TestFilter/in_init_basic.pm9 Jun 2003 23:45:58 -
@@ -11,6 +11,8 @@
use base qw(Apache::Filter);
+BEGIN { warn "Apache::Filter $INC{'Apache/Filter.pm'}" }
+
use Apache::Const -compile => qw(OK M_POST);
use constant READ_SIZE => 1024;
Then, if it's indeed your globally installed Apache::Filter and not the local
one, dump @INC (in the same place) to see whether the global path comes before
the local 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
Re: PerlOptions Clone/Parent in mp2
Marc M. Adkins wrote: wrt Apache 2.0, mod_perl 2.0... I'm not using Clone or Parent at the current time, but I was re-reading the documentation on them for an unrelated reason and started thinking about how they would work. Suppose I want to set up five virtual hosts with modules A - E. Then I want to set up six virtual hosts with modules F - M. The first five virtual hosts can all share a pool of interpreters and the second six virtual hosts can share a different pool of interpreters. How might I declare two parent interpreters globally, one with modules A - E and the other with modules F - M such that I could share a pool of interpreters derived from the first parent with five virtual hosts and a pool of interpreters derived the second parent with a different six virtual hosts? This is all theoretical, I don't actually need this right now, and probably won't ever. Just trying to imagine how these options would be used. Currently you can't do that. Each vhost can inherit from the base server perl, clone it or start a while new pool of interpreters. However I think it is possible to make the architecture more flexible to allow pools sharing across specific vhosts, or even location containers (if the scope is set to be only for the handler). e.g. something like: #base server # parameters # parameters PerlUseTiPool A PerlUseTiPool A PerlUseTiPool B PerlUseTiPool B Of course we are talking about threaded mpms here. __ 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: modules that work with both modperl1 and 2
Shannon Eric Peevey wrote:
Perrin Harkins wrote:
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
To answer your original question, Apache::Peek on CPAN now works with both
mod_perl versions. And while it uses separate implementations for each
version, the test suite uses the same code to test both.
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate "use MODULE" lines into the module bases upon which
version of modperl they have installed. Is it possible to use the
BEGIN {} subroutine as this?
You don't need a preprocessor. You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:
if ($mod_perl::VERSION >= 1.99) {
require Apache2::Module;
import Apache2::Module;
} else {
require Apache1::Module;
import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to. That
will make it run before the rest of the code in the current package.
- Perrin
Ok, I'm back... :( Here is the code, modified to use "require":
use mod_perl;
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
# if (!MP2) { use Apache::Constants qw(:common); }
if (MP2) {
require Apache::Const;
import Apache::Access;
require Apache::Access;
import Apache::Access;
require Apache::Connection;
import Apache::Connection;
require Apache::Log;
import Apache::Log;
require Apache::RequestRec;
import Apache::RequestRec;
require Apache::RequestUtil;
import Apache::RequestUtil;
}
You don't need to import anything, since none of these modules import
anything. Just require will do.
Here is the code that is coughing up the error:
102 #Look for user based on UIDAttr
103
104my $attrs = ['dn'];
105 $mesg = $ldap->search(
106 base => $basedn,
107 scope => 'sub',
108 filter => "($uidattr=$user)",
109 attrs => $attrs
110 );
111
112 if (my $error = $mesg->code())
113{
114 $r->note_basic_auth_failure;
115 MP2 ? $r->log_error("user $user: LDAP Connection Failed:
$error",$r->uri) : $r->log_reason("us
er $user: LDAP Connection Failed: $error",$r->uri);
116 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
this should be:
return MP2 ? Apache::HTTP_UNAUTHORIZED : Apache::Constants::HTTP_UNAUTHORIZED;
and before the handler (at the top of your module) you need to add:
BEGIN {
if (MP2) {
require Apache::Const;
Apache::Const->import(-compile => 'HTTP_UNAUTHORIZED');
}
else {
require Apache::Constants;
Apache::Constants->import('HTTP_UNAUTHORIZED');
}
}
See:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
117}
118
119unless ($mesg->count())
120{
121 $r->note_basic_auth_failure;
122 MP2 ? $r->log_error("user $user: user entry not found for
filter: $uidattr=$user",$r->uri) : $
r->log_reason("user $user: user entry not found for filter:
$uidattr=$user",$r->uri);
123 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
124}
And, here is the error that I am getting in the Apache2 logs, (using
mod_perl 1.99_09)
[Mon Jun 09 13:45:30 2003] [error] user asdf: user entry not found for
filter: uid=asdf/
[Mon Jun 09 13:45:30 2003] [error] [client 127.0.0.1] Can't locate
object method "HTTP_UNAUTHORIZED" via package "Apache::Log" (perhaps you
forgot to load "Apache::Log"?) at
/usr/local/share/perl/5.6.1/Apache/AuthNetLDAP.pm line 123.
As you can see, it is running everything up to the HTTP_UNAUTHORIZED
constant...
If you have any ideas, I would greatly appreciate it. :)
Thanks,
speeves
cws
PS. As a matter of fact, I get the same error when using "use"
instead... (Possibly a screwed perl or mod_perl installation? I'm
running debian woody, apache 2.0.46, perl 5.6.1, mod_perl 1.99_09.)
--
__
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: modules that work with both modperl1 and 2
Perrin Harkins wrote:
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate "use MODULE" lines into the module bases upon which version
of modperl they have installed. Is it possible to use the BEGIN {}
subroutine as this?
You don't need a preprocessor. You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:
if ($mod_perl::VERSION >= 1.99) {
require Apache2::Module;
import Apache2::Module;
} else {
require Apache1::Module;
import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to. That
will make it run before the rest of the code in the current package.
- Perrin
Ok, I'm back... :( Here is the code, modified to use "require":
use mod_perl;
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
# if (!MP2) { use Apache::Constants qw(:common); }
if (MP2) {
require Apache::Const;
import Apache::Access;
require Apache::Access;
import Apache::Access;
require Apache::Connection;
import Apache::Connection;
require Apache::Log;
import Apache::Log;
require Apache::RequestRec;
import Apache::RequestRec;
require Apache::RequestUtil;
import Apache::RequestUtil;
}
Here is the code that is coughing up the error:
102 #Look for user based on UIDAttr
103
104my $attrs = ['dn'];
105 $mesg = $ldap->search(
106 base => $basedn,
107 scope => 'sub',
108 filter => "($uidattr=$user)",
109 attrs => $attrs
110 );
111
112 if (my $error = $mesg->code())
113{
114 $r->note_basic_auth_failure;
115 MP2 ? $r->log_error("user $user: LDAP Connection Failed:
$error",$r->uri) : $r->log_reason("us
er $user: LDAP Connection Failed: $error",$r->uri);
116 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
117}
118
119unless ($mesg->count())
120{
121 $r->note_basic_auth_failure;
122 MP2 ? $r->log_error("user $user: user entry not found
for filter: $uidattr=$user",$r->uri) : $
r->log_reason("user $user: user entry not found for filter:
$uidattr=$user",$r->uri);
123 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
124}
And, here is the error that I am getting in the Apache2 logs, (using
mod_perl 1.99_09)
[Mon Jun 09 13:45:30 2003] [error] user asdf: user entry not found for
filter: uid=asdf/
[Mon Jun 09 13:45:30 2003] [error] [client 127.0.0.1] Can't locate
object method "HTTP_UNAUTHORIZED" via package "Apache::Log" (perhaps you
forgot to load "Apache::Log"?) at
/usr/local/share/perl/5.6.1/Apache/AuthNetLDAP.pm line 123.
As you can see, it is running everything up to the HTTP_UNAUTHORIZED
constant...
If you have any ideas, I would greatly appreciate it. :)
Thanks,
speeves
cws
PS. As a matter of fact, I get the same error when using "use"
instead... (Possibly a screwed perl or mod_perl installation? I'm
running debian woody, apache 2.0.46, perl 5.6.1, mod_perl 1.99_09.)
Re: getting *any* variables out of the server environment
On Mon, 2003-06-09 at 15:24, Perrin Harkins wrote:
> [ Please keep it on the list. ]
>
Sorry about that!
> On Mon, 2003-06-09 at 16:12, Ryan Muldoon wrote:
> > > Ryan, can you post a more complete code example?
> > >
> > > - Perrin
> > Here it is:
> >
> > package Apache::AuthNx509;
> >
> > use strict;
> > use Apache::Constants qw(:common);
> > use Text::ParseWords qw(quotewords);
> > use Apache::Log ();
> >
> > sub handler {
> > my $r = shift;
> > my $c = $r->connection;
> > my $log = $r->log;
> > return OK unless $r->is_main;
> >
> > my $certcomponent = $r->dir_config('CertComponent') ||
> > 'SSL_CLIENT_S_DN_O';
> > my $certcompvalue = $r->dir_config('CertComponentValue') ||
> > 'University of Wisconsin';
> > my $usercomponent = $r->dir_config('RemoteUserCertComponent') ||
> > 'SSL_CLIENT_S_DN_CN';
> >
> > #my $cn = $r->subprocess_env('MOD_PERL');
> > # $log->notice("test: $ENV{'MOD_PERL'}");
> > my $apachecertcomp = $r->subprocess_env{$certcomponent};
>
> That should be $r->subprocess_env($certcomponent). It's a method, not a
> hash key. Also, put the lookup_uri stuff back in, since it seems that
> you need it when trying to get the stuff from mod_ssl.
>
> - Perrin
I must have been stupid. Making those two corrections, everything works
(Almost)! Right now it is failing on my attempts to set the user
variable (I want to be able to set REMOTE_USER to an arbitrary cert
field). I'll have to dig a bit to figure out how to do that. Thank you
everyone on the list for helping me out so much today - I really
appreciate it. Many days of hair-pulling are at an end. ;-)
--Ryan
Re: getting *any* variables out of the server environment
[ Please keep it on the list. ]
On Mon, 2003-06-09 at 16:12, Ryan Muldoon wrote:
> > Ryan, can you post a more complete code example?
> >
> > - Perrin
> Here it is:
>
> package Apache::AuthNx509;
>
> use strict;
> use Apache::Constants qw(:common);
> use Text::ParseWords qw(quotewords);
> use Apache::Log ();
>
> sub handler {
> my $r = shift;
> my $c = $r->connection;
> my $log = $r->log;
> return OK unless $r->is_main;
>
> my $certcomponent = $r->dir_config('CertComponent') ||
> 'SSL_CLIENT_S_DN_O';
> my $certcompvalue = $r->dir_config('CertComponentValue') ||
> 'University of Wisconsin';
> my $usercomponent = $r->dir_config('RemoteUserCertComponent') ||
> 'SSL_CLIENT_S_DN_CN';
>
> #my $cn = $r->subprocess_env('MOD_PERL');
> # $log->notice("test: $ENV{'MOD_PERL'}");
> my $apachecertcomp = $r->subprocess_env{$certcomponent};
That should be $r->subprocess_env($certcomponent). It's a method, not a
hash key. Also, put the lookup_uri stuff back in, since it seems that
you need it when trying to get the stuff from mod_ssl.
- Perrin
Re: getting *any* variables out of the server environment
Actually, upon flushing my browser cache and checking again, I can in fact read the MOD_PERL environment variable just fine. But still no luck on any mod_ssl related variables. --Ryan
Re: Mod_perl 1.99 spawning processes causing major performanceissue
Thanks for using REPORT!
On Mon, 2003-06-09 at 16:07, George Bagley wrote:
> On Apache 1.3, when I do a ps -ef, I cannot see the cgi script running.
> I assume this is because Apache is NOT spawning a separate process to
> satisfy the request.
>
> On Apache2, there are hundreds of the cgi scripts running and
> performance is roughly half what it was on Apache 1.3
Sounds like your scripts are not actually running under mod_perl. To
test this, you can try printing out the value of $ENV{'MOD_PERL'} in one
of them. If you're running under mod_perl (via ModPerl::Registry) that
variable will be defined.
> # PerlModule ModPerl::Registry
>
> AddHandler cgi-script cgi pl
> # AddHandler perl-script .pl
> # PerlResponseHandler Apache::Registry
> PerlResponseHandler ModPerl::Registry
> PerlOptions +ParseHeaders
> AllowOverride None
> Options +ExecCGI -Includes
> # SetHandler perl-script
> SetHandler cgi-script
>
That last line is the problem. The perl-script one should be
uncommented, not the cgi-script one.
- Perrin
Re: getting *any* variables out of the server environment
Ok, removed. Thank you very much for the in-depth replies. It is very useful. Unfortunately any variable-reading continues to elude me. But I really appreciate all the help! well, it sounds like you are having a larger problem that just mod_ssl-based variables. since you mention you're interested in learning... :) if you really want to track this down you could start from the beginning, meaning a bare bones server and a bare bones mod_perl content handler that merely iterates over %ENV and $r->subprocess_env() (see the do() method from Apache::Table) this kind of bare bones thing used to be a pain, but with Apache-Test, it has gotten _lots_ easier. you can find Apache-Test on CPAN http://search.cpan.org/CPAN/authors/id/S/ST/STAS/Apache-Test-1.01.tar.gz you can look at some of the SSL tests in the Perl-Framework http://cvs.apache.org/viewcvs.cgi/httpd-test/perl-framework/ to see how they use Apache-Test to test SSL based things. for instance env.t tests basic environment setting for SSL connections - you can use that as the starting point for writing tests for your own stuff. or you can even download the Perl framework from http://httpd.apache.org/test/ and run the ssl tests to make sure you're server is configured properly. just some advice, and you certainly don't need to go through all the effort of reading, setting up the test environment, etc. however, once you get Apache-Test set up it will make your module development much, much easier, and you'll be able to pinpoint exactly where things go wrong much easier. some basic explanations and pointers to other docs can be found here http://www.perl.com/pub/a/2003/05/22/testing.html HTH --Geoff
Mod_perl 1.99 spawning processes causing major performance issue
-8<-- Start Bug Report 8<-- 1. Problem Description: Hi I have ugraded from apache1.3 to Apache2 and I am having a performance problem with a cgi script. Hardware Dell 2550, Dual Proc, 2GB RAM, RedHat Linux 9.0 On Apache 1.3, when I do a ps -ef, I cannot see the cgi script running. I assume this is because Apache is NOT spawning a separate process to satisfy the request. On Apache2, there are hundreds of the cgi scripts running and performance is roughly half what it was on Apache 1.3 The cgi script in question makes a connection to a mysql database. I have had to increase the max number of connections allowed by mysql to allow for the large number of spawned perl processes attempting to make a DB connection. Is there a configuration option to stop this happening? I have the following relating to perl in my httpd.conf # LoadModule foo_module modules/mod_foo.so # LoadModule perl_module modules/mod_perl.so # PerlRequire "/usr/local/apache2/2.0.45/conf/startup.pl" PerlModule Apache2 # PerlModule ModPerl::Registry AddHandler cgi-script cgi pl # AddHandler perl-script .pl # PerlResponseHandler Apache::Registry PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders AllowOverride None Options +ExecCGI -Includes # SetHandler perl-script SetHandler cgi-script 2. Used Components and their Configuration: *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_AP_PREFIX=> /usr/local/apache MP_COMPAT_1X=> 1 MP_GENERATE_XS => 1 MP_INST_APACHE2 => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 MP_USE_STATIC => 1 *** /usr/local/apache/bin/httpd -V Server version: Apache/2.0.45 Server built: Apr 30 2003 17:51:58 Server's Module Magic Number: 20020903:0 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/usr/local/apache2/2.0.45" -D SUEXEC_BIN="/usr/local/apache2/2.0.45/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** /usr/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.20-8smp, archname=i686-linux uname='linux redeye-lin-01.pajmc.com 2.4.20-8smp #1 smp thu mar 13 17:45:54 est 2003 i686 i686 i386 gnulinux ' config_args='-d -Dprefix=/usr' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O3', cppflags='-fno-strict-aliasing -I/usr/include/gdbm' ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)', 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=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Apr 30 2003 17:16:30 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: /usr/lib/perl5/5.8.0/i686-linux /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i686-linux /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl 3. This is the core dump trace: (if you get a core dump): I am not getting an ERROR. Just a major performance issue. This report was generated by t/REPORT on Mon Jun 9 20:59:06 2003 GMT. -8<-- End Bug Report --8<-- Note: Complete the rest of the details and post this bug report to dev perl.apache.org. To subscribe to the list send an empty email to [EMAIL PROTECTED]
Re: getting *any* variables out of the server environment
On Mon, 2003-06-09 at 15:35, Geoffrey Young wrote: > no, I wasn't saying that :) subprocess_env() from the main request is the > right way to go. I was just trying to let you know that it has nothing to > do with %ENV really. I wouldn't go that far. %ENV does get populated with that stuff, just not yet. > perhaps this is why > the eagle book said to get them from a subrequest - presumably the > subrequest would have them, since it runs through the fixup phase and SSL > stuff is per-connection and not per-request. Exactly, and as it happens, that chapter is on-line. The part Ryan was referring to is here: http://modperl.com:9000/book/chapters/ch6.html#Using_Digital_Certificates_for_A Ryan, can you post a more complete code example? - Perrin
Re: getting *any* variables out of the server environment
On Mon, 2003-06-09 at 14:35, Geoffrey Young wrote:
> Ryan Muldoon wrote:
> > Geoffrey,
> >
> > Thanks for the explanation. Unfortunately, I think I am still a little
> > unclear as to how to proceed. If I understand you correctly, my first
> > method is completely wrongheaded.
>
> :)
>
> > (I tried this because it is how the
> > "Writing Apache Modules with Perl and C" does it. p.327)
>
> don't have my book handy to check that.
>
> > So it sounds
> > like the second way is the appropriate usage for subprocess_env(). But
> > it seems like you're saying that I shouldn't be using that at all.
>
> no, I wasn't saying that :) subprocess_env() from the main request is the
> right way to go. I was just trying to let you know that it has nothing to
> do with %ENV really.
>
Ok, cool. Thanks for the clarification ;-)
> > Specifically, here is what I'd like to get out of the environment:
> > SSL_CLIENT_S_DN_CN
> > SSL_CLIENT_S_DN_O
> > and things of that nature.
>
> ok, those are definitely setup in the subprocess_env table according to the
> code I just took a look at. however...
>
> > According to mod_ssl's documentation, these
> > are put in ENV upon processing of a client certificate.
>
> from what I can see, that's not entirely true. they are set in
> subprocess_env where they sit and wait, presumably for somebody else to call
> add_cgi_vars since mod_ssl does not (but mod_cgi and mod_perl both do).
>
> the problem you're seeing is that these variables are setup during the fixup
> phase, so in using a PerlAuthenHandler you're trying to see them too early.
>
> int ssl_hook_Fixup(request_rec *r)
> {
> SSLSrvConfigRec *sc = mySrvConfig(r->server);
> SSLDirConfigRec *dc = myDirConfig(r);
> table *e = r->subprocess_env;
> ...
> /*
> * Annotate the SSI/CGI environment with standard SSL information
> */
> /* the always present HTTPS (=HTTP over SSL) flag! */
> ap_table_set(e, "HTTPS", "on");
> /* standard SSL environment variables */
> if (dc->nOptions & SSL_OPT_STDENVVARS) {
> for (i = 0; ssl_hook_Fixup_vars[i] != NULL; i++) {
> var = (char *)ssl_hook_Fixup_vars[i];
> val = ssl_var_lookup(r->pool, r->server, r->connection, r, var);
> if (!strIsEmpty(val))
> ap_table_set(e, var, val);
> }
> }
>
> in other words, you're SOL from the current request. perhaps this is why
> the eagle book said to get them from a subrequest - presumably the
> subrequest would have them, since it runs through the fixup phase and SSL
> stuff is per-connection and not per-request.
>
Yeah, I think that was the motivation. On the upside of my current
difficulty, I'm getting to learn a lot more about how apache does
things.
> > Ideally, I'd
> > like to make which fields to extract configurable, so I don't want to
> > hard-code.
> >
> > Currently, I have
> > PerlPassEnv SSL_CLIENT_S_DN_O
> > PerlPassEnv SSL_CLIENT_S_DN_CN
> > in my httpd.conf, but it doesn't seem to make any kind of difference.
>
> don't do that. PerlPassEnv is for passing variables such as those from
> /etc/profile to the %ENV of the Apache child processes.
>
Ok, removed. Thank you very much for the in-depth replies. It is very
useful. Unfortunately any variable-reading continues to elude me. But
I really appreciate all the help!
--Ryan
Re: Mod_perl spawning processes
On Mon, 2003-06-09 at 15:34, George Bagley wrote: > CONFIG redhat linux 9.0 > apache 2 I'm afraid that's not enough info to guess what you're doing. Please read http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems > I have ugraded from apache1.3 to Apache2 and I am having a performance > problem with a cgi script. Do you mean a script running under ModPerl::Registry? We don't support actual CGI on this list, just mod_perl. - Perrin
Re: getting *any* variables out of the server environment
>From what I understand, what you outline *should* work. It just doesn't
for me for some reason. I really appreciate everyone's help though.
(And as an aside - I learned how to program in Perl from your books -
many thanks)
--Ryan
On Mon, 2003-06-09 at 14:23, Randal L. Schwartz wrote:
> > "Ryan" == Ryan Muldoon <[EMAIL PROTECTED]> writes:
>
> Ryan> Geoffrey,
> Ryan> Thanks for the explanation. Unfortunately, I think I am still a little
> Ryan> unclear as to how to proceed. If I understand you correctly, my first
> Ryan> method is completely wrongheaded. (I tried this because it is how the
> Ryan> "Writing Apache Modules with Perl and C" does it. p.327) So it sounds
> Ryan> like the second way is the appropriate usage for subprocess_env(). But
> Ryan> it seems like you're saying that I shouldn't be using that at all.
> Ryan> Specifically, here is what I'd like to get out of the environment:
> Ryan> SSL_CLIENT_S_DN_CN
> Ryan> SSL_CLIENT_S_DN_O
> Ryan> and things of that nature. According to mod_ssl's documentation, these
> Ryan> are put in ENV upon processing of a client certificate. Ideally, I'd
> Ryan> like to make which fields to extract configurable, so I don't want to
> Ryan> hard-code.
>
> Well, then, in any handler after the mod_ssl has run, you
> should be be able to use $r->subprocess_env("SSL_CLIENT_S_DN_CN")
> to get at that info.
>
> Ryan> Currently, I have
> Ryan> PerlPassEnv SSL_CLIENT_S_DN_O
> Ryan> PerlPassEnv SSL_CLIENT_S_DN_CN
> Ryan> in my httpd.conf, but it doesn't seem to make any kind of difference.
> Ryan> To make sure it isn't just mod_ssl being lame for some reason, I've
> Ryan> tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
> Ryan> avail. :(
>
> That takes the enviroment variables that apache was started with
> and passes those to mod_perl. Probably not what you want.
>
> (I'm doing this from memory, so please correct me if I'm wrong.)
Re: getting *any* variables out of the server environment
I'm trying to do this as a PerlAuthenHandler, so it should be well past
mod_ssl's involvement, but before the fixup stage. Trying to print out
MOD_PERL either through a subprocess or ENV fails. So maybe I'm in
bigger trouble than I thought?
--Ryan
On Mon, 2003-06-09 at 14:26, Issac Goldstand wrote:
> Ryan,
> Ust out of curiosity, at what stage in the request chain are you doing
> this? If you are doing anything before mod_ssl populates its environment
> variables (which I seem to rembmer being at Fixup, although I may be
> confusing with something else), you wouldn't be able to access them. You
> *should* still be able to get to other Apache environment variables.
> Try an easy one: test for mod_perl. If that works, your environment
> variables are OK, and it's likely a mod_ssl problem that you're having.
>
> Issac
>
> - Original Message -
> From: "Ryan Muldoon" <[EMAIL PROTECTED]>
> To: "Geoffrey Young" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, June 09, 2003 10:13 PM
> Subject: Re: getting *any* variables out of the server environment
>
>
> > Geoffrey,
> >
> > Thanks for the explanation. Unfortunately, I think I am still a little
> > unclear as to how to proceed. If I understand you correctly, my first
> > method is completely wrongheaded. (I tried this because it is how the
> > "Writing Apache Modules with Perl and C" does it. p.327) So it sounds
> > like the second way is the appropriate usage for subprocess_env(). But
> > it seems like you're saying that I shouldn't be using that at all.
> > Specifically, here is what I'd like to get out of the environment:
> > SSL_CLIENT_S_DN_CN
> > SSL_CLIENT_S_DN_O
> > and things of that nature. According to mod_ssl's documentation, these
> > are put in ENV upon processing of a client certificate. Ideally, I'd
> > like to make which fields to extract configurable, so I don't want to
> > hard-code.
> >
> > Currently, I have
> > PerlPassEnv SSL_CLIENT_S_DN_O
> > PerlPassEnv SSL_CLIENT_S_DN_CN
> > in my httpd.conf, but it doesn't seem to make any kind of difference.
> > To make sure it isn't just mod_ssl being lame for some reason, I've
> > tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
> > avail. :(
> >
> > --Ryan
> >
> > On Mon, 2003-06-09 at 13:59, Geoffrey Young wrote:
> > > Ryan Muldoon wrote:
> > > > I'm not able to get *any* variables out from the apache server
> > > > environment.
> > >
> > > ok, first off, this is a two step process for Apache. the first step is
> > > that modules (like mod_ssl) populate the subprocess_env table with
> various
> > > values. then, modules like mod_cgi and mod_perl come along and populate
> > > %ENV with the values from subprocess_env as well as various other CGI
> > > specific variables (like DOCUMENT_ROOT or whatever else there is). the
> > > point is that you're really not after environment variables if you want
> to
> > > test for something like $r->subprocess_env('HTTPS') - that it ends up as
> > > $ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.
> > >
> > > just for your own edification :)
> > >
> > > > As you might be able to imagine, this is extremely
> > > > frustrating, and inhibits my ability to do anything of use with
> > > > mod_perl. My basic technique has been:
> > > > my $uri = $r->uri;
> > > > return unless $r->is_main();
> > > > my $subr = $r->lookup_uri($uri);
> > > > my $apachecertcomp = $subr->subprocess_env($certcomponent);
> > >
> > > I don't understand the need for a subrequest to the same URI -
> > > subprocess_env has nothing to do with an actual subprocess. each
> request
> > > (including subrequests) have their own subprocess_env table attached to
> $r.
> > > in many cases, modules are coded to behave differently for subrequests
> > > than for the main request, so something you may see in
> $r->subprocess_env()
> > > could not be in $r->lookup_uri($uri)->subprocess_env().
> > >
> > > > But this doesn't work. I also tried
> > > > my $var = $r->subprocess_env("VARIABLE_NAME");
> > > > And this does not work either. I really need to be able to use
> > > > environment variables that mod_ssl sets in my authentication handler.
> > >
> > > a few things here too. for the reasons described above,
> subprocess_env() is
> > > not a substitute for %ENV, so if what you want is a true %ENV value
> (such as
> > > those from PerlPassEnv), you will not be able to get to it via
> > > $r->subprocess_env().
> > >
> > > > Any ideas? Thanks!
> > >
> > > HTH
> > >
> > > --Geoff
> > >
> > >
> > >
> >
>
Re: getting *any* variables out of the server environment
I didn't. But I just set that, and it didn't seem to make a difference --Ryan On Mon, 2003-06-09 at 14:16, Randy Kobes wrote: > On Mon, 9 Jun 2003, Ryan Muldoon wrote: > > > Geoffrey, > > > > Thanks for the explanation. Unfortunately, I think I am > > still a little unclear as to how to proceed. If I understand > > you correctly, my first method is completely wrongheaded. (I > > tried this because it is how the "Writing Apache Modules with > > Perl and C" does it. p.327) So it sounds like the second way > > is the appropriate usage for subprocess_env(). But it seems > > like you're saying that I shouldn't be using that at all. > > Specifically, here is what I'd like to get out of the > > environment: SSL_CLIENT_S_DN_CN SSL_CLIENT_S_DN_O and things of > > that nature. According to mod_ssl's documentation, these are > > put in ENV upon processing of a client certificate. Ideally, > > I'd like to make which fields to extract configurable, so I > > don't want to hard-code. > > > > Currently, I have > > PerlPassEnv SSL_CLIENT_S_DN_O > > PerlPassEnv SSL_CLIENT_S_DN_CN > > in my httpd.conf, but it doesn't seem to make any kind of difference. > > To make sure it isn't just mod_ssl being lame for some reason, I've > > tried it with DOCUMENT_ROOT and other standard ENV variables. But to no > > avail. :( > > Do you have a >SSLOptions +StdEnvVars > directive inside the relevant location of your httpd.conf?
Re: getting *any* variables out of the server environment
Ryan Muldoon wrote:
Geoffrey,
Thanks for the explanation. Unfortunately, I think I am still a little
unclear as to how to proceed. If I understand you correctly, my first
method is completely wrongheaded.
:)
(I tried this because it is how the
"Writing Apache Modules with Perl and C" does it. p.327)
don't have my book handy to check that.
So it sounds
like the second way is the appropriate usage for subprocess_env(). But
it seems like you're saying that I shouldn't be using that at all.
no, I wasn't saying that :) subprocess_env() from the main request is the
right way to go. I was just trying to let you know that it has nothing to
do with %ENV really.
Specifically, here is what I'd like to get out of the environment:
SSL_CLIENT_S_DN_CN
SSL_CLIENT_S_DN_O
and things of that nature.
ok, those are definitely setup in the subprocess_env table according to the
code I just took a look at. however...
According to mod_ssl's documentation, these
are put in ENV upon processing of a client certificate.
from what I can see, that's not entirely true. they are set in
subprocess_env where they sit and wait, presumably for somebody else to call
add_cgi_vars since mod_ssl does not (but mod_cgi and mod_perl both do).
the problem you're seeing is that these variables are setup during the fixup
phase, so in using a PerlAuthenHandler you're trying to see them too early.
int ssl_hook_Fixup(request_rec *r)
{
SSLSrvConfigRec *sc = mySrvConfig(r->server);
SSLDirConfigRec *dc = myDirConfig(r);
table *e = r->subprocess_env;
...
/*
* Annotate the SSI/CGI environment with standard SSL information
*/
/* the always present HTTPS (=HTTP over SSL) flag! */
ap_table_set(e, "HTTPS", "on");
/* standard SSL environment variables */
if (dc->nOptions & SSL_OPT_STDENVVARS) {
for (i = 0; ssl_hook_Fixup_vars[i] != NULL; i++) {
var = (char *)ssl_hook_Fixup_vars[i];
val = ssl_var_lookup(r->pool, r->server, r->connection, r, var);
if (!strIsEmpty(val))
ap_table_set(e, var, val);
}
}
in other words, you're SOL from the current request. perhaps this is why
the eagle book said to get them from a subrequest - presumably the
subrequest would have them, since it runs through the fixup phase and SSL
stuff is per-connection and not per-request.
Ideally, I'd
like to make which fields to extract configurable, so I don't want to
hard-code.
Currently, I have
PerlPassEnv SSL_CLIENT_S_DN_O
PerlPassEnv SSL_CLIENT_S_DN_CN
in my httpd.conf, but it doesn't seem to make any kind of difference.
don't do that. PerlPassEnv is for passing variables such as those from
/etc/profile to the %ENV of the Apache child processes.
--Geoff
Mod_perl spawning processes
Hi CONFIG redhat linux 9.0 apache 2 I have ugraded from apache1.3 to Apache2 and I am having a performance problem with a cgi script. On 1.3, when I do a ps, I cannot see the cgi script running. On 2, there are hundreds of the cgi scripts running. The cgi makes a connection to a mysql database. Is there a configuration option to stop this happening? Thanks George Bagley Senior Systems Analyst Red Eye International Ltd 24-28 Nelson's Row Clapham London SW4 7JT d: 020 7627 9313 t: 020 7627 9300 f: 020 7627 9301 e: [EMAIL PROTECTED] n: www.redeye.com eCRM experts
Re: getting *any* variables out of the server environment
On Mon, 9 Jun 2003, Ryan Muldoon wrote: > Geoffrey, > > Thanks for the explanation. Unfortunately, I think I am > still a little unclear as to how to proceed. If I understand > you correctly, my first method is completely wrongheaded. (I > tried this because it is how the "Writing Apache Modules with > Perl and C" does it. p.327) So it sounds like the second way > is the appropriate usage for subprocess_env(). But it seems > like you're saying that I shouldn't be using that at all. > Specifically, here is what I'd like to get out of the > environment: SSL_CLIENT_S_DN_CN SSL_CLIENT_S_DN_O and things of > that nature. According to mod_ssl's documentation, these are > put in ENV upon processing of a client certificate. Ideally, > I'd like to make which fields to extract configurable, so I > don't want to hard-code. > > Currently, I have > PerlPassEnv SSL_CLIENT_S_DN_O > PerlPassEnv SSL_CLIENT_S_DN_CN > in my httpd.conf, but it doesn't seem to make any kind of difference. > To make sure it isn't just mod_ssl being lame for some reason, I've > tried it with DOCUMENT_ROOT and other standard ENV variables. But to no > avail. :( Do you have a SSLOptions +StdEnvVars directive inside the relevant location of your httpd.conf? -- best regards, randy kobes
Re: getting *any* variables out of the server environment
Ryan,
Ust out of curiosity, at what stage in the request chain are you doing
this? If you are doing anything before mod_ssl populates its environment
variables (which I seem to rembmer being at Fixup, although I may be
confusing with something else), you wouldn't be able to access them. You
*should* still be able to get to other Apache environment variables.
Try an easy one: test for mod_perl. If that works, your environment
variables are OK, and it's likely a mod_ssl problem that you're having.
Issac
- Original Message -
From: "Ryan Muldoon" <[EMAIL PROTECTED]>
To: "Geoffrey Young" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, June 09, 2003 10:13 PM
Subject: Re: getting *any* variables out of the server environment
> Geoffrey,
>
> Thanks for the explanation. Unfortunately, I think I am still a little
> unclear as to how to proceed. If I understand you correctly, my first
> method is completely wrongheaded. (I tried this because it is how the
> "Writing Apache Modules with Perl and C" does it. p.327) So it sounds
> like the second way is the appropriate usage for subprocess_env(). But
> it seems like you're saying that I shouldn't be using that at all.
> Specifically, here is what I'd like to get out of the environment:
> SSL_CLIENT_S_DN_CN
> SSL_CLIENT_S_DN_O
> and things of that nature. According to mod_ssl's documentation, these
> are put in ENV upon processing of a client certificate. Ideally, I'd
> like to make which fields to extract configurable, so I don't want to
> hard-code.
>
> Currently, I have
> PerlPassEnv SSL_CLIENT_S_DN_O
> PerlPassEnv SSL_CLIENT_S_DN_CN
> in my httpd.conf, but it doesn't seem to make any kind of difference.
> To make sure it isn't just mod_ssl being lame for some reason, I've
> tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
> avail. :(
>
> --Ryan
>
> On Mon, 2003-06-09 at 13:59, Geoffrey Young wrote:
> > Ryan Muldoon wrote:
> > > I'm not able to get *any* variables out from the apache server
> > > environment.
> >
> > ok, first off, this is a two step process for Apache. the first step is
> > that modules (like mod_ssl) populate the subprocess_env table with
various
> > values. then, modules like mod_cgi and mod_perl come along and populate
> > %ENV with the values from subprocess_env as well as various other CGI
> > specific variables (like DOCUMENT_ROOT or whatever else there is). the
> > point is that you're really not after environment variables if you want
to
> > test for something like $r->subprocess_env('HTTPS') - that it ends up as
> > $ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.
> >
> > just for your own edification :)
> >
> > > As you might be able to imagine, this is extremely
> > > frustrating, and inhibits my ability to do anything of use with
> > > mod_perl. My basic technique has been:
> > > my $uri = $r->uri;
> > > return unless $r->is_main();
> > > my $subr = $r->lookup_uri($uri);
> > > my $apachecertcomp = $subr->subprocess_env($certcomponent);
> >
> > I don't understand the need for a subrequest to the same URI -
> > subprocess_env has nothing to do with an actual subprocess. each
request
> > (including subrequests) have their own subprocess_env table attached to
$r.
> > in many cases, modules are coded to behave differently for subrequests
> > than for the main request, so something you may see in
$r->subprocess_env()
> > could not be in $r->lookup_uri($uri)->subprocess_env().
> >
> > > But this doesn't work. I also tried
> > > my $var = $r->subprocess_env("VARIABLE_NAME");
> > > And this does not work either. I really need to be able to use
> > > environment variables that mod_ssl sets in my authentication handler.
> >
> > a few things here too. for the reasons described above,
subprocess_env() is
> > not a substitute for %ENV, so if what you want is a true %ENV value
(such as
> > those from PerlPassEnv), you will not be able to get to it via
> > $r->subprocess_env().
> >
> > > Any ideas? Thanks!
> >
> > HTH
> >
> > --Geoff
> >
> >
> >
>
Re: getting *any* variables out of the server environment
PerlSetEnv works fine. I can't, however, put PerlPassEnv inside either
a Location or Directory block, if that makes any difference. Apache
says it is a configuration error to do so (though PerlSetEnv works
fine).
I've tried every way that I can think of to do
$r->subprocess_env('VARIABLE'), and it definitely does not work. :(
--Ryan
On Mon, 2003-06-09 at 14:04, Perrin Harkins wrote:
> On Mon, 2003-06-09 at 14:49, Ryan Muldoon wrote:
> > I tried that as well (and just re-tried). My understanding is that the
> > %ENV hash only gets updated in the fixup stage, so the mod_ssl
> > environment variables can't be accessed that way. Thanks for the
> > suggestion though!
>
> Okay. And you're certain that a simple $r->subprocess_env('VARIABLE')
> doesn't work? Have you tried setting a variable yourself as a test with
> PerlSetEnv in httpd.conf?
>
> - Perrin
Re: getting *any* variables out of the server environment
> "Ryan" == Ryan Muldoon <[EMAIL PROTECTED]> writes:
Ryan> Geoffrey,
Ryan> Thanks for the explanation. Unfortunately, I think I am still a little
Ryan> unclear as to how to proceed. If I understand you correctly, my first
Ryan> method is completely wrongheaded. (I tried this because it is how the
Ryan> "Writing Apache Modules with Perl and C" does it. p.327) So it sounds
Ryan> like the second way is the appropriate usage for subprocess_env(). But
Ryan> it seems like you're saying that I shouldn't be using that at all.
Ryan> Specifically, here is what I'd like to get out of the environment:
Ryan> SSL_CLIENT_S_DN_CN
Ryan> SSL_CLIENT_S_DN_O
Ryan> and things of that nature. According to mod_ssl's documentation, these
Ryan> are put in ENV upon processing of a client certificate. Ideally, I'd
Ryan> like to make which fields to extract configurable, so I don't want to
Ryan> hard-code.
Well, then, in any handler after the mod_ssl has run, you
should be be able to use $r->subprocess_env("SSL_CLIENT_S_DN_CN")
to get at that info.
Ryan> Currently, I have
Ryan> PerlPassEnv SSL_CLIENT_S_DN_O
Ryan> PerlPassEnv SSL_CLIENT_S_DN_CN
Ryan> in my httpd.conf, but it doesn't seem to make any kind of difference.
Ryan> To make sure it isn't just mod_ssl being lame for some reason, I've
Ryan> tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
Ryan> avail. :(
That takes the enviroment variables that apache was started with
and passes those to mod_perl. Probably not what you want.
(I'm doing this from memory, so please correct me if I'm wrong.)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: getting *any* variables out of the server environment
Geoffrey,
Thanks for the explanation. Unfortunately, I think I am still a little
unclear as to how to proceed. If I understand you correctly, my first
method is completely wrongheaded. (I tried this because it is how the
"Writing Apache Modules with Perl and C" does it. p.327) So it sounds
like the second way is the appropriate usage for subprocess_env(). But
it seems like you're saying that I shouldn't be using that at all.
Specifically, here is what I'd like to get out of the environment:
SSL_CLIENT_S_DN_CN
SSL_CLIENT_S_DN_O
and things of that nature. According to mod_ssl's documentation, these
are put in ENV upon processing of a client certificate. Ideally, I'd
like to make which fields to extract configurable, so I don't want to
hard-code.
Currently, I have
PerlPassEnv SSL_CLIENT_S_DN_O
PerlPassEnv SSL_CLIENT_S_DN_CN
in my httpd.conf, but it doesn't seem to make any kind of difference.
To make sure it isn't just mod_ssl being lame for some reason, I've
tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
avail. :(
--Ryan
On Mon, 2003-06-09 at 13:59, Geoffrey Young wrote:
> Ryan Muldoon wrote:
> > I'm not able to get *any* variables out from the apache server
> > environment.
>
> ok, first off, this is a two step process for Apache. the first step is
> that modules (like mod_ssl) populate the subprocess_env table with various
> values. then, modules like mod_cgi and mod_perl come along and populate
> %ENV with the values from subprocess_env as well as various other CGI
> specific variables (like DOCUMENT_ROOT or whatever else there is). the
> point is that you're really not after environment variables if you want to
> test for something like $r->subprocess_env('HTTPS') - that it ends up as
> $ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.
>
> just for your own edification :)
>
> > As you might be able to imagine, this is extremely
> > frustrating, and inhibits my ability to do anything of use with
> > mod_perl. My basic technique has been:
> > my $uri = $r->uri;
> > return unless $r->is_main();
> > my $subr = $r->lookup_uri($uri);
> > my $apachecertcomp = $subr->subprocess_env($certcomponent);
>
> I don't understand the need for a subrequest to the same URI -
> subprocess_env has nothing to do with an actual subprocess. each request
> (including subrequests) have their own subprocess_env table attached to $r.
> in many cases, modules are coded to behave differently for subrequests
> than for the main request, so something you may see in $r->subprocess_env()
> could not be in $r->lookup_uri($uri)->subprocess_env().
>
> > But this doesn't work. I also tried
> > my $var = $r->subprocess_env("VARIABLE_NAME");
> > And this does not work either. I really need to be able to use
> > environment variables that mod_ssl sets in my authentication handler.
>
> a few things here too. for the reasons described above, subprocess_env() is
> not a substitute for %ENV, so if what you want is a true %ENV value (such as
> those from PerlPassEnv), you will not be able to get to it via
> $r->subprocess_env().
>
> > Any ideas? Thanks!
>
> HTH
>
> --Geoff
>
>
>
Re: getting *any* variables out of the server environment
On Mon, 2003-06-09 at 14:49, Ryan Muldoon wrote:
> I tried that as well (and just re-tried). My understanding is that the
> %ENV hash only gets updated in the fixup stage, so the mod_ssl
> environment variables can't be accessed that way. Thanks for the
> suggestion though!
Okay. And you're certain that a simple $r->subprocess_env('VARIABLE')
doesn't work? Have you tried setting a variable yourself as a test with
PerlSetEnv in httpd.conf?
- Perrin
Re: getting *any* variables out of the server environment
Ryan Muldoon wrote:
I'm not able to get *any* variables out from the apache server
environment.
ok, first off, this is a two step process for Apache. the first step is
that modules (like mod_ssl) populate the subprocess_env table with various
values. then, modules like mod_cgi and mod_perl come along and populate
%ENV with the values from subprocess_env as well as various other CGI
specific variables (like DOCUMENT_ROOT or whatever else there is). the
point is that you're really not after environment variables if you want to
test for something like $r->subprocess_env('HTTPS') - that it ends up as
$ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.
just for your own edification :)
As you might be able to imagine, this is extremely
frustrating, and inhibits my ability to do anything of use with
mod_perl. My basic technique has been:
my $uri = $r->uri;
return unless $r->is_main();
my $subr = $r->lookup_uri($uri);
my $apachecertcomp = $subr->subprocess_env($certcomponent);
I don't understand the need for a subrequest to the same URI -
subprocess_env has nothing to do with an actual subprocess. each request
(including subrequests) have their own subprocess_env table attached to $r.
in many cases, modules are coded to behave differently for subrequests
than for the main request, so something you may see in $r->subprocess_env()
could not be in $r->lookup_uri($uri)->subprocess_env().
But this doesn't work. I also tried
my $var = $r->subprocess_env("VARIABLE_NAME");
And this does not work either. I really need to be able to use
environment variables that mod_ssl sets in my authentication handler.
a few things here too. for the reasons described above, subprocess_env() is
not a substitute for %ENV, so if what you want is a true %ENV value (such as
those from PerlPassEnv), you will not be able to get to it via
$r->subprocess_env().
Any ideas? Thanks!
HTH
--Geoff
RE: getting *any* variables out of the server environment
I'm using mod_perl 1. But I'm setting the handlers in httpd.conf. I
sent a message to the list on thursday ("problem with pulling variables
from mod_ssl") that more fully describes my situtation.
--Ryan
On Mon, 2003-06-09 at 14:31, Marc M. Adkins wrote:
> IF you're using mp2...in your httpd.conf are you setting up the handlers
> with modperl or perl-script? The former doesn't provide any environment
> variables:
>
> http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
>
> I don't believe this applies to mp1.
>
> mma
>
> > -Original Message-
> > From: Ryan Muldoon [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 09, 2003 11:30 AM
> > To: [EMAIL PROTECTED]
> > Subject: getting *any* variables out of the server environment
> >
> >
> > I'm not able to get *any* variables out from the apache server
> > environment. As you might be able to imagine, this is extremely
> > frustrating, and inhibits my ability to do anything of use with
> > mod_perl. My basic technique has been:
> > my $uri = $r->uri;
> > return unless $r->is_main();
> > my $subr = $r->lookup_uri($uri);
> > my $apachecertcomp = $subr->subprocess_env($certcomponent);
> > But this doesn't work. I also tried
> > my $var = $r->subprocess_env("VARIABLE_NAME");
> > And this does not work either. I really need to be able to use
> > environment variables that mod_ssl sets in my authentication handler.
> > Any ideas? Thanks!
> >
> > --Ryan
> >
>
RE: getting *any* variables out of the server environment
IF you're using mp2...in your httpd.conf are you setting up the handlers
with modperl or perl-script? The former doesn't provide any environment
variables:
http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
I don't believe this applies to mp1.
mma
> -Original Message-
> From: Ryan Muldoon [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 09, 2003 11:30 AM
> To: [EMAIL PROTECTED]
> Subject: getting *any* variables out of the server environment
>
>
> I'm not able to get *any* variables out from the apache server
> environment. As you might be able to imagine, this is extremely
> frustrating, and inhibits my ability to do anything of use with
> mod_perl. My basic technique has been:
> my $uri = $r->uri;
> return unless $r->is_main();
> my $subr = $r->lookup_uri($uri);
> my $apachecertcomp = $subr->subprocess_env($certcomponent);
> But this doesn't work. I also tried
> my $var = $r->subprocess_env("VARIABLE_NAME");
> And this does not work either. I really need to be able to use
> environment variables that mod_ssl sets in my authentication handler.
> Any ideas? Thanks!
>
> --Ryan
>
Re: getting *any* variables out of the server environment
I tried that as well (and just re-tried). My understanding is that the
%ENV hash only gets updated in the fixup stage, so the mod_ssl
environment variables can't be accessed that way. Thanks for the
suggestion though!
--Ryan
On Mon, 2003-06-09 at 13:41, Perrin Harkins wrote:
> On Mon, 2003-06-09 at 14:29, Ryan Muldoon wrote:
> > I'm not able to get *any* variables out from the apache server
> > environment.
>
> Did you try the normal $ENV{'VARIABLE'} approach?
>
> - Perrin
Re: getting *any* variables out of the server environment
On Mon, 2003-06-09 at 14:29, Ryan Muldoon wrote:
> I'm not able to get *any* variables out from the apache server
> environment.
Did you try the normal $ENV{'VARIABLE'} approach?
- Perrin
getting *any* variables out of the server environment
I'm not able to get *any* variables out from the apache server
environment. As you might be able to imagine, this is extremely
frustrating, and inhibits my ability to do anything of use with
mod_perl. My basic technique has been:
my $uri = $r->uri;
return unless $r->is_main();
my $subr = $r->lookup_uri($uri);
my $apachecertcomp = $subr->subprocess_env($certcomponent);
But this doesn't work. I also tried
my $var = $r->subprocess_env("VARIABLE_NAME");
And this does not work either. I really need to be able to use
environment variables that mod_ssl sets in my authentication handler.
Any ideas? Thanks!
--Ryan
Re: modules that work with both modperl1 and 2
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
> Yeah, I've been messing with that, but it seems to me that I need
> something similar to a preprocessor directive, where I can load the
> appropriate "use MODULE" lines into the module bases upon which version
> of modperl they have installed. Is it possible to use the BEGIN {}
> subroutine as this?
You don't need a preprocessor. You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:
if ($mod_perl::VERSION >= 1.99) {
require Apache2::Module;
import Apache2::Module;
} else {
require Apache1::Module;
import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to. That
will make it run before the rest of the code in the current package.
- Perrin
Re: modules that work with both modperl1 and 2
Perrin Harkins wrote:
On Mon, 2003-06-09 at 12:12, Shannon Eric Peevey wrote:
PS Am having problems with the compile time loading of modules depending
on the existence of either modperl1 or 2... "use" dies and "require" is
not importing the symbols correctly at runtime...
If you read the docs for "use" (perldoc -f use), you will see that "use"
is just like:
BEGIN { require Module; import Module LIST; }
If you want to import things correctly when using require, you have to
call import yourself.
- Perrin
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate "use MODULE" lines into the module bases upon which version
of modperl they have installed. Is it possible to use the BEGIN {}
subroutine as this?
speeves
cws
Re: Compling mod_perl as a static module....
Ged, This is what the make output shows... I've read the docs. Perhaps I need to try compiling mod_perl with a different method (I recall a build option with apxs, outside of the apache src tree). o perl_module uses ConfigStart/End + mod_perl build type: DSO + setting up mod_perl build environment + id: mod_perl/1.27 + id: Perl/v5.8.0 (freebsd) [/usr/local/bin/perl] Here are the makepl flags I have thus far: USE_DSO=0 DYNAMIC=0 USE_APACI=1 APACHE_PREFIX=/usr/local/apache APACHE_SRC=../apache_1.3.27/src DO_HTTPD=1 EVERYTHING=1 ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1 APACI_ARGS=--with-perl=/usr/local/bin/perl APACI_ARGS=--enable-module=rewrite APACI_ARGS=--enable-module=include APACI_ARGS=--enable-module=info APACI_ARGS=--enable-module=usertrack APACI_ARGS=--server-gid=nogroup APACI_ARGS=--suexec-docroot=/usr/local/apache/htdocs APACI_ARGS=--enable-module=most APACI_ARGS=--enable-module=auth_db APACI_ARGS=--enable-module=mmap_static APACI_ARGS=--enable-shared=max APACI_ARGS=--enable-module=ssl APACI_ARGS=--enable-rule=SHARED_CORE APACI_ARGS=--activate-module=src/modules/dosevasive/libdosevasive.a
Re: modules that work with both modperl1 and 2
On Mon, 2003-06-09 at 12:12, Shannon Eric Peevey wrote:
> PS Am having problems with the compile time loading of modules depending
> on the existence of either modperl1 or 2... "use" dies and "require" is
> not importing the symbols correctly at runtime...
If you read the docs for "use" (perldoc -f use), you will see that "use"
is just like:
BEGIN { require Module; import Module LIST; }
If you want to import things correctly when using require, you have to
call import yourself.
- Perrin
modules that work with both modperl1 and 2
Hi! Just wondering if anyone knows of a perl module that is coded to work with modperl1 and 2? I am hitting a wall in getting my module to do that, and want to cheat a little off of someone who already has... ;) thanks, speeves cws PS Am having problems with the compile time loading of modules depending on the existence of either modperl1 or 2... "use" dies and "require" is not importing the symbols correctly at runtime... My bad for not completely understanding how to use "require". (Am trying to work this out as we speak.) Thanks again!
Re: PERL/java interface available?
At 07:34 2003-06-09 -0600, you wrote: Would anyone happen to know if there is a PERL/java interface where these two languages could talk to each other? Java can call any native function that's packaged in a dso or dll. (But is it possible to compile Perl modules to standalone dso?) Did anyone mention B::JVM::Jasmin or JPL? See links below... -Mark - Porting Perl to the Java Virtual Machine http://www.ebb.org/bkuhn/writings/technical/thesis More about JPL http://www.oreilly.com/catalog/prkunix/info/more_jpl.html Java Native Interface Tutorial http://java.sun.com/docs/books/tutorial/native1.1/
Re: PERL/java interface available?
I believe there's a Java.pm module on CPAN that will allow a perl program to instantiate java objects and call methods on them. That may or may not be enough intercommunication for what you need. Wes Sheldahl "Charlie Smith" <[EMAIL PROTECTED]> on 06/09/2003 09:34:04 AM To:[EMAIL PROTECTED] cc: Subject:PERL/java interface available? Would anyone happen to know if there is a PERL/java interface where these two languages could talk to each other? Charlie -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ==
Re: PERL/java interface available?
- Original Message - From: "Charlie Smith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 09, 2003 3:34 AM Subject: PERL/java interface available? Would anyone happen to know if there is a PERL/java interface where these two languages could talk to each other? Charlie Hi Charlie: Check out the 'Inline' modules on CPAN: http://search.cpan.org/author/INGY/Inline-0.44/Inline.pod You also may want to look at SWIG at: http://www.swig.org/ I have used Inline::C and SWIG for c and c++, but not for java; but they say they work... Aloha => Beau; PS: The 'Inline' modules are neat because your code is just that - inline; it's easier to see what's going on.
Re: Compling mod_perl as a static module....
At 03:26 AM 6/9/2003, Ged Haywood wrote: Hi there, On Sun, 8 Jun 2003, Forrest Aldrich wrote: > I want to try compiling mod_perl statically What's the question? 73, Ged. [ ... ] Referring back to my original post, it with the options I specified, the compile process still insists on compiling mod_perl as a DSO. Even if I explicitly set USE_DSO=0 -- I wonder if one of the other flags (like EVERYTHING=1) is triggering the DSO compile. This seems to be very tricky. _F
Re: [mp2] make test fails with 1.99_10-dev sources on redhat
On Saturday at 9:22am, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote: SB> I think the issue is very simple: @INC had system libraries dirs SB> before the freshly build ones, so dumping @INC contents prior to libs SB> loading should aid the debug. But please use the latest cvs, since SB> I've messed with @INC a bit recently. SB> SB> In parallel, we are planning to verify .so objects that they were SB> created by the same mod_perl.so to avoid completely this kind of SB> problems. Well it won't prevent the pickup of wrong libraries, it'll SB> just scream aloud when this will happen. So your debug is still very SB> important. SB> Seeing that you were answering emails even on a Saturday, I feel guilty about taking that out of town trip yesterday. Oh well! I think we should be able to enjoy the little bit of summer that we get here in Canada to the fullest. Now onto serious stuff. /usr/bin/perl here is the system-wide perl install that came bundled with Redhat. /usr/bin/perl -MApache2 -Mmod_perl -le 'print mod_perl->VERSION' 1.9908 I posted t/REPORT output in the beginning of the thread and can repost upon request. I did a cvs up, and issued: * /usr/bin/perl Makefile.PL MP_AP_PREFIX=/servers/httpd-2.0.44-pl * make * make test and was greeted by the now familiar output (same as originally reported) /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean sh: line 1: ulimit: core file size: cannot modify limit: Operation not permitted APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 sh: line 1: ulimit: core file size: cannot modify limit: Operation not permitted /servers/httpd-2.0.44-pl/bin/httpd -d /home/haroon/src/build/modperl-2.0/t -f /home/haroon/src/build/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS using Apache/2.0.44 (prefork MPM) waiting for server to start: ..[Mon Jun 09 09:38:20 2003] [info] 22 Apache:: modules loaded [Mon Jun 09 09:38:20 2003] [info] 5 APR:: modules loaded [Mon Jun 09 09:38:20 2003] [info] base server + 9 vhosts ready to run tests [Mon Jun 09 09:38:20 2003] [error] Invalid CODE attribute: TestFilter::in_init_basic at /home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm line 30 BEGIN failed--compilation aborted at /home/haroon/src/build/modperl-2.0/t/filter/TestFilter/in_init_basic.pm line 30. Compilation failed in require at (eval 35) line 3. [Mon Jun 09 09:38:20 2003] [error] Can't load Perl module TestFilter::in_init_basic for server localhost.localdomain:8529, exiting... !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 Thanks, -- Haroon Rafique <[EMAIL PROTECTED]>
Re: is anybody using mp2 in production?
- Original Message - From: "Chris Faust" <[EMAIL PROTECTED]> To: "Sreeji K Das" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, June 09, 2003 3:20 AM Subject: Re: is anybody using mp2 in production? > > (Btw, Chris, are you using the worker mpm ? Is it > > stable ? We'd like to go the worker mpm way & would > > like to know if any1 is using it yet in production.) > > > > On our dev server yes, and all seems well - but we haven't rolled it out in > production yet. Its one of those things we want to do but keep getting side > tracked with something else. > Sooner then later we will be giving it a shot though. > > I'd be interested in what you thought of the switch after going live, we > were never sure (but getting there now) if we should have started with MP2 > or not, never got a chance to see MP1 in action. > > -Chris > Hi - My low-volume personal site has been on Apache2-mp2-mason since October 2002 - no problems (other than the ones I caused). In April I put one of my clients up with the same setup; another in May. (I pried both away from M$ IIS!) Although both are small company low-volume sites, they seem to be running without problems - knock on wood. All sites mentioned above are running SuSE 8.2 Linux. Aloha => Beau; By the way, have you ever tried to explain the idom "knock on wood" to someone for whom English is not their first language? I have been trying to explain it to my wife - from Japan - for ten years now without success :)
PERL/java interface available?
Would anyone happen to know if there is a PERL/java interface where these two languages could talk to each other? Charlie -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ==
Re: is anybody using mp2 in production?
> (Btw, Chris, are you using the worker mpm ? Is it > stable ? We'd like to go the worker mpm way & would > like to know if any1 is using it yet in production.) > On our dev server yes, and all seems well - but we haven't rolled it out in production yet. Its one of those things we want to do but keep getting side tracked with something else. Sooner then later we will be giving it a shot though. I'd be interested in what you thought of the switch after going live, we were never sure (but getting there now) if we should have started with MP2 or not, never got a chance to see MP1 in action. -Chris
Re: Fw: [OT] [Perl] HTML::Mason help anyone?
Ged Haywood wrote: [snip] >>>I have a simple form [snip] >>>The problem is that I only see the values printed when I use the "GET" >>>option in the form above, when I change "GET" to "POST" nothing gets >>>printed... >>POST data can only be read once, if you want to read it again you have >>to save it somewhere. It looks to me like before you try to read it, >>it's being read by something else and therefore lost to you. >>This question seems to crop up quite a lot (if this is the right answer:) >Off topic for the perl list but since you all saw the question... >The problem was related to the form's enctype specifier, I saw an error message in the apache log > >" [libapreq] unknown content-type: `text/plain'" > >Now I'm not really sure where the variables disappeared to (an explanation would be kind) but as soon >as I removed this specifier the data started showing up right in the handler even when using >"POST".. >anyone care to explain this please? Hmm... That looks like the form is not being submitted properly. When you submit a form, it can encode it in a number of ways. The most popular standard way is to use application/x-www-form-urlencoded (which means that the POST content is formatted to look like a query string: param=some+value&otherparam=anotherval) or, if there's an upload, mutlipart/form-data (which makes the POST data resemble a MIME email with boundaries). If you specify another type, then libapreq might chocke on it, not knowing how to interpret the data it recieves. Does that help a bit? Issac
Re: Fw: [Perl] HTML::Mason help anyone?
Hi there, On Mon, 9 Jun 2003, Issac Goldstand wrote: > Forwarded from the Israeli Perl Mongers mailing list: > > - Original Message - > From: "Ron" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, June 09, 2003 1:48 PM > Subject: [Perl] HTML::Mason help anyone? > > > > I have a simple form [snip] > > The problem is that I only see the values printed when I use the "GET" > > option in the form above, when I change "GET" to "POST" nothing gets > > printed... POST data can only be read once, if you want to read it again you have to save it somewhere. It looks to me like before you try to read it, it's being read by something else and therefore lost to you. This question seems to crop up quite a lot (if this is the right answer:) 73, Ged.
Fw: [Perl] HTML::Mason help anyone?
Forwarded from the Israeli Perl Mongers mailing list:
- Original Message -
From: "Ron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 09, 2003 1:48 PM
Subject: [Perl] HTML::Mason help anyone?
> I have a simple form that looks like so:
>
> enctype="text/plain">
>
>
>
>
> all HTML files are processed by Mason using the directive
> in httpd.conf
>
> and my simple handler object simply does:
>
> % foreach (sort %ARGS) {
><% $_ %>
> % }
>
> The problem is that I only see the values printed when I use the "GET"
> option in the form above, when I change "GET" to "POST" nothing gets
> printed... what am I doing wrong? it seams to me that Mason is not
> seeing any posted data...
>
> Thanks
> Ron.
>
> ___
> Perl mailing list
> [EMAIL PROTECTED]
> http://www.perl.org.il/mailman/listinfo/perl
>
Re: Compling mod_perl as a static module....
Hi there, On Sun, 8 Jun 2003, Forrest Aldrich wrote: > I want to try compiling mod_perl statically What's the question? 73, Ged.
