RE: Taint
-Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, October 02, 2000 12:59 PM To: '[EMAIL PROTECTED]' Subject: Taint A couple of questions about taint checking. 1) What is the default taint check setting? off 2) Does compiling mod_perl with EVERYTHING=1 make a difference to the taint setting? no 3) Does 'PerlTaintCheck Off' actually work? yes 4) How do I check the taint setting at run-time from a perl handler? I'm not sure that you can. PerlTaintCheck On or Off applies to all perl scripts/handlers... see http://perl.apache.org/guide/porting.html#Taint_Mode HTH --Geoff Thanks! Jack Herrington Engineering Manager Certive - Building the world's first broadband B2B network (650) 701-8809
RE: Taint
no, the other compile time :) see camel 3rd ed chapter 18 for compile v run-time distinctions, esp p467 --Geoff -Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, October 02, 2000 2:05 PM To: 'Vivek Khera' Cc: '[EMAIL PROTECTED]' Subject: RE: Taint Compile-time? You mean, when I compile Perl 5.6 I can permanently disable taint checking? -Original Message- From: Vivek Khera [mailto:[EMAIL PROTECTED]] Sent: Monday, October 02, 2000 11:04 AM To: Herrington, Jack Cc: '[EMAIL PROTECTED]' Subject: RE: Taint "HJ" == Herrington, Jack [EMAIL PROTECTED] writes: HJ Is there a way to enable and disable taint checking at run-time? No; taint mode is a Perl compile time decision.
RE: Undefined subroutine error (only now and then)
-Original Message- From: Paulo Narciso Filho [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 28, 2000 12:23 PM To: [EMAIL PROTECTED] Subject: Undefined subroutine error (only now and then) I'm using Apache and mod_perl to develop a dynamic web site. When I execute a specific script for the first time (after restarting Apache, for instance), it always works. If I reload the page, I (sometimes) get the following message in my apache error log: [error] Undefined subroutine Apache::ROOTagv_2eembra co::perl::agvs::agvs_2ecgi::GetUser called at (file_location) line 19, frame2 chunk 35. I think this is related to Apache::StatINC - I've seen it now and again when using StatINC, and IIRC it has been reported by others on the list... StatINC is only really for development anyway - you may want to check out Apache::Reload as a StatINC substitute if it's really bothersome. HTH --Geoff The subroutine is there (it executes in the first time). If I keep trying to reload the page, sometimes it works, sometimes it doesn't. The same error happens to other scripts, with different subroutines being called, but never happens if I run them from the command line (with the scripts slightly modified). some things from the server configuration: PerlInitHandler Apache::StatINC Location stuff SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all PerlSendHeader on Can anyone help? Thanx Paulo
RE: Apache::Request-new() problem
-Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, September 25, 2000 10:36 PM To: [EMAIL PROTECTED] Subject: Apache::Request-new() problem I have the same problem as one of the previous reporters with Apache::Request-new(). The problem occurs whether I call it after a 'use' or after a 'PerlModule' load. Perl returns the no 'new' method could be found for Apache::Request. My setup is: Apache 1.3.12 mod_perl 1.24 Perl 6.5 Redhat 6.2 libapreq 0.31 Both Apache::Request and Apache::Cookie exhibit the same symptoms, and simply running this Perl script: use Apache::Request; my $apr = Apache::Request-new( $r ); Gives exactly the same response (as opposed to complaining about the unititliazed $r). Is there anywhere I can locate the original Apache::Request all-Perl code? well, if you don't have that, then you likely don't have Apache::Request or Apache::Cookie - they aren't part of the mod_perl distribution :) you need libapreq, which can be found under the Apache tree on CPAN HTH --Geoff Jack Herrington Engineering Manager Certive - Building the world's first broadband B2B network (650) 701-8809
RE: Apache::Request-new() problem
-Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 26, 2000 12:17 PM To: [EMAIL PROTECTED] Subject: RE: Apache::Request-new() problem well, if you don't have that, then you likely don't have Apache::Request or Apache::Cookie - they aren't part of the mod_perl distribution :) you need libapreq, which can be found under the Apache tree on CPAN libapreq appears to come with Bundle::Apache, but I also downloaded it seperately and installed it directly. oh, ok... if running from Registry, try this: #!/usr/bin/perl use strict; use Apache::Request; my $apr = Apache::Request-new(shift); if that fails, start checking the usual suspects: libapreq was built, but not actually installed in perl's @INC mod_perl wasn't built with EVERYTHING=1 (I'm not sure whether libapreq needs PERL_TABLE_API=1 or not) those ought to help some... if that fails, send the exact script, OS, build options, actual error messages, etc... My thinking is that the XS code isn't working with Perl 5.6. I have it working with 5.6 on linux just fine... There are other XS based libraries that are working (like MD5), but this one refuses to work. HTH --Geoff
RE: Scheduling an Apache child for termination/influence MaxRequestsPerChild counter
-Original Message- From: Ime Smits [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 26, 2000 12:57 PM To: [EMAIL PROTECTED] Subject: Scheduling an Apache child for termination/influence MaxRequestsPerChild counter Hi, I wonder if it's possible to somehow alter Apache's internal counter matched against MaxRequestPerChild or schedule the launching of a new child from withing mod_perl. The reason I want to do this, is that in the administrator section of my website, quite some stuff gets cached from the PostgreSQL backend on a per process basis and there is really no use to keep all those caches after the administrator hit the logout button. http://perl.apache.org/guide/porting.html#Terminating_requests_and_process see the part on child_terminate() HTH --Geoff Plus, I want to be able to terminate a process if some kind cache inconsistency is detected. I know it's better to track the origin of that inconsistency and fix it there, but I'm using some modules which I did not create myself and I'm not planning to dig into 5000+ lines of code I did not wrote. What I really would like to do is to just finish the current page, dropping a line like "things are getting fishy here", wipe the administrator's session cookie and let the child die. Ime
RE: PerlAddVar bug
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 26, 2000 2:35 PM
To: Geoffrey Young
Cc: 'Eric Cholet'; Matt Sergeant; [EMAIL PROTECTED]
Subject: RE: PerlAddVar bug
On Thu, 6 Jul 2000, Geoffrey Young wrote:
I guess my expectation is that $r-dir_config('MyVar') and
$r-dir_config-get('MyVar') should inherit equally, which
as far as I can
tell, they don't. PerlSetVar or PerlAddVar - it makes no
difference.
the problem is related to the Apache::Server-dir_config
support. in the
directive handler, if path was NULL, the var was set/add-ed
only to the
server_rec-module_config. $r-dir_config falls back to the
server_rec-module_config if the var is not found in
request_rec-per_dir_config, but $r-dir_config-get does
not. the patch
below fixes the problem, works just as PerlSetEnv does. the
key/val is
always added to the per-dir table, and also added to the
per-server table
is path == NULL, for use at startup time.
groovy - the patch seems to work just fine (you've been busy, it seems :)
p.s.
i also just committed a change so PerlAddVar is now an ITERATE2 rather
than TAKE 2, so you can say:
PerlAddVar Key val-one val-two val-three
that works ok too.
Any particular reason for keeping PerlSetVar TAKE2?
anyway, thanks again for the efforts
--Geoff
Index: src/modules/perl/perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.102
diff -u -r1.102 perl_config.c
--- src/modules/perl/perl_config.c2000/09/22 18:52:00 1.102
+++ src/modules/perl/perl_config.c2000/09/26 18:29:51
@@ -717,17 +717,17 @@
CHAR_P perl_cmd_var(cmd_parms *cmd, void *config, char *key,
char *val)
{
+perl_dir_config *rec = (perl_dir_config *)config;
MP_TRACE_d(fprintf(stderr, "perl_cmd_var: '%s' =
'%s'\n", key, val));
-if (cmd-path) {
-perl_dir_config *rec = (perl_dir_config *) config;
-if (cmd-info) {
-table_add(rec-vars, key, val);
-}
-else {
-table_set(rec-vars, key, val);
-}
+
+if (cmd-info) {
+table_add(rec-vars, key, val);
}
else {
+table_set(rec-vars, key, val);
+}
+
+if (cmd-path == NULL) {
dPSRV(cmd-server);
if (cmd-info) {
table_add(cls-vars, key, val);
RE: [slightly OT] cache refusal problem with IE, http headers
I know this thread is rather lengthy, and took a few turns along the way,
but I ran across this link the other day and thought it might be of use for
everyone on the list - it's an official explanation of how IE handlers
caching via headers. there's also a few links in it that are worth noting
as well...
http://support.microsoft.com/support/kb/articles/Q234/0/67.ASP
HTH
--Geoff
-Original Message-
From: Ime Smits [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 19, 2000 5:41 AM
To: [EMAIL PROTECTED]
Subject: [slightly OT] cache refusal problem with IE, http headers
Hi,
I tried to nail this problem down for over 6 hours now. I use GD.pm to
dynamically generate images used in a dynamically generated
Apache::ASP
page. Each image is given a name which is unique (in fact: a
md5 on the
original name, width, height, color depth). Some of these
images are used in
a javascript onMouseOver. The images are send out to the browser via a
script, with the unique id as $ENV{PATH_INFO}.
Now the odd thing is, both IE's I tried (4.01 and 5.5) seem
to /refuse/ to
cache the image oppsed to all Netscape versions, which handle
things like
expected. After searching deja, I found out that more people had this
problem, but I only read about javascript preloading and stuff. That's
already been taken care off. If I take a copy of those images
and let Apache
handle the request directly from disk, everything is ok.
So I started to get suspicious about headers. I thought maybe
IE was choking
on the session-id cookie from Apache::ASP, so I rewrote the
Apache::ASP
gateway to plain mod_perl. I messed around with headers, even read
http://perl.apache.org/guide/correct_headers.html three
times, but nothing
fixed my problem so far.
I know the problem is not really mod_perl related. I agree on
the fact that
this is probably a typical Microsoft inconsistancy. Maybe
some of you have
had the same problem.
Below is a sample of the headers it returns. Any ideas?
Anything that is
communicated without me seeing it?
Thanks,
Ime
[ime@nobel /tmp]$ wget -S
http://192.168.31.1/mediaexporter.pl/ef6880b34b91e817f8c9973f0
e7efe10.png
--10:55:32--
http://192.168.31.1:80/mediaexporter.pl/ef6880b34b91e817f8c9973f0e7efe10.png
= `ef6880b34b91e817f8c9973f0e7efe10.png.86'
Connecting to 192.168.31.1:80... connected!
HTTP request sent, awaiting response... 200 OK
2 Date: Tue, 19 Sep 2000 09:21:34 GMT
3 Server: Apache/1.3.12 (Unix) mod_perl/1.21_03
4 Expires: Thu, 19 Oct 2000 08:52:50 GMT
5 Last-Modified: Tue, 19 Sep 2000 09:20:46 GMT
6 Cache-Control: public
7 ETag: ef6880b34b91e817f8c9973f0e7efe10
8 Content-Length: 294
9 Connection: close
10 Content-Type: image/png
and here for the same image, but as a normal static file fron disk:
HTTP request sent, awaiting response... 200 OK
2 Date: Tue, 19 Sep 2000 09:22:50 GMT
3 Last-Modified: Tue, 19 Sep 2000 09:22:10 GMT
4 Server: Apache/1.3.9 (Unix) mod_perl/1.21_03
5 ETag: "477b1-147-39b3889d"
6 Accept-Ranges: bytes
7 Connection: close
8 Content-Length: 327
9 Content-Type: image/png
RE: cvs commit: modperl/src/modules/perl mod_perl.h perl_config.c
pardon my being away, but does this mean that the earlier (possible) fix
Apache::ModuleConfig-get($r, __PACKAGE__)
was not the cause of the error, or that it was and the __PACKAGE__ part is
not necessary now?
I was wondering whether to fix my calls for people who weren't up to cvs
speed...
--Geoff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 22, 2000 2:52 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: modperl/src/modules/perl mod_perl.h perl_config.c
dougm 00/09/22 11:52:04
Modified:.Changes
src/modules/perl mod_perl.h perl_config.c
Log:
plug leak in DIR_MERGE
rename mod_perl_cleanup_av - mod_perl_cleanup_sv
Revision ChangesPath
1.517 +2 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.516
retrieving revision 1.517
diff -u -r1.516 -r1.517
--- Changes 2000/09/13 07:48:55 1.516
+++ Changes 2000/09/22 18:51:52 1.517
@@ -10,6 +10,8 @@
=item 1.24_01-dev
+plug leak in DIR_MERGE, thanks to Matt Sergeant for the spot
+
fixes to run and pass 'make test' on ActivePerl [Randy
Kobes, Gerald Richter]
Makefile.PL:post_initialize fix for win32, thanks to john
sterling for
1.103 +1 -1 modperl/src/modules/perl/mod_perl.h
Index: mod_perl.h
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.h,v
retrieving revision 1.102
retrieving revision 1.103
diff -u -r1.102 -r1.103
--- mod_perl.h 2000/08/15 19:36:33 1.102
+++ mod_perl.h 2000/09/22 18:51:59 1.103
@@ -1132,7 +1132,7 @@
void perl_setup_env(request_rec *r);
SV *perl_bless_request_rec(request_rec *);
void perl_set_request_rec(request_rec *);
-void mod_perl_cleanup_av(void *data);
+void mod_perl_cleanup_sv(void *data);
void mod_perl_cleanup_handler(void *data);
void mod_perl_end_cleanup(void *data);
void mod_perl_register_cleanup(request_rec *r, SV *sv);
1.102 +18 -11modperl/src/modules/perl/perl_config.c
Index: perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.101
retrieving revision 1.102
diff -u -r1.101 -r1.102
--- perl_config.c 2000/08/15 19:36:33 1.101
+++ perl_config.c 2000/09/22 18:52:00 1.102
@@ -436,7 +436,7 @@
sva = newSVpv(arg,0);
if(!*cmd) {
*cmd = newAV();
- register_cleanup(p, (void*)*cmd, mod_perl_cleanup_av,
mod_perl_noop);
+ register_cleanup(p, (void*)*cmd, mod_perl_cleanup_sv,
mod_perl_noop);
MP_TRACE_d(fprintf(stderr, "init `%s' stack\n", hook));
}
MP_TRACE_d(fprintf(stderr, "perl_cmd_push_handlers:
@%s, '%s'\n", hook, arg));
@@ -823,13 +823,13 @@
return NULL;
}
-void mod_perl_cleanup_av(void *data)
+void mod_perl_cleanup_sv(void *data)
{
-AV *av = (AV*)data;
-if(SvREFCNT((SV*)av)) {
- MP_TRACE_g(fprintf(stderr, "cleanup_av: SvREFCNT(0x%lx)==%d\n",
- (unsigned long)av, (int)SvREFCNT((SV*)av)));
- SvREFCNT_dec((SV*)av);
+SV *sv = (SV*)data;
+if (SvREFCNT(sv)) {
+MP_TRACE_g(fprintf(stderr, "cleanup_sv:
SvREFCNT(0x%lx)==%d\n",
+ (unsigned long)sv, (int)SvREFCNT(sv)));
+SvREFCNT_dec(sv);
}
}
@@ -929,7 +929,7 @@
*basevp = (mod_perl_perl_dir_config *)basev,
*addvp = (mod_perl_perl_dir_config *)addv;
-SV *sv,
+SV *sv=Nullsv,
*basesv = basevp ? basevp-obj : Nullsv,
*addsv = addvp ? addvp-obj : Nullsv;
@@ -958,16 +958,23 @@
if((perl_eval_ok(NULL) == OK) (count == 1)) {
sv = POPs;
++SvREFCNT(sv);
- mrg-obj = sv;
mrg-pclass = SvCLASS(sv);
}
PUTBACK;
FREETMPS;LEAVE;
}
else {
- mrg-obj = newSVsv(basesv);
- mrg-pclass = basevp-pclass;
+sv = newSVsv(basesv);
+mrg-pclass = basevp-pclass;
}
+
+if (sv) {
+mrg-obj = sv;
+register_cleanup(p, (void*)mrg,
+ perl_perl_cmd_cleanup, mod_perl_noop);
+
+}
+
return (void *)mrg;
}
RE: does notes() work with custom_response()?
try this:
--- Yours.pmThu Sep 14 08:04:00 2000
+++ Mine.pm Thu Sep 14 08:02:49 2000
@@ -57,8 +57,8 @@
{
my $r = shift;
- my $notes = $r-notes;
- my $pnotes = $r-pnotes;
+ my $notes = $r-prev-notes || $r-notes;
+ my $pnotes = $r-prev-pnotes || $r-pnotes;
$r-status( SERVER_ERROR );
$r-send_http_header;
HTH
--Geoff
-Original Message-
From: brian d foy [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 13, 2000 6:19 PM
To: [EMAIL PROTECTED]
Subject: does notes() work with custom_response()?
=head
should notes() be available to a handler installed with
custom_response()?
notice the code below:
0) handler() decides which function will handle the response
and sets a note.
1) in test(), if part of the uri contains /error/, then
another note is set and a custom_response() is used.
the error() routine handles the error(). it sees the
note set by handler() but not by test(),
2) in test(), if part of the uri contains /push/, then
a note is set and error() is installed as a handler.
error() then sees both notes.
should 1) propogate both notes? are things even designed to
work that way?
=cut
package LinkBank5::ErrorTest;
use Apache::Constants;
sub handler
{
my $r = shift;
my $uri = $r-uri;
$r-notes( 'LB-handler' = "Run at @{[scalar localtime]}" );
if( $uri =~ /test/ )
{
$r-push_handlers( PerlHandler = \test );
return OK;
}
if( $uri =~ /error/ )
{
$r-push_handlers( PerlHandler = \error );
return OK;
}
else { return DECLINED; }
}
sub test
{
my $r = shift;
my $uri = $r-uri;
#this note is not set, although the handler note is propogated
if( $uri =~ /error/ ) # e.g. /test/error
{
$r-notes('LB-Error' = 'Oops! i messed up');
$r-notes('error-notes' = 'Oops! i messed up');
$r-custom_response( SERVER_ERROR, "/error" );
return SERVER_ERROR; #tested with OK and DECLINED too
}
#using a PushHandler works
elsif( $uri =~ /push/ ) # e.g. /test/push
{
$r-notes('LB-Push' = 'Oops! i messed up');
$r-push_handlers( PerlHandler = \error );
return OK;
}
$r-send_http_header;
my $note = $r-notes('LB-handler');
$r-print("I'm in test!\n");
$r-print("The note is [$note]\n");
return OK;
}
sub error
{
my $r = shift;
my $notes = $r-notes;
my $pnotes = $r-pnotes;
$r-status( SERVER_ERROR );
$r-send_http_header;
$r-print("I'm in error!\n");
print "Notes are -\n";
print map { "$_ = $$notes{$_}\n" } sort keys %$notes;
print "PNotes are -\n";
print map { "$_ = $$pnotes{$_}\n" } sort keys %$pnotes;
return OK;
}
1;
__END__
--
brian d foy [EMAIL PROTECTED]
Director of Technology, Smith Renaud, Inc.
875 Avenue of the Americas, 2510, New York, NY 10001
V: (212) 239-8985
RE: does notes() work with custom_response()?
-Original Message- From: brian d foy [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 14, 2000 9:09 AM To: [EMAIL PROTECTED] Subject: RE: does notes() work with custom_response()? On Thu, 14 Sep 2000, Geoffrey Young wrote: i was using: - my $notes = $r-notes; - my $pnotes = $r-pnotes; you suggested: + my $notes = $r-prev-notes || $r-notes; + my $pnotes = $r-prev-pnotes || $r-pnotes; neither of those worked for me. did they work for you? well, I tried to understand what you were doing so I set up a quick test and yes, it worked - but I may not be reproducing your setup exactly... remember that custom_response() is a tie into Apache's ErrorDocument handling, which uses an internal redirect, and for internal redirects you can use $r-prev to get at the initial request's stuff. See the eagle book for more detail... from this and your other post, you might want to take a look at http://perl.apache.org/guide/perl.html#Exception_Handling_for_mod_perl to get another perspective on exception handling... HTH --Geoff -- brian d foy [EMAIL PROTECTED] Director of Technology, Smith Renaud, Inc. 875 Avenue of the Americas, 2510, New York, NY 10001 V: (212) 239-8985
RE: does notes() work with custom_response()?
-Original Message- From: brian d foy [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 14, 2000 9:58 AM To: [EMAIL PROTECTED] Subject: RE: does notes() work with custom_response()? On Thu, 14 Sep 2000, Geoffrey Young wrote: remember that custom_response() is a tie into Apache's ErrorDocument handling, which uses an internal redirect, and for internal redirects you can use $r-prev to get at the initial request's stuff. See the eagle book for more detail... okay - i got that to work. i was getting confused because notes from the handler() were showing up in the current request's notes for the custom_response() handler *and* (as i've discovered) in the previous notes. should that happen? if you are doing (as I suspect) Location /test/push SetHandler LinkBank5::ErrorTest ... /Location Location /error SetHandler LinkBank5::ErrorTest ... /Location $r-prev-notes and $r-notes will both contain the note set by handler() because it's being called twice... --Geoff notice the duplicated LB-handler: #the stuff from $r-notes Notes are - LB-handler = Run at Thu Sep 14 09:50:11 2000 PERL_CUR_HOOK = PerlHandler #the stuff from $r-prev-notes Prev Notes are - LB-Error = Oops! i messed up LB-handler = Run at Thu Sep 14 09:50:11 2000 PERL_CUR_HOOK = PerlHandler from this and your other post, you might want to take a look at http://perl.apache.org/guide/perl.html#Exception_Handling_for_mod_perl to get another perspective on exception handling... however, i'm not doing anything with exceptions. i'm not handling errors - i'm aborting the request as a last ditch scenario. for some reason the script has decided that it can't continue and wants to send DONE while still taking care of some logging and notification. -- brian d foy [EMAIL PROTECTED] Director of Technology, Smith Renaud, Inc. 875 Avenue of the Americas, 2510, New York, NY 10001 V: (212) 239-8985
RE: mod_perl IfModule directives?
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 12, 2000 9:02 AM
To: [EMAIL PROTECTED]
Subject: mod_perl IfModule directives?
I know this isn't in mod_perl yet, so take this as a feature
request :-)
What I'd like to see is a mod_perl equivalent of IfModule,
so that I can
add custom config directives to my httpd.conf perfectly safely:
IfPerlModule AxKit
AxAddStyleMap text/xsl Apache::AxKit::Language::Sablot
/IfPerlModule
cool idea...
is
Perl
$AxAddStyleMap = "text/xsl Apache::AxKit::Language::Sablot"
if Apache-module('AxKit');
/Perl
good enough for the moment?
--Geoff
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: mod_perl IfModule directives?
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 12, 2000 9:21 AM
To: Geoffrey Young
Cc: [EMAIL PROTECTED]
Subject: RE: mod_perl IfModule directives?
On Tue, 12 Sep 2000, Geoffrey Young wrote:
cool idea...
is
Perl
$AxAddStyleMap = "text/xsl Apache::AxKit::Language::Sablot"
if Apache-module('AxKit');
/Perl
good enough for the moment?
I'm not convinced that will work, since it sets the directives in the
Apache::ReadConfig package, not mine.
I just tested it with Apache::Dispatch, which also uses ModuleConfig, and it
works just fine. I guess it depends on the mechanism you are using to make
your directives visible in your module...
Besides, I think you just made up
Apache-module() :-)
oh, to have such power ;)
--Geoff
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: Memory leak hell...
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 11, 2000 2:54 PM
To: Matt Sergeant
Cc: [EMAIL PROTECTED]
Subject: Re: Memory leak hell...
[snip]
look for xsubs in those modules you're using that are calling
new{SV,AV,HV,RV} or SvREFCNT_inc(). sounds like botched refcnting or
failure to mortalize a new*V.
actually, my first guess is Apache::ModuleConfig-get, if you don't
explicitly pass __PACKAGE__ as the last argument, perl_eval_pv() is
called, which has a leak plugged in perl-current:
[ 6201] By: gsar on
2000/06/06 00:42:59
Log: Perl_eval_pv() leaks 4 bytes every time it is
called because it
does a PUSHMARK that's never ever POPMARKed; in
general, only
Perl_call_[sp]v() need a PUSHMARK for incoming arguments;
Perl_eval_[sp]v() don't because they don't take
any incoming
arguments (this leak has been around since the
original version
of perl_eval_pv() in 5.003_97e)
Branch: perl
! perl.c
so first try changing:
Apache::ModuleConfig-get($r)
to
Apache::ModuleConfig-get($r, __PACKAGE__)
that's a good bit of info to know - thanks...
--Geoff
RE: Apache crashes with Apache::DBI
-Original Message- From: Pires Claudio [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 05, 2000 10:12 AM To: modperl Subject: Apache crashes with Apache::DBI Hi, I have problems to load Apache DBI. I added the PerlModule Apache::DBI into httpd.conf and when I restarted Apache I got this message bash# /etc/rc.d/init.d/httpd restart; Shutting down http: [ OK ] Starting httpd: [ OK ] bash# /etc/rc.d/init.d/httpd status; httpd dead but subsys locked it seems like Apache crashes... I dont know why... I could saw in the Apache::DBI doc that mod_perl must be configured with PERL_CHILD_INIT=1 and PERL_STACKED_HANDLERS=1. How can I know if mod_perl was compiled with this directives? http://localhost/perl-status?hooks (if configured) How can I know what directives were used to compile mod_perl? I download mod_perl as an RPM from RedHat... And I havent posibilities to recompile it... should I recompile it? probably :) IIRC, Apache::DBI had problems with the redhat DSO for 6.1, but it could have been another 6.X version. At any rate, compiling from source isn't too difficult. See perl.apache.org/guide for lots of pointers... or there is any way to modify the configuration without compilation? no Thanks a lot Claudio HTH --Geoff
RE: cvs commit: modperl/src/modules/perl mod_perl.c
the mod_perl.c update is causing conficts with the set_handlers patch...
the patch works, albit with lots of fuzz, but make yields:
mod_perl.c: In function `perl_run_stacked_handlers':
mod_perl.c:1342: parse error before `register'
make[3]: *** [mod_perl.o] Error 1
make[2]: *** [all] Error 1
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/apache_1.3.12/src'
make: *** [apache_httpd] Error 2
just in case you want to issue a new patch :)
--Geoff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 01, 2000 1:16 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: modperl/src/modules/perl mod_perl.c
dougm 00/08/31 22:15:42
Modified:.Changes
Leak Leak.xs
src/modules/perl mod_perl.c
Log:
fixes for ActivePerl
Revision ChangesPath
1.513 +2 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.512
retrieving revision 1.513
diff -u -r1.512 -r1.513
--- Changes 2000/09/01 05:10:09 1.512
+++ Changes 2000/09/01 05:15:37 1.513
@@ -10,6 +10,8 @@
=item 1.24_01-dev
+fixes for ActivePerl [Gurusamy Sarathy [EMAIL PROTECTED]]
+
change apaci/Makefile.tmpl and src/modules/perl/Makefile so Perl's
include path comes before /usr/local/include, e.g. to make
sure Perl's
patchlevel.h is used, thanks to Ryan Morgan for the spot
1.4 +1 -1 modperl/Leak/Leak.xs
Index: Leak.xs
===
RCS file: /home/cvs/modperl/Leak/Leak.xs,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Leak.xs 1999/11/15 20:05:27 1.3
+++ Leak.xs 2000/09/01 05:15:40 1.4
@@ -121,7 +121,7 @@
{
char *state = lookup((struct hash_s **)p, sv, t_new);
if (state != t_old) {
- fprintf(stderr, "%s %p : ", state ? state : t_new, sv);
+ PerlIO_printf(PerlIO_stderr(), "%s %p : ", state ?
state : t_new, sv);
sv_dump(sv);
}
return hwm+1;
1.125 +21 -2 modperl/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.c,v
retrieving revision 1.124
retrieving revision 1.125
diff -u -r1.124 -r1.125
--- mod_perl.c 2000/08/15 19:36:33 1.124
+++ mod_perl.c 2000/09/01 05:15:41 1.125
@@ -850,10 +850,21 @@
dPPDIR;
dPPREQ;
dTHR;
-GV *gv = gv_fetchpv("SIG", TRUE, SVt_PVHV);
+GV *gv;
+
+#ifdef USE_ITHREADS
+dTHX;
+
+if (!aTHX) {
+ PERL_SET_CONTEXT(perl);
+}
+#endif
(void)acquire_mutex(mod_perl_mutex);
-
+
+gv = gv_fetchpv("SIG", TRUE, SVt_PVHV);
+
+
#if 0
/* force 'PerlSendHeader On' for sub-requests
* e.g. Apache::Sandwich
@@ -1299,6 +1310,14 @@
I32 i, do_clear=FALSE;
SV *sub, **svp;
int hook_len = strlen(hook);
+
+#ifdef USE_ITHREADS
+dTHX;
+
+if (!aTHX) {
+ PERL_SET_CONTEXT(perl);
+}
+#endif
if(handlers == Nullav) {
if(hv_exists(stacked_handlers, hook, hook_len)) {
RE: PerlAuthenHandler invalid command
-Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, August 28, 2000 3:45 PM To: Geoffrey Young Cc: 'Frank Plunkett'; [EMAIL PROTECTED] Subject: RE: PerlAuthenHandler invalid command On Mon, 28 Aug 2000, Geoffrey Young wrote: build mod_perl with perl Makefile.PL EVERTHING=1 or PERL_AUTHEN=1 EVERYTHING=1 of course :) I don't think MakeMaker uses Soundex module yet :) maybe something to integrate into the mod_perl 2.0 build mechanism ;) HTH --Geoff -Original Message- From: Frank Plunkett [mailto:[EMAIL PROTECTED]] Sent: Monday, August 28, 2000 3:31 PM To: [EMAIL PROTECTED] Subject: PerlAuthenHandler invalid command Hi modperites, I keep receiving the following error message when starting httpd: Syntax error on line 99 of /usr/local/apache/conf/httpd.conf: Invalid command 'PerlAuthenHandler', perhaps mis-spelled or defined by a module not included in the server configuration my httpd.conf looks like this: Location /wwwhes AuthName Test AuthType Basic SetHandler perl-script PerlAuthenHandler Apache::AuthAny require valid-user /Location # I did a perl Makefile.pl everything=1 but still no luck. perl Makefile.PL Reading Makefile.PL args from ../makepl_args.mod_perl Configure mod_perl with /home/apache_1.3.12/src ? [y] Shall I build httpd in /home/apache_1.3.12/src for you? [y] Appending mod_perl to src/Configuration Using config file: /usr/local/mod_perl-1.24/src/Configuration Creating Makefile + configured for Solaris 270 platform + setting C compiler to cc + setting C pre-processor to cc -E + checking for system header files + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.24 + id: Perl/v5.6.0 (solaris) [perl] + adjusting Apache build environment + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in os/unix Creating Makefile in ap Creating Makefile in main Creating Makefile in lib/expat-lite Creating Makefile in modules/standard Creating Makefile in modules/perl EXTRA_CFLAGS: -DSOLARIS2=270 -DMOD_PERL -DUSE_EXPAT -I$(SRCDIR)/lib/expat-li te PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled Will run tests as User: 'nobody' Group: 'other' Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl salcd6# make (cd /home/apache_1.3.12/src make CC="cc";) === os/unix _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
RE: PerlAuthenHandler invalid command
-Original Message- From: Frank Plunkett [mailto:[EMAIL PROTECTED]] Sent: Monday, August 28, 2000 3:42 PM To: [EMAIL PROTECTED] Subject: Re: PerlAuthenHandler invalid command Geoff I did build with perl Makefile.PL PERL_AUTHEN=1 That was the first thing I thought also. Frank ok, sorry I didn't read far enough :) did you 'make install'? typically, you only see the message if you haven't enabled the api or you haven't installed mod_perl... see http://perl.apache.org/guide/install.html#A_Summary_of_a_Basic_mod_perl_In and http://perl.apache.org/guide/install.html#How_can_I_tell_whether_mod_perl_ HTH --Geoff -Original Message- From: Geoffrey Young [EMAIL PROTECTED] To: 'Frank Plunkett' [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Monday, August 28, 2000 3:40 PM Subject: RE: PerlAuthenHandler invalid command build mod_perl with perl Makefile.PL EVERTHING=1 or PERL_AUTHEN=1 HTH --Geoff -Original Message- From: Frank Plunkett [mailto:[EMAIL PROTECTED]] Sent: Monday, August 28, 2000 3:31 PM To: [EMAIL PROTECTED] Subject: PerlAuthenHandler invalid command Hi modperites, I keep receiving the following error message when starting httpd: Syntax error on line 99 of /usr/local/apache/conf/httpd.conf: Invalid command 'PerlAuthenHandler', perhaps mis-spelled or defined by a module not included in the server configuration my httpd.conf looks like this: Location /wwwhes AuthName Test AuthType Basic SetHandler perl-script PerlAuthenHandler Apache::AuthAny require valid-user /Location # I did a perl Makefile.pl everything=1 but still no luck. perl Makefile.PL Reading Makefile.PL args from ../makepl_args.mod_perl Configure mod_perl with /home/apache_1.3.12/src ? [y] Shall I build httpd in /home/apache_1.3.12/src for you? [y] Appending mod_perl to src/Configuration Using config file: /usr/local/mod_perl-1.24/src/Configuration Creating Makefile + configured for Solaris 270 platform + setting C compiler to cc + setting C pre-processor to cc -E + checking for system header files + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.24 + id: Perl/v5.6.0 (solaris) [perl] + adjusting Apache build environment + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in os/unix Creating Makefile in ap Creating Makefile in main Creating Makefile in lib/expat-lite Creating Makefile in modules/standard Creating Makefile in modules/perl EXTRA_CFLAGS: -DSOLARIS2=270 -DMOD_PERL -DUSE_EXPAT -I$(SRCDIR)/lib/expat-li te PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled Will run tests as User: 'nobody' Group: 'other' Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl salcd6# make (cd /home/apache_1.3.12/src make CC="cc";) === os/unix
[ANNOUNCE] Apache-Dispatch-0.06
The URL http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.06.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Dispatch-0.06.tar.gz size: 7452 bytes md5: 1546415d4d9aa380567b961d395827d6 DESCRIPTION Apache::Dispatch translates $r-uri into a class and method and runs it as a PerlHandler. Basically, this allows you to call PerlHandlers as you would CGI scripts without having to load your httpd.conf with a slurry of Location tags. EXAMPLE in httpd.conf PerlModule Apache::Dispatch PerlModule Bar Location /Foo SetHandler perl-script PerlHandler Apache::Dispatch DispatchPrefix Bar /Location in browser: http://localhost/Foo/baz the results are the same as if your httpd.conf looked like: Location /Foo SetHandler perl-script PerlHandler Bar::dispatch_baz /Location but with the additional security of protecting the class name from the browser and keeping the method name from being called directly. Because any class under the Bar:: hierarchy can be called, one Location directive is be able to handle all the methods of Bar, Bar::Baz, etc... Changes: 0.06 8.29.2000 - changed call to error_dispatch to pass $r and $@ - documented the arguments passed to the extras - log the error if the handler dies and there is no error_dispatch() routine defined
RE: Can't Locate Apache::File
did you build mod_perl with EVERYTHING=1 or PERL_FILE_API=1? HTH --Geoff -Original Message- From: David E. Wheeler [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 29, 2000 1:56 PM To: [EMAIL PROTECTED] Subject: Can't Locate Apache::File Hi All, I've just installed the latest version of Lincoln Stein's Apache::MP3 (nice job, Doc!), which offers support for caching MP3 ICY info. It uses Apache::File to do so. This the first time I've used Apache::File on this server, but was still surprised to find that it failed to load: [Wed Aug 23 10:14:53 2000] [error] Can't locate loadable object for module Apache::File in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .. /usr/local/apache/ /usr/local/apache/lib/perl) at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 As near as I can tell, it is in fact there, and when I do % perl -le 'use Apache::File;' It seems to load just fine. The module lives in /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/File.pm Anyone got any idea why it can't find it? I'm running Apache 1.3.12 with mod_perl 1.24 compiled in on RedHat Linux 6.2. TIA! David
RE: PerlAuthenHandler invalid command
build mod_perl with perl Makefile.PL EVERTHING=1 or PERL_AUTHEN=1 HTH --Geoff -Original Message- From: Frank Plunkett [mailto:[EMAIL PROTECTED]] Sent: Monday, August 28, 2000 3:31 PM To: [EMAIL PROTECTED] Subject: PerlAuthenHandler invalid command Hi modperites, I keep receiving the following error message when starting httpd: Syntax error on line 99 of /usr/local/apache/conf/httpd.conf: Invalid command 'PerlAuthenHandler', perhaps mis-spelled or defined by a module not included in the server configuration my httpd.conf looks like this: Location /wwwhes AuthName Test AuthType Basic SetHandler perl-script PerlAuthenHandler Apache::AuthAny require valid-user /Location # I did a perl Makefile.pl everything=1 but still no luck. perl Makefile.PL Reading Makefile.PL args from ../makepl_args.mod_perl Configure mod_perl with /home/apache_1.3.12/src ? [y] Shall I build httpd in /home/apache_1.3.12/src for you? [y] Appending mod_perl to src/Configuration Using config file: /usr/local/mod_perl-1.24/src/Configuration Creating Makefile + configured for Solaris 270 platform + setting C compiler to cc + setting C pre-processor to cc -E + checking for system header files + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.24 + id: Perl/v5.6.0 (solaris) [perl] + adjusting Apache build environment + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in os/unix Creating Makefile in ap Creating Makefile in main Creating Makefile in lib/expat-lite Creating Makefile in modules/standard Creating Makefile in modules/perl EXTRA_CFLAGS: -DSOLARIS2=270 -DMOD_PERL -DUSE_EXPAT -I$(SRCDIR)/lib/expat-li te PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled Will run tests as User: 'nobody' Group: 'other' Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl salcd6# make (cd /home/apache_1.3.12/src make CC="cc";) === os/unix
RE: push_handlers (was: PerlCleanupHandler vs register_cleanup)
a quick test showed the handlers to be FIFO, so I would expect you to get
moda
modb
modc
d
e
HTH
--Geoff
-Original Message-
From: Paul G. Weiss [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 24, 2000 2:38 PM
To: 'Stas Bekman'
Cc: modperl
Subject: push_handlers (was: PerlCleanupHandler vs register_cleanup)
While we're on the subject of handlers, if
I have
PerlLogHandlers moda modb modc
in my conf file
and I do
$r-push_handlers('PerlLogHandler', \d);
$r-push_handlers('PerlLogHandler', \e);
during the content phase
what is the order that the stacked log handlers run?
-P
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 24, 2000 12:47 PM
To: Paul G. Weiss
Cc: modperl
Subject: Re: PerlCleanupHandler vs register_cleanup
On Thu, 24 Aug 2000, Paul G. Weiss wrote:
What is the difference between doing
$r-push_handlers('PerlCleanupHandler', \function);
and
$r-register_cleanup(\function);
The same:
http://www.modperl.com/book/chapters/ch9.html#Server_Core_Functions
The register_cleanup() method registers a subroutine that
will be called
after the logging stage of a request. This is much the same
as installing
a cleanup handler with the PerlCleanupHandler directive. See
Chapter 7 for
some practical examples of using register_cleanup().
_
Stas Bekman JAm_pH -- Just Another
mod_perl Hacker
http://stason.org/ mod_perl Guide
http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
RE: modperl newbie: question about unable to load File.pm
make sure that you enabled Apache::File when you built mod_perl, ie perl Makefile.PL EVERYTHING=1 or perl Makefile.PL PERL_FILE_API=1 HTH --Geoff -Original Message- From: Hoffman , Geoffrey [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 24, 2000 3:40 PM To: modperl Subject: modperl newbie: question about unable to load File.pm I am trying to learn mod_perl, and have been going through the O'Reilly book. Got to the "footer" example, where it just simply adds some HTML to the bottom of a page. not a big deal. when I try to run it, I get issues with mod_perl not being able to find File.pm. here is some of what I see (I removed lots of extra text): File.pm: Can't locate loadable object for module Apache::File in @INC (@INC contains: /usr/local/apache/lib/perl /usr/local/lib/perl5/5.00503/sun4-solaris /usr/local/lib/perl5/5.00503 /usr/local/lib/perl5/site_perl/5.005/sun4-solaris /usr/local/lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl) at /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/mod_perl.pm line 14 [Thu Aug 24 15:30:59 2000] Footer.pm: [Thu Aug 24 15:30:59 2000] Footer.pm: BEGIN failed--compilation aborted at /usr/local/apache/lib/perl/Apache/Footer.pm line 6. for reference, this is Solaris 2.6. Footer.pm is the module I am trying to write, sites at ~apache/lib/perl/Apache/Footer.pm. this is latest Apache (1.3.12) and mod_perl (1.24). Mainly a stock install, with grabbing the sources, doing the standard make and make install on them. I didn't do any extra setup for it, other than Use Apache::File ();, which is basically where it is choking. I checked, File.pm IS located down in the /usr/local/lib/perl5 directory, in the same directories as other modules that ARE working (like Constants). Hate to ask what may be an obvious question, but anyone have any idea what is causing this? any information would be appreciated.
RE: anon CVS of modperl hangs?
doesn't work for me... cvsup seems to be up, though --Geoff -Original Message- From: Jens-Uwe Mager [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 23, 2000 2:54 PM To: [EMAIL PROTECTED] Subject: anon CVS of modperl hangs? I am trying to do an anon cvs update of modperl and it appears to hang without doing anything. I can cvs upd other projects. Could anyone try that and look if it works? -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone:+49 5131 709320 FAX: +49 5131 709325 Internet: [EMAIL PROTECTED]
RE: anon CVS of modperl hangs?
doesn't work for me... cvsup seems to be up, though --Geoff -Original Message- From: Jens-Uwe Mager [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 23, 2000 2:54 PM To: [EMAIL PROTECTED] Subject: anon CVS of modperl hangs? I am trying to do an anon cvs update of modperl and it appears to hang without doing anything. I can cvs upd other projects. Could anyone try that and look if it works? -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone:+49 5131 709320 FAX: +49 5131 709325 Internet: [EMAIL PROTECTED]
RE: $r-get_handlers bug/oversight?
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 21, 2000 6:41 PM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'
Subject: RE: $r-get_handlers bug/oversight?
On Wed, 16 Aug 2000, Geoffrey Young wrote:
ack... so the alias only goes one way? I guess it makes
sense that we
can't know at run time what the Init handler stands for,
but how come
get_handlers('PerlInitHandler') comes up blank? Isn't it
just a table
entry?
it's not in the get/set handler lookup table. just use
PostReadRequest/HeaderParser for now, we'll see about making
Init do the
right thing with get/set handlers later.
fair enough :)
the patch looks great - thanks for spending the time...
--Geoff
RE: :Oracle problem in conjunction with Apache.
there are a number of threads on this and the modperl list that address the issue: http://marc.theaimsgroup.com/?l=apache-modperlm=96461467121206w=2 or http://marc.theaimsgroup.com/?l=apache-modperlm=96682673408989w=2 or http://perl.apache.org/guide/troubleshooting.html#install_driver_Oracle_fail ed_C each thread outlines a few solutions that have worked for people, but they all come back to ldconfig (I think) - choose the one that helps you best... HTH --Geoff -Original Message- From: Mike Ford [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 22, 2000 1:27 PM To: [EMAIL PROTECTED] Subject: DBD::Oracle problem in conjunction with Apache. I have been able to use DBD::Oracle on my own workstation for quite some time now, and haven't had any considerable problems that stopped me dead in my tracks. I've been assisting a coworker who is trying to get DBD::Oracle installed on his own test environment and having little luck. Here's the story so far: We've got the DBD::Oracle 1.06 installed as of this morning on his RedHat 6.2 box, and no tests are failing under 'make test'. To accomplish this, we have set ORACLE_HOME, ORACLE_USERID, and TWO_TASK, as well as appending ORACLE_HOME/lib onto LD_LIBRARY_PATH. We finished up with 'make install' and tried running some perl. As long as we're running from command line, the system will connect to the database and work properly. When we attempt to run the same code through the web server, it croaks and gives the following error in the log: Premature end of script headers: /usr/local/apache/cgi-bin/index.cgi install_driver(Oracle) failed: Can't load '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libclntsh.so.1.0: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169 at (eval 6) line 3 Perhaps a required shared library or dll isn't installed where expected I can't see the difference in my set up and his (btw, I'm running on RH6.1), so I'm not sure why we're encountering this problem. Anyone know a solution? Thanks -- Mike Ford Web Developer, WorkFlow Integrators, Inc. [EMAIL PROTECTED] www.wfiinc.com -- DBI HOME PAGE AND ARCHIVES: http://www.symbolstone.org/technology/perl/DBI/ To unsubscribe from this list, please visit: http://www.isc.org/dbi-lists.html If you are without web access, or if you are having trouble with the web page, please send mail to [EMAIL PROTECTED] with the subject line of: 'unsubscribe'. --
RE: Producing an error page
http://perl.apache.org/guide/snippets.html#Redirecting_Errors_to_the_Client HTH --Geoff -Original Message- From: Jay Strauss [mailto:[EMAIL PROTECTED]] Sent: Monday, August 21, 2000 9:56 AM To: [EMAIL PROTECTED] Subject: Producing an error page Hi, I'm asking this again, due to lack of response (but I can't believe no one out there knows how to do this). How do I produce an error page (in HTML), when I call the script from a browser, that looks just like the error screen I get when I run a script at the command line? That is, if I run the following script from the command line: --- #!/usr/bin/perl -w use strict; use diagnostics; ($first, $second) = @ARGV; exit; --- I'll get a whole bunch of messages telling me I "use strict" and I have variables that I didn't define with "my". But, if I call it from my browser, I just get back a "Internal Server Error" page. Instead I want all the diagnostics messages. Thanks Jay Jay Strauss [EMAIL PROTECTED] (h) 773.935.5326 (c) 312.617.0264
RE: $r-get_handlers bug/oversight?
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 15, 2000 11:22 PM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'
Subject: Re: $r-get_handlers bug/oversight?
On Tue, 25 Apr 2000, Geoffrey Young wrote:
Hi all...
I've noticed that get_handlers() will return the
enabled handlers
for a PerlPostReadRequestHandler, but not when it is specified as a
PerlInitHandler (either by calling
$r-get_handlers('PerlPostReadRequestHandler') or
$r-get_handlers('PerlInitHandler'). It is the same with
PerlHeaderParserHandler. An oversight?
PerlInitHandler is just an alias for PerlPostReadRequestHandler and
PerlHeaderParserHandler. mod_perl can only know at config-time if
InitHandler should be alias to PostReadRequest or
HeaderParser, i don't
think get_handlers() can figure out which you mean at request time.
ack... so the alias only goes one way? I guess it makes sense that we
can't know at run time what the Init handler stands for, but how come
get_handlers('PerlInitHandler') comes up blank? Isn't it just a table
entry?
Also, I can't get anything for PerlCleanupHandlers, which kinda
makes sense, since Cleanup isn't really a phase, per se (at
least according
to the book). Does it make sense to add this to
get_handlers() as well?
the get_handlers() patch posted earlier should enable get/set of
PerlCleanupHandlers.
well, it got the handler ok, but I couldn't set it properly:
#!/usr/bin/perl
my $r = shift;
$r-set_handlers(PerlCleanupHandler = [\cleanup]);
$r-send_http_header('text/plain');
print "done";
sub cleanup {
warn "hi";
}
is a no go. same with using ['My::Cleanup'] as the arg...
I also noticed that the patch didn't fix the get_handlers() coderef bug:
#!/usr/bin/perl
my $r = shift;
$r-push_handlers(PerlCleanupHandler = sub { warn "hi"; });
#my $handlers = $r-get_handlers('PerlCleanupHandler');
$r-send_http_header('text/plain');
print "done";
uncomment the get_handlers() line and the cleanup handler never runs and you
get "Attempt to free unreferenced scalar"
if you have some tuits :)
--Geoff
RE: canned footers
-Original Message- From: Alex Menendez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 16, 2000 2:07 PM To: [EMAIL PROTECTED] Cc: The MODPERL Subject: Re: canned footers Your right. this works great for html! Unfortunately, however, Apache sandwich really does not work for me because it only deals with GET requests and it can not deal with cgi requests directly. I would need to alter my cgi's in order to use sandwich. I am looking for a mod_perl solution that will add footers to unaltered stand alone cgis. any other ideas out there? you would need to implement a filter that was capable of parsing the output of your cgi script... look into using Apache::Filter along with a slightly modified version the Apache::Footer example in the eagle book that puts the the footer in the right place... HTH --Geoff thanx, -amen "Bruce W. Hoylman" wrote: Have you looked at Apache::Sandwich from CPAN? It is easy to implement and I have used it for awhile now to add confidentiality headers and footers to pages in a small to medium site. cpan m /Apache::Sandwich/ Module id = Apache::Sandwich CPAN_USERID VKHERA (Vivek Khera [EMAIL PROTECTED]) CPAN_VERSION 2.04 CPAN_FILEV/VK/VKHERA/Apache-Sandwich-2.04.tar.gz MANPAGE Apache::Sandwich - Layered document (sandwich) maker INST_FILE /opt/gnu/lib/perl5/site_perl/5.005/Apache/Sandwich.pm INST_VERSION 2.04 It could most certainly be use as a basis for your needs and requirements. Peace.
RE: DB persistence
-Original Message- From: Mark D Wolinski [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 16, 2000 2:32 PM To: [EMAIL PROTECTED] Subject: RE: DB persistence If I have mod_perl installed, will CGI's not running under mod_perl benefit from Apache::DBI as well if they connect to the same database? Mark W no - Apache::DBI is mod_perl specific... --Geoff -Original Message- From: Shimon Rura [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 16, 2000 2:22 PM To: Pramod Sokke; [EMAIL PROTECTED] Subject: RE: DB persistence It seems to be starting a new connection each time. If you want connection pooling, you should use the Apache::DBI module, which will transparently pool DBI connections for you. Shimon Rura -Original Message- From: Pramod Sokke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 16, 2000 2:00 PM To: [EMAIL PROTECTED] Subject: DB persistence Hi all, I think I misled everybody with my previous question on this topic. To put it in simple words: Apache 1.3.12/mod_perl 1.24/Solaris 2.7 I'm establishing db connection at server startup and the logs indicate that's done. But in my subsequent calls to 'connect' in my scripts, I see the same message "Establishing connection to PURCHASEDB:purchasedb" in my webserver error log. Does this mean it's ignoring the already available db handle and making fresh connections? In other words, how do I make sure whether the original handle is used or if a fresh connection is established? Any help is greatly appreciated. Thanks, Pramod
RE: $r-notes with slashes
-Original Message-
From: Andrew Fuqua [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 14, 2000 12:44 PM
To: [EMAIL PROTECTED]
Subject: $r-notes with slashes
I'm trying to pass a path name with slashes as the value of a
note, and
when I try to retrieve the note from another handler in the same
request, the note is not there. Code goes like this:
in a PerlInitHandler:
$r-notes('dir_name' = '/some/dir/name/');
later, in a PerlAuthzHandler:
my $dir_name = $r-notes('dir_name');
and $dir_name is empty. :( I can set and retrieve the note just fine
as long as there are no slashes in the note.
try pnotes:
$r-pnotes(dir_name = $some_string);
or
$r-pnotes(dir_name = \$some_string);
Another question. From a handler, how can I change the value of a
variable that was PerlSetVar'ed in httpd.conf?
you can use Apache::Table to get or set things in PerlSetVar:
$r-dir_config-get('foo');
$r-dir_config-set(foo = 'changed');
I haven't changed PerlSetVar like this, but a quick test showed that it
worked ok...
I've noticed that the Apache::Table way only works for PerlSetVar things on
a per-directory basis - it doesn't seem to inherit per-server variables
properly at this time...
HTH
--Geoff
Thanks,
Andrew
RE: Apache::Reload
you may have missed the conversation yesterday on modperl-dev, but just to
recap...
it just came up that Apache::Symbol::undef_functions really isn't needed any
more. That is, 5.004+ avoids the manditory 'subroutine redefined' warnings
and makes then not-manditory. Thus local $^W stops the warnings. I was just
dealing with this with Dispatch.pm and have already removed it in the next
version. Also, the presence of Apache::Symbol is up in the air in 2.0,
possibly to be included for back-compat, though...
just FYI
--Geoff
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 11, 2000 7:13 AM
To: [EMAIL PROTECTED]
Subject: RFC: Apache::Reload
This dates back to discussions nearly a year ago now, from Randal's
initial Stonehenge::Reload, and Doug saying he'd like to see a more
generic Apache::Reload that got rid of the necessity to call
reload_me in
your own code... Anyway, I needed this facility too, since I wanted
modules to be able to just "use Apache::Reload" and have them
reloaded,
without having to call something myself in some sort of
handler() function, because 90% of my modules don't use a
handler() entry
point... So I came up with Apache::Reload based mostly on
Apache::StatINC
and partly on Stonehenge::Reload, here's the code, comments welcome:
package Apache::Reload;
use strict;
$Apache::Reload::VERSION = '0.01';
my %Stat; # = ($INC{"Apache/Reload.pm"} = time);
my %INCS;
sub import {
my $class = shift;
my ($package,$file) = (caller)[0,1];
$package =~ s/::/\//g;
$package .= ".pm";
warn "Apache::Reload: $package loaded me\n";
if (grep /^off$/, @_) {
delete $INCS{$package};
}
else {
$INCS{$package} = $file;
}
}
sub handler {
my $r = shift;
my $do_undef = ref($r)
(lc($r-dir_config("UndefOnReload") || '') eq
'on');
my $DEBUG = ref($r)
(lc($r-dir_config("ReloadDebug") || '') eq
'on');
while (my($key, $file) = each %INCS) {
local $^W;
warn "Apache::Reload: Checking mtime of $key\n"
if $DEBUG;
my $mtime = (stat $file)[9];
warn("Apache::Reload: Can't locate $file\n"),next
unless defined $mtime and $mtime;
unless (defined $Stat{$file}) {
$Stat{$file} = $^T;
}
if ($mtime $Stat{$file}) {
if ($do_undef and $key =~ /\.pm$/) {
require Apache::Symbol;
my $class =
Apache::Symbol::file2class($key);
$class-Apache::Symbol::undef_functions(undef, 1);
}
delete $INC{$key};
require $key;
warn("Apache::Reload: process $$ reloading
$key\n")
if $DEBUG;
}
$Stat{$file} = $mtime;
}
return 1;
}
1;
__END__
=head1 NAME
Apache::Reload - Reload this module on each request (if modified)
=head1 SYNOPSIS
In httpd.conf:
PerlInitHandler Apache::StatINC
Then your module:
package My::Apache::Module;
use Apache::Reload;
sub handler { ... }
1;
=head1 DESCRIPTION
This module is an adaptation of Randall Schwartz's Stonehenge::Reload
module that attempts to be a little more intuitive and makes the usage
easier. Like Apache::StatINC it must be installed as an Init Handler,
but unlike StatINC it must also be used by the module you
want reloading.
If you want to temporarily turn off reloading of a module (which is
slightly problematic since it won't happen until the next hit on the
same server because of the way this thing works) you can use the 'off'
option:
use Apache::Reload 'off';
Obviously you wouldn't do that generally, but it can be useful if you
intend to make large changes to a particular module.
=head1 AUTHOR
Matt Sergeant, [EMAIL PROTECTED]
=head1 SEE ALSO
Apache::StatINC, Stonehenge::Reload
=cut
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: parsing SSI in cgi scripts?
check out Apache::Filter + Apache::SSI - both on CPAN --Geoff -Original Message- From: Vladislav Safronov [mailto:[EMAIL PROTECTED]] Sent: Friday, August 11, 2000 11:59 AM To: [EMAIL PROTECTED] Subject: parsing SSI in cgi scripts? Hi, Is there way for processing SSI commands in perl? (my templates may contains SSI commands, so what should I do - just type in real html or process them somehow?) /Vlad
RE: Apache::DBI using 'reauthenticate' instead of caching
very interesting. I might suggest a config option to toggle the functionality within Apache::DBI instead of a new module entirely. Or maybe including it as another module within the Apache::DBI distribution. I don't know how everyone else feels, but all the stuff in the Apache:: namespace is generic and this being largly Apache::DBI except for an Oracle specific enhancement doesn't sound like it warrants it's own thing. But certainly don't let me be the final word :) your enhancement, if user configurable within Apache::DBI, might make it possible to jump between cached or reauthenticatedconnectionson a vhosts basis. Now that's cool... BTW, I did submit a (rather ugly)fixfor a (minor but important to me) bug in Apache::DBI way back in december - it was never implemented by the author for unknown reasons - see http://marc.theaimsgroup.com/?l=apache-modperlm=94699007507299w=2for the details if you are interested. --Geoff -Original Message-From: Jeff Horn [mailto:[EMAIL PROTECTED]]Sent: Friday, August 11, 2000 1:57 PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: Fw: Apache::DBI using 'reauthenticate' instead of caching Gentlemen: Have you had any time to look at this? I'm attatching my modified version of Apache::DBI. Please send me your comments and concerns as I would like to send this out to the mod_perl and DBI community very shortly. I thank you for your time! - Original Message - From: Jeff Horn To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Tuesday, June 20, 2000 7:50 PM Subject: RFC: Apache::DBI using 'reauthenticate' instead of caching Gentlemen: John Groenveld suggested that I run this by each of you. I have made a hack to Apache::DBI which uses the Oracle specific DBD call to $dbh-func($user, $pwd, 'reauthenticate') to maintain a single connection per Oracle database and then simply reauthenticate on the existing connection. This turns out to be 5-6 times faster than initiating a brand new connect for each script. Now, this is slower than straight Apache::DBI in an environment where the same connect string is used for every script running on a web server. However, it is a definite win in situations where database level security is being used and there are large numbers of logins! If you have any time to look at this I'd be most appreciative. I'd like to contribute this to CPAN as soon as I run it by a few more people and add a few bells and whistles. Your suggestions as to what to name the new module would also be appreciated. Currently it's implemented as a replacement for Apache::DBI (and steals the name), but before I submit it I want to rename the module (perhaps to something like Apache::DBI::Reauth). One problem that needs to be addressed before making this generally available is that I need to set DBI attributes back to their defaults and then reset any specified in the connect string before returning the database handle. This is not a problem in my current environment, but will be in a general environment. Any other problems you see with the code are appreciated! Thank you so much for your valuable time! -- Jeff Horn
RE: RequestNotes passing arrays
-Original Message-
From: Steven Wren [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 10, 2000 2:39 AM
To: [EMAIL PROTECTED]
Subject: RequestNotes passing arrays
Hello Geoffrey
I am not sure if u want people writing to u directly about
RequestNotes,
so tell me to bugger off and i will send this to the modperl
mailing list.
;-)
no bother - I'll forward it to the list, though, in case anyone else has
this problem...
anyway..
I am using requestnotes on a site i am doing and have been
impressed with
it. I have just one problem that has surfaced.
When passing an array from a form to my modperl handler, i
cannot seem to
'read' in the array into an array variable. I have done this
previously
using the standard CGI package.
my HTML looks like this...
input type=hidden name=array_options[size] value=xxx
input type=hidden name=array_options[colour] value=
in my modperl code i have tried..
my @product_option = $input-get('array_options');
or
my %product_option = $input-get('array_options');
but neither contain any data.
I ran a quick test which showed that the actual name of the parameter
getting posted is 'array_options[size]'.
try:
$size = $input-get('array_options[size]');
I suspect that if it works with CGI.pm that's due to some manipulations
behind the scenes, but I don't really know...
using CGI, like I have before, does not work either, is this because
RequestNotes already handles the POSTed vars?
right, RequestNotes (which is really using Apache::Request for parsing)
gobbles up the POSTed stuff at init (or wherever you run it) so it's no
longer available for parsing by CGI.pm. I think I say something like this
in the man page...
HTH
--Geoff
so it it legal to have strings as the array keys as far as
RequestNotes is
concerned, or must I have standard keys(0,1,2,..etc)?
or do i just have no idea :-)
Thanks again for your help.
Cheers!
Steven Wren
RE: custom server string
-Original Message- From: Dave Moore [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 08, 2000 5:55 PM To: [EMAIL PROTECTED] Subject: custom server string i need to change the outgoing Server header on all requests to our site. dont ask why I would want to do that. i have my orders. i read some old posts from the 90's which said I would have to write my own send_http_header() method. sounds fun but id rather not. Is this still the case and if so...why? has anyone else had to do this? you could always change the apache source... anyone know how the ASF feels about doing this? --Geoff dave -- Dave Moore Web Application Developer mailto:[EMAIL PROTECTED] ePALS Classroom Exchange http://www.epals.com/ Connecting more than 1.9 million students and teachers in 182 countries!
RE: custom server string
-Original Message- From: Vivek Khera [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 09, 2000 10:43 AM To: [EMAIL PROTECTED] Subject: Re: custom server string "DM" == Dave Moore [EMAIL PROTECTED] writes: DM i need to change the outgoing Server header on all requests to our site. DM dont ask why I would want to do that. i have my orders. i read some old DM posts from the 90's which said I would have to write my own DM send_http_header() method. sounds fun but id rather not. Is this still the DM case and if so...why? has anyone else had to do this? Just yesterday Randal posted a handler here that adds a X_mod_perl_rules header to every page out of his site. Perhaps you could modify that? the Server outbound header gets overwritten by internal magic - changing it via api calls appears fruitless... --Geoff -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
[ANNOUNCE] Apache-Dispatch-0.04
The URL http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.04.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Dispatch-0.04.tar.gz size: 6903 bytes md5: 42e7d4c530b60b9096ad2750eab2f81a Changes: 0.04 8.8.2000 - fixed bug to allow null DispatchExtras directive - cleaned up Makefile.PL - borrowed from Apache::StatINC and added DispatchStat directive (suggested by Matt Sergeant and Dan Campbell)
RE: [ANNOUNCE] Apache::Dispatch-0.03
-Original Message- From: Roger Espel Llima [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 08, 2000 12:52 PM To: [EMAIL PROTECTED] Subject: Re: [ANNOUNCE] Apache::Dispatch-0.03 [snip] Yep, that's one weird bit of syntax. I just needed this recently to write a test.pl, and it took quite a bit of testing to get it working. :) this showed up in p5p in late june... $foo = "bar"; @$foo = (1,2,3); $foo-[1] = 4; print @bar; wicked cool... --Geoff Incidentally, does anyone know of a way to do this that works under strict? The above requires a "no strict 'refs'" to work. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
RE: problem with DBD::Oracle and so
if you are running DBD-Oracle 1.04 or later and 1.03 was working ok, check out this thread... http://marc.theaimsgroup.com/?l=apache-modperlm=96461467121206w=2 specifically http://marc.theaimsgroup.com/?l=apache-modperlm=96461680225138w=2 which worked for me... HTH --Geoff -Original Message- From: me [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 05, 2000 5:18 PM To: [EMAIL PROTECTED] Subject: problem with DBD::Oracle and so i know this is been discussed before.. but i could not easily find them in the archive.. I always get the following err: Can't load '/perl5.6.0/lib/site_perl/5.6.0/i686-linux/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libclntsh.so.8.0: cannot open shared object file: No such file or directory at /home/perlish/apps/perl5.6.0/lib/5.6.0/i686-linux/DynaLoader.p m line 200. when try to start apache. any hint?
RE: [ANNOUNCE] Apache::Dispatch-0.03
for anyone who is interested (apparently not many :) I ran a quick "hello
world" LWP::Simple based benchmark using Apache::Registry (with
RegistryLoader), a normal PerlHandler, and Apache::Dispatch...
Benchmark: timing 5000 iterations of dispatch, handler, registry...
dispatch: 108 wallclock secs (24.21 usr + 5.73 sys = 29.94 CPU) @
167.00/s (n=5000)
handler: 91 wallclock secs (22.88 usr + 5.71 sys = 28.59 CPU) @ 174.89/s
(n=5000)
registry: 98 wallclock secs (23.77 usr + 5.45 sys = 29.22 CPU) @ 171.12/s
(n=5000)
and also uncovered a small bug:
--- Dispatch.pm 2000/08/04 15:36:32 1.8
+++ Dispatch.pm 2000/08/07 12:00:41
@@ -105,9 +105,8 @@
# since the uri is dispatchable, check each of the extras
#-
- my @extras = $dcfg-{_extras} ?
- @{$dcfg-{_extras}} :
- @{$scfg-{_extras}};
+ my @extras = $dcfg-{_extras} ? @{$dcfg-{_extras}} :
+$scfg-{_extras} ? @{$scfg-{_extras}} : undef;
foreach my $extra (@extras) {
if ($extra eq "PRE") {
just FYI...
--Geoff
RE: [ANNOUNCE] Apache::Dispatch-0.03
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 07, 2000 8:57 AM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'
Subject: RE: [ANNOUNCE] Apache::Dispatch-0.03
On Mon, 7 Aug 2000, Geoffrey Young wrote:
for anyone who is interested (apparently not many :) I ran
a quick "hello
world" LWP::Simple based benchmark using Apache::Registry (with
RegistryLoader), a normal PerlHandler, and Apache::Dispatch...
Benchmark: timing 5000 iterations of dispatch, handler, registry...
dispatch: 108 wallclock secs (24.21 usr + 5.73 sys = 29.94 CPU) @
167.00/s (n=5000)
handler: 91 wallclock secs (22.88 usr + 5.71 sys =
28.59 CPU) @ 174.89/s
(n=5000)
registry: 98 wallclock secs (23.77 usr + 5.45 sys =
29.22 CPU) @ 171.12/s
(n=5000)
Does Dispatch stat() the module on every hit? It might be useful to
provide a switch to turn that off, if so.
here's the only strace fragment with stat calls (with PerlSendHeaders Off)
read(3, "GET /Dispatch/foo HTTP/1.0\r\nConn"..., 4096) = 854
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL) = 965653681
gettimeofday({965653681, 395188}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [RT_0], 8) = 0
stat("/usr/local/apache/spinnaker/Dispatch/foo", 0xb7cc) = -1 ENOENT (No
such file or directory)
stat("/usr/local/apache/spinnaker/Dispatch", 0xb7cc) = -1 ENOENT (No
such file or directory)
stat("/usr/local/apache/spinnaker", {st_mode=S_IFDIR|0755, st_size=1024,
...}) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [RT_0], 8) = 0
rt_sigaction(SIGALRM, NULL, {0x40099490, [], SA_INTERRUPT|0x400}, 8) = 0
dup2(15, 2) = 2
which I would guess is just apache doing apache translation things, right?
After determining the proper class-method() by parsing the uri and making
some assumptions, Dispatch.pm calls class-can(method), which does magic
things, of which I know little about the inner workings...
I was interested in somehow trying to cache known methods to avoid
successive can() calls, but I wasn't quite sure how to go about that one
yet...
does that help?
--Geoff
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch-0.03
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Monday, August 07, 2000 9:29 AM To: Geoffrey Young Cc: '[EMAIL PROTECTED]' Subject: RE: [ANNOUNCE] Apache::Dispatch-0.03 On Mon, 7 Aug 2000, Geoffrey Young wrote: Does Dispatch stat() the module on every hit? It might be useful to provide a switch to turn that off, if so. which I would guess is just apache doing apache translation things, right? Yes, as the guide says, you could install an Apache::OK trans handler to get rid of those. After determining the proper class-method() by parsing the uri and making some assumptions, Dispatch.pm calls class-can(method), which does magic things, of which I know little about the inner workings... I was interested in somehow trying to cache known methods to avoid successive can() calls, but I wasn't quite sure how to go about that one yet... does that help? No, because it's not what I meant :-) oh :) Assuming you're in a development stage, I might expect Dispatch to stat the module that it's loading, like StatINC does, to check if it needs reloading again. And I'd turn that off for development. This gives you the advantage that Apache::Registry has of re-loading new scripts (except in Dispatch's case, its a module not a script). And it won't stat _all_ the modules installed on every hit, like StatINC does, so the overhead should be reasonable. well, I had assumed that for development, one could just install StatINC and have that work, but I didn't actually try it. until now, that is, and yes, it works... so, you are desiring a StatINC like feature within Dispatch itself? sounds like overkill to me - after all, you're in development, so stat()ing everything shouldn't be a big deal... --Geoff -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch-0.03
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Monday, August 07, 2000 9:45 AM To: Geoffrey Young Cc: '[EMAIL PROTECTED]' Subject: RE: [ANNOUNCE] Apache::Dispatch-0.03 so, you are desiring a StatINC like feature within Dispatch itself? sounds like overkill to me - after all, you're in development, so stat()ing everything shouldn't be a big deal... OK, so take development out of the picture, and put in there a server that you can't restart, but would like to be able to tweak your scripts on... yeah, yeah... :) actually, someone else asked me off the list for the same type of thing - I wasn't so sure about it, but I guess now I'm out numbered... DispatchStat On|Off coming soon to a server near you... --Geoff -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch-0.03
ok, here's a pre-PAN http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.04.tar.gz I borrowed some code from Apache::StatINC to add a single module reload. Unfortunately, this doesn't cover inherited circumstances, although I don't know how important that is going to be to folks. I really wanted to have DispatchStat be On, Off, or ISA, where ISA reloaded the asked for module and all it's parents - since given Class-method(), method() might not actually be in Class. Basically, I wasn't able to find a way to get to @Class::ISA where Class is unknown until run-time (that is, it's held in $class). I figured I should be able to use some symbolic referencing or something, but I couldn't get it to work. other than that, it seems to work ok... suggestions welcome :) --Geoff
[ANNOUNCE] Apache::Dispatch-0.03
The URL
http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.03.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GE/GEOFF/Apache-Dispatch-0.03.tar.gz
size: 5735 bytes
md5: 91eacb0aeff8e751ebc8c7156426fbfb
Changes:
0.03 8.4.2000
- complete API and internal rewrite
o added DispatchExtras and DispatchPrefix directive
o removed per-server configurations
o added new pre_dispatch, post_dispatch, error_dispatch
and dispatch_index method tie-ins
- updated documentation
- more kudos to Matt Sergeant for invaluable insight
README:
NAME
Apache::Dispatch - call PerlHandlers with the ease of CGI scripts
SYNOPSIS
httpd.conf:
PerlModule Apache::Dispatch
PerlModule Bar
Location /Foo
SetHandler perl-script
PerlHandler Apache::Dispatch
DispatchPrefix Bar
DispatchExtras Pre Post Error
/Location
DESCRIPTION
Apache::Dispatch translates $r-uri into a class and method and runs
it as a PerlHandler. Basically, this allows you to call PerlHandlers
as you would CGI scripts - directly from the browser - without having
to load your httpd.conf with a slurry of Location tags.
=head1 EXAMPLE
in httpd.conf
PerlModule Apache::Dispatch
PerlModule Bar
Location /Foo
SetHandler perl-script
PerlHandler Apache::Dispatch
DispatchPrefix Bar
/Location
in browser:
http://localhost/Foo/baz
the results are the same as if your httpd.conf looked like:
Location /Foo
SetHandler perl-script
PerlHandler Bar::dispatch_baz
/Location
but with the additional security of protecting the class name from
the browser and keeping the method name from being called directly.
Because any class under the Bar:: hierarchy can be called, one
Location directive is be able to handle all the methods of Bar,
Bar::Baz, etc...
CONFIGURATION DIRECTIVES
DispatchPrefix
The base class to be substituted for the $r-location part of the
uri. Applies on a per-location basis only.
DispatchExtras
A list of extra processing to enable per-request. They may be
applied on a per-server or per-location basis. If the main
handler is not a valid method call, the request is declined prior
to the execution of any of the extra methods.
Pre - eval()s Foo-pre_dispatch() prior to dispatching the uri
uri. The $@ of the eval is not checked in any way.
Post - eval()s Foo-post_dispatch() prior to dispatching the
uri. The $@ of the eval is not checked.
Error - If the main handler returns other than OK then
Foo-error_dispatch() is called and return status of it
is returned instead. Without this feature, the return
status of your handler is returned.
SPECIAL CODING GUIDELINES
Apache::Dispatch uses object oriented calls behind the scenes. This
means that you either need to account for your handler to be called
as a method handler, such as
sub dispatch_bar {
my $class = shift; # your class
my $r = shift;
}
or get the Apache request object yourself via
sub dispatch_bar {
my $r = Apache-request;
}
This also has the interesting side effect which would allow you to
define, say, a base error_dispatch() method in Foo which is then
inherited by Foo::Bar, but overriden in Foo::Bar::Baz.
NOTES
In addition to the special methods pre_dispatch(), post_dispatch(),
and error_dispatch(), if you define dispatch_index() it will be called
by /Foo or /Foo/. /Foo/index is always directly callable, but /Foo
will only translate to /Foo/index at the highest level - that is,
when just the location is specified. Meaning /Foo/Baz/index will call
Bar::Baz-dispatch_index, but /Foo/Baz will try to call Bar-Baz().
There is no require()ing or use()ing of the packages or methods prior
to their use as a PerlHandler. This means that if you try to dispatch
a method without a PerlModule directive or use() entry in your
startup.pl you probably will not meet with much success. This adds a
bit of security and reminds us we should be pre-loading that code in
the parent process anyway...
If the uri can be dispatched but contains anything other than
[a-zA-Z0-9_/-] Apache::Dispatch declines to handle the request.
Like everything in perl, the package names are case sensitive.
Verbose debugging is enabled by setting $Apache::Dispatch::DEBUG=1.
Very verbose debugging is enabled at 2. To turn off all debug
information set your apache LogLevel directive above info level.
This is alpha software, and as such has not been tested on multiple
platforms or environments for security, stability or other concerns.
It requires PERL_DIRECTIVE_HANDLERS=1, PERL_METHOD_HANDLERS=1,
PERL_LOG_API=1, PERL_HANDLER=1, and maybe other hooks to function
properly.
FEATURES/BUGS
No known bugs or unexpected features at this time...
SEE ALSO
perl(1), mod_perl(1), Apache(3)
AUTHOR
Geoffrey Young
RE: Apache::RefererBlock and ModuleConfig problem?
-Original Message- From: Michael Hall [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 03, 2000 1:23 PM To: [EMAIL PROTECTED] Subject: Re: Apache::RefererBlock and ModuleConfig problem? On Thu, Aug 03, 2000 at 01:27:17PM +0100, Matt Sergeant wrote: On Thu, 3 Aug 2000, Geoffrey Young wrote: you need to specify EVERYTHING=1 or PERL_DIRECTIVE_HANDLERS=1 to enable Apache::ModuleConfig, ie perl Makefile.PL EVERYTHING=1 make etc... Which raises an interesting question... Is there any way for Makefile.PL to determin if a particular option was enabled at mod_perl build time? 'http://site/perl-status?hooks' ? that's for run time - we're looking for a way to discover enabled hooks that doesn't require a running server. --Geoff -- I let my mind wander and it didn't come back... Mike Hall, Unix Admin - Rock Island Communications [EMAIL PROTECTED] System Admin - riverside.org [EMAIL PROTECTED]
RE: [ANNOUNCE] Apache::Dispatch-0.02
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 9:46 AM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'
Subject: Re: [ANNOUNCE] Apache::Dispatch-0.02
You're gonna hate me for this...
Can you add pre and post methods for the dispatching? It
would be really
useful to be able to (for example) save and restore
$SIG{__DIE__}, and
maybe other things like that, rather than having to
explicitly remember to
call them yourself.
ok, I'll work on adding pre_dispatch() and post_dispatch()
(and possibly
dispatch_error) calls to the existing framework and see what
I can come up
with...
--Geoff
well, I wasn't able to get that functionality into the existing design, but
that's ok because I wasn't too happy with it anyway :)
http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.03.tar.gz
is the new version. I haven't uploaded it yet because I wanted to ask
anyone interested whether they are terribly upset that the API will be
changing and Apache::Dispatch won't support per-server handler calling.
Basically, you'll still need at least one Location directive, since in
order to get pre and post processing in, we had to move to PerlHandler from
PerlFixupHandler.
anyway, here's the new README. I think the code generally cleaner than what
came before, so I'll upload it later in the week if nobody speaks up and
objects :)
--Geoff
NAME
Apache::Dispatch - call PerlHandlers with the ease of CGI scripts
SYNOPSIS
httpd.conf:
PerlModule Apache::Dispatch
PerlModule Bar
Location /Foo
SetHandler perl-script
PerlHandler Apache::Dispatch
DispatchPrefix Bar
DispatchExtras Pre Post Error
/Location
DESCRIPTION
Apache::Dispatch translates $r-uri into a class and method and runs
it as a PerlHandler. Basically, this allows you to call PerlHandlers
as you would CGI scripts - directly from the browser - without having
to load your httpd.conf with a slurry of Location tags.
EXAMPLE
in httpd.conf
PerlModule Apache::Dispatch
PerlModule Bar
Location /Foo
SetHandler perl-script
PerlHandler Apache::Dispatch
DispatchPrefix Bar
DispatchExtras Pre Post Error
/Location
in browser:
http://localhost/Foo/baz
the results are the same as if your httpd.conf looked like:
Location /Foo
SetHandler perl-script
PerlHandler Bar::dispatch_baz
/Location
This configuration offers additional security by protecting the
class from the browser and keeping the method name from being
called directly. Because any class under the Bar:: hierarchy can be
called, one Location directive is able to handle all the methods
of Bar, Bar::Baz, etc...
CONFIGURATION DIRECTIVES
DispatchPrefix
Applies on a per-location basis only. The base class to be
substituted for the $r-location part of the uri.
DispatchExtras
A list of extra processing to enable per-request. They may be
applied on a per-server or per-location basis. If the main
handler is not a valid method call, the request is declined prior
to the execution of any of the extra methods.
Pre - eval()s Foo-pre_dispatch() prior to dispatching the uri
uri. The $@ of the eval is not checked in any way.
Post - eval()s Foo-post_dispatch() prior to dispatching the
uri. The $@ of the eval is not checked.
Error - If the main handler returns other than OK then
Foo-error_dispatch() is called and return status of it
is returned instead. Without this feature, the return
status of your handler is returned.
SPECIAL CODING GUIDELINES
Apache::Dispatch uses object oriented calls behind the scenes. This
means that you either need to account for your handler to be called
as a method handler, such as
sub dispatch_bar {
my $class = shift; # your class
my $r = shift;
}
or get the Apache request object yourself via
sub dispatch_bar {
my $r = Apache-request;
}
NOTES
In addition to the special methods pre_dispatch(), post_dispatch(),
and error_dispatch(), if you define dispatch_index() it will be called
if the method is empty (eg, by /Foo or /Foo/).
There is no require()ing or use()ing of the packages or methods prior
to their use as a PerlHandler. This means that if you try to dispatch
a method without a PerlModule directive or use() entry in your
startup.pl you probably will not meet with much success. This adds a
bit of security and reminds us we should be pre-loading that code in
the parent process anyway...
If the uri can be dispatched but contains anything other than
[a-zA-Z0-9_/-] Apache::Dispatch declines to handle the request.
Like everything in perl, the package names are case sensitive.
Verbose debugging is enabled by setting $Apache::Dispatch::DEBUG=1.
Very verbose debugging is enabled at 2. To turn off all debug
information set your apache
[ANNOUNCE] Apache::Dispatch-0.02
DispatchMethod and DispatchMode rules. Applies on a per-server basis, except where a Location directive is using DispatchBase. Values of the main server will be inherited by each virtual host. NOTES There is no require()ing or use()ing of the packages or methods prior to their use as a PerlHandler. This means that if you try to dispatch a method without a PerlModule directive or use() entry in your startup.pl you probably will not meet with much success. This adds a bit of security and reminds us we should be pre-loading that code in the parent process anyway... Apache::Dispatch tries to be a bit intelligent about things. If, by the time it reaches the fixup phase, the uri can be mapped to a real file, directory, or Location tag (other than one containing a DispatchBase directive), Apache::Dispatch declines to handle the request. If the uri can be dispatched but contains anything other than [a-zA-Z0-9_/-] Apache::Dispatch declines to handle the request. DispatchDeny always includes the following namespaces: AUTOLOAD CORE SUPER UNIVERSAL Like everything in perl, the package names are case sensitive. Verbose debugging is enabled by setting $Apache::Dispatch::DEBUG=1. Very verbose debugging is enabled at 2. To turn off all debug information set your apache LogLevel directive above info level. This is alpha software, and as such has not been tested on multiple platforms or environments for security, stability or other concerns. It requires PERL_FIXUP=1, PERL_LOG_API=1, PERL_HANDLER=1, and maybe other hooks to function properly. FEATURES/BUGS No known bugs or features at this time... SEE ALSO perl(1), mod_perl(1), Apache(3) AUTHOR Geoffrey Young [EMAIL PROTECTED] COPYRIGHT Copyright 2000 Geoffrey Young - all rights reserved. This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
RE: [ANNOUNCE] Apache::Dispatch-0.02
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 9:46 AM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'
Subject: Re: [ANNOUNCE] Apache::Dispatch-0.02
You're gonna hate me for this...
Can you add pre and post methods for the dispatching? It
would be really
useful to be able to (for example) save and restore $SIG{__DIE__}, and
maybe other things like that, rather than having to
explicitly remember to
call them yourself.
ok, I'll work on adding pre_dispatch() and post_dispatch() (and possibly
dispatch_error) calls to the existing framework and see what I can come up
with...
--Geoff
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 29, 2000 6:16 AM
To: Geoffrey Young
Cc: [EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] Apache::Dispatch
On Fri, 28 Jul 2000, Geoffrey Young wrote:
hi Matt...
I can't access my normal email from home, so forgive
the non-quoting of your message... :)
the way I set it up, when running in DispatchMode =
Safe (the default, which I didn't mention in the
docs), you wouldn't be able to call /File/Find/find
without explitily allowing File or File::Find in
DispatchAllow. I think this addresses the namespace
issue - if someone wants to open up File::Find, or
whatever, that badly, they can always do it anyway, I
suppose.
OK, I think that covers the namespace issue - although I
don't see a use
for a non-safe mode!
thanks for the input. after thinking about it over the weekend, I think we
just need a few changes to make it better...
I'll remove Foolish (the name was a dead givaway that it would be gone soon
:), but I think that Brave would greatly enhance the development process by
allowing you to test handlers without having to stop and start the server to
add location tags to reload the module. I'll be sure to add documentation
to that extent.
[basically the way I saw it working was you specified a
namespace prefix
for each Location, so you'd have DispatchPrefix MyApp, and
http://server/location/Foo would call MyApp::Foo-handler,
assuming that
/location is the entry in Location for the above config line]
I did re-read the archives and I saw you mention this. I think I may add an
additional directive
DispatchClass that only works from a Location tag that does just that. It
would be in addition to the existing API and would allow only one class per
location. I'll also add documentation suggesting that it exists for
security reasons, so using it like
Location /Foo
DispatchClass Foo
defeats the purpose :)
But maybe we're missing eachother on this? Or you
have something in mind that I don't? I'll admit, I'm
far from a web security expert, and this does need to
be quite secure to be a benefit to anyone...
as for method restrictions, I can't remember if it was
talked about - I'll have to go over the archives
again.
however, having to specify Foo::Bar-method for each
method you want to use seems like overkill to me,
almost as limiting as having to add all those location
tags.
Thats not what I meant. If you just force a method prefix,
the same way I
suggest above using a namespace prefix, and default to cmd_
or something,
then its much easier to design a complex app in a class where you have
web-space functions (those beginning with cmd_) and non-web space
functions (i.e. private functions that implement parts of your
application, where you don't want people directly calling the
method). Without that, it would be trivial for someone to
call new() or
something, which might not be intended (and might have side effects).
right, now I remember. I still think that implying handler() should be an
option, however, since some people do write one handler per module for
mod_perl. How about changing DispatchMethod Subroutine to Prefix and having
that prefix all method calls with dispatch_ , which seems a bit more self
documenting?
I suppose that setting DispatchMethod = Handler
(the default) along with Safe mode would offer a good
amount of protection against blunders, allowing only
Foo::Bar-handler. I guess I was just trying to offer
a fair amount of flexibility, but with flexibility
comes the ability to kill your server. of course, a
regular CGI script can do that too if you're not
careful. :)
Thats too restrictive - that way you have to have one class
per URL - not
a nice way to work.
I don't really think that, in general, imposing method
restrictions is necessary, for there isn't really a
way to pass any arguments to the method anyway, right?
don't all mod_perl handlers get the request object as
the only argument (unless prototyped as $$)?
Just because you can't pass arguments, doesn't mean bad stuff can
happen... Imagine you write a sub clear_cache {...}, that empties some
sort of cache. It doesn't take any arguments,
Apache::Dispatch passes in a
request object as the first param, but its ignored by the
function, and
the 733t h4x0r has cleared your cache. (not a terribly
dangerous example,
but hopefully you get the picture).
yeah, I see it now...
do you think the above addresses all your issues?
--Geoff
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Monday, July 31, 2000 10:35 AM To: Geoffrey Young Cc: [EMAIL PROTECTED] Subject: RE: [ANNOUNCE] Apache::Dispatch On Mon, 31 Jul 2000, Geoffrey Young wrote: I'll remove Foolish (the name was a dead givaway that it would be gone soon :), but I think that Brave would greatly enhance the development process by allowing you to test handlers without having to stop and start the server to add location tags to reload the module. I'll be sure to add documentation to that extent. OK, I think the documentation then should suggest (obviously not enforce) that this is useful primarily for testing new handlers, not as a way to build your application due to the inherent security issues. ok - I might even change the name to Development or something like that... [basically the way I saw it working was you specified a namespace prefix for each Location, so you'd have DispatchPrefix MyApp, and http://server/location/Foo would call MyApp::Foo-handler, assuming that /location is the entry in Location for the above config line] I did re-read the archives and I saw you mention this. I think I may add an additional directive DispatchClass that only works from a Location tag that does just that. It would be in addition to the existing API and would allow only one class per location. I'll also add documentation suggesting that it exists for security reasons, so using it like Location /Foo DispatchClass Foo defeats the purpose :) Of course, but thats not likely to happen too often :) I don't think DispatchClass is a great name though. It implies that you'll always be calling methods in that class. Prefix sounded better to me... But you're the boss :) Because you won't always be calling Foo, but also Foo::Bar::Blarg? That makes sense... But maybe we're missing eachother on this? Or you have something in mind that I don't? I'll admit, I'm far from a web security expert, and this does need to be quite secure to be a benefit to anyone... as for method restrictions, I can't remember if it was talked about - I'll have to go over the archives again. however, having to specify Foo::Bar-method for each method you want to use seems like overkill to me, almost as limiting as having to add all those location tags. Thats not what I meant. If you just force a method prefix, the same way I suggest above using a namespace prefix, and default to cmd_ or something, then its much easier to design a complex app in a class where you have web-space functions (those beginning with cmd_) and non-web space functions (i.e. private functions that implement parts of your application, where you don't want people directly calling the method). Without that, it would be trivial for someone to call new() or something, which might not be intended (and might have side effects). right, now I remember. I still think that implying handler() should be an option, however, since some people do write one handler per module for mod_perl. How about changing DispatchMethod Subroutine to Prefix and having that prefix all method calls with dispatch_ , which seems a bit more self documenting? Sure. And have http://server/location/Foo/ call MyApp::Foo-dispatch_index() (or if you want to be microsoftian, dispatch_default() ;-) wow - maybe later. right now I have it declining directory requests so that mod_dir can handle them. that's a really good idea, though - I'll see what I can do with it... --Geoff -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
[ANNOUNCE] Apache::Dispatch
The URL http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.01.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Dispatch-0.01.tar.gz size: 5170 bytes md5: acee515fc8d19223f017c8380cae5b26 well, after the conference, I felt motivated to do some stuff. Then I got on the red-eye and spent the early part of this week recovering :) anyway, Apache::Dispatch is a module we've talked about before and that I've been meaning to get to for a while, but just found the tuits this week. Hopefully, it addresses some of the safety concerns expressed a few months ago about such a concept. consider it REAL alphaware for the moment - it works (at least for me), but until everyone pokes around it some and looks for holes it may not be entirely safe. that said, if people are listening beyond the template traffic, here is the README... --Geoff NAME Apache::Dispatch - call PerlHandlers with the ease of CGI SYNOPSIS httpd.conf: PerlModule Apache::Dispatch PerlFixupHandler Apache::Dispatch DispatchMode Safe DispatchMethod Handler DispatchAllow Custom DispatchDeny Apache Protected DESCRIPTION Apache::Dispatch translates $r-uri into a class and method and runs it as a PerlHandler. Basically, this allows you to call PerlHandlers as you would CGI scripts - from the browser - without having to load your httpd.conf with a slurry of Location tags. EXAMPLE in httpd.conf: PerlModule Apache::Dispatch PerlFixupHandler Apache::Dispatch DispatchMode Safe DispatchMethod Handler DispatchAllow Test in browser: http://localhost/Foo the results are the same as if your httpd.conf looked like: Location /Foo SetHandler perl-script PerlHandler Foo /Location CONFIGURATION All configuration directives apply on a per-server basis. Virtual Hosts inherit any directives from the main server or can delcare their own. DispatchMode- Safe: allow only those methods whose namespace is explitily allowed by DispatchAllow and explitily not denied by DispatchDeny Brave: allow only those methods whose namespace is explitily not denied by DispatchDeny Foolish:allow any method DispatchMethod - Handler:assume the method name is handler(), meaning that /Foo/Bar becomes Foo::Bar-handler() Subroutine: assume the method name is the last part of the uri - /Foo/Bar becomes Foo-Bar() Determine: the method may either be handler() or the last part of the uri. the last part is checked first, so this has the additional benefit of allowing both /Foo/Bar/handler and /Foo/Bar to to call Foo::Bar::handler(). of course, if Foo-Bar() exists, that will be called since it would be found first. DispatchAllow - a list of namespaces allowed execution according to the above rules DispatchDeny- a list of namespaces denied execution according to the above rules NOTES Apache::Dispatch tries to be a bit intelligent about things. If by the time the uri reaches the fixup phase it can be mapped to a real file, directory, or Location tag, Apache::Dispatch declines the request. DispatchDeny always includes the following namespaces: AUTOLOAD CORE SUPER UNIVERSAL Like everything in perl, the package names are case sensitive relative to $r-uri. Verbose debugging is enabled by setting $Apache::Dispatch::DEBUG=1. Very verbose debugging is enabled at 2. To turn off all debug information set your apache LogLevel directive above info level. This is alpha software, and as such has not been tested on multiple platforms or environments. It requires PERL_INIT=1, PERL_LOG_API=1, and maybe other hooks to function properly. FEATURES/BUGS DispatchDeny and DispatchAllow work, but not quite the way I want. For instance, DispatchDeny Custom will deny to Customer:: methods, while DispatchAllow Custom will allow Custom::Filter-handler() and Custom-filter(), but deny Customer:: methods. I think DistpatchAllow has the proper behavior, but DispatchDeny may need to be changed. Input is welcome. SEE ALSO perl(1), mod_perl(1), Apache(3), Apache::ModuleConfig(3) AUTHOR Geoffrey Young [EMAIL PROTECTED] COPYRIGHT Copyright 2000 Geoffrey Young - all rights reserved. This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
Re: [ANNOUNCE] Apache::Dispatch
hi Matt... I can't access my normal email from home, so forgive the non-quoting of your message... :) the way I set it up, when running in DispatchMode = Safe (the default, which I didn't mention in the docs), you wouldn't be able to call /File/Find/find without explitily allowing File or File::Find in DispatchAllow. I think this addresses the namespace issue - if someone wants to open up File::Find, or whatever, that badly, they can always do it anyway, I suppose. But maybe we're missing eachother on this? Or you have something in mind that I don't? I'll admit, I'm far from a web security expert, and this does need to be quite secure to be a benefit to anyone... as for method restrictions, I can't remember if it was talked about - I'll have to go over the archives again. however, having to specify Foo::Bar-method for each method you want to use seems like overkill to me, almost as limiting as having to add all those location tags. I suppose that setting DispatchMethod = Handler (the default) along with Safe mode would offer a good amount of protection against blunders, allowing only Foo::Bar-handler. I guess I was just trying to offer a fair amount of flexibility, but with flexibility comes the ability to kill your server. of course, a regular CGI script can do that too if you're not careful. :) I don't really think that, in general, imposing method restrictions is necessary, for there isn't really a way to pass any arguments to the method anyway, right? don't all mod_perl handlers get the request object as the only argument (unless prototyped as $$)? It had occured to me not to allow Foolish behavior (allowing anything under the sun to execute) so I may remove it if there is much reservation from folks... let me know what you think... --Geoff __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
RE: Patch not accepted?
-Original Message- From: Ken Williams [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 27, 2000 2:38 PM To: modperl Subject: Patch not accepted? Hi all, I sent a patch for Apache::test a week or so ago. I got no responses, so I'm here to advocate again for its incorporation. The original message is here: I haven't had a chance to test it out yet, but the idea is a good one - it would be nice if each of the Apache:: CPAN modules were to have a live test. better still that they can use a common package for it. I like the way you changed Apache::Filter's test suite in recent versions, so if it's like that, cool... I can only attribute the lack of response to the voracious appetites of various booth babes... --Geoff http://forum.swarthmore.edu/epigone/modperl/swonflefim Are any of the CVS guardians listening? Doug seems to be long absent. -Ken
RE: lookup_uri() / lookup_file() behavior
-Original Message- From: Christian Gilmore [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 27, 2000 12:34 PM To: Modperl Mailing List (E-mail) Subject: lookup_uri() / lookup_file() behavior I'm trying to determine what the proper behavior for lookup_uri() / lookup_file() should be. This call creates a subrequest that appears as if it is a new one up until the content handler phase. From the eagle book, pages 452-3: lookup_file() and lookup_uri() invoke Apache subrequests. A subrequest is treated exactly like an ordinary request, except that the post read request ... [is] not run... lookup_uri() performs the URI translation on the provided URI, passing the request to the access control and authorization handlers, if any... Should the subrequest have the same stack of handlers and environment with which the parent request began or should it have the same stack and environment at the time the parent request launched the subrequest? From my readings of the Modules eagle book (such as pages 62-3 and 452-3) and the Apache eagle book (such as page 271) and my own common sense, I'd say it should be the former (same as the beginning of the parent). What would you say? sounds right - if you're wondering whether using push/set_handlers() would apply to a subrequest, I would think not. each request has it's own request object and associated parameters (such as $r-uri, etc...), so it makes sense to me that the phase handlers would not be inherited, especially since the uri could be to a different Location which could have it's own set of handlers. but making sense to me is certainly far from gospel... and anyway, I tried a test case and couldn't get a pushed fixup handler to register with the subrequest :) HTH --Geoff Regards, Christian - Christian Gilmore Infrastructure Tools Team Lead Web Multimedia Development Tivoli Systems, Inc.
RE: lookup_uri() / lookup_file() behavior
-Original Message- From: Christian Gilmore [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 27, 2000 3:46 PM To: 'Geoffrey Young'; 'Modperl Mailing List (E-mail)' Subject: RE: lookup_uri() / lookup_file() behavior sounds right - if you're wondering whether using push/set_handlers() would apply to a subrequest, I would think not. That's exactly what I'm wondering. and anyway, I tried a test case and couldn't get a pushed fixup handler to register with the subrequest :) Try clearing the stack in the parent request before the subrequest is launched. Does it reappear in the subrequest? well that's interesting - no it doesn't... if I push a handler on the initial request, it doesn't show up in the subrequest (as expected) but if I undef a phase for the initial request, the subrequest doesn't execute them either (not what I expect, at least). looks like a bug? well, get/set handlers is known to be problematic already - I know Doug et al (hi Eric :) plan on (someday) re-implementing it, but for now, I guess it's just another problem case :( HTH --Geoff Regards, Christian
RE: DBD-Oracle and mod_perl
-Original Message- From: Tommy Wareing [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 26, 2000 8:55 AM To: Geoffrey Young Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: Re: DBD-Oracle and mod_perl On Wed, Jul 26, 2000 at 08:27:06AM -0400, Geoffrey Young wrote: hi everyone... I was just wondering if anyone has been able to get the newer releases of DBD-Oracle to work under mod_perl? that is, using DBD-Oracle 1.04, 1.05, and 1.06, under perl 5.005 (RH6.0 standard) and DBI-1.14 I get consistently non-working results, but only when running under mod_perl. If I revert to 1.03, all is fine again... Tim's changed the Makefile.PL to include $::opt_b = 1; # try to use Oracle's own 'build' rule (it used to default to 0). is this the same as the Makefile.PL -b option? Tim mentioned making that the default in later versions, but that is what I have been using for a while. Hmmm... Unfortunately, this has the side effect of requiring you to set LD_LIBRARY_PATH to load the libararies, and to my knowledge (not very much knowledge), there's no way to actually set this value back to 0, other than editing the script. So, either a) edit the script, don't use Oracle's build rule, and don't set LD_LIBRARY_PATH, or b) use Oracle's build rule, and do set LD_LIBRARY_PATH. well LD_LIBRARY_PATH was set to $ORACLE_HOME/lib, but another suggested adding $ORACLE_HOME/lib to /etc/ld.so.config, which seemed to work ok. thanks for your input and help. --Geoff I presume there ought to be a downside to option a? -- Tommy Wareing This .sig space available for rent. Apply within..
RE: DBD-Oracle and mod_perl
-Original Message- From: aaron [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 26, 2000 8:48 AM To: Geoffrey Young Cc: [EMAIL PROTECTED] Subject: Re: DBD-Oracle and mod_perl at a time earlier than now, Geoffrey Young wrote: hi everyone... I was just wondering if anyone has been able to get the newer releases of DBD-Oracle to work under mod_perl? yep. I was getting these errors before the conference, but wanted to investigate further. Yesterday I rolled my own perl 5.6 ( with -Dusethreads) and rebuilt everything, mod_perl, DBI, DBD::Oracle, etc. Still the same results... i've got it working under SunOS 5.7 and RedHat Linux 6.2 basically, I get the following errors on a simple connect and 'select sysdate from dual': looks like it's not linked correctly. try adding $ORACLE_HOME/lib to LD_LIBRARY_PATH or /etc/ld.so.conf ( and run ldconfig ). it was in LD_LIBRARY_PATH, but not in /etc/ld.so.conf. cool, that seemed to do the trick... thanks not knowing much about ldconfig, just curious about the error: ldconfig: warning: /u01/app/oracle/product/8.0.5.1/lib/libclntsh.so.1.0 is not a symlink cause for concern? --Geoff use DBD::Oracle; # results in: # Can't load '/usr/local/lib/perl5/site_perl/5.6.0/i686-linux-thread-multi/ auto/DBD/Oracl e/Oracle.so' for module DBD::Oracle: libclntsh.so.1.0: cannot open shared object file: No such file or directory at see.. it can't find libclntsh.so.1.0. i don't have that exact file, but i do have /opt/oracle/product/8.1.6/lib/libclntsh.so hth, aaron
DBD-Oracle and mod_perl
hi everyone... I was just wondering if anyone has been able to get the newer releases of DBD-Oracle to work under mod_perl? that is, using DBD-Oracle 1.04, 1.05, and 1.06, under perl 5.005 (RH6.0 standard) and DBI-1.14 I get consistently non-working results, but only when running under mod_perl. If I revert to 1.03, all is fine again... I was getting these errors before the conference, but wanted to investigate further. Yesterday I rolled my own perl 5.6 ( with -Dusethreads) and rebuilt everything, mod_perl, DBI, DBD::Oracle, etc. Still the same results... basically, I get the following errors on a simple connect and 'select sysdate from dual': use DBD::Oracle; # results in: # Can't load '/usr/local/lib/perl5/site_perl/5.6.0/i686-linux-thread-multi/auto/DBD/Oracl e/Oracle.so' for module DBD::Oracle: libclntsh.so.1.0: cannot open shared object file: No such file or directory at /usr/local/lib/perl5/5.6.0/i686-linux-thread-multi/DynaLoader.pm line 200. at /usr/local/apache/perl-bin/dbtest.pl line 9 letting DBI load DBD::Oracle itself, my trace looks like this: DBI 1.14-nothread dispatch trace level set to 6 - DBI-connect(dbi:Oracle:HELM, www, , HASH(0x86e040c)) - DBI-install_driver(Oracle) for perl=5.006 pid=3393 ruid=99 euid=99 and that's all, but the script manages to release control of the phase, because I use a cleanup handler to log to (a different) database, which then gets: - DBI-connect(dbi:Oracle:PORTAL, porter, , HASH(0x8480178)) - DBI-install_driver(Oracle) for perl=5.006 pid=3393 ruid=99 euid=99 install_driver: DBD::Oracle loaded (version 1.06) Use of inherited AUTOLOAD for non-method DBD::Oracle::ORA_OCI() is deprecated at /usr/local/lib/perl5/site_perl/5.6.0/i686-linux-thread-multi/DBD/Oracle.pm line 48. Use of uninitialized value. of course, the same script running from shell runs just fine (with the three mod_perl related lines removed, of course), both use()ing DBD::Oracle and without. anyway, it's probably just me. I don't have a problem with DBD::Oracle 1.03 so it's no biggie but I wanted to point it out, just in case... --Geoff Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.14-5.0, archname=i686-linux-thread-multi uname='linux spinnaker.laserlink.net 2.2.14-5.0 #1 tue mar 7 21:07:39 est 2000 i686 unknown ' config_args='-Dcc=gcc -Dusethreads -des' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='gcc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-D_REENTRANT -fno-strict-aliasing' ccflags ='-D_REENTRANT -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 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, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lpthread -lc -lposix -lcrypt libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a 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: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Jul 25 2000 19:47:55 @INC: /usr/local/lib/perl5/5.6.0/i686-linux-thread-multi /usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl .
RE: Severe problem with $r-log_error
did you compile mod_perl with EVERYTHING=1 or PERL_LOG_API=1
--Geoff
-Original Message-
From: Axel Wagner [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 11, 2000 11:30 AM
To: [EMAIL PROTECTED]
Subject: Severe problem with $r-log_error
Hi,
I have a serious problem with the logging facility of MOD_PERL.
Something that once worked perfectly well suddenly turned quite.
I have tried all the logging statements from the eagle book, but
my error log file refuses to show any trace thereof.
I have also set the LogLevel to debug, but even with the following
I do not succeed:
my $rlog = $r-log;
$rlog-error('Message I try to print out');
nor with any of the following:
$r-log_error($msg);
$r-log-error($msg);
Not even a $r-log-debug(); works.
Only a brute warn() leaves a trace.
This is the identification of my server:
Apache/1.3.12 (Unix) PHP/3.0.16 mod_perl/1.24 mod_ssl/2.6.4
OpenSSL/0.9.5a
Help would be very appreciated.
Axel Wagner
--
Biobase GmbH -Mascheroder Weg 1B- D-38114 Braunschweig
phone: +49531/2603610 fax:+49531/2603670
eMail: [EMAIL PROTECTED] http://www.biobase.de
RE: PerlSetupEnv is evil
-Original Message- From: Roger Espel Llima [mailto:[EMAIL PROTECTED]] Sent: Friday, July 07, 2000 5:19 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: PerlSetupEnv is evil [snip] It also turns out that specifying "PerlSetupEnv Off" outside of any Directory apparently gets ignored. Is that a bug? I put another "PerlSetupEnv Off" in the Directory entry for the DocumentRoot, and now it's not doing these annoying subrequests anymore. it is a bug (prior report: http://marc.theaimsgroup.com/?l=apache-modperlm=95867712412668w=2) - PerlSetupEnv is not inheriting properly. I think this fell to low on the ToDo list since there is a (rather lengthy) workaround of sprinkling PerlSetupEnv Off everywhere you need/want it. Anyway, after tracing through this stuff, I'm more convinced than ever that PerlSetupEnv is ugly and slow and to be avoided. well, PerlSetupEnv Off is a known performance booster, now we know by how much :) --Geoff -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
RE: Interfacing from Apache to Access
look into DBI and DBD::ODBC on CPAN (http://www.perl.com/CPAN-local/modules/by-module/) from the DBI mailing list, I gather lots of folks use DBD::ODBC for perl-MSAccess connectivity... HTH --Geoff -Original Message- From: Lorenzo Gordon [mailto:[EMAIL PROTECTED]] Sent: Monday, July 10, 2000 9:45 AM To: modperl Subject: Interfacing from Apache to Access Hello, I am a software developer for The London School of Hygiene Tropical Medicine, UK. My query is the following: I have been able to successfully run a Perl script from MS-DOS that would pull out the necessary info. from an Access database I wrote last year (Access 97). The problem is that in order to get the script to talk to the web pages i am currently designing, the script must run on the School's network, which is a Unix Solaris machine running Apache. Both the School's Web Administrator have been struggling (and so far failing) to find an ODBC-like driver that will enable Unix to talk to Access via my Perl script. The implications of not been able to create some connection between these various componenets are massive. Any solutions/pointers/advice anyone might have would be greatly appreciated. I can't believe I'm the first person to have come across this problem! Please respond either to [EMAIL PROTECTED] . TIA, Lorenzo Gordon.
RE: Apache::ASP and post-POST redirect
-Original Message- From: Joshua Chamas [mailto:[EMAIL PROTECTED]] Sent: Friday, July 07, 2000 12:46 PM To: Dmitry Beransky Cc: [EMAIL PROTECTED]; Ken Williams Subject: Re: Apache::ASP and post-POST redirect I bet its an ASP-Apache::Filter issue, because in general there has been quite a lot with of issues coordinating between filtered modules on the headers. I haven't really been following this thread, since I don't use asp, but Apache::Filter (1.09?) introduced a new mechanism for sending the headers. basically, it waits to see the first print to STDOUT from the last filter before calling $r-send_http_headers(), whereas previously it was sending headers right at the call to $r-filter_input by the last filter. I don't see how this would make a difference to anyone (except to the positive), though, but I thought I'd bring it up just in case... HTH --Geoff
PerlAddVar bug
Sorry to bring up PerlAddVar again, but this time I have a legitimate bug.
It stems from what I reported last time about items in Apache::Table not
being visible outside a Location directives:
that is, given:
Alias /test /usr/local/apache/test
# this outside value of foo doesn't get seen!
# PerlSetVar here doesn't make a difference either
PerlAddVar foo "outside"
Location /test
SetHandler perl-script
PerlHandler Test::AddVar
Order Allow,Deny
Allow from All
PerlSetupEnv Off
PerlAddVar foo "one"
PerlAddVar foo "two"
PerlAddVar bar "bar"
PerlAddVar foo "three"
/Location
package Test::AddVar;
use Apache::Constants qw( OK );
use strict;
sub handler {
my $r = shift;
$r-send_http_header("text/plain");
my @foo = $r-dir_config-get('foo');
print "get() foo\n";
print join "\n", @foo;
print "\ndo()\n";
$r-dir_config-do( sub {
my($key, $value) = @_;
print("$key = $value\n");
1;
});
print "done!";
return OK;
}
1;
results:
get() foo
one
two
three
do()
foo = one
foo = two
bar = bar
foo = three
done!
-Geoff
RE: What is *.xs file?
-Original Message- From: James G Smith [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 06, 2000 11:20 AM To: Sam Xie Cc: [EMAIL PROTECTED] Subject: Re: What is *.xs file? Sam Xie [EMAIL PROTECTED] wrote: Umm this list is for perl as a module in apache not modules for perl... Yes! It is for a perl module in apache. I am going to write a perl module, which is capable to read a name list file in AFS for authenticattion and authorization. That's why I am studying on this issue. Thanks for your help! Sam I would start with `man h2xs' (only a start), and get _Programming Perl_, which talks about it some, as does _The Perl Cookbook_, I believe. Then there's the perlmodlib, perlxs, and perlxstut man pages. The first covers writing perl modules, the second covers the xs interface, and the last is a tutorial. After those, you might want to read perlguts (man page covering the internal functions within perl). I haven't read through all these, but they would be my first place to look. perlmonth.com had a rather nice set of XS articles starting in issue 6 issue 10 has links to all of them: http://www.perlmonth.com/columns/modules/modules.html?issue=10 --Geoff -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
RE: PerlAddVar bug
-Original Message-
From: Eric Cholet [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 06, 2000 1:47 PM
To: Matt Sergeant; Geoffrey Young
Cc: [EMAIL PROTECTED]
Subject: Re: PerlAddVar bug
On Thu, 6 Jul 2000, Geoffrey Young wrote:
Sorry to bring up PerlAddVar again, but this time I have
a legitimate bug.
It stems from what I reported last time about items in
Apache::Table not
being visible outside a Location directives:
See the section on DIR_MERGE in the Eagle book. It just
needs someone to
write that code for PerlAddVar/PerlSetVar.
But there is dir_merge code for those variables, this works for me:
PerlSetVar MyVar foo
Location /test/
PerlSetVar MyVar bar
SetHandler "perl-script"
PerlHandler Apache::Registry
Options +ExecCGI
/Location
test/foo:
my $r = shift;
$r-send_http_header('text/plain');
print $r-dir_config('MyVar');
% GET http://localhost/test/foo
bar
I don't know about PerlAddVar, haven't tested Geoff's examples yet,
but it should work as well since those vars all end up in
perl_dir_config-vars
I guess my expectation is that $r-dir_config('MyVar') and
$r-dir_config-get('MyVar') should inherit equally, which as far as I can
tell, they don't. PerlSetVar or PerlAddVar - it makes no difference.
if you change your test case to:
PerlSetVar MyVar foo
Location /test/
# PerlSetVar MyVar bar
SetHandler "perl-script"
PerlHandler Apache::Registry
Options +ExecCGI
/Location
test/foo:
my $r = shift;
$r-send_http_header('text/plain');
print "1: " . $r-dir_config('MyVar');
print "\n2: " . $r-dir_config-get('MyVar');
% GET http://localhost/test/foo
1: foo
2:
I think you'll see it...
--Geoff
--
Eric
RE: can't properly append to file from mod_perl script
Are you setting PerlWarn On and checking for errors?
I get these when compiling your script under RegistryLoader:
Variable "$results_file" will not stay shared at
/usr/local/apache/perl-bin/test.cgi line 29.
Variable "$entry" will not stay shared at
/usr/local/apache/perl-bin/test.cgi line 31.
Variable "$display_file" will not stay shared at
/usr/local/apache/perl-bin/test.cgi line 38.
Useless use of concatenation in void context at
/usr/local/apache/perl-bin/test.cgi line 56.
see
http://perl.apache.org/guide/perl.html#my_Scoped_Variable_in_Nested_S
the mod_perl guide is full of lots of goodies that are worth reading...
HTH
--Geoff
-Original Message-
From: Rob Egan [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 30, 2000 8:01 PM
To: [EMAIL PROTECTED]
Subject: RE: can't properly append to file from mod_perl script
Hi,
I sent an earlier post with a script that was appending
garbage along with
user email addresses that were submitted through a form.
After seeing all
the suggestions about improvement, I went ahead and rewrote
the script from
scratch (it's much shorter now!). My version actually
prevents garbage from
being placed into the output file, but it still has a
problem. If I open up
two browsers on separate machines, go to the page containing
the form, and
simultaneously submit addresses from both machines, after maybe 8 or 9
entries the output becomes incorrect. For example, if I enter
the following
e-mail addresses one at a time from the form:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Then I view the output file and see this output:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
It's as though the parameters I'm pulling from the form get
stuck somewhere,
but I can't figure out where. I tried autoflushing buffers
for both STDOUT
and the output channel I use to write the output (called
RESULTS in the
script), but that doesn't help. Some of you guys had
mentioned writing some
cleanup code after I close my file, but I don't quite
understand what I need
to clean up (sorry, I'm kind of new at this). Any ideas? (the
code is below)
-Rob
begin script text
#!/usr/local/bin/perl -w
# call strict, CGI, and Fcntl modules
use strict;
use CGI;
use Fcntl qw(:flock);
use FileHandle;
# autoflush buffers
$| = 1;
# Variable definitions
my $results_file = "./beastie.results.csv";
my $display_file = "./email_thankyou.html";
my $entry;
Sub routine definitionsDon't change anything
below here
# General error routine (takes 3 string arguments, displays
results in HTML)
sub bail {
my ($status, $keyword, $message) = "@_";
print h1("$status $keyword"), p($message), end_html();
die $message;
}
# Open results file, lock it, write entry, close/unlock it.
sub write_entry {
RESULTS-autoflush(1);
open(RESULTS, "$results_file") || bail(500, "Results
Error", "$!");
flock(RESULTS, LOCK_EX);
print RESULTS $entry;
close(RESULTS);
}
# Display thank you page with link back to main site.
sub say_thanks {
print CGI::header();
open(DISPLAYFILE, "$display_file") || bail(500, "Error", "$!");
while(DISPLAYFILE) {
print;
}
close(DISPLAYFILE);
}
Begin main program
# Create CGI object, and gather email addresses into array
my $query = CGI-new();
my $address = $query-param('email');
# Format URL encoded email address into ascii, append date
stamp to it.
$address =~ s/%([\dA-Fa-f][\dA-Fa-f])/pack("C", hex($1))/eg;
$entry = "$address, " . localtime() . "\n";
# Write the email and timestamp to results file, display
thank you page,
exit.
write_entry();
say_thanks();
exit(0);
End of script
RE: error DBI with quote
this more properly belongs on the DBI list, but see
page 122 of the cheetah book:
"Bind values are passed to the database seperately from
the SQL statement, so there's no need to 'wrap up' the value in SQL quoting
rules."
thus, no need to call quote()...
HTH
--Geoff
-Original Message-From: Jesús Lasso Sánchez
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, July 05, 2000 2:27
PMTo: [EMAIL PROTECTED]Subject: error DBI with
quote
Hi,
I have a problem with DBI and Oracle. I
have an input form where i insert a phrase like
"Mike's
car"
when i try to do the insert, it produces an
error: "not valid sentence". this is the code:
$sql=qq{INSERT
INTOTABLE_NAME (PHRASE) VALUES (?)};
my $insert_phrase=$dbh-prepare($sql);
$sql-bind_param(1,$dbh-quote($phrase),SQL_VARCHAR);
$insert_phrase-execute();
Anybody know something about this
thanks
__Jesús
Lasso - Ya.com Internet Factory[EMAIL PROTECTED]www.ya.com - www.globalya.com
RE: Browser Sniffing
-Original Message-
From: Edwin Pratomo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 29, 2000 10:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Browser Sniffing
Ask Bjoern Hansen wrote:
On Thu, 29 Jun 2000, Drew Taylor wrote:
I'm hoping it's been done already, because the user-agent
strings are
terribly inconsistent...
I needed something like that once and ended up with this:
sub UA {
my $ua = shift;
my $n = "";
my $v = "";
.
this doesn't seem to be aware of either WAP browsers or the emulators.
A typical usage of this is to return WML pages if the request
comes from
a WAP browser, otherwise return html pages.
Palm VII is reported to return Mozilla/2.0 (compatible; Elaine/1.0)
for what it's worth...
--Geoff
Regards,
Edwin..
RE: Session Cookies:cant retrieve value
-Original Message-
From: darren chamberlain [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 30, 2000 8:48 AM
To: Steven Wren
Cc: [EMAIL PROTECTED]
Subject: Re: Session Cookies:cant retrieve value
[snip]
Try setting the cookie in an early phase of the request
(PerlInitHandler or,
PerlHeaderParserHandler, for example) and set the cookie
there. In addition,
stick the value of the cookie into pnotes and retrieve it
during the same
request from pnotes, and from future requests from the headers.
I do this pretty often; my PerlInitHandler parses the cookies
and puts them
into pnotes, and in all other request phases I always access
them from pnotes,
for consistency. That way, I know that there is always a cookie there.
plug
Apache::RequestNotes will parse the cookies and place them in pnotes for
you during the init phase in case you don't feel like writing your own
handler for it. It also takes care of GET/POST requests and file uploads
while it's at it.
\plug
--Geoff
An example:
package InitHandler;
sub handler {
my ($r) = @_;
# I use this line to grab cookies everywhere -- CGI::Cookie and
# and Apache::Cookie are too much overhead for me when this is
# so much simpler.
my %cookies = map { $1 = $2 if (/([^=]+)=(.*)/) }
grep !/^$/, split /;\s*/,$r-header_in('cookie');
# the sub generate_a_cookie creates ithe cookie
$cookies{'My-Cookie-Name'} ||= generate_a_cookie();
# Set the cookie to go into the outgoing headers:
$r-push_handlers(PerlFixupHandler =
sub {
my ($r) = @_;
my $cookies = $r-pnotes('cookies');
my $expires = time + 60*60*24; # 24 hours from now
$r-headers_out-add('Set-Cookie' = join ('; ',
((sprintf("My-Cookie-Name=%s",$cookies{'My-Cookie-Name'}))
(sprintf("expires=%s",$expires)),
("path=/"),
(sprintf("domain=%s",$r-get_server_name);
return OK;
});
# Put the cookie into pnotes for retrieval later in the
same request!
$r-pnotes('cookies' = \%cookies);
return DECLINED; # So any other init handlers get to run
}
And then, in a later content handler, I do something like:
package ContentHandler;
sub handler {
my ($r) = @_;
# note this is a hashref!
my $cookies = $r-pnotes('cookies');
# ... as usual.
return OK;
}
# In you httpd.conf:
Location /
PerlInitHandler InitHandler
PerlHandler ContentHandler
# Other stuff
/Location
The nice thing about this way of doing it is that %cookies in
the other
handler (or whatever later phase) is a reference to the value
in pnotes,
so it is automatically updated if you modifiy it, and will be
sent with
the current values (i.e., any changes made up to the headers
actually being
sent will be preserved).
Hope this helps.
darren
--
Absence is to love what wind is to fire. It extinguishes the small, it
enkindles the great..
RE: Session Cookies:cant retrieve value
-Original Message-
From: darren chamberlain [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 30, 2000 9:29 AM
To: Geoffrey Young
Cc: [EMAIL PROTECTED]
Subject: Re: Session Cookies:cant retrieve value
Geoffrey Young ([EMAIL PROTECTED]) said something to this effect:
-Original Message-
From: darren chamberlain [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 30, 2000 8:48 AM
To: Steven Wren
Cc: [EMAIL PROTECTED]
Subject: Re: Session Cookies:cant retrieve value
[snip]
plug
Apache::RequestNotes will parse the cookies and place
them in pnotes for
you during the init phase in case you don't feel like
writing your own
handler for it. It also takes care of GET/POST requests
and file uploads
while it's at it.
/plug
--Geoff
It sure will. I downloaded it when it first came out, but
prefer the pure Perl
version of cookie parsing that I showed because it also works
(if you change
the $r-headers_in line to $ENV{HTTP_COOKIE}) in CGI. I took
the technique
from a some cookie parsing I had originally done in bash.
It's simple, concise,
and fast.
It's also ugly, and Apache::RequestNotes is not.
:)
Now that I
think of it, I
started using the init handler technique *after* I read
through RequestNotes...
Maybe I stole it unconsciously... Sorry Geoff...
so worries - this is open source, so feel free to do what you wish. I would
hope that's what we're doing here - exchanging ideas, expertise, and, in
general, maximixing eachother's valuable time :)
As somebody mentioned recently in the browser identity thread, there are
lots of Apache:: modules out there - I was just trying to remind folks that
RequestNotes is around if they need it...
--Geoff
darren
--
I'm not sure which upsets me more: that people are so
unwilling to accept
responsibility for their own actions, or that they are so
eager to regulate
everyone else's.
-- Kee Hinckley
RE: can't properly append to file from mod_perl script
you might want to 'use strict' and see what pops up :)
additionally, you might want to read up on mod_perl_traps.pod and
http://perl.apache.org/guide/porting.html
specifically
http://perl.apache.org/guide/porting.html#Exposing_Apache_Registry_secret
HTH
--Geoff
-Original Message-
From: Rob Egan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 28, 2000 6:38 PM
To: [EMAIL PROTECTED]
Subject: can't properly append to file from mod_perl script
Hi,
I am relocating content from a non-mod_perl Apache site to a new
mod_perl/1.24 enabled Apache server and I have a problems
getting one of the
CGI scripts to behave in mod_perl. All it does is capture
e-mail addresses,
and place them in a text file so we can gather them up later
and drop them
into a database. If you run the script as a regular CGI
(without mod_perl
enabled) it works great. But on the mod_perl enabled server,
the script
throws garbage into the file and overwrites previous entries if a user
submits more than one e-mail address in a single session
(i.e. they enter
one address, click "Back", then enter another address).
However, if the user
submits one e-mail address, then quits their browser,
restarts the browser
and enters another e-mail, it works just fine. Does anybody
have any idea
why this would happen? I've included the CGI script below
with actual URL's
omitted (which was written by some consultant who no longer
works here).
Thanks!
-Rob
[EMAIL PROTECTED]
-begin script text
#!/usr/local/bin/perl
$|=1;
# Enumerate the locking options for clarity...
$LOCK_EX = 2;
$LOCK_UN = 8;
$results_file = "./results.csv";
$cl = $ENV{'CONTENT_LENGTH'};
$rqm = $ENV{'REQUEST_METHOD'};
sub lock {
# print "lockingBR";
flock(RESULTS, $LOCK_EX);
# print "seekingBR";
# seeks to the end of the file in case
# someone got while we were waiting for the lock
seek(RESULTS, 0, 2);
# print "lockedBR";
}
sub unlock {
# print "unlockingBR";
flock(RESULTS, $LOCK_UN);
# print "unlockedBR";
}
sub web_die {
print "Location: http://omitted";
die("\n");
}
sub web_die_action {
print "Location: http://omitted";
die("\n");
}
sub return_error
{
local ($status, $keyword, $message) = @_;
print "Content-type: text/html", "\n";
print "Status: ", $status, " ", $keyword, "\n\n";
print End_of_Error;
HTMLHEADTITLEUnexpected CGI Error/TITLE/HEAD
BODY
H1$keyword/H1
HR$message/HR
/BODY
/HTML
End_of_Error
exit(1);
}
sub write_entry
{
# Lock after you open
lock();
$count = 0;
foreach (keys %FORM)
{
$count++;
}
for ($i = 0; $i $count; $i++)
{
$index = $i + 1;
if ($FORM{"FIELD_$index"} eq "")
{
$FORM{"FIELD_$index"} = "NO ENTRY";
}
$FORM{"FIELD_$index"} =~ s/\"/\"\"/g; #
...change " to ""
$FORM{"FIELD_$index"} =~ s/\r//g; #
...kill line feeds
$FORM{"FIELD_$index"} =~ s/\n/ /g; #
...change cr to whitespace
$FORM{"FIELD_$index"} = "\"" .
$FORM{"FIELD_$index"} . "\"";
print RESULTS $FORM{"FIELD_$index"};
print RESULTS ","
}
print RESULTS "\n";
# Unlock before you close
unlock();
close(RESULTS);
location;
}
if ($rqm eq "POST")
{
read(STDIN, $buffer, $cl);
@pairs = split(//, $buffer);
$q = 0;
foreach $pair (@pairs)
{
$q++;
($name, $value) = split(/=/, $pair);
$FORM{"FIELD_$q"} = $value;
$FORM{"FIELD_$q"} =~ tr/+/ /;
$FORM{"FIELD_$q"} =~
s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
if ($FORM{"FIELD_$q"} eq "0-12")
{
location;
exit(0);
}
}
}
elsif ($cl 0)
{
web_die_action;
# Error: form results must be submitted with method POST
}
###
if (! (-e $results_file))
{
if (open (RESULTS, "results.csv"))
{
write_entry;
}
else
{
return_error (500, "Results Error", "Cannot
create results.csv to store
entries.");
}
}
else
{
if (! ((-r $results_file) (-w $results_file)) )
{
return_error (500, "Results Error", "Cannot
read or write to
results.csv.");
}
else
{
open(RESULTS, "results.csv") || web_die;
write_entry;
}
}
exit(0);
sub location
{
print "Location: http://omitted";
}
RE: Apache::Upload ?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 28, 2000 5:46 PM
To: Geoffrey Young
Cc: [EMAIL PROTECTED]
Subject: Re: Apache::Upload ?
Geoffrey Young wrote:
the documentation in Apache::Request is pretty complete.
I've only tested
Apache::Upload and don't use it in production (because I
don't need to
support uploads) but you can start your script like this:
use strict;
my $r = Apache::Request-new(shift);
my $upload = $r-upload;
now you have an Apache::Upload object. use the various
methods on $upload
as are in the docs. for instance, the perldoc shows you
how to get back a
filehandle that you can use to read the file:
my $fh = $upload-fh;
my $lines = 0;
while($fh) {
++$lines;
...
}
HTH
--Geoff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 28, 2000 3:31 PM
To: Geoffrey Young
Cc: 'Casey Bristow'; [EMAIL PROTECTED]
Subject: Re: Apache::Upload ?
i to need an upload solution
to get Apache::Request::upload in i just
cpan'd it down as
install Bundle::Apache
there was quite a few dependencies
that it needed
i then restarted apache
and perl-status had it in there
now my question is does anyone have a example script
using this upload
feature?
i saw some snippets in perldoc Apache::Request
that are quite usable
but if someone has an example
it would simply save me some time!
thanks
hmm , ive been try for the last while based on your
suggestions and the
preldoc man
here are the files ive been using
can you tell me whats wrong?
PerlRun: `Can't locate object method "new" via package
"Apache::Request"
at /home/www/perl/uploadstuff.pl line 8.
you might want to add
use Apache::Request;
at the top of that script.
--Geoff
is what i get
RE: Upgrade
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 28, 2000 4:45 PM To: Geoffrey Young Cc: [EMAIL PROTECTED] Subject: RE: Upgrade Looks like I'm going to have to recompile the works. I've downloaded http://www.perl.com/CPAN/src/latest.tar.gz and mod_perl-1.2.tar When running the config on mod_perl as it is in the INSTALL file. It crashes out on the make. Looking like some source error with the ap_configtestonly function. Any suggestions? looks like there has been some correction of this sort in 1.24_01, which can be downloaded from http://perl.apache.org/from-cvs/modperl/ just pick the latest one - there hasn't been any cvs action for a while... HTH --Geoff mod_perl.c: In function `perl_startup': mod_perl.c:738: `ap_configtestonly' undeclared (first use in this function) mod_perl.c:738: (Each undeclared identifier is reported only once mod_perl.c:738: for each function it appears in.) *** Error code 1 Stop in /usr/local/apache_1.3.6/src/modules/perl. *** Error code 1 Stop in /usr/local/apache_1.3.6/src/modules. *** Error code 1 Stop in /usr/local/apache_1.3.6/src. *** Error code 1 Stop in /usr/local/mod_perl-1.24. = Keith W. At the helm for better or worse = On Wed, 28 Jun 2000, Geoffrey Young wrote: as long as you have mod_so compiled into apache, you should be able to add mod_perl as a DSO. you can check with httpd -l the advice you will get the most from this list is to recompile apache with a static mod_perl and forget DSO, but DSO stability is reported to have improved of late so it may not give you much grief. If you really can't recompile apache, DSO is for you... see http://perl.apache.org/guide/install.html specifically http://perl.apache.org/guide/install.html#Build_mod_perl_as_a_DSO_inside_t HTH --Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 28, 2000 3:01 PM To: [EMAIL PROTECTED] Subject: Upgrade I have to get mod_perl into a currently runnning apache server. How does one go about adding mod_perl if not done at compile time? Sysinfo: FreeBSD 4.0-stable Apache 1.3.6 - source install not ports collection. = Keith W. At the helm for better or worse =
[new module] Apache::Regex
Hi all... I posted to the list a little while ago a simple regular expression PerlHandler implementation. I've cleaned it up since then and thought I might post it to CPAN if there is any interest. I was thinking of Apache::Regex as the release name. I know it's a basic module, and people who need the functionality usually do it themselves, but... Apache::Regex accepts PerlAddVar directives and applies s/$change/$to/eeg the requested HTML file on a line by line basis. Features include: Apache::Filter aware, accepts multiple change/to pairs, only tries to process HTML files. It requires mod_perl 1.24. While overhead intensive, a I originally wrote it for a friend who wanted to be able to use a js enabled page in a plaintext version of the site without having to maintain two pages. Since the plaintext page requests are minimal, the added overhead is negligable. I guess I can see it as also being an easy way to migrate a site when a company changes names once a week :) Anyway, the pre-release can be seen at http://morpheus.laserlink.net/~gyoung/modules/Apache-Regex-0.01.tar.gz constructive comments welcome --Geoff
RE: Upgrade
as long as you have mod_so compiled into apache, you should be able to add mod_perl as a DSO. you can check with httpd -l the advice you will get the most from this list is to recompile apache with a static mod_perl and forget DSO, but DSO stability is reported to have improved of late so it may not give you much grief. If you really can't recompile apache, DSO is for you... see http://perl.apache.org/guide/install.html specifically http://perl.apache.org/guide/install.html#Build_mod_perl_as_a_DSO_inside_t HTH --Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 28, 2000 3:01 PM To: [EMAIL PROTECTED] Subject: Upgrade I have to get mod_perl into a currently runnning apache server. How does one go about adding mod_perl if not done at compile time? Sysinfo: FreeBSD 4.0-stable Apache 1.3.6 - source install not ports collection. = Keith W. At the helm for better or worse =
RE: Apache::Upload ?
the documentation in Apache::Request is pretty complete. I've only tested
Apache::Upload and don't use it in production (because I don't need to
support uploads) but you can start your script like this:
use strict;
my $r = Apache::Request-new(shift);
my $upload = $r-upload;
now you have an Apache::Upload object. use the various methods on $upload
as are in the docs. for instance, the perldoc shows you how to get back a
filehandle that you can use to read the file:
my $fh = $upload-fh;
my $lines = 0;
while($fh) {
++$lines;
...
}
HTH
--Geoff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 28, 2000 3:31 PM
To: Geoffrey Young
Cc: 'Casey Bristow'; [EMAIL PROTECTED]
Subject: Re: Apache::Upload ?
i to need an upload solution
to get Apache::Request::upload in i just
cpan'd it down as
install Bundle::Apache
there was quite a few dependencies
that it needed
i then restarted apache
and perl-status had it in there
now my question is does anyone have a example script using this upload
feature?
i saw some snippets in perldoc Apache::Request
that are quite usable
but if someone has an example
it would simply save me some time!
thanks
RE: mod_perl install
you may want to see http://perl.apache.org/guide/install.html specifically http://perl.apache.org/guide/install.html#APACHE_PREFIX HTH --Geoff -Original Message- From: Michael L. Stokes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 27, 2000 11:46 AM To: [EMAIL PROTECTED] Subject: mod_perl install mod_perl'ers, I got mod_perl to compile and rebuild httpd, but the new httpd did not have the prefix correct (it used the default location). I have 2 questions; 1) What do I need to do to get the correct prefix to the httpd build when compiling from the mod_perl scripts? 2) What is the procedure to set up the mod_perl installation so that I can build it using the httpd installation scripts? Thanks Mike respond using [EMAIL PROTECTED]
RE: Totally annoyed at IE ( Cookie oddity )
I just tried the following registry script with NS4.7 and IE5 (both win) and
it worked just fine...
#!/usr/bin/perl
use strict;
my $r = shift;
$r-err_headers_out-add('Set-cookie' = 'cookie1=value1;
domain=.laserlink.net');
$r-err_headers_out-add('Set-cookie' = 'cookie2=value2;
domain=.laserlink.net');
$r-err_headers_out-add('Set-cookie' = 'cookie2=value3;
domain=.laserlink.net');
die;
I even added a path and expires tag and it still was ok. I did notice,
however, that IE garbles the date somewhat and after repeated promptings
will cease to prompt me again. chalk it up to the standard MS woes, I
guess...
HTH
--Geoff
mod_perl 1.24_dev
apache 1.3.12
-Original Message-
From: John Armstrong [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 23, 2000 6:36 AM
To: [EMAIL PROTECTED]
Subject: Totally annoyed at IE ( Cookie oddity )
Trying to get IE to take a cookie in either an error header or a
standard header has just been driving me insane tonight. After every
possible iteration I ended up with the following and a redirect. Note
that $r-header_out() worked without a redirect as well.
$r-err_header_out('Set-cookie' = "AF_SID=".$session{ _session_id
}."; path=/; expires=Tue, Jun 23 2021 10:26:12 GMT; domain=.spa.com"
);
The following did _not_ work for IE but did work for every other
browser I tested ( NS 4.5/5 on Win/Linux/Mac ).
$r-err_headers_out-add('Set-cookie' = "AF_SID=".$session{
_session_id }."; path=/; expires=Tue, Jun 23 2020 10:26:12 GMT;
domain=.spa.com" );
$r-err_headers_out-{ 'Set-cookie' } = "AF_SID=".$session{
_session_id }."; path=/; expires=Tue, Jun 23 2020 10:26:12 GMT;
domain=.spa.com;" ;
So the question is, why does IE accept a single header but not
multiple headers? I did not see this anywhere in the mailing list of
the Eagle book and have never really come across this issue before.
Just looking for a reason so that I am not treating this like
some mystery.
John-
is PerlAddVar working?
hi all...
I've been trying all morning to access PerlAddVar variables as
expected (see
http://marc.theaimsgroup.com/?l=apache-modperlm=95718409824646w=2 and
forward)
I'm not sure if anyone tested Doug's patch
(http://marc.theaimsgroup.com/?l=apache-modperlm=95742001627308w=2) or if
that exact patch is what made it into the latest cvs, but I can't get it to
work as documented in 1.24_dev:
my @values = $r-dir_config-get('Fred');
has anyone had success with this? I think that get() isn't returning in a
list context - PerlAddVar will work for setting the values, and the multiple
values show up when calling $r-dir_config-do(), but @values just gets one
value back.
maybe I've been staring at it for too long and am missing something
obvious...
in my poking around, I noticed something else of interest. given:
PerlSetVar INVISIBLE "not in Apache::Table"
Location /foo
SetHandler perl-script
PerlHandler Custom::Handler
PerlSetVar VISIBLE "in Apache::Table"
/Location
$r-dir_config-do(sub {
my ($field, $value) = @_;
warn "\t$field = $value\n";
1;
});
only VISIBLE is shown when in the do() loop - INVISIBLE is still accessible
via $r-dir_config('INVISIBLE') though. Personally, I'd like to see all my
available variables, if possible.
anyway...
--Geoff
RE: Simple program _setting_ REMOTE_ADDR - SOLUTION
-Original Message-
From: Dan Rench [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 23, 2000 12:33 PM
To: Steve van der Burg
Cc: [EMAIL PROTECTED]
Subject: Re: Simple program _setting_ REMOTE_ADDR - SOLUTION
On Fri, 23 Jun 2000, Steve van der Burg wrote:
Taking your remote_ip hint, and reading the Eagle a bit
more closely,
I came up with this:
In httpd.conf:
Location /cgi-bin/VENDOR
PerlAccessHandler LHSC::FakeRemoteIP
/Location
Why an Access handler? I realize it works, but a more appropriate
phase would be PerlFixupHandler, since you aren't doing any access
control in your module. A couple other nitpicky points: you probably
should return 'DECLINED' at the end, not 'OK', in case there are more
handlers that want to do something during that phase and it
returning OK is fine for a fixup handler - as many fixup handlers as are
enabled will be run (same with just about all the phases except
PerlTransHandler and PerlTypeHandler, with some minor caveats)
--Geoff
also probably
would be a good idea to restore the "real" address after so your logs
show the actual client IP. Something like this:
package FakeIP;
use strict;
use Apache::Constants 'DECLINED';
sub handler {
my $r = shift;
$r-notes('true_client_ip', $r-connection-remote_ip);
$r-connection-remote_ip('1.2.3.4');
$r-push_handlers('PerlLogHandler' =
sub {
my $r = shift;
$r-connection-remote_ip($r-notes('true_client_ip'));
return DECLINED;
}
);
return DECLINED;
}
1;
RE: stripping CRLF on the way out?
I wrote a quick handler that implements a regex as a PerlHandler
maybe this will help to strip out comments:
(oh, and if anyone would like to see this as an official module, I can clean
it up and release it - I didn't really think there would be much interest in
it when I wrote it...)
package Custom::Regex;
#-
# usage: PerlHandler Custom::Regex
#
#the following variables will be entered into a regex as:
#s/$RegexChange/$RegexTo/eeg
#
#PerlSetVar RegexChange "change this"
#PerlSetVar RegexTo "to that"
#
#PerlSetVar Filter On # optional - will work within
# # Apache::Filter
#-
use Apache::Constants qw( OK DECLINED SERVER_ERROR );
use Apache::File;
use Apache::Log;
use strict;
$Custom::Regex::VERSION = '0.01';
sub handler {
#-
# initialize request object and variables
#-
my $r = shift;
my $log = $r-server-log;
my $change= $r-dir_config('RegexChange') || undef;
my $to= $r-dir_config('RegexTo') || undef;
# make Apache::Filter aware
my $filter= $r-dir_config('Filter') =~ m/On/i ? 1 : 0;
my ($fh, $status, $output);
#-
# do some preliminary stuff...
#-
$log-info("Using Custom::Regex");
unless ($r-content_type eq 'text/html') {
$log-info("\trequest is not for an html document - skipping...");
$log-info("Exiting Custom::Regex");
return DECLINED;
}
#-
# get the filehandle
#-
if ($filter) {
$log-info("\tgetting input from Apache::Filter");
($fh, $status) = $r-filter_input;
} else {
$log-info("\tgetting input from requested Apache::File");
$fh = Apache::File-new($r-filename);
}
if (!$fh || $status ne OK) {
$log-warn("\tcannot open request! $!");
$log-info("Exiting Custom::Regex");
return DECLINED;
}
#-
# do the regex on the request
#-
if ($change $to) {
$log-info("\tsubstituting $to for $change");
while ($fh) {
my $output;
eval { ($output = $_) =~ s/$change/$to/eeg };
if ($@) {
$log-error("\tsubstitution error: $@");
$log-info("Exiting Custom::Regex");
return SERVER_ERROR;
} else {
print $output;
}
}
}
#-
# wrap up...
#-
$log-info("Exiting Custom::Regex");
return OK;
}
1;
--Geoff
-Original Message-
From: Dave DeMaagd [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 22, 2000 11:15 AM
To: [EMAIL PROTECTED]
Subject: stripping CRLF on the way out?
Have an application that generates nicely formatted HTML (from
templates, so that they can be easily edited), but since there's a
awful lot of extra line breaks (and other things, like comments) that
we'd like to strip out (save bandwidth), is there an easy way to do
this via mod_perl, something like a PerlOutputHandler???
Something like this would be a far sight easier than having to rewrite
all of the scripts to do this themselves...
Any advice would help greatly!
--
Dave DeMaagd - [EMAIL PROTECTED] - http://www.spinynorm.net
I don't have a solution, but I admire your problem.
SysAdmin/Programmer - TheImageGroup - ===|:=P
RE: stripping CRLF on the way out?
I don't use the regex handler all that often, but I thought it might come in handy for this type of thing. of course, reducing real-time overhead is always prefered. HTML::Clean looks like a cool module, I'm sure I'll use it often now that I know of it - thanks for pointing it out... --Geoff -Original Message- From: Paul Lindner [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 22, 2000 10:53 AM To: Geoffrey Young Cc: 'Dave DeMaagd'; [EMAIL PROTECTED] Subject: Re: stripping CRLF on the way out? Try running HTML::Clean on your template, instead of using CPU for every request to strip output. I've done this with some success on a few projects.. Also, Apache::ASP users can activate HTML::Clean to post-process all HTML output, which can result in 20-40% savings. I read somewhere that 5 bytes is equivalent to 1ms on a 28.8 connection, so these types of optimizations are generally worth the effort. -Original Message- From: Dave DeMaagd [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 22, 2000 11:15 AM To: [EMAIL PROTECTED] Subject: stripping CRLF on the way out? Have an application that generates nicely formatted HTML (from templates, so that they can be easily edited), but since there's a awful lot of extra line breaks (and other things, like comments) that we'd like to strip out (save bandwidth), is there an easy way to do this via mod_perl, something like a PerlOutputHandler??? Something like this would be a far sight easier than having to rewrite all of the scripts to do this themselves... Any advice would help greatly! -- Dave DeMaagd - [EMAIL PROTECTED] - http://www.spinynorm.net I don't have a solution, but I admire your problem. SysAdmin/Programmer - TheImageGroup - ===|:=P -- Paul Lindner [EMAIL PROTECTED] Red Hat Inc..
RE: Apache::DBI
-Original Message- From: Eric Jain [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 21, 2000 1:30 PM To: Mod_Perl Subject: Apache::DBI Is it be possible to modify Apache::DBI in sich a way that only database connections specified in a PerlRequired startup.pl with Apache::DBI-connect_on_init(...) are stored and all subsequent DBI-connect(...) connections are properly established (if no matching stored connection is available), but not stored afterwards? I'm not sure why you would want to do such a thing, but I don't think it fits with DBI/Apache::DBI's model... why exactly are you looking for this behavior? --Geoff Or could Apache::DBI::db::disconnect be changed, so it would actually disconnect, except if it was handling one of the connect_on_init connections? -- Eric Jain
RE: err_headers_out Q
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 09, 2000 1:21 PM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'
Subject: Re: err_headers_out Q
On Fri, 2 Jun 2000, Geoffrey Young wrote:
hi all...
this simple script:
#!/usr/bin/perl
my $r = shift;
$r-err_headers_out-add('Set-Cookie' = "name=error");
warn "pre headers_out: " . $r-headers_out-get('Set-Cookie');
$r-send_http_header('text/plain');
warn "post headers_out: " . $r-headers_out-get('Set-Cookie');
print "done";
yields:
pre headers_out: at /usr/local/apache/perl-bin/err.cgi line 7.
post headers_out: name=error at
/usr/local/apache/perl-bin/err.cgi line 9.
and sets the cookie...
I was initially trying to create a PerlInitHandler to put a
cookie in
err_headers_out, which I would expect to be set only if
other handlers down
the line error out, but it was being set every request.
am I misunderstanding err_headers_out, or is
send_http_header misbehaving?
see http_protocol.c:send_http_header():
if (!ap_is_empty_table(r-err_headers_out))
r-headers_out = ap_overlay_tables(r-pool,
r-err_headers_out,
r-headers_out);
oh, that explains it. and thanks for pointing out the relevant code bits...
sorry it took me so long to express my graditude :)
--Geoff
[Advocacy] apachetoday.com
apachetoday.com was launched sometime last week (I think), and today features Stas and mod_perl on the front page :) --Geoff
RE: Apache::ASP
well, I don't use Apache::ASP, but a quick glance of the README yielded the apropriate instructions you are looking for... :) --Geoff -Original Message- From: Clement Law [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 07, 2000 1:54 PM To: [EMAIL PROTECTED] Subject: Apache::ASP How do I make it so when it sees the extension .asp it does the asp thing? instead of putting this Location /asp/ SetHandler perl-script PerlHandler Apache::ASP PerlSetVar Global /tmp /Location
RE: Apache::Dispatch
-Original Message- From: Ken Williams [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 06, 2000 12:38 AM To: Christopher Lee Cc: [EMAIL PROTECTED] Subject: Re: Apache::Dispatch [EMAIL PROTECTED] (Christopher Lee) wrote: There's a real live working example if anybody wants it, called "Wing", available from your local friendly CPAN. The module is used as an IMAP interface but the main module handles everything except logins, the url is used to pass commands around, the one I'm looking at at the moment is http://server1.herald.ox.ac.uk/wing/cmd/ball/x/compose The "wing/cmd" tells the module that this is a call for the function called (in this case) "cmd_compose" with the parameters "ball" (a username) (x is a dummy used for other functions I think). Internally the module takes 'compose' and prefixes it with 'cmd_', evals the string as a soft reference to a function and returns an error code if the function doesn't exist, or runs the function if it does. It only lets a strict subset of functions run (it always appends a "cmd_" to the name) so internal functions are safe . well, if we somewhat limited ourselves, we could only call handler() routines. Thus localhost/Custom would call Custom-handler() and that would be the end. I don't think the drawbacks of having one function per module will really be that bad, since we're only talking about the content handling phase... That step is *crucial* to the security of the system. Without it, browsers could call any method in the module, including ones that aren't meant to be called. D, W.R.! By specifying the cmd_ prefix you're essentially adding a "public" declaration to these subroutines, albeit a fairly ugly one. In general, when accepting arbitrary user input you want to make sure there are only a very few access points to the code, then make sure you have very tight validation of the data in those access points. Taint mode comes to mind as one tool in the belt. right, except that you can't code a module in taint mode, you have to rely on the user setting PerlTaint On (right?) ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
RE: $r-register_cleanup limits?
-Original Message-
From: Jim Woodgate [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 06, 2000 9:48 AM
To: [EMAIL PROTECTED]
Subject: $r-register_cleanup limits?
In a module I'm using register_cleanup so the client doesn't need to
wait for me to do a bunch of work. It basically does this:
foreach (@images) {
unless (-f $thumb{$_}) {
create_thumb($_);
$r-register_cleanup(sub {create_more_sizes($_, ...)});
}
}
create_more_sizes will create various additional sizes to
scale down a
large picture.
This seems to work really well unless there is a large set of images,
then the cleanup handler doesn't get all the way through. I
don't see
any warnings/errors. (And unfortunately since the thumbnail is
created the next time someone visits create_more_sizes won't get
called unless I do explicit checks, which would cause me to actually
read the images and I was hoping to avoid that)
Anyway I'm not sure if I'm hitting a limit on the amount of time it
is taking or if I'm just registering too many cleanups.
I was thinking of $r-reset_timeout() as the first line of
create_more_size(), but thought I would check with the list
first as I
don't fully understand the ramifications.
I'm afraid I don't know the answer, but I would be interested in knowing
whether any of the *_timeout functions apply to the cleanup phase - the
Timeout directive docs and the eagle book seem to imply that these are
methods aimed at closing the data connection, and I thought the connection
was over by the time cleanup is called...
just more questions - sorry I can't be of help, though...
--Geoff
--
[EMAIL PROTECTED]
RE: NEWBIE: appending to page content
-Original Message- From: Jim Sproull [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 06, 2000 11:00 AM To: [EMAIL PROTECTED] Subject: NEWBIE: appending to page content I'm relatively new to mod_perl and have been fighting with a relatively simple task: appending data to all text/html pages. So, for instance, I want something like this returned to the client: HTML BODY . /BODY /HTML EXTRA SPECIAL MESSAGE - well, I'm not an HTML whiz, but I'm not sure about the consequences of appending messages outside of the ending HTML tag... at any rate, the examples in the eagle book for appending a header and footer (ch 4) should get you started. There's also Apache::Sandwich and Apache::SimpleReplace that can assist you, should you not want to code it yourself yet... HTH --Geoff I've been reading as much info on the web as I can find (and I'm going out to buy the book after I write this), and I'm kinda confused as how to get the page content and then append to it. I tried direclty printing from a PerlHandler, but that seemed to be just ignored. Can I access the data directly from the request object? Any help in this would be appreciated. Jim Sproull [EMAIL PROTECTED]
RE: [benchmark] DBI/preload (was Re: [RFC] improving memory mapping thru code exercising)
-Original Message-
From: Ken Miller [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 06, 2000 12:13 PM
To: [EMAIL PROTECTED]
Subject: RE: [benchmark] DBI/preload (was Re: [RFC] improving memory
mapping thru code exercising)
At 11:10 AM 6/6/00 -0400, Geoffrey Young wrote:
-Original Message-
From: Jason Terry [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 06, 2000 10:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [benchmark] DBI/preload (was Re: [RFC]
improving memory
mapping thru code exercising)
I just wanted to thank you guys for sending this to the
mailing list.
I added these lines to my startup script
use Carp;
CGI-compile(qw(my_common_functions));
DBI-install_driver('mysql');
I tried this in my startup.pl with Oracle, and this is what I got:
DBI handle cleared whilst still active at
this typically means that you have opened a cursor and the $dbh has gone out
of scope before calling $sth-finish
are you doing other stuff in your startup.pl?
/home/cardlock/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Orac
le.pm line 82.
dbih_clearcom (h 0x54f978, com 0x3319e8):
FLAGS 0x211: COMSET Warn AutoCommit
TYPE 1
PARENT undef
KIDS 0 (0 active)
IMP_DATA undef in 'DBD::Oracle::dr'
I tried both
use DBD::Oracle
I use() DBD::Oracle as above in my startup.pl, but I don't see any
warnings...
and
DBI-install_driver( 'Oracle' );
I don't have any experience with this method...
with the same results. It didn't seem to cause any problems, since
everything still worked.
Something to worry about?
generally no, but since lots of people use() DBD::* in the startup files, it
doesn't sound normal
--GEoff
Cheers!
-klm.
---
Ken Miller, Consultant
Shetland Software Services Inc.
RE: NEWBIE: appending to page content
-Original Message-
From: Jim Sproull [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 06, 2000 1:53 PM
To: [EMAIL PROTECTED]
Subject: RE: NEWBIE: appending to page content
Thanks to Geoff Young for pointing me in the right direction towards
Apache::SimpleReplace. I have made my own stripped down
version of this,
but still need guidance (Geoff, you're welcome to reply again
if you can
help ;) Since I only want all text/html pages to be appended
to, I want all
other types to be sent asis. Here's what I'm doing now:
in conf:
Location /
SetHandler perl-script
PerlHandler AddData
/Location
in lib/perl/AddData.pm:
sub handler {
my $r = shift;
$log = $r-server-log;
log_info("Opening ". $r-filename . " w/ type of " .
$r-content_type);
$rqh = Apache::File-new($r-filename)
|| return SERVER_ERROR;
$r-send_http_header();
$r-send_fd($rqh);
if ($r-content_type eq "text/html") { # it's HTML
log_info("Appending extra data ");
$r-print("testing");
}
return OK;
try returning DECLINED if $r-content_type is 'httpd/unix-directory' or
matches directory or something similar. put this at the top of your handler
so that the decline is topmost and you avoid unnecessary processing... this
will let apache's normal directory indexing take over when appropriate...
HTH
--Geoff
}
This works fine for specified html pages. However, when a
DirectoryIndex
page is called indirectly (http://www.foobar.com/ for
instance), an item of
type httpd/unix-directory gets printed. So, I guess I'm
asking 'in what
stage does the DirectoryIndex get called, and why is it being
ignored in
this case?'
Jim
[EMAIL PROTECTED]
RE: NEWBIE: appending to page content
-Original Message- From: Jim Sproull [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 06, 2000 2:09 PM To: Geoffrey Young Cc: [EMAIL PROTECTED] Subject: RE: NEWBIE: appending to page content [snip] Hi again Geoff. Thanks for the quick answer. I actually tried adding return DECLINED if $r-content_type ne "text/html"; well this is essentially what Apache::SimpleReplace does - and I just tested it on a directory that has +Indexes and it works just fine: content-type httpd/unix-directory. make sure you have PerlWarn On in your httpd.conf and are using strict at the top of your module, just in case it's a coding problem ;) at the top, which seems to stop the connection dead in its tracks (when content_type ne 'text/html') and I get this: Making HTTP connection to jim.sitepak.net. Sending HTTP request. HTTP request sent; waiting for response. Alert!: Unexpected network read error; connection aborted. what's your error_log say? I didn't think that looked right, but I wasn't exactly sure what returning DECLINED did (in terms of the request process). Any ideas? returning DECLINED pretty much means that apache should skip over your processing as though it never happened and let apache process the request as it normally would. The book explains it in detail very well... In truth, I haven't seen anyone else return DECLINED from the PerlHandler phase, but it seemed to work ok so I let Apache::SimpleReplace return DECLINED to handle stuff like directory indexes (and any other unthought of things). I might have missed something, though... --Geoff Jim [EMAIL PROTECTED] } This works fine for specified html pages. However, when a DirectoryIndex page is called indirectly (http://www.foobar.com/ for instance), an item of type httpd/unix-directory gets printed. So, I guess I'm asking 'in what stage does the DirectoryIndex get called, and why is it being ignored in this case?' Jim [EMAIL PROTECTED]
RE: NEWBIE: appending to page content
-Original Message- From: Jim Sproull [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 06, 2000 2:35 PM To: Geoffrey Young Subject: RE: NEWBIE: appending to page content -Original Message- From: Geoffrey Young [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 06, 2000 2:30 PM To: 'Jim Sproull' Cc: [EMAIL PROTECTED] Subject: RE: NEWBIE: appending to page content Hi again Geoff. Thanks for the quick answer. I actually tried adding return DECLINED if $r-content_type ne "text/html"; well this is essentially what Apache::SimpleReplace does - and I just tested it on a directory that has +Indexes and it works just fine: content-type httpd/unix-directory. make sure you have PerlWarn On in your httpd.conf and are using strict at the top of your module, just in case it's a coding problem ;) [SNIP] heh, ok, this is weird. I used strict (it wasn't there before), fixed this line: $rqh = Apache::File-new($r-filename) || return SERVER_ERROR; (forgot the 'my') and now it works. Though, I'm not sure as you get into mod_perl, you'll see that 'use strict' and 'my' are essentially required. besides the eagle book, I would suggest that you also use perl.apache.org/guide as a reference, as well as the many Apache:: modules on CPAN why this would cause a read error, but you never know. Anyway, thanks again for your help! You've been more than patient with me. :) no problem - enjoy the reading :) --Geoff Jim [EMAIL PROTECTED]
RE: [RFC: performance] Preloading Perl Modules at Server Startup
-Original Message- From: Vivek Khera [mailto:[EMAIL PROTECTED]] Sent: Monday, June 05, 2000 10:09 AM To: mod_perl list Subject: Re: [RFC: performance] Preloading Perl Modules at Server Startup "SB" == Stas Bekman [EMAIL PROTECTED] writes: SB But an even better approach is to create a separate startup file SB (where you code in plain perl) and put there things like: SB use DBI; SB use Carp; SB Then you Crequire() this startup file in Ihttpd.conf with the SB CPerlRequire directive, placing it before the rest of the mod_perl SB configuration directives: SB PerlRequire /path/to/start-up.pl You should recommend use DBI (); use Carp (); so that no symbols are imported into the name space of the start-up.pl script as it is unlikely to be needed there. Also, I'd recommend using libapreq's Apache::Request if you don't need the content generating parts of CGI.pm... which leads to an enhancement I'd like to see Doug add to libapreq's functionality: Currently, you need to do a call like this if you're using Apache::Request inside a Registry script: my $ar = Apache::Request-new(Apache-request()) or die "Whoa Nelly!"; my $apr = Apache::Request-new(shift); requires less typing and still has the desired effect in Regitry scripts or handlers... --Geoff I'd like to see the Apache::Request-new() method automatically call Apache-request() if no parameters are passed to it. Inside a Apache-handler, it is easy since you already have a Apache-request object passed to you, but in Registry, it is a lot of extra typing.
RE: [RFC: performance] Preloading Perl Modules at Server Startup
[snip] Also, I'd recommend using libapreq's Apache::Request if you don't need the content generating parts of CGI.pm... which leads to an enhancement I'd like to see Doug add to libapreq's functionality: Currently, you need to do a call like this if you're using Apache::Request inside a Registry script: my $ar = Apache::Request-new(Apache-request()) or die "Whoa Nelly!"; my $apr = Apache::Request-new(shift); did I really just say that? I guess that doesn't work for Registry scripts after all... sorry for the FUD :) --Geoff requires less typing and still has the desired effect in Regitry scripts or handlers... --Geoff I'd like to see the Apache::Request-new() method automatically call Apache-request() if no parameters are passed to it. Inside a Apache-handler, it is easy since you already have a Apache-request object passed to you, but in Registry, it is a lot of extra typing.
RE: [RFC: performance] Preloading Perl Modules at Server Startup
-Original Message- From: Geoffrey Young [mailto:[EMAIL PROTECTED]] Sent: Monday, June 05, 2000 10:30 AM To: 'Vivek Khera'; mod_perl list Subject: RE: [RFC: performance] Preloading Perl Modules at Server Startup [snip] Also, I'd recommend using libapreq's Apache::Request if you don't need the content generating parts of CGI.pm... which leads to an enhancement I'd like to see Doug add to libapreq's functionality: Currently, you need to do a call like this if you're using Apache::Request inside a Registry script: my $ar = Apache::Request-new(Apache-request()) or die "Whoa Nelly!"; my $apr = Apache::Request-new(shift); did I really just say that? I guess that doesn't work for Registry scripts after all... sorry for the FUD :) ok, it does work... I'll stop posting now... --Geoff requires less typing and still has the desired effect in Regitry scripts or handlers... --Geoff I'd like to see the Apache::Request-new() method automatically call Apache-request() if no parameters are passed to it. Inside a Apache-handler, it is easy since you already have a Apache-request object passed to you, but in Registry, it is a lot of extra typing.
