Re: do I really need "mod_perl"
Wow! Hey, that really did explain it. Thanks. On Sat, 30 Dec 2000, John K Sterling wrote: > read this: http://take23.org/whatis_mod_perl.xml > > it should explain all. > > sterling > > > Yung Kwong Wing wrote: > > > Hi, > > > > Sorry for asking a stupid question, but I was wondering do I really need > > to install "mod_perl" to get my website to work with CGI. > > > > It seems that after my unsuccessful attempt at installing "mod_perl", I > > can use the Perl interpreter just fine and I can use the CGI-bin just fine > > also. > > > > I have placed my observations and records in the following URL: > > http://home.netvigator.com/~yungp/my_perl.html > > > > If you look at the observations and records under the date "Dec 30, 2000", > > you will see the modules that are currently installed and that my CGI > > works just fine without "mod_perl" > > > > If anyone can shed the light on this mystery to me, it would be greatly > > appreciated. > > > > Thanks > > > > Peter > > >
trouble with Rewrite
I have the following in a virtual host
RewriteEngine on
RewriteLog "logs/rewrite.log"
RewriteLogLevel 9
# redirect URL's on that exist on the secure side
RewriteCond /rc/manage$2!-d
RewriteRule ^(/rc/manage)(/.+).*
https://%{SERVER_NAME}%{REQUEST_URI}
The log say:
applying pattern '^(/rc/manage)(/.+).*' to uri '/rc/manage/animals/'
RewriteCond: input='/rc/manage' pattern='!-d' => matched
rewrite /rc/manage/animals/ ->
https://spcamc.is.bizsystems.com/rc/manage/animals/
then it does the redirect.
Problems at log line
2)The pattern $2 does not show up in the log
3) !-d matches even though /rc/manage exists and is a directory
Question?? What's wrong with the above scenario??
[EMAIL PROTECTED]
Re: Apache::Request and redirects
On Sat, 30 Dec 2000, Matt Sergeant wrote:
> > Another minor issue is that Apache::Request is not trivially subclassed,
> > the returned value from $self->SUPER::new() must be reblessed into the
> > desired class.
>
> Thats a pretty standard perl idiom:
>
> sub new {
> my $class = shift;
> my $self = $class->SUPER::new;
> bless $self, $class;
> }
Well, a package is generally expected to bless its objects into the value
of $class, not the value of __PACKAGE__. You shouldn't have to override
the constructor simply to rebless the object.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: do I really need "mod_perl"
On Sat, Dec 30, 2000 at 12:18:00PM -0800, John K Sterling wrote: > read this: http://take23.org/whatis_mod_perl.xml > > it should explain all. > > sterling An excellent link. > Yung Kwong Wing wrote: > > > Hi, > > > > Sorry for asking a stupid question, but I was wondering do I really need > > to install "mod_perl" to get my website to work with CGI. [ ... ] > > If anyone can shed the light on this mystery to me, it would be greatly > > appreciated. Obviously, you know after reading the above link you don't need mod_perl to run standard perl-written cgi's. One of the additional benefits not mentioned in that article is Embperl. Embperl is a nifty little tool that let's you embed server side interpreted perl in a normal .html document. Very handy indeed! In order for Embperl to work, however, mod_perl must be installed. Enjoy. :) - Myrddin -- ICQ: 22404528 Why Vegan? http://www.firstmagic.com/vegan --
Re: do I really need "mod_perl"
read this: http://take23.org/whatis_mod_perl.xml it should explain all. sterling Yung Kwong Wing wrote: > Hi, > > Sorry for asking a stupid question, but I was wondering do I really need > to install "mod_perl" to get my website to work with CGI. > > It seems that after my unsuccessful attempt at installing "mod_perl", I > can use the Perl interpreter just fine and I can use the CGI-bin just fine > also. > > I have placed my observations and records in the following URL: > http://home.netvigator.com/~yungp/my_perl.html > > If you look at the observations and records under the date "Dec 30, 2000", > you will see the modules that are currently installed and that my CGI > works just fine without "mod_perl" > > If anyone can shed the light on this mystery to me, it would be greatly > appreciated. > > Thanks > > Peter
do I really need "mod_perl"
Hi, Sorry for asking a stupid question, but I was wondering do I really need to install "mod_perl" to get my website to work with CGI. It seems that after my unsuccessful attempt at installing "mod_perl", I can use the Perl interpreter just fine and I can use the CGI-bin just fine also. I have placed my observations and records in the following URL: http://home.netvigator.com/~yungp/my_perl.html If you look at the observations and records under the date "Dec 30, 2000", you will see the modules that are currently installed and that my CGI works just fine without "mod_perl" If anyone can shed the light on this mystery to me, it would be greatly appreciated. Thanks Peter
Re: Apache::Request and redirects
On Sun, 24 Dec 2000, Shevek wrote:
> I want the parameters from the first request to be preserved into the
> subrequest.
Store in a global variable then:
$MyPackage::request = $apr;
Then access in the internal redirect.
> Another minor issue is that Apache::Request is not trivially subclassed,
> the returned value from $self->SUPER::new() must be reblessed into the
> desired class.
Thats a pretty standard perl idiom:
sub new {
my $class = shift;
my $self = $class->SUPER::new;
bless $self, $class;
}
--
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: problems with mod_perl
Hi there, On Sat, 30 Dec 2000, Yung Kwong Wing wrote: > OH I forgot to ask. How do I install the libww and the required HTML > modules? Exactly what modules do they need? # perl -MCPAN -eshell > > Also, be sure to so a "make install" from the mod_perl directory before Check the Eagle Book and the Guide for installation instructions: htp://perl.apache.org/guide 73, Ged.
Re: getting rid of nested sub lexical problem
On Thu, 21 Dec 2000, Doug MacEachern wrote:
> On Thu, 19 Oct 2000, Chris Nokleberg wrote:
>
> > Following up on my post on this subject a couple of months ago, here is a
> > proof-of-concept drop-in replacement for Apache::Registry that eliminates
> > the "my() Scoped Variable in Nested Subroutine" problem.
>
> nice hack!
>
> > It requires PERL5OPT = "-d" and PERL5DB = "sub DB::DB {}" environment
> > variables set when starting the mod_perl-enabled httpd. This enables the
> > %DB::sub hash table that holds subroutine start and end line info. I
> > presume that this has some negative (marginal?) impact on performance. If
> > someone knows of a better way to reliably figure out where a subroutine
> > starts and ends, please let me know.
>
> there is quite a bit of overhead when -d is enabled. have a look at
> Apache::DB.xs, there's in init_debugger() function todo what -d does. if
> another method was added to turn it off, after the registry script was
> compiled, the overhead would be reduced a great deal.
oooh, cool. I've added this to Apache::DB.xs:
int
stop_debugger()
CODE:
if (PL_perldb) {
PL_perldb = 0;
RETVAL = TRUE;
}
else
RETVAL = FALSE;
OUTPUT:
RETVAL
It appears that setting PL_perldb to zero is all that's required to turn
off the debugger! I thought I might have to fiddle with the symbol tables
but this seems to work.
I've attached the latest version of Apache::NiceRegistry (suggestions
welcome) below. Not sure this is the right thing to do , but I call
Apache::DB::init_debugger directly because I need the return value (don't
want to stop_debugger if it was turned on outside of this handler), and I
don't want the warning that Apache::DB->init produces.
Also, why does Apache::DB unset $Apache::Registry::MarkLine?
Thanks,
Chris
--
package Apache::NiceRegistry;
use base Apache::RegistryNG;
use strict;
use Apache::DB ();
$Apache::Registry::MarkLine = 1;
my %skip_subs = map { $_ => 1 } qw( handler BEGIN END CHECK INIT );
sub compile {
my ($pr, $eval) = @_;
$eval ||= $pr->{'sub'};
my $init_db = Apache::DB::init_debugger();
$pr->SUPER::compile($eval);
Apache::DB::stop_debugger() if $init_db;
my $package = $pr->namespace;
my @lines = split /\n/, $$eval;
foreach my $sub (grep /^$\Qpackage\E/, keys %DB::sub) {
my ($name) = $sub =~ /:([^:]+)$/;
next if $skip_subs{$name};
my ($start, $end) = $DB::sub{$sub} =~ /:(\d+)-(\d+)$/;
$lines[$start + 1] =~ s:(sub[^\{]+\{):$1&\{sub\{:;
$lines[$end + 1] =~ s:\}(?!.*\})$:\}\}\}:;
}
$$eval = join "\n", @lines;
$pr->flush_namespace($package);
$pr->SUPER::compile($eval);
}
1;
