RE: mod_perl and dbi:Oracle

[Geoffrey Young]

> -Original Message-
> From: Aleksandr Vladimirskiy [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 16, 2001 1:33 PM
> To: [EMAIL PROTECTED]
> Subject: mod_perl and dbi:Oracle
> 
> 
> Hi,
> 
> I am building a system using apache,mod_perl and oracle. it is in the
> very early stages. right now all i have is a module that prints out a
> simple text string to the browser. for the next step i am trying to
> access an oracle db, but get a message in the error log from 
> the module
> that ORACLE_HOME environment variable isn't set. i have tried to set
> this variable in the module itself as well as in the apache
> configuration file (the  that governs my program) 
> but without
> success.

there are a few options...

from /etc/profile or the .profile of user nobody (or whoever you run apache
as):
ORACLE_HOME=/u01/app/oracle/product/8.0.5.1; export ORACLE_HOME

from /etc/profile or the .profile of user nobody (or whoever you run apache
as)

from your startup.pl:
BEGIN {
  $ENV{'ORACLE_HOME'} = "/u01/app/oracle/product/8.0.5.1";
}

from httpd.conf:
PerlSetEnv ORACLE_HOME /u01/app/oracle/product/8.0.5.1


or any combination of the above :)

DBD::Oracle needs ORACLE_HOME at it's compile time, so setting it from
within your startup.pl and use()ing DBD::Oracle there is probably your best
bet.  YMMV.

HTH

--Geoff

> 
> Can anyone help?
> 
> Alex Vladimirskiy
> 

[DIGEST] mod_perl digest 01/07/2001

[Geoffrey Young]

--

  mod_perl digest
 
   January 7, 2001 - January 13, 2001

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o cvs patches
  o module announcements
  o mailing list highlights
  o news
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


cvs patches

  o Minor fixes to Apache::PerlRun [7] [8]


module announcements

  o Apache::Reload 0.06 - a replacement for Apache::StatINC, with 
more features and better debugging [9]

  o Apache-AuthenLDAP 0.52 - authenticates a user against an LDAP
backend [10]

  o Apache-AuthzLDAP 0.51 - authorizes a user against an LDAP
backend [11]

  o Apache-AuthzCache 0.03 - work with a mod_perl authorization
module to provide caching of group membership [12]

  o ApacheDBI 0.88 - provides persistent database connections [13]


mailing list highlights

  o This thread discusses the possibility of differentiating between
a child exit and when the parent process is shut down [14]

  o A new version of the mod_perl Guide was released this week - 
read it and prosper [15]

  o Discussion on limiting apache processes based on virtual memory 
[16] ended up giving a nice explanation of how and why to use
Apache::SizeLimit [17]

  o Two useful non-mod_perl based modules were announced on the list:
  HTTP::GHTTP 1.03 - a very lightweight C/XS based HTTP
  downloader [18]
  HTTP::WebTest 0.01 - runs tests on remote URLs or local web 
  files and generates a detailed test report [19]


news

  o Netcraft mod_perl statistics are out for December [20]
  mod_perl: 181,1864 Domains, 214,467 IP Addresses

  o take23.org published "Introduction to Programming in mod_perl"
this week [21]


links

  o The Apache/Perl Integration Project [22]
  o mod_perl documentation [23]
  o mod_perl modules on CPAN [24]
  o mod_perl homepage [25]
  o mod_perl news and advocacy [26]
  o mod_perl list archives [27] [28]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97928337200810&w=2
[8] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97931426708751&w=2
[9] http://forum.swarthmore.edu/epigone/modperl/wharzoldex
[10] http://forum.swarthmore.edu/epigone/modperl/kulmoistel
[11] http://forum.swarthmore.edu/epigone/modperl/whoireldsnend
[12] http://forum.swarthmore.edu/epigone/modperl/khonkhorkah
[13] http://take23.org/news/2001/01/14/apachedbi.xml
[14] http://forum.swarthmore.edu/epigone/modperl/nalclyskix
[15] http://forum.swarthmore.edu/epigone/modperl/clusounou
[16] http://forum.swarthmore.edu/epigone/modperl/whalglendswy
[17] http://marc.theaimsgroup.com/?t=9792418057&w=2&r=1
[18] http://forum.swarthmore.edu/epigone/modperl/dwermrehzee 
[19] http://forum.swarthmore.edu/epigone/modperl/zhooquoljer
[20] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97912083608055&w=2
[21] http://take23.org/articles/2001/01/08/intro.xml/1
[22] http://perl.apache.org
[23] http://perl.apache.org/#docs
[24] http://www.cpan.org/modules/by-module/Apache/
[25] http://www.modperl.com
[26] http://www.take23.org
[27] http://forum.swarthmore.edu/epigone/modperl/
[28] http://marc.theaimsgroup.com/?l=apache-modperl&r=1&w=2

RE: Apache::Registry - END Block not being called when script reloaded

[Geoffrey Young]

> -Original Message-
> From: Geoffrey Young 
> Sent: Monday, January 15, 2001 8:57 AM
> To: 'Chris D'Annunzio'; [EMAIL PROTECTED]
> Subject: RE: Apache::Registry - END Block not being called when script
> reloaded
> 
> I am unable to reproduce this using the latest cvs + perl 
> 5.6.0 under a bunch of different settings...
> 
> are you using an old version of mod_perl and/or perl perhaps?
> 
> if not, a small test case with relevant config info would 
> help track it down...

sorry - I didn't see your follow-up email with the relevant stuff...

I was able to recreate your problem...

others may have additional help or opinions, but I've never heard of anyone
doing an END block that way...

typically, you would preload any modules you use() using a startup.pl or
PerlModule - I guess you aren't doing either one of these since that would
cause the END block to be run when the server is shutdown (see the guide and
this thread from last week for more info:
http://forum.swarthmore.edu/epigone/modperl/nalclyskix)

anyway, sounds like you may need to re-evaluate how you are doing things...

--Geoff

RE: Apache::Registry - END Block not being called when script reloaded

[Geoffrey Young]

> -Original Message-
> From: Chris D'Annunzio [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 12, 2001 3:25 PM
> To: [EMAIL PROTECTED]
> Subject: Apache::Registry - END Block not being called when script
> reloaded
> 

[snip]
 
> The usual behavior for Apache::Registry is to explicitly call the
> END block each time the script runs. However, I have found that if I
> modify the main script and then execute a request without 
> restarting the
> server, the END block is not called in that 1st request where 
> the script
> is reloaded.
> 
> After the first request, the behavior returns to normal. Is 
> this a known
> bug or is there some other reason for this behavior? Has anyone else
> encountered this? 
> 

I am unable to reproduce this using the latest cvs + perl 5.6.0 under a
bunch of different settings...

are you using an old version of mod_perl and/or perl perhaps?

if not, a small test case with relevant config info would help track it
down...

--Geoff

RE: Apache::Registry newbie question -- CGI state

[Geoffrey Young]

> -Original Message-
> From: Alexander Farber (EED) [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 10, 2001 9:41 AM
> Cc: [EMAIL PROTECTED]
> Subject: Re: Apache::Registry newbie question -- CGI state
> 
> 
> Geoffrey Young wrote:
> > > #!/usr/bin/perl
> > > # file: hello.cgi
> > > use CGI qw(:standard);
> > > use strict;
> > 
> > I don't ever user CGI.pm, but aren't you forgetting to 
> create a new CGI
> > object in here?
> > 
> > > my $name = param('name') || 'Anonymous';
> 
> Geoff, I have another question: if you don't use 
> CGI.pm, how do you generate the web form elements? 
> Just "print qq{}" or are
> there some nicer tricks?

see one of the many, many threads in the archives on templating :)

--Geoff

> 

RE: Apache::Registry newbie question -- CGI state

[Geoffrey Young]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 10, 2001 6:01 AM
> To: [EMAIL PROTECTED]
> Subject: Apache::Registry newbie question -- CGI state
> 
> 
> I am trying to implement Example 2-14 in Stein and MacEachern.
> Here's my code:
> 
> #!/usr/bin/perl
> # file: hello.cgi
> use CGI qw(:standard);
> use strict;

I don't ever user CGI.pm, but aren't you forgetting to create a new CGI
object in here?

> my $name = param('name') || 'Anonymous';


HTH

--Geoff

RE: Can't get DBI to work with mod_perl

[Geoffrey Young]

> -Original Message-
> From: Joe Grastara [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 09, 2001 7:02 PM
> To: [EMAIL PROTECTED]
> Subject: Can't get DBI to work with mod_perl
> 

> I'm having trouble getting a script that uses the DBI module 
> to work under
> mod_perl. It works fine at the command line or as a normal cgi script.
[snip]
> 
> #!/usr/local/bin/perl
>  
> use strict; 
> use DBI; 
> use CGI
> qw(:standard); 
>  
> ###Set Local Environmental Variable for Oracle###
>  
> $ENV{"ORACLE_HOME"} = "/db/"; 

this should be done from a BEGIN block, exported globally in /etc/profile,
or as a PerlSetVar in httpd.conf  - DBD::Oracle needs it at compile time.
It may be in your local .profile, but apache usually runs as user nobody...

>   
> ###Print out some HTML###
>  
> print < Content-type: text/html\n
>  
>   Ph Lookup  
>  HTML_1

this may be a typo, but HTML_1 has to be the at the start of the line - no
spaces...

if you are using a recent version of DBD::Oracle on linux and see an error
that has to do with libclntsh.so check out 
http://forum.swarthmore.edu/epigone/modperl/grahsehspor

other than that, DBI->trace and perl.apache.org/guide is your friend :)

--Geoff

 

RE: difference in 123, 124 => 124_01

[Geoffrey Young]

> -Original Message-
> From: Michael [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 09, 2001 5:47 PM
> To: [EMAIL PROTECTED]
> Subject: difference in 123, 124 => 124_01
> 
> 
> In upgrading to 1.24_01 I notice some warnings when the apache starts 
> that I don't remember being present.
> 
> Specifically resulting from the inclusion of perl handlers i.e.
> 
>   PerlRequire /usr/local/apache/libhandlers/client23.pm
> 
> where the identical handler is used for both http and https service
> 

PerlRequire is not the standard way to load a pm - try using PerlModule or a
proper startup.pl instead...

--Geoff

RE: How do you run libapreq-0.31/eg/perl/file_upload.pl

[Geoffrey Young]

> -Original Message-
> From: Gerd Kortemeyer [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 09, 2001 6:43 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: How do you run libapreq-0.31/eg/perl/file_upload.pl
> 

> 
> might help the browser to figure out that the first page is 
> over. Also, if
> nothing helps, send an explicit no-cache in the header:
> 
> $r->content_type('text/html');
> $r->header_out('Cache-control','no-cache');
> $r->header_out('Pragma','no-cache');
> $r->send_http_header;

all of that can be accomplished with 
  $r->no_cache(1);
  $r->send_http_header('text/html');

--Geoff

> 
> - Gerd.
> 

[DIGEST] mod_perl digest 01/01/2001

[Geoffrey Young]

--

  mod_perl digest
 
   January 1, 2001 - January 6, 2001

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o cvs patches
  o module announcements
  o mailing list highlights
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


cvs patches

  o fix Apache::PerlRun is-a -> has-a Apache relationship change 
oversight [7]

  o fix $r subclassing mechanism when value of `r' or `_r' key is a 
hashref [8]


module announcements

  o Apache-ProxyRewrite 0.10 - a reverse-proxy that will rewrite URLs 
embedded in HTML documents per apache configuration directives [9]

  o HTML::Mason 0.896 - allows web pages and sites to be constructed
from shared, reusable building blocks called components, which
contain a mix of Perl and HTML and can call each other and pass
values back and forth like subroutines [10]


mailing list highlights

  o Here are tips on helping to get around 'User Pressed Submit Twice' 
problems,  [11] [12] including code for a quick Javascript 
solution [13]

  o Did you know that $r->document_root is writable? [14]

  o Some tips on securing a front-end back-end proxy setup [15]

  o More proxy talk - this time on getting those tricky mod_rewrite
rules right [16] [17]

  o Linux Hello World 2000 benchmark results are in [18]

  o Doug added quite a bit of documentation this week to the 2.0
development tree.  
  - 2.0 overview [19]
  - 2.0 design [20]


links

  o The Apache/Perl Integration Project [21]
  o mod_perl documentation [22]
  o mod_perl modules on CPAN [23]
  o mod_perl homepage [24]
  o mod_perl news and advocacy [25]
  o mod_perl list archives [26] [27]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97867331327427&w=2
[8] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97867366827849&w=2
[9] http://forum.swarthmore.edu/epigone/modperl/spoushalband
[10] http://forum.swarthmore.edu/epigone/modperl/mogrugli
[11] http://forum.swarthmore.edu/epigone/modperl/skunqualchon
[12] http://forum.swarthmore.edu/epigone/modperl/relddanshi
[13]
http://forum.swarthmore.edu/epigone/modperl/boirimshox/5.0.0.25.2.2001010509
[EMAIL PROTECTED]
[14] http://forum.swarthmore.edu/epigone/modperl/breldskahsang
[15] http://forum.swarthmore.edu/epigone/modperl/yendstilmul
[16] http://forum.swarthmore.edu/epigone/modperl/smingswoupril
[17] http://forum.swarthmore.edu/epigone/modperl/zhaxkhandblend
[18] http://forum.swarthmore.edu/epigone/modperl/sercrerdprou
[19] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97846563515032&w=2
[20] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97846518913900&w=2
[21] http://perl.apache.org
[22] http://perl.apache.org/#docs
[23] http://www.cpan.org/modules/by-module/Apache/
[24] http://www.modperl.com
[25] http://www.take23.org
[26] http://forum.swarthmore.edu/epigone/modperl/
[27] http://marc.theaimsgroup.com/?l=apache-modperl&r=1&w=2

RE: Adding a mod_perl / handler gives odd SCRIPT_NAME and PATH_INFO...

[Geoffrey Young]

> -Original Message-
> From: Jacqui Caren [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 09, 2001 8:06 AM
> To: Mod Perl
> Cc: Oliver Taylor; Jacqui Caren
> Subject: Adding a mod_perl / handler gives odd SCRIPT_NAME and
> PATH_INFO...
> 
> 
> 
> 
> The problem is that we expect everything after / to be
> part of PATH_INFO - from the CGI env it is not possible 
> to tell if we are trying to exclude / from the dynamic part of
> the URL or whether Apache/mod_perl has decided to moe this part
> of the URl into the script name.
> 
> Any suggestions are welcome.

rewrite requests to / or /index.html to your working  - that
will keep your dynamic stuff looking like it came from /

> 
> FYI: we have currently modified the sstem to include our own 
> TransHandler
> however for various reasons this is not an ideal solution...

if you are already writing your own trans handler, you'll benefit from
setting PerlSetupEnv Off and getting $r->path_info yourself instead of
gleaning it from %ENV...

HTH

--Geoff


> 
> Jacqui
> 
> 

RE: RedHat 7.0 and mod-perl

[Geoffrey Young]

there were some problem reports when 7.0 was first released - I don't think
any of those resulted in resolutions sent to the list...

from what I've heard, the gcc that ships with 7.0 had some real problems - I
dunno the current status, though...

--Geoff

> -Original Message-
> From: Jamie Krasnoo [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 08, 2001 7:21 PM
> To: Modperl
> Subject: RedHat 7.0 and mod-perl
> 
> 
> Is anyone using mod-perl with apache-1.3.14 on RedHat 7.0? 
> Any complaints?
> 
> Jamie Krasnoo
> 

RE: [ANNOUNCE] Apache-AuthenLDAP 0.52

[Geoffrey Young]

> -Original Message-
> From: Christian Gilmore [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 08, 2001 2:24 PM
> To: 'Geoffrey Young'; 'Modperl Mailing List (E-mail)'
> Subject: RE: [ANNOUNCE] Apache-AuthenLDAP 0.52
> 
> 
> Yup, but according to Doug, the patch committed to fix the 
> set_handlers
> problems is not slated to enter production until 1.26 is 
> released. 1.25
> will not contain the patch. You'd have to ask Doug why.

I could have sworn that those fixes made it in to 1.24_01 - I've stopped
having problems with get/set_handlers and coderefs since then...

I think I remember the stuff you reported back then - it's still not fixed?

anyway, my cvs box is being moved, so I can't even look at Changes...

--Geoff

> 
> Regards,
> Christian
> 

RE: [ANNOUNCE] Apache-AuthenLDAP 0.52

[Geoffrey Young]

> -Original Message-
> From: Christian Gilmore [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 08, 2001 12:52 PM
> To: Modperl Mailing List (E-mail)
> Subject: [ANNOUNCE] Apache-AuthenLDAP 0.52
>
> o  Better handled of pre-1.26 set_handlers bugs

did I miss something - this is the second time someone has mentioned 1.26...
is 1.25 not slated to be the next release?

--Geoff

RE: Help with Limit in

[Geoffrey Young]

> -Original Message-
> From: James G Smith [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 01, 2001 1:21 PM
> To: Scott Alexander
> Cc: [EMAIL PROTECTED]
> Subject: Re: Help with Limit in  
> 
> 
> 
> Ahh...  Now we get into the interesting bits of mod_perl.  There 
> is a way to change the DocumentRoot on a per-request basis.  Just 
> not a way to do this in the config files.
> 
> Use the function Apache::document_root.  For example:
> 
> my $old_docroot = $r -> document_root($new_docroot);

hi guys... 

  I was following up on this post for the digest, did some testing, and saw
something of interest:

http://localhost/cgi-bin/foo.cgi => output of foo.cgi execution

PerlInitHandler that sets DocumentRoot to /usr/local/apache/cgi-bin
(Directory directive)
http://localhost/foo.cgi => code for foo.cgi

PerlInitHandler that sets DocumentRoot to /usr/local/apache/perl-bin
(Location directive)
http://localhost/foo.cgi => 403


interesting, uh, feature :)

--Geoff

RE: mod_perl 1.24_01 Cookie Problem..?? Was: Apache::AuthCookieDBI BEGIN problems...??

[Geoffrey Young]

> -Original Message-
> From: Jeff Sheffield [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 05, 2001 3:48 PM
> To: Jacob Davies
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; James Hall
> Subject: mod_perl 1.24_01 Cookie Problem..?? Was: 
> Apache::AuthCookieDBI
> BEGIN problems...??
> 
[snip]
> 
> >I looked through the guide and searched the maillist archive but did
> >not find much info to help with this.
> >I also tried to install Apache::AuthCookieDBI, but documentation is
> >very limited for that and never could get it right.
> and that got me to thinking maby this is a mod_perl  1.24_01 problem.
> because I am experiencing the same sort of thing.

not likely - I use 1.24_01 and Apache::AuthCookie without incident

try checking your headers manually as I suggested to James...

--Geoff

> 
> Jeff
> 

RE: Newbie cookie question

[Geoffrey Young]

> -Original Message-
> From: James Hall [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 05, 2001 3:23 PM
> To: [EMAIL PROTECTED]
> Subject: Newbie cookie question
>
> Now that I have mod_perl installed I cannot pass any cookies 
> like I used to.
> I have not changed any scripts [yet] and all use DBI connections to a
> postgres DB.
> 

a code snippet of how you set your cookies would be most helpful...

be sure to check your outbound and inbound headers (either using telnet or
CPAN modules such as Apache::DumpHeaders or Apache::DebugInfo) to see what
is going on

do you have PerlSendHeaders On?

--Geoff

RE: missing docs

[Geoffrey Young]

> -Original Message-
> From: Vivek Khera [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 04, 2001 12:23 PM
> To: Mod Perl List
> Subject: missing docs
> 
> 
> In answering another question today, I noticed that the variable
> $Apache::Registry::NameWithVirtualHost is not documented in the
> perldoc for Apache::Registry.
> 
> While scanning the Registry.pm file, I further noticed that there is a
> call to $r->get_server_name for the virtual host name.  This too is
> not documented in perldoc Apache.  The only documented way I see to
> get this from the $r object is to use $r->server->server_hostname.
> 
> Should $r->get_server_name() be documented, or is it a "private"
> method?  

they are both documented (along with their differences) in the Eagle book -
I guess perldoc Apache is just behind (as seems to be the usual case)...

Andrew Ford's new mod_perl Pocket Reference goes a long way toward
documenting new functionality as of 1.24, but I suppose it's virually
impossible to keep up with the pace of development.  Just take a look at the
Changes file from 1.24 to current cvs.  ack...

--Geoff

> It seems wasteful to create an Apache::Server object just to
> fetch the virtual host name.
> 
> -- 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Vivek Khera, Ph.D.Khera Communications, Inc.
> Internet: [EMAIL PROTECTED]   Rockville, MD   +1-240-453-8497
> AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/
> 

RE: the edge of chaos

[Geoffrey Young]

> -Original Message-
> From: G.W. Haywood [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 04, 2001 10:35 AM
> To: Justin
> Cc: [EMAIL PROTECTED]
> Subject: Re: the edge of chaos
> 
> 
> Hi there,
> 
> On Thu, 4 Jan 2001, Justin wrote:
> 
> > So dropping maxclients on the front end means you get clogged
> > up with slow readers instead, so that isnt an option..
> 
> Try looking for Randall's posts in the last couple of weeks.  He has
> some nice stuff you might want to have a play with.  Sorry, I can't
> remember the thread but if you look in Geoff's DIGEST you'll find it.

I think you mean this:
http://forum.swarthmore.edu/epigone/modperl/phoorimpjun

and this thread:
http://forum.swarthmore.edu/epigone/modperl/zhayflimthu

(which is actually a response to Justin :)

> 
> Thanks again Geoff!

glad to be of service :)

--Geoff

> 
> 73,
> Ged.
> 

RE: mod_perl confusion.

[Geoffrey Young]

> -Original Message-
> From: Tom Karlsson [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 04, 2001 8:09 AM
> To: [EMAIL PROTECTED]
> Subject: mod_perl confusion.
> 
> 
> Hello All,
> 
> I've recently looked through the mod_perl mail archives in 
> order to find
> someone who has/had the same problem as me. 
> 
> It seems that a lot of people have had problems with 
>  and
>  in situations where both virtualhost sections has a similar
> URI and scriptname.
> 
> This problem causes random execution of either of the scripts 
> no matter
> what virtualhost you're accessing. Like
> 
> exampleA.com/cgi-bin/script
> exampleB.com/cgi-bin/script

try setting
$Apache::Registry::NameWithVirtualHost = 1;
in your startup.pl and make sure that you are use()ing Apache::Registry in
there as well...

and see if that fixes things...

HTH

--Geoff
 
[snip]
> Thanks.
> 
> Friendly Regards
> /TK
> 

RE: How do you run libapreq-0.31/eg/perl/file_upload.pl ?

[Geoffrey Young]

> -Original Message-
> From: Alexander Farber (EED) [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 04, 2001 4:58 AM
> To: [EMAIL PROTECTED]
> Subject: How do you run libapreq-0.31/eg/perl/file_upload.pl ?
> 
[snip]
> 
> 2) After putting 
> 
> PerlModule Apache::Request
> 
> SetHandler perl-script
> PerlHandler Apache::Request
> 

that won't work - Apache::Request is not a PerlHandler.  remember that
Perl*Handlers default to calling handler(), which Apache::Request doesn't
have (which is exactly what your error_log says)

> 
> into my httpd.conf, I get the following in my error_log:
> 
> [Thu Jan  4 10:47:39 2001] [notice] Apache/1.3.14 (Unix) 
> mod_perl/1.24_01 configured
> -- resuming normal operations
> [Thu Jan  4 10:47:51 2001] [error] Undefined subroutine 
> &Apache::Request::handler cal
> led.
> 
[snip]
> 3) And the:
> 
> PerlModule Apache::Request
> PerlModule Apache::Registry
> 
> SetHandler perl-script
> PerlHandler Apache::Registry
> Options ExecCGI
> PerlSendHeader On
> 

well, almost...  either change that to a  directive or remove the
filename from the  directive, so that Apache::Request applies to
all scripts within cgi-bin...

see http://perl.apache.org/guide/config.html for more details...

> 
> Displays the web form, but nothing happens (same form
> displayed again), when I click the "Process File" button 
> and nothing is shown in the error_log.
> 
> Also I have sometimes to reload several times to see a change.
> 
> Should I wrap the code in the file_upload.pl into a "package"?

no - keep it simple while you figure things out...

> Can't I use Apache::Request w/o Apache::Registry? 

Apache::Request can be used without Apache::Registry, as long as you use it
properly.  They aren't the same type of module - compare man Apache::Request
and man Apache::Registry

> Am I loading
> the modules wrong way?
> 
> I should of course read and re-read the complete guide and 
> finish the Eagle book (I will),

yes :)

> but maybe someone can provide 
> me a small kick-start? Thank you

HTH

--Geoff

> 
> Regards
> Alex
> 

[RFC] new Apache::Dispatch feature

[Geoffrey Young]

hi all...

I know Apache::Dispatch is starting to become quite feature, uh, rich, but
would be interested in what people who are using it (if any :) thought about
something...

I've been noticing in my logs that people are starting to get nosy and, for
Foo/Bar/baz people are wondering what is in /Foo/Bar (for which Dispatch
returns DECLINED and Apache returns NOT_FOUND)...

maybe it would cut down on (some of) this poking around if we could do
/Foo/Bar/baz.asp or something :)

currently, if $uri =~ m![^\w/-]! then we decline the request... I was
thinking changing this to a translation of any non-word characters in the
method name to _ or something: /Foo/Bar/baz.asp => My::Bar->dispatch_baz_asp

or maybe stripping off everything after the . (or maybe both :)

Of course, it would be only for appearance, which is why I'm asking...
anyone interested?

--Geoff

BTW, the latest version, close to CPAN and without the above modifications
can be found at

http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.09.tar.gz

RE: apache attempting to re-read POST from STDIN on ErrorDoc redirect

[Geoffrey Young]

> -Original Message-
> From: Eric Kolve [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 03, 2001 1:25 PM
> To: '[EMAIL PROTECTED]'
> Subject: apache attempting to re-read POST from STDIN on ErrorDoc
> redirect
> 
> 
> I have the following Apache::Registry script, which posts to 
> itself.  At the
> top, I read in the posted values using CGI.  If I receive one 
> of them I die
> to demonstrate my little bug.  This causes a SERVER_ERROR to 
> be returned to
> apache, which then attempts to perform an internal redirect 
> to a static html
> errordoc page.  The problem I am having is that CGI has read 
> the posted
> values from STDIN, apache is trying to re-read them on the internal
> redirect, which causes it to block.  I have found several 
> solutions to this,
> one being to set CONTENT_LENTGTH to 0, or to simply use 
> Apache::Request
> instead of CGI.  What I am really interested in is what exactly is
> Apache::Request doing to prevent apache from attempting to 
> re-read from
> STDIN for post values.

not sure about the Apache::Request part, but a recent version of mod_perl
should fix this for you...

from Changes for 1.24_01:

fix $r->read() so it will not block if all data has already been read
and so that Apache will not hang during ap_discard_request_body() on
error or redirect after all data has been read

HTH

--Geoff

> 
> thanks,
> --eric
> 
> --SCRIPT--
> use strict;
> use CGI;
>  
> my $cgi = CGI->new;
>  
> my $mode = $cgi->param('mode');
> die if $mode;;
> print qq|Content-Type: text/html\n\n|;
>  
> print qq|
> 
> 
> 
> 
> 
> 
> |; 
> 

RE: PerlSetupEnv Off not working

[Geoffrey Young]

> -Original Message-
> From: John K Sterling [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 02, 2001 5:52 PM
> To: JR Mayberry
> Cc: [EMAIL PROTECTED]
> Subject: Re: PerlSetupEnv Off not working
> 
> 
> i assume thats a typo, i think PerlSetupEnv has been in since '96
> 
> have you seen this bug report? 
> http://marc.theaimsgroup.com/?l=apache-modperl&m=95867712412668&w=2
> might have something to do with it.

for the record, this was fixed in 1.24_01

--Geoff

> 
> sterling
> 
 

[DIGEST] mod_perl digest 12/25/2000

[Geoffrey Young]

--

  mod_perl digest
 
   December 25, 2000 - December 31, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o cvs patches
  o module announcements
  o mailing list highlights
  o news
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


cvs patches

  o allow $r->finfo to be modified [7]

  o fix directive handlers bug triggered by LoadModule foo_module [8]

  o win32 updates for 1.3.15, including ApacheModulePerl.{dsp,dll} ->
mod_perl.{dsp,so} rename [9]


module announcements

  o Apache::RequestNotes 0.06 - pass form and cookie data around in 
pnotes [10]

  o Apache::PageKit 0.91 - a web applications framework providing a
clear separation of programming, content and presentation [11]

  o Apache::FileMan pre-release 0.03 - provides the same 
functionality as Apache::AutoIndex and can be used to both 
navigate and manage the web site [12]

  o Avacet Application Engine 2.0b2 - offers a language-neutral 
definition of data and interfaces for exchanging data, as well as
a reference implementation of an application engine [13]


mailing list highlights

  o This interesting thread discusses the overhead involved in using
vars.pm versus fully qualified globals. [14]


  Other than that, not much of interest happened over the holidays - 
  I think I'll just call it another great year for mod_perl...


news

  o Netcraft December statistics [15]
 Apache 59.69% IIS 20.09%

  o Security Space December statistics [16]
 Apache 57.97% IIS 28.45%
 11.51% (161,527) of Apache servers are running mod_perl [17]


links

  o The Apache/Perl Integration Project [18]
  o mod_perl documentation [19]
  o mod_perl modules on CPAN [20]
  o mod_perl homepage [21]
  o mod_perl news and advocacy [22]
  o mod_perl list archives [23] [24]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97810977729586&w=2
[8] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97815291126928&w=2
[9] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97829122618630&w=2
[10] http://forum.swarthmore.edu/epigone/modperl/zheldphaspeld
[11] http://forum.swarthmore.edu/epigone/modperl/dermsarfi
[12] http://forum.swarthmore.edu/epigone/modperl/bixsilflay
[13] http://forum.swarthmore.edu/epigone/modperl/darsmorthon
[14] http://forum.swarthmore.edu/epigone/modperl/twingpolsu
[15] http://www.netcraft.com/survey
[16] http://www.securityspace.com/s_survey/data/index.html
[17] http://www.securityspace.com/s_survey/data/man.200012/apachemods.html
[18] http://perl.apache.org
[19] http://perl.apache.org/#docs
[20] http://www.cpan.org/modules/by-module/Apache/
[21] http://www.modperl.com
[22] http://www.take23.org
[23] http://forum.swarthmore.edu/epigone/modperl/
[24] http://marc.theaimsgroup.com/?l=apache-modperl&r=1&w=2

RE: Where can I find....

[Geoffrey Young]

> -Original Message-
> From: Michael [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 28, 2000 6:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Where can I find 
> 

> 
> Thanks, I have the complete list. It is given in 
> man Apache::Constants
> 
> What I'm trying to do is figure out how to use them. The two above 
> OK, and DECLINED can be returned to an internal call from the auth 
> portion of Apache and will allow it to proceed or bomb. I'd like to 
> find out what the rest do. From their names many of them appear like 
> they could be quite useful.

get a copy of the Eagle book (www.modperl.com) and read it thoroughly - it
has something to say about just about all of them.

--Geoff

> 
> Michael
> [EMAIL PROTECTED]
> 

[ANNOUNCE] Apache::RequestNotes 0.06

[Geoffrey Young]

The URL

 
http://morpheus.laserlink.net/~gyoung/modules/Apache-RequestNotes-0.06.tar.g
z

has entered CPAN as

  file: $CPAN/authors/id/G/GE/GEOFF/Apache-RequestNotes-0.06.tar.gz
  size: 4800 bytes
   md5: 809cb54e2b9b8143a9809753c8f23dc3


well, now that libapreq-0.31_03 is out, with Apache::Request->instance(),
Apache::RequestNotes is little more than a convienent data parser.
Nevertheless, I updated the docs to let folks know about the new libapreq
functionality and changed the instantiation call to use instance() so that
in case anyone still uses Apache::RequestNotes they can use Apache::Request
in other handlers without getting clobbered in the process...

Changes:
0.06  12.27.2000
- changed Apache::Request->new() call to instance()
- documented availability of Apache::Request->instance()
- initialized Apache::RequestNotes::err properly
- minor pod changes

[DIGEST] mod_perl digest 12/17/2000

[Geoffrey Young]

--

  mod_perl digest
 
   December 17, 2000 - December 24, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o cvs patches
  o module announcements
  o mailing list highlights
  o advocacy
  o FAQ of the week
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


cvs patches

  o more Apache::test enhancements and fixes [7]

  o stop win32 crash when bringing down service [8]

  o allow Makefile.PL to build mod_perl on Win32 using VC++ [9] 

  o allow modification of $r->hostname [10]

  o build fix for using gcc with AIX [11]

  o prevent $PerlRequire in a  section from triggering an 
endless loop [12]

  o rewrite of Apache::WRITE() in c/xs [13]

  o include mod_perl hook/feature config in Apache::MyConfig [14]
  
  o Solving an 'uninitialized value' warn in Apache::SizeLimit.
post_connection() expects a return status from the callback 
function [15]

  o rid PL_na usage in Symbol.xs [16]

  o fix $r->custom_response bug which was triggering core dumps if no
ErrorDocuments were configured [17]

  o if Perl is linked with -lpthread, then httpd needs to be linked 
with -lpthread, make sure that happens with USE_DSO=1, warn if 
USE_APXS=1 [18]


module announcements

  o Apache::Filter 1.016 - Alter the output of previous handlers [19]

  o HTML::Embperl 2.0 beta - a module for embedding Perl code in HTML
pages that includes building pages/sites out of small reusable
objects/components and session handling [20]

  o Apache::VMonitor 0.6 - emulates the reporting functionalities of
top(), mount(), df(), and ifconfig() utilities [21]

  o libapreq 0.31_03 - Apache::Request and Apache::Cookie 
functionality [22]


mailing list highlights

  o The mod_perl Pocket Reference is on a bookshelf near you [23]

  o Here are a few tips on how to throttle those bad robots [24]

  o Some SpeedyCGI and mod_perl comparisons [25]

  o TPC-5 call for papers for the mod_perl track has begun [26]

  o A tip on how to use Apache::Module to recover httpd.conf
configuration directives (mod_alias in this case) [27]


links

  o The Apache/Perl Integration Project [28]
  o mod_perl documentation [29]
  o mod_perl modules on CPAN [30]
  o mod_perl homepage [31]
  o mod_perl news and advocacy [32]
  o mod_perl list archives [33] [34]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97729402907389&w=2
[8] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97729435907907&w=2
[9] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97729485408597&w=2
[10] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97729573810055&w=2
[11] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97729619410837&w=2
[12] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97729705112226&w=2
[13] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97729964515941&w=2
[14] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97733817606770&w=2
[15] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97733879908447&w=2

[16] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97746492117680&w=2
[17] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97751855007398&w=2
[18] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97753815701515&w=2
[19] http://forum.swarthmore.edu/epigone/modperl/zafryska
[20] http://forum.swarthmore.edu/epigone/modperl/brexnyflun
[21] http://forum.swarthmore.edu/epigone/modperl/vayflimpker
[22] http://forum.swarthmore.edu/epigone/modperl/dwahvayswax
[23] http://forum.swarthmore.edu/epigone/modperl/sworcrimpberm
[24] http://forum.swarthmore.edu/epigone/modperl/zhayflimthu
[25] http://forum.swarthmore.edu/epigone/modperl/steldflerdflen
[26] http://forum.swarthmore.edu/epigone/modperl/wonborclol
[27] http://forum.swarthmore.edu/epigone/modperl/wherdswinzex
[28] http://perl.apache.org
[29] http://perl.apache.org/#docs
[30] http://www.cpan.org/modules/by-module/Apache/
[31] http://www.modperl.com
[32] http://www.take23.org
[33] http://forum.swarthmore.edu/epigone/modperl/
[34] http://marc.theaimsgroup.com/?l=apache-modperl&r=1&w=2

RE: Apache::DBI and altered packages

[Geoffrey Young]

> -Original Message-
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 22, 2000 11:55 AM
> To: Geoffrey Young; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Apache::DBI and altered packages
> 
> 
> 
> If you change the ping() method to check whether or not your 
> package still
> works, Apache::DBI will automatically get a new connection 
> when it fails.

yeah, that's an idea - lots of packages to check, though.  but this might be
the best solution...

thanks

--Geoff

> 
> - Perrin
> 

RE: Apache::DBI and altered packages

[Geoffrey Young]

> -Original Message-
> From: jared still [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 22, 2000 11:52 AM
> To: Geoffrey Young
> Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Subject: Re: Apache::DBI and altered packages
> 
> 
> 
> 
> Geoff,
> 
> I'm going to make a non-technical suggestion:  You need to have  
> change control implemented so that packages in your database
> are not changing during business hours.
> 
> If you are 24x7, then you need to schedule an outage, and notify
> your customers of scheduled downtime.
> 
> This is more of a management and logistics problem than a Perl
> or Apache or Oracle problem
> 

what, you mean not making changes to production on a regular basis?  what do
you think I'm trying to run, a stable shop or something?

you have to actually be here to believe what goes on, though :)

Apache::DBI and altered packages

[Geoffrey Young]

hi all...

I was wondering if anyone has found a good way around persistent connections
and package recompiles.  With Apache::DBI, on occasion when someone
recompiles a package and doesn't tell me, I see

ORA-04061: existing state of package body "FOO.BAR" has been invalidated
ORA-04065: not executed, altered or dropped package body "FOO.BAR"
ORA-06508: PL/SQL: could not find program unit being called

my Oracle gurus here tell me that whenever a package changes any open
connections will get this error.  Since the connection itself ok (just not
the stuff I need to use) the only solution currently available seems to be
$r->child_terminate() so that at least that child doesn't barf every time.
However, this leaves the current request in a lurch...

I was thinking that maybe something like Apache::DBI::reconnect() was needed
- call DBI->disconnect then DBI->connect again.

that is unless someone has dealt with this in another way - someone
mentioned that perhaps the proper ALTER OBJECT permissions would force a
recompile - I dunno...

--Geoff

RE: help with custom Error documents/redirection

[Geoffrey Young]

> -Original Message-
> From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 22, 2000 1:14 AM
> To: Geoffrey Young
> Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Subject: RE: help with custom Error documents/redirection
> 
> 
> On Wed, 13 Dec 2000, Geoffrey Young wrote:
>  
> > BTW, it's always good (at least I've found) to call
> > my $prev_uri = $r->prev ? $r->prev->uri : $r->uri;
> 
> or with one less method call :)
> my $prev_uri = ($r->prev || $r)->uri; 

now that's cool - I just love perl...

> 

RE: mod_perl training

[Geoffrey Young]

> -Original Message-
> From: Gunther Birznieks [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 20, 2000 5:28 AM
> To: mod_perl list
> Subject: mod_perl training
> 
> Anyway, I know this topic has been very quiet since last 
> week. But I just 
> wanted to say that I don't want to let it die (for those that 
> expressed 
> interest), and I am definitely still interested even if I am going to 
> shutup for the next week (which many of you may be happy about). :)

not to supress an important topic, but do you think we could impress on the
interested parties to move the discussion to [EMAIL PROTECTED] and
away from the main list?

--Geoff

 

RE: HTTP authentication based sessioning with logout ability

[Geoffrey Young]

> -Original Message-
> From: G.W. Haywood [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 19, 2000 1:38 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: HTTP authentication based sessioning with logout ability
> 
> 
> Hi there,
> 
> On Tue, 19 Dec 2000 [EMAIL PROTECTED] wrote:
> 
> [Reams and reams of stuff snipped, without apology]
> 

I'd append to Ged's comments with:

The Eagle book is your friend - the answer to 

> return OK if $r->sub_request;
> 
> [Tue Dec 19 17:32:04 2000] [error] Can't locate object 
> method "sub_request" via package "Apache" at 
> /usr/lib/perl5/5.6.0/i386-linux/raxware/AssignRealm.pm line 85.

can be found within (hint, there's no sub_request() method, and had you read
Doug's follow-up to the post you sent you would have seen that :)

in fact, you don't have to even buy the book - convienently
http://www.modperl.com/book/chapters/ch6.html is online and contains the
answers you crave (but supporting Doug's hard work and smarts is, well,
smart - just go buy it)

in general, though, you'd be better off using shrink-wrapped stuff from CPAN
(such as the many Apache::Auth* modules that are out there.) especially if
you don't have the time to learn all the nuances of what is going on...

good luck and welcome to the community...

--Geoff

RE: [DIGEST] mod_perl digest 12/10/2000

[Geoffrey Young]

yack...  sorry guys, hope I didn't offend anyone.  I really have to stop
doing these monday morning...

> 
> mailing list highlights
> 
>   o Although everyone ought to know by now that Apache 1.3.14 requires

should have been...

o There were several threads discussing benchmarking this week:
>   Apache::Session [10]
>   Template Toolkit [11]
>   Hello World 2000 [12]
> 

again, my humble apologies...

--Geoff

RE: Apache::Compress patch

[Geoffrey Young]

> -Original Message-
> From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 14, 2000 8:34 AM
> To: 'Ken Williams'
> Cc: '[EMAIL PROTECTED]'
> Subject: Apache::Compress patch
> 
> 
> hi ken...
> 
> 
> something has been bugging me in Apache::Compress for a while now - it
> _always_ tries to compress output.
> 
[snip]

whoops on that patch...  it didn't print filtered output that was less than
300 characters *doh*.  This should do the trick (against Compress.pm
1.003)...

--Geoff

--- Compress.pm.old Thu Dec 14 08:22:15 2000
+++ Compress.pm Mon Dec 18 15:29:26 2000
@@ -35,10 +35,23 @@
   return SERVER_ERROR unless $fh;
   
   if ($can_gzip) {
-$r->content_encoding('gzip');
-$r->send_http_header;
 local $/;
-print Compress::Zlib::memGzip(<$fh>);
+local $^W;  # length() gives an uninitialized warning. hmmm...
+my $file = <$fh>;
+
+my $length = length($file);
+
+return DECLINED unless $length;
+
+if ($length < 300) {
+  $r->send_http_header;
+  $r->print($file);
+}
+else {
+  $r->content_encoding('gzip');
+  $r->send_http_header;
+  print Compress::Zlib::memGzip($file);
+}
   } else {
 $r->send_http_header;
 $r->send_fd($fh);

[DIGEST] mod_perl digest 12/10/2000

[Geoffrey Young]

--

  mod_perl digest
 
   December 10, 2000 - December 16, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o module announcements
  o mailing list highlights
  o advocacy
  o FAQ of the week
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


module announcements

  o Apache::VMonitor 0.5 - emulates the reporting functionalities of 
top(), mount(), df(), and ifconfig() utilities [7]

  o HTML::Template 2.1 - makes using HTML templates simple and natural
by extending standard HTML with a few new HTML-esque tags [8]

  o HTML::Mason 0.895 - allows web pages and sites to be constructed
from shared, reusable building blocks called components, which
contain a mix of Perl and HTML and can call each other and pass
values back and forth like subroutines [9]


mailing list highlights

  o Although everyone ought to know by now that Apache 1.3.14 requires
  Apache::Session [10]
  Template Toolkit [11]
  Hello World 2000 [12]

  o A suggested patch to Apache::ReadConfig (ApacheReadConfig) 
prohibits PerlModule and PerlRequire from being activated
by  sections [13]

  o A few tips on writing STDOUT to a string [14]

  o Some pitfalls to be aware of when trying to expire cookies [15]

  o Long thread of the week goes to a discussion on forking a process
from mod_perl.  There's lots of interesting stuff in this one [16]

  o The mod_perl Center for Linguistic Studies awards go to...
  Aaron Johnson [17] 
  Tim Bunce [18]
;)

  o A comparison of webmail servers WING and TWIG [19]

  o For anyone who was wondering how Apache::DBI handles transactions
(or wondering what a transaction is, for that matter) there is
a nice description here [20]


advocacy

  o Still overflowing from the past week, there are a number of active
threads on mod_perl advocacy.  The most focused of these was 
dedicated to mod_perl tutorials [21].


FAQ of the week

  Yikes, 1.3.14 is two months old and we saw this twice this week...

  o I'm trying to make mod_perl with Apache 1.3.14, but see the error:
"Apache Version 1.3.0 required, aborting..."

Using mod_perl with Apache 1.3.14 requires an upgrade to 1.24-01
(or some hacking around). Get the latest version from the mod_perl
distribution page [22]


links

  o The Apache/Perl Integration Project [23]
  o mod_perl documentation [24]
  o mod_perl modules on CPAN [25]
  o mod_perl homepage [26]
  o mod_perl news and advocacy [27]
  o mod_perl list archives [28]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://forum.swarthmore.edu/epigone/modperl/sougoipand
[8] http://forum.swarthmore.edu/epigone/modperl/mimpshaxyand
[9] http://forum.swarthmore.edu/epigone/modperl/flekhusol
[10] http://forum.swarthmore.edu/epigone/modperl/whimpfleezil
[11] http://forum.swarthmore.edu/epigone/modperl/perkeebrao
[12] http://forum.swarthmore.edu/epigone/modperl/swimpsneecru
[13] http://marc.theaimsgroup.com/?t=9765995771&w=2&r=1
[14] http://forum.swarthmore.edu/epigone/modperl/creebreglang
[15] http://forum.swarthmore.edu/epigone/modperl/crertonstah
[16] http://forum.swarthmore.edu/epigone/modperl/plorulrin
[17] http://forum.swarthmore.edu/epigone/modperl/smixdermgling
[18] http://forum.swarthmore.edu/epigone/modperl/peldskintwang
[19] http://forum.swarthmore.edu/epigone/modperl/thermblelfru
[20] http://forum.swarthmore.edu/epigone/modperl/spintwelzhy
[21] http://forum.swarthmore.edu/epigone/modperl/croocrixswix
[22] http://perl.apache.org/dist/mod_perl-1.24_01.tar.gz
[23] http://perl.apache.org
[24] http://perl.apache.org/#docs
[25] http://www.cpan.org/modules/by-module/Apache/
[26] http://www.modperl.com
[27] http://www.take23.org
[28] http://forum.swarthmore.edu/epigone/modperl/

RE: Apache::Reload and environment variables

[Geoffrey Young]

> -Original Message-
> From: Mark Doyle [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 15, 2000 4:06 PM
> To: Jimi Thompson
> Cc: [EMAIL PROTECTED]
> Subject: Re: Apache::Reload and environment variables
> 
> 
> 
> On Friday, December 15, 2000, at 04:01 PM, Jimi Thompson wrote:
> 
> > If the variable ORACLE_HOME doesn't change why not just set 
> it as an 
> > environment variable outside the program and export it? 
> 
> >> PerlSetEnv ORACLE_HOME /oracle/app/oracle/product/8.0.3/
> >> PerlModule Apache::DBI
> >> [...]
> >> PerlModule Apache::Reload
> >> PerlInitHandler Apache::Reload
> >> PerlSetVar ReloadAll Off
> 
> That snippet is from my httpd.conf file - it is globally
> defined there. Isn't that the same as what you are saying?

well, it's not the same - what he means is for you to export ORACLE_HOME in
/etc/passwd or somesuch 

DBD::Oracle needs ORACLE_HOME set at compile time - for Registry scripts its
ok to PerlSetEnv so that when your .cgi use()s DBD::Oracle, it's there...

for handlers, though, PerlSetEnv may be too late, especially if you are
using a startup.pl script.  generally what I do is to use a BEGIN block in
startup.pl to define ORACLE_HOME prior to using Apache::DBI, DBI, and
DBD::Oracle.  if you export it from /etc/profile then you probably don't
need to do this (but it can't hurt, either - I do both)

I don't know specifically why Apache::Reload is causing this behavior, but
try the above and see if that clears things up...

HTH

--Geoff

> 
> Cheers,
> Mark
> 

RE: Warning, Apache Version 1.3.0 required

[Geoffrey Young]

> -Original Message-
> From: Richard [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 15, 2000 1:19 PM
> To: [EMAIL PROTECTED]
> Subject: Warning, Apache Version 1.3.0 required
> 
> 
> Ok, i've searched the archives and cannot find help for this 
> problem there.
> 
> I have compiled Apache v 1.3.14, without errors.
> 
> I have then gone to compile mod_perl v1.24, below is my effort.
> 
> The error/warning at the bottom states that i require Apache 1.3.0.

short answer: upgrade to 1.24_01
long answer: search the archives more closely ;)

HTH

--Geoff
> 
> Anyone shed any light on why this would happen?
> 
> Thanks in advance, 
> 
> Richard Harrison
> 
> 

RE: Mod_perl tutorials

[Geoffrey Young]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 14, 2000 10:09 AM
> To: Stas Bekman
> Cc: Matt Sergeant; mod_perl list
> Subject: Re: Mod_perl tutorials
> 
> 
> But I'm cool with the name as long as there's a prominent link of "why
> 'take23'?" somewhere up front, so that others can learn why as well.

bah - if they really want to know, it's in the index of the Eagle book...

as long as it is sufficiently linked, CNAMEd, and search-engine friendly I
don't think it matters much

kinda like
print pack('c5',(41*2),sqrt(7056),(unpack('c',H)-2),oct(115),10);

the answer is there and figuring it out is half the fun :)

--Geoff

Apache::Compress patch

[Geoffrey Young]

hi ken...


something has been bugging me in Apache::Compress for a while now - it
_always_ tries to compress output.

my thought here is that all filters in the pipeline should be able to return
DECLINED and have apache's defaults take over.  unfortunately, Compress
basically only uses the browser compatibility (and some minimal filehandle
checks) to determine its action, which is either to compress or not compress
(but it always involves a print in either case).

The reason this is important is that if there are two (or more) filters in
the pipeline and the all return DECLINED because a file is not found (which
is better than NOT_FOUND because later handlers may deal with the situation
of null input differently) then Compress tries to compress null and you get
a null document back instead of 404.  

also, this comment from mod_gzip has me thinking...

 * Default to 300 bytes as a minimum size requirement for it
 * to even be worth a compression attempt. This works well as a
 * minimum for both GZIP and ZLIB which are both LZ77 based and,
 * as such, always have the potential to actually increase the
 * size of the file.

here's a quick patch that solves both issues (well we count characters
instead of bytes, but it's close enough and 'use bytes' seemed to really
complain about the uninitialized stuff worse than without it)

--- Compress.pm.old Thu Dec 14 08:22:15 2000
+++ Compress.pm Thu Dec 14 08:21:52 2000
@@ -35,10 +35,13 @@
   return SERVER_ERROR unless $fh;
   
   if ($can_gzip) {
+local $/;
+local $^W;  # length() gives an uninitialized warning. hmmm...
+my $file = <$fh>;
+return DECLINED unless length($file) > 300;
 $r->content_encoding('gzip');
 $r->send_http_header;
-local $/;
-print Compress::Zlib::memGzip(<$fh>);
+print Compress::Zlib::memGzip($file);
   } else {
 $r->send_http_header;
 $r->send_fd($fh);


BTW, I've been thinking of trying to integrate a perl interface into
mod_gzip (since all the compression code is containted within it and it has
lots of built in intelligence), but since my C is poor I'm at a loss of
where to start (can't use h2xs since it doesn't have a *.h file).  If anyone
is interested in guiding the C challenged...

--Geoff

RE: [OT] Re: Mod_perl tutorials

[Geoffrey Young]

> -Original Message-
> From: Robin Berjon [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 13, 2000 6:24 PM
> To: Stas Bekman
> Cc: Drew Taylor; mod_perl list
> Subject: [OT] Re: Mod_perl tutorials
> 
[snip]

> This doesn't mean that modperlnew will be
> taken within hours but one should be very careful when using 
> registrars'
> whois/dns check tools. If you could want it, buy it 
> immediately. Maybe some
> registrars are not that kind of bandits, but it's hard to 
> know. When the
> revolution comes, we should probably hang most of those nic people ;)

I didn't have that experience with dotster.com where it took me a few weeks
to make up my mind...  for what it's worth...

--Geoff


> 
> -- robin b.
> Immature poets imitate, mature poets steal. -- T.S. Eliot
> 

RE: Mod_perl tutorials

[Geoffrey Young]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 13, 2000 3:01 PM
> To: Matt Sergeant
> Cc: Jay Jacobs; [EMAIL PROTECTED]
> Subject: Re: Mod_perl tutorials
> 
> /me scuffles off to register no-args.org now... :)
> 
  I'm partial to to rawargs.org myself - it's more visceral...

;)

--Geoff

RE: Has anyone built mob_perl on SuSE 7 or RH 7???

[Geoffrey Young]

> -Original Message-
> From: Carson, Chuck [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 13, 2000 1:25 PM
> To: '[EMAIL PROTECTED]'
> Subject: Has anyone built mob_perl on SuSE 7 or RH 7???
> 
> 
> 
> I have been trying to no end to get mod_perl-1.24 to compile with
> Apache-1.3.14 on SuSE 7.0 and Red Hat 7.0. Here are some 
> procedures I have
> tried. Note, each time I have started with freshly upacked tarballs of
> mod_perl-1.24 and apache-1.3.14.
> 
[snip]
> * WARNING *
> 
>   Apache Version 1.3.0 required, aborting...
> 
> * WARNING *

you need mod_perl 1.24_01 to build against Apache 1.3.14 (or you need to
hack a few things) - the archives should have told you that :)

some people around here have reported problems with the gcc that shipped
with RH7.0 - if you continue to have problems, maybe try downgrading to the
gcc from 6.2 (I'm still on 6.2, so I haven't tried it yet)

HTH

--Geoff

[snip]

RE: help with custom Error documents/redirection

[Geoffrey Young]

> -Original Message-
> From: B. Burke [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 13, 2000 10:44 AM
> To: [EMAIL PROTECTED]
> Subject: help with custom Error documents/redirection
> 
> 
> I'm looking to implement custom error handling, and I'm 
> hitting a snag.
> I'm hoping to do something like on pg.168 of the Eagle book, where you
> have a handler and user $r->prev to get the original request.
> 
> I'm wanting to redirect to 1 of 2 pages, depending on what the
> requested page was.  I plan on using $r->custom_response to do the
> redirection (as shown on pg. 170 of the Eagle bk).
> 
> The problem I'm having is that $r->prev doesn't seem to be getting
> the request.  I setup a  for the handler, and setup an
> ErrorDocument to point to the Location.  It works, except that I can't
> seem to get $r->prev to tell me what the request was.

you know that $r->prev returns a request object, and not anthing specific
(like the previous location), right?  :)

if you're still unable to get it working, try pointing custom_response to a
script that gleans $r->prev->uri and returns the proper response based on
that...  the whole error document cycle is hard to get until you get it.
keep playing and you'll see the light eventually :)

BTW, it's always good (at least I've found) to call
my $prev_uri = $r->prev ? $r->prev->uri : $r->uri;
because if the page/script is accessed directly then $r->prev is undefined
and you get a runtime error.

HTH

--Geoff

> 
> Any help will be greatly appreciated.
> 
> Thanks,
> Brian B.
> 

RE: Still bugs in Apache::Dispatch with .htaccess

[Geoffrey Young]

> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 11, 2000 1:27 PM
> To: Geoffrey Young
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: Still bugs in Apache::Dispatch with .htaccess
> 
> 
> 
> I'd make it as simple as possible. Make it DispatchRoot (akin to
> DocumentRoot). 

  I like that name (and concept) better...


> Don't try and do anything fancy.

  but that's so much more fun ;)

--Geoff

> 
> -- 
> 
> 
> /||** Director and CTO **
>//||**  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** Personal Web Site: http://sergeant.org/ **
>  \\//
>  //\\
> //  \\
> 

RE: Still bugs in Apache::Dispatch with .htaccess

[Geoffrey Young]

> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 11, 2000 11:57 AM
> To: Geoffrey Young
> Subject: RE: Still bugs in Apache::Dispatch with .htaccess
> 
> 
> On Mon, 11 Dec 2000, Geoffrey Young wrote:
> 
> >
> >
> > I've started poking around...
> >
> > in order to allow .htaccess configurations we have to be 
> able to accomodate:
> > /Foo/Bar/Baz/foo  where .htaccess lives in Foo:  Prefix +
> > Bar::Baz->foo()
> > /Foo/Bar/Baz/foo  where .htaccess lives in Bar:  Prefix 
> + Baz->foo()
> >
> > yuk.  with  you don't have to worry about the 
> left hand side...
> 
> OK, so how about a new directive: DispatchBase. If that is set, remove
> that from $r->filename, and use that as the base path. 
> Otherwise use the
> $r->location method.

yeah, I thought about that too - it would involve less overhead than
scanning for the location of the .htaccess file, but wouldn't be as friendly
as DispatchAccess On.

I also don't want to confuse people, though.  The issue here is 
v.  and not specifically .htaccess files (any more, at least :) -
applying this to a  could start to get obscure (as if it isn't
already :)

DispatchTrim "/usr/local/apache/htdocs/"  ?
DispatchBase (which is probably what I should have called DispatchISA) ?
DispatchDirectory ?

or do both that and have a .htaccess scan as well?

--Geoff


> 
> -- 
> 
> 
> /||** Director and CTO **
>//||**  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** Personal Web Site: http://sergeant.org/ **
>  \\//
>  //\\
> //  \\
> 

[DIGEST] mod_perl digest 12/3/2000

[Geoffrey Young]

--

  mod_perl digest
 
   December 3, 2000 - December 9, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o module announcements
  o mailing list highlights
  o news
  o FAQ of the week
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


module announcements

  o Apache::SSI 2.16 - implementation of Server Side Includes that 
provides a subclassable interface allowing you to define your
own SSI tags [7]

  o HTML-Embperl 1.3.0 - a module for embedding Perl code in HTML
pages that includes building pages/sites out of small reusable
objects/components and session handling [8]

  o Apache-Dispatch 0.08 - call PerlHandlers with the ease of
Registry scripts [9]

  o Apache::ASP 2.07 - provides an Active Server Pages port to for
Perl scripting only, and enables the development of dynamic web 
applications with session management and embedded perl code [10]


mailing list highlights

  o While not specifically for mod_perl, the first release of lingerd
- a daemon (service) designed to take over the job of TCP/IP 
lingering_closes - made its debut this week [11]

  o take23.org - one stop shopping for mod_perl news and info - also
made its debut this week [12]

  o Some debugging techniques and tools for people writing mod_perl
handlers were discussed [13]

  o For the security minded, running Apache using chroot can offer
another level of protection.  This thread contains some thoughts
as well as links to additional information [14]


news

  o Netcraft mod_perl statistics are out for September [15]
  1,524,620 Domains, 197,931 IP Addresses


FAQ of the week

  o What can be done to better advocate mod_perl?

Apparently, everyone has an opinion :)  There were several
threads this week that focused on mod_perl advocacy.  It all 
started (this time) with Stas sending out an RFC [16].  This
spawned 21 related threads (by my count).  The largest of these
is now 104 messages long [17].  Some of the more focused
departures are about
   easier installation [18]
   certification [19]
   object orientation [20]
Sorting through all these is an exercise left to the reader...


links

  o The Apache/Perl Integration Project [21]
  o mod_perl documentation [22]
  o mod_perl modules on CPAN [23]
  o mod_perl homepage [24]
  o mod_perl list archives [25]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://forum.swarthmore.edu/epigone/modperl/skiltehsmex
[8] http://forum.swarthmore.edu/epigone/modperl/joskumsteld
[9] http://forum.swarthmore.edu/epigone/modperl/mandquygri
[10] http://forum.swarthmore.edu/epigone/modperl/phinbliwhox
[11] http://forum.swarthmore.edu/epigone/modperl/queelahsteh
[12] http://forum.swarthmore.edu/epigone/modperl/glungrablar
[13] http://forum.swarthmore.edu/epigone/modperl/skingthendblex
[14] http://forum.swarthmore.edu/epigone/modperl/stimlorthen
[15] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97594404107042&w=2
[16] http://forum.swarthmore.edu/epigone/modperl/twimralnan
[17] http://forum.swarthmore.edu/epigone/modperl/sneflarskimp
[18] http://forum.swarthmore.edu/epigone/modperl/swarbrahox
[19] http://forum.swarthmore.edu/epigone/modperl/dumgexdwah
[20] http://forum.swarthmore.edu/epigone/modperl/prerdrerchul
[21] http://perl.apache.org
[22] http://perl.apache.org/#docs
[23] http://www.perl.com/CPAN-local/modules/by-module/Apache/
[24] http://www.modperl.com
[25] http://forum.swarthmore.edu/epigone/modperl/

RE: Still bugs in Apache::Dispatch with .htaccess

[Geoffrey Young]

> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 11, 2000 8:27 AM
> To: [EMAIL PROTECTED]
> Subject: Still bugs in Apache::Dispatch with .htaccess
> 
> 
> Sorry Geoff,
> 
> OK, the bug now is that the _translate_uri sub expects you to 
> be working
> with  rather than .htaccess. 

argh - I knew there was a reason I enforced DispatchPrefix from within a
 tag - I have all the memory of a bowling ball...

> It does this to do
> s/location/prefix/, which is why it doesn't work with .htaccess.
> 
> Now first of all, there's a bit of a security risk in there - 
> you're doing
> s/$location/$prefix/. Always *always* use \Q\E around those 
> if you don't
> want someone to be malicous.

right - I suppose I should be using \Q - I do, however, check for
metacharacters in the url as the (nearly) very first step:
  # if the uri contains any characters we don't like, bounce...
  # is this necessary?
  if ($uri =~ m![^\w/-]!) {
$log->info("\t$uri has bogus characters...")
   if $Apache::Dispatch::DEBUG;
$log->info("Exiting Apache::Dispatch");
return DECLINED;
  }

sufficient?

BTW, I return DECLINED often for scenarios like this within Dispatch, but
have contemplated recently returning NOT_FOUND...  opinions?  I don't want
to break existing behaviors for people...

> 
> Second, we want to get this working inside of .htaccess. My 
> thought as to
> how to do this is to set something defining where the directive is set
> when your config methods are called. So I'm assuming you can 
> get this from
> $parms->path(). Store this in the $cfg hash, and then in 
> _translate_uri
> do:
> 
> my $location = $r->location || $cfg->{'Path'};
> 
> Or something like that.

yeah, something like that might be the only alternative...  I'll have to
play with it... 

can you send me your .htaccess file - I may actually have some time in the
next day or so to try and figure this out...

> 
> Anyway, for now, back to normal handlers... :-)

bah :)

--Geoff
> 
> -- 
> 
> 
> /||** Director and CTO **
>//||**  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** Personal Web Site: http://sergeant.org/ **
>  \\//
>  //\\
> //  \\
> 

RE: RFC: mod_perl advocacy project resurrection

[Geoffrey Young]

> -Original Message-
> From: Ajit Deshpande [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 05, 2000 12:19 PM
> To: kevin montuori
> Cc: [EMAIL PROTECTED]
> Subject: Re: RFC: mod_perl advocacy project resurrection
> 
> 
> On Tue, Dec 05, 2000 at 10:51:08AM -0500, kevin montuori wrote:
> >   additionally, i think that some consideration should 
> be given to
> >   how mod_perl is packaged.  although it's well documented (and
> >   generally quite simple) there are three kits that need to be
> >   compiled (apache, perl, mod_perl) before the simplest handler
> >   can be tested.  i think to an applications programmer who's
> [..]
> 
> I think packaging is key here. For example If we can get 
> RedHat to package 
> the apache and mod_perl RPMs (albeit DSO) such that a basic 
> set of handlers
> and modules just *work*, I think we will be whole lot better off.

I think if we could all agree on a standard newbie package and get RedHat
engineers to agree to it it might go a long way...  I don't remember ever
seeing RedHat asking this list for advice on how it should package mod_perl
(Paul?)

not that they could ever really get everyone on the list to agree :)  but I
think EVERYTHING=1 and a static build would be a majority consensus.

--Geoff 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCE] Apache::Dispatch-0.08

[Geoffrey Young]

The URL

 
http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.08.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/G/GE/GEOFF/Apache-Dispatch-0.08.tar.gz
  size: 13499 bytes
   md5: 10f5b985b84aa98beb24807868e02851


This is a minor release - unless you need to use .htaccess files you can
take your time upgrading:

Changes:
0.08  12.04.2000
  - minor documentation additions and fixups
  - changed all directives so that they can be used from within
.htaccess files (suggested by Matt Sergeant)
  - removed extraneous SERVER_CREATE and SERVER_MERGE sections


for those of you who don't know what Apache::Dispatch is... from the README:

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 Regsitry scripts without having to load your httpd.conf
with a slurry of  tags.


I started some very preliminary benchmarking, the results of which look
promising and can be found in ToDo

--Geoff


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [DIGEST] mod_perl digest 11/26/2000

[Geoffrey Young]

> -Original Message-
> From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 04, 2000 7:48 AM
> To: '[EMAIL PROTECTED]'
> Subject: [DIGEST] mod_perl digest 11/26/2000
> 
> 
> 
> news
> 
>   o Netcraft statistics are out for November [15]
>  Apache 5% IIS 20.16%

whoops - nobody here would really believe that :)

  o Netcraft statistics are out for November [15]
 Apache 59.67% IIS 20.16%

sorry about the bogus links at the bottom of the page, too - I knew doing
this monday mornings before my coffee would catch up to me sooner or
later...  thanks to all those who caught the errors early :)

--Geoff


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[DIGEST] mod_perl digest 11/26/2000

[Geoffrey Young]

--

  mod_perl digest
 
   November 26, 2000 - December 2, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o module announcements
  o mailing list highlights
  o news
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


module announcements

  o No new modules this week, but we did see RFCs for
  Apache::DProf [7]
  Apache::Carp [8]


mailing list highlights

  o mod_proxy will upgrade your (non-caching) request headers to
HTTP/1.0 if the request is HTTP/0.9 before passing the request
off.  This can have unintended consequences if trying to use
Apache as a non-HTTP server. [9] [10]

  o IE has the annoying habit of sometimes ignoring the Content-Type
header and applying a content type appropriate to the file 
extension.  For example, a .pdf file sent with the header
Content-Type: application/pdf but generated via /foo.pl may
be interpreted incorrectly.  You can get around this by adding
the appropriate file extension as uri path info (eg foo.pl?.pdf)
of by using the header 
  Content-Disposition: inline; filename=foo.pdf [11]

  o Beware of reply-to-all - you may expose your secrets :) [12]

  o Some browsers support gzip encoding, even though they do not
send Accept-Encoding: gzip header.  Some send the proper header,
but cannot process certain gzip'ed requests.  Go figure [13]

  o Folks are throwing around the idea of an Apache::WebDAV [14]


news

  o Netcraft statistics are out for November [15]
 Apache 5% IIS 20.16%

  o Security Space November statistics [16]
 Apache 57.99% IIS 28.08%
 11.02% (150,158) of Apache servers are running mod_perl [17]


links

  o The Apache/Perl Integration Project [20]
  o mod_perl documentation [21]
  o mod_perl modules on CPAN [22]
  o mod_perl homepage [23]
  o mod_perl list archives [24] [25]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://forum.swarthmore.edu/epigone/modperl/lulskumzy
[8] http://forum.swarthmore.edu/epigone/modperl/prayswexwand
[9] http://forum.swarthmore.edu/epigone/modperl/shicluldwor
[10] http://forum.swarthmore.edu/epigone/modperl/jyclandlul
[11] http://forum.swarthmore.edu/epigone/modperl/glaxquumang
[12] http://forum.swarthmore.edu/epigone/modperl/boifandskang
[13] http://forum.swarthmore.edu/epigone/modperl/fronspeglend
[14] http://forum.swarthmore.edu/epigone/modperl/skalblerdbrim
[15] http://www.netcraft.com/survey
[16] http://www.securityspace.com/s_survey/data/index.html
[17] http://www.securityspace.com/s_survey/data/man.200011/apachemods.html
[18] http://perl.apache.org
[19] http://perl.apache.org/#docs
[20] http://www.perl.com/CPAN-local/modules/by-module/Apache/
[21] http://www.modperl.com
[22] http://forum.swarthmore.edu/epigone/modperl/
[23] http://archive.covalent.net/modperl/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Easy way to access PerlSetEnv from outside apache cycle?

[Geoffrey Young]

> -Original Message-
> From: Gedanken [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 01, 2000 3:46 PM
> To: [EMAIL PROTECTED]
> Subject: Easy way to access PerlSetEnv from outside apache cycle?
> 
> 
> 
[snip]

> 
> Is there any easy way to let this command line script patch into the
> variablespace created by the PerlSetEnv's? 

PerlSetEnv just sets environment variables, which you can access as normal
environment variables in your handler...

thus, just export what you need in your shell or tack stuff onto %ENV

--Geoff

 Did the original 
> designer see
> something over my head or was he/she on mod_crack?
> 
> -- 
> gedanken
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Apache::Dispatch directives

[Geoffrey Young]

forget that patch - it probably won't do what you want either...

I was mainly thinking about limiting the scope of DispatchPrefix  for
security reasons (keeping people from being sloppy)...

if you don't think this is too much of a concern, then perhaps I'll change
everything to OR_ALL?

--Geoff



> -Original Message-
> From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 01, 2000 2:24 PM
> To: 'Matt Sergeant'; [EMAIL PROTECTED]
> Subject: RE: Apache::Dispatch directives
> 
> 
> all options are RSRC_CONF | ACCESS_CONF except 
> DispatchPrefix, which is
> ACCESS_CONF...
> 
> my thought on making DispatchPrefix local only to directories was that
> Apache::Dispatch was specific to a  tag: other 
> options I thought
> could be applied globally, but you wouldn't want My::Handler 
> to resolve from
> /foo and /bar... but maybe you would?  I dunno...
> 
> anyway, I don't ordinarily use .htaccess, so I didn't test 
> Apache::Dispatch
> with them in mind...
> 
> what effect does .htaccess have on DIR_MERGE?
> 
> anyway, you can try this and see if it has hany ill effects - 
> I can't think
> of any.  DispatchFilter will have to stay the way it is, 
> though, because I
> didn't feel like writing a huge if/else block to capture all the
> possibilities of mixing PerlSetVar Filter On with DispatchFilter :)
> 
> Index: Makefile.PL
> ===
> RCS file: /usr/local/CVS/Apache-Dispatch/Makefile.PL,v
> retrieving revision 1.12
> diff -u -r1.12 Makefile.PL
> --- Makefile.PL 2000/11/06 16:30:07 1.12
> +++ Makefile.PL 2000/12/01 19:22:08
> @@ -14,7 +14,7 @@
>{ name => 'DispatchPrefix',
>  errmsg   => 'a class to be used as the base class', 
>  args_how => 'TAKE1',
> -req_override => 'ACCESS_CONF', },
> +req_override => 'OR_AUTHCFG', },
>  
>#--
># DispatchExtras defines the extra dispatch methods to enable
> @@ -22,7 +22,7 @@
>{ name => 'DispatchExtras',
>  errmsg   => 'choose any of: Pre, Post, or Error', 
>  args_how => 'ITERATE',
> -req_override => 'RSRC_CONF | ACCESS_CONF', },
> +req_override => 'OR_ALL', },
>  
>#--
># DispatchStat enables module testing and subsequent reloading
> @@ -30,7 +30,7 @@
>{ name => 'DispatchStat',
>  errmsg   => 'choose one of On, Off, or ISA',
>  args_how => 'TAKE1',
> -req_override => 'RSRC_CONF | ACCESS_CONF', },
> +req_override => 'OR_ALL', },
>  
>#--
># DispatchAUTOLOAD defines AutoLoader behavior
> @@ -38,7 +38,7 @@
>{ name => 'DispatchAUTOLOAD',
>  errmsg   => 'choose one of On or Off',
>  args_how => 'TAKE1',
> -req_override => 'RSRC_CONF | ACCESS_CONF', },
> +req_override => 'OR_ALL', },
>  
>#--
># DispatchISA is a list of modules your module should inherit from
> @@ -46,7 +46,7 @@
>{ name => 'DispatchISA',
>  errmsg   => 'a list of parent modules',
>  args_how => 'ITERATE',
> -req_override => 'RSRC_CONF | ACCESS_CONF', },
> +req_override => 'OR_ALL', },
>  
>#--
># DispatchFilter makes the dispatched handler Apache::Filter aware 
> 
> > -Original Message-
> > From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, December 01, 2000 1:55 PM
> > To: [EMAIL PROTECTED]
> > Subject: Apache::Dispatch directives
> > 
> > 
> >  do not seem to be allowed in .htaccess files. I don't 
> > see a reason for
> > this restriction, Geoff ???
> > 
> > Particularly, I want to just be able to say:
> > 
> > DispatchPrefix MyModule
> > 
> > in a .htaccess file and have it just work.
> > 
> > -- 
> > 
> > 
> > /||** Director and CTO **
> >//||**  AxKit.com Ltd   **  ** XML Application Serving **
> >   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
> >  // \\| // ** Personal Web Site: http://sergeant.org/ **
> >  \\//
> >  //\\
> > //  \\
> > 
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Apache::Dispatch directives

[Geoffrey Young]

all options are RSRC_CONF | ACCESS_CONF except DispatchPrefix, which is
ACCESS_CONF...

my thought on making DispatchPrefix local only to directories was that
Apache::Dispatch was specific to a  tag: other options I thought
could be applied globally, but you wouldn't want My::Handler to resolve from
/foo and /bar... but maybe you would?  I dunno...

anyway, I don't ordinarily use .htaccess, so I didn't test Apache::Dispatch
with them in mind...

what effect does .htaccess have on DIR_MERGE?

anyway, you can try this and see if it has hany ill effects - I can't think
of any.  DispatchFilter will have to stay the way it is, though, because I
didn't feel like writing a huge if/else block to capture all the
possibilities of mixing PerlSetVar Filter On with DispatchFilter :)

Index: Makefile.PL
===
RCS file: /usr/local/CVS/Apache-Dispatch/Makefile.PL,v
retrieving revision 1.12
diff -u -r1.12 Makefile.PL
--- Makefile.PL 2000/11/06 16:30:07 1.12
+++ Makefile.PL 2000/12/01 19:22:08
@@ -14,7 +14,7 @@
   { name => 'DispatchPrefix',
 errmsg   => 'a class to be used as the base class', 
 args_how => 'TAKE1',
-req_override => 'ACCESS_CONF', },
+req_override => 'OR_AUTHCFG', },
 
   #--
   # DispatchExtras defines the extra dispatch methods to enable
@@ -22,7 +22,7 @@
   { name => 'DispatchExtras',
 errmsg   => 'choose any of: Pre, Post, or Error', 
 args_how => 'ITERATE',
-req_override => 'RSRC_CONF | ACCESS_CONF', },
+req_override => 'OR_ALL', },
 
   #--
   # DispatchStat enables module testing and subsequent reloading
@@ -30,7 +30,7 @@
   { name => 'DispatchStat',
 errmsg   => 'choose one of On, Off, or ISA',
 args_how => 'TAKE1',
-req_override => 'RSRC_CONF | ACCESS_CONF', },
+req_override => 'OR_ALL', },
 
   #--
   # DispatchAUTOLOAD defines AutoLoader behavior
@@ -38,7 +38,7 @@
   { name => 'DispatchAUTOLOAD',
 errmsg   => 'choose one of On or Off',
 args_how => 'TAKE1',
-req_override => 'RSRC_CONF | ACCESS_CONF', },
+req_override => 'OR_ALL', },
 
   #--
   # DispatchISA is a list of modules your module should inherit from
@@ -46,7 +46,7 @@
   { name => 'DispatchISA',
 errmsg   => 'a list of parent modules',
 args_how => 'ITERATE',
-req_override => 'RSRC_CONF | ACCESS_CONF', },
+req_override => 'OR_ALL', },
 
   #--
   # DispatchFilter makes the dispatched handler Apache::Filter aware 

> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 01, 2000 1:55 PM
> To: [EMAIL PROTECTED]
> Subject: Apache::Dispatch directives
> 
> 
>  do not seem to be allowed in .htaccess files. I don't 
> see a reason for
> this restriction, Geoff ???
> 
> Particularly, I want to just be able to say:
> 
> DispatchPrefix MyModule
> 
> in a .htaccess file and have it just work.
> 
> -- 
> 
> 
> /||** Director and CTO **
>//||**  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** Personal Web Site: http://sergeant.org/ **
>  \\//
>  //\\
> //  \\
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Order of Installation!!!

[Geoffrey Young]

> -Original Message-
> From: Edmar Edilton da Silva [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 01, 2000 12:41 PM
> To: [EMAIL PROTECTED]
> Subject: Order of Installation!!!
> 
> 
> Hi all,
> I have installed on my machine the following modules:
> apache 1.3.12-2
> mod_perl 1.21-10
> DBI 1.13-1
> DBD::Oracle 1.03
> Apache::DBI 0.86-1

looks like you are using RPMs?  take a look at
http://perl.apache.org/guide/install.html#A_word_on_mod_perl_RPM_packages

> 
> The problem is that when I run a perl script under mod_perl, the
> response time is almost the same than the response time of the same
> script being ran without the mod_perl module. And I know that mod_perl
> was correctly installed. 

you sure about that?

http://perl.apache.org/guide/install.html#How_can_I_tell_whether_mod_perl_


> Another problem is that I can not 
> open database
> connections when the WWW server starts because happen an error in the
> child processes of the apache. 

if you are using RedHat RPMs with Apache::DBI there was a problem with the
dist from 6.0 or 6.1 (or 6.2 - call it all of 6 :)

try to boil it down some - make sure that DBI works outside of apache, then
read the Apache::DBI docs and look into whether it is caching your
connections, then try to open connections with connect_on_init...

HTH

--Geoff

> I think can there is some 
> problem in the
> installation or configuration of the modules.
> Did the order for installing of the modules do any difference?
> If someone help me will be very appreciated. Thanks...
> 
> --
> 
> Edmar Edilton da Silva
> Bacharel em Ciência da Computacão - UFV
>   Mestrando em Ciência da Computacão - UNICAMP
> 
> 
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: More Speed -> mod_perl Module for HTML Compression

[Geoffrey Young]

> -Original Message-
> From: Wiswell, Virginia [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 30, 2000 2:52 PM
> To: 'Geoffrey Young'; 'Nigel Hamilton'; mod_perl list
> Subject: RE: More Speed -> mod_perl Module for HTML Compression 
> 
> 
>  
> > there's mod_gzip, available from
> > http://www.remotecommunications.com/apache/mod_gzip/
> > which I've played with and looks pretty good
> > 
> > or Apache::Compress, available from CPAN, which also works 
> > rather nicely
> > (and is Apache::Filter ready, so you can chain PerlHandlers into it)
> > 
> > just beware that not all browsers that claim to accept gzip 
> > compression
> > actually do...
> > 
> 
> geoff - is there any documentation as to which browsers will 
> or will not
> handle gzip compression?

I don't think so - from lurking around mod_gzip, I think the folks at Remote
Communications have a pretty good grip on what _really_ accepts compression
and what doesn't (or so I've gathered), but I don't think it's documented
anywhere authoritative (that I know about, at least)

a look at the mod_gzip code
(http://12.17.228.52/mod_gzip/src/1.3.14.3/mod_gzip.txt search for 'Basic
sanity checks completed and we are still here') lists lots of
Accept-Encoding problems, but only mention Nescape 4.75 on unix by name...

HTH

--Geoff

> 
> thanks.
> 
> virginia
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: More Speed -> mod_perl Module for HTML Compression

[Geoffrey Young]

> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 30, 2000 2:33 PM
> To: Geoffrey Young
> Cc: 'Nigel Hamilton'; mod_perl list
> Subject: RE: More Speed -> mod_perl Module for HTML Compression
> 
> 
> > just beware that not all browsers that claim to accept gzip 
> compression
> > actually do...
> 
> No its the other way around. Not all browsers that can accept 
> gzip send
> out Accept-Encoding: gzip. Notably early versions of IE4.

I was basing that on discussions on the mod_gzip list and the following
(from the mod_gzip code)

 * 5. Many browsers ( such as Netscape 4.75 for UNIX ) are unable
 *to handle Content-encoding only for specific kinds of HTML
 *transactions such as Style Sheets even though the browser
 *says it is HTTP 1.1 compliant and is suppying the standard
 *'Accept-encoding: gzip' field. According to the IETF
 *specifications any user-agent that says it can accept
 *encodings should be able to do so for all types of HTML
 *transactions but this is simply not the current reality.
 *Some will, some won't... even if they say they can.

I don't have any first hand experience with it, though...

--Geoff


> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: More Speed -> mod_perl Module for HTML Compression

[Geoffrey Young]

there's mod_gzip, available from
http://www.remotecommunications.com/apache/mod_gzip/
which I've played with and looks pretty good

or Apache::Compress, available from CPAN, which also works rather nicely
(and is Apache::Filter ready, so you can chain PerlHandlers into it)

just beware that not all browsers that claim to accept gzip compression
actually do...

HTH

--Geoff

> -Original Message-
> From: Nigel Hamilton [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 30, 2000 1:14 PM
> To: mod_perl list
> Subject: More Speed -> mod_perl Module for HTML Compression 
> 
> 
> Hi,
>   I'm trying to reduce the amount of data sent from server to
> browser by using compression ---> hopefully accelerating the time to
> serve a page.
> 
>   Does anyone know of a mod_perl module that compresses HTML and a
> companion Javascript procedure that decompresses the data on the
> client-side?
> 
>   I know there are Gzip modules that zip files on the way back to
> the browser ... but I'm after something that zips on the server and  
> decompresses transparently in Javascript across all browsers. 
> Ideally I
> want to do: document.write(uncompressed-contents) in Javascript on the
> client-side.
> 
>   Has anyone come up with something for this?
> 
>   Also for average-sized files, does the time taken to perform the
> decompression/compression negate any speed increase gained by 
> reduced file
> size?
> 
> Nige
> 
> Nigel Hamilton
> __
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: 1.24 to 1.24_01 spinning httpds on startup (solved)

[Geoffrey Young]

I think I remember a thread on dev that talked about this...

http://archive.covalent.net/modperl-cvs/2000/09/0050.xml was maybe the cause
of the change in behavior?

HTH

--Geoff



> -Original Message-
> From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 30, 2000 3:12 AM
> To: Michael J Schout
> Cc: [EMAIL PROTECTED]
> Subject: Re: 1.24 to 1.24_01 spinning httpds on startup (solved)
> 
> 
> On Tue, 28 Nov 2000, Michael J Schout wrote:
> 
> > 
> > $PerlRequire = '/some/path/file.pl';
> > 
> > 
> > Changing this to:
> > 
> > 
> > push @PerlRequire, '/some/path/file.pl';
> > 
> > 
> > Fixed the problem under 1.24_01 for me and everything 
> appears to be kosher now.
> > 
> > Maybe the behavior of PerlRequire has changed between 1.24 
> and 1.24_01?  
> 
> Hmn... Happens to me too after upgrading from 1.24 to 1.24_01
> (Apache 1.3.12).
> 
> #0  0x400fe7f9 in _IO_vfprintf (s=0xbf800474, 
> format=0x81433b5 "_<(eval %lu)", ap=0xbf80053c) at
> vfprintf.c:209
> #1  0x4010c0b3 in _IO_vsprintf (string=0xbf80056c "", 
> format=0x81433b5 "_<(eval %lu)", args=0xbf80053c) at
> iovsprintf.c:47
> #2  0x4010676f in sprintf (s=0xbf80056c "", 
> format=0x81433b5 "_<(eval %lu)") at sprintf.c:38
> #3  0x811037c in Perl_pp_entereval ()
> #4  0x80c9997 in perl_eval_sv ()
> #5  0x808b9ee in perl_require_module ()
> #6  0x808a126 in perl_section ()
> #7  0x8089fac in perl_section_self_boot ()
> #8  0x808816a in perl_cmd_require ()
> #9  0x809ffd7 in ap_clear_module_list ()
> #10 0x80a0423 in ap_handle_command ()
> #11 0x8089b34 in perl_handle_command ()
> #12 0x808a445 in perl_section ()
> #13 0x8089fac in perl_section_self_boot ()
> #14 0x808816a in perl_cmd_require ()
> #15 0x809ffd7 in ap_clear_module_list ()
> #16 0x80a0423 in ap_handle_command ()
> #17 0x8089b34 in perl_handle_command ()
> #18 0x808a445 in perl_section ()
> #19 0x8089fac in perl_section_self_boot ()
> [... repeating ...]
> 
> I don't see any changes to the Perl configure code...
> 
> 
>  $PerlRequire = '/tmp/startup.pl';
> 
> 
> $ cat /tmp/startup.pl
> warn "works?";
> 1;
> 
> 
>   - ask
> 
> -- 
> ask bjoern hansen - 
> more than 70M impressions per day, 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Apache config control using Perl?

[Geoffrey Young]

> -Original Message-
> From: Ben Heuer [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 30, 2000 2:35 AM
> To: modperl
> Subject: Apache config control using Perl?
> 
> 
> Hello:
[snip]

> 2. How can I customise the line that gets added to the 
> logs/error.log file?

write a PerlLogHandler and complete control is within your reach...

see www.modperl.com for the Eagle book, complete with examples :)

HTH

--Geoff

> Can I use somesort of the CustomLog for this? I need to 
> prefix every line
> wiht the name of my website, and to customize the error 
> messages. Can this
> be done?
> 
> I would appreciate any help.
> 
> Thanks!
> Ben
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[DIGEST] mod_perl digest 11/19/2000

[Geoffrey Young]

--

  mod_perl digest
 
   November 19, 2000 - November 25, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o module announcements
  o mailing list highlights
  o FAQ of the week
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


module announcements

  o HTTP::GHTTP 1.0 - a lightweight HTTP client library based on the
gnome libghttp library [7]


mailing list highlights

  It was another relatively slow week...

  o Some discussion on the future of libapreq - such as possible ToDo
items, various bugs that need attention, and the possibility of a
new maintainer - has been started [8]

  o SDBM_File, BerkeleyDB, and DB_File are compared in an interesting
thread discussing a new caching module MLDBM::Sync [9] [10] [11]

  o A patch was submitted to DBI::ProxyServer and Net::Daemon which
together allow for a tricky DBI connection pooling scheme based
on DBI::connect_cached() [12]

  o A minor bug was found in Apache::test [13]


FAQ of the week

  o After restarting Apache I can't see the changes I made to my
handlers or other perl modules - how do I get mod_perl to see
the changes?

Sending Apache the HUP signal, via apachectl restart or kill -HUP,
only reads changes to your httpd.conf file - it does not refresh
content of the perl modules themselves.  This makes module
development a bit more tedious so, of course, there are some easy
solutions available.  Apache::StatINC is included in the base
mod_perl distribution, but is not recommended for production use
due to its rather large overhead.  Apache::Reload, available on 
CPAN, is a modified version of Apache::StatINC that allows for
greater control over reload behavior.  The PerlFreshRestart
directive is also available, but frequently reported to be less 
than fully stable.


links

  o The Apache/Perl Integration Project [14]
  o mod_perl documentation [15]
  o mod_perl modules on CPAN [16]
  o mod_perl homepage [17]
  o mod_perl list archives [18] [19]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://forum.swarthmore.edu/epigone/modperl/horgunkhon
[8] http://forum.swarthmore.edu/epigone/modperl/clendcharal
[9] http://forum.swarthmore.edu/epigone/modperl/rixfrasmoi
[10] http://forum.swarthmore.edu/epigone/modperl/syspexclar
[11] http://forum.swarthmore.edu/epigone/modperl/stultwelddwimp
[12] http://forum.swarthmore.edu/epigone/modperl/clojixbang
[13] http://forum.swarthmore.edu/epigone/modperl/maysolsnimp
[14] http://perl.apache.org
[15] http://perl.apache.org/#docs
[16] http://www.perl.com/CPAN-local/modules/by-module/Apache/
[17] http://www.modperl.com
[18] http://forum.swarthmore.edu/epigone/modperl/
[19] http://archive.covalent.net/modperl/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Using the same mod_perl cgi-bin by 2 domains mapped to the same IP

[Geoffrey Young]

> -Original Message-
> From: David Jourard [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 22, 2000 11:54 AM
> To: [EMAIL PROTECTED]
> Subject: Using the same mod_perl cgi-bin by 2 domains mapped 
> to the same
> IP
> 
[snip]
> 
> I'd like to get it so that both domain names can access the 
> same cgi-bin 
> configured to run as mod_perl.
> 
> It works well in one but I get an Undefined for the other (or 
> vice versa) 
> since its probably using scripts compiled for that child 
> process from the 
> other.
> 
> eg.
> 
> Undefined subroutine 
> &Apache::example2_2ecom::cgi2dbin::myscript_2ecgi::MyFunction

try setting
$Apache::Registry::NameWithVirtualHost = 0;

in your startup.pl

and read
http://perl.apache.org/guide/config.html#A_Script_From_One_Virtual_Host_C

should do the trick...

--Geoff

> 
> Thank-you
> David J.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[DIGEST] mod_perl digest 11/12/2000

[Geoffrey Young]

--

  mod_perl digest
 
   November 12, 2000 - November 18, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o module announcements
  o mailing list highlights
  o FAQ of the week
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


module announcements

  o HTML-Embperl 1.3b7 - a module for embedding Perl code in HTML 
pages that includes buliding pages/sites out of small reusable
objects/components and session handling [7]


mailing list highlights

  o The call for papers for ApacheCon US 2001 is upon us [8]

  o A very detailed post was put forward describing the (current, but
previously undocumented) behavior of mod_proxy. [9]  This entire
thread is definitely worth the time.

  o A rather lengthy thread on trying to install mod_perl on 
Alpha/Tru64 should prove enlightening for those who are trying to
get started on this platform. [10]

  o Using Apache::File->tmpfile() with $r->send_fd requires calling
seek $fh, 0, 0; prior to calling $r->send_fd.  In a follow up, the
differences between seek and sysseek, open and sysopen were 
explained. [11]

  o mod_perl security discussed from the standpoint of allowing
thousands of developers access to mod_perl's power [12]

  o There may be a bug in mod_perl  sections that does not
allow for duplicate directives within the same location [13] [14]


links

  o The Apache/Perl Integration Project [15]
  o mod_perl documentation [16]
  o mod_perl modules on CPAN [17]
  o mod_perl homepage [18]
  o mod_perl list archives [19] [20]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://forum.swarthmore.edu/epigone/modperl/vaxquale
[8] http://forum.swarthmore.edu/epigone/modperl/blahphoiben
[9] http://forum.swarthmore.edu/epigone/modperl/limpbandming
[10] http://forum.swarthmore.edu/epigone/modperl/maxminsni
[11] http://forum.swarthmore.edu/epigone/modperl/gruldendsten
[12] http://forum.swarthmore.edu/epigone/modperl/yehsworgen
[13] http://forum.swarthmore.edu/epigone/modperl/zhaxyinggrimp
[14] http://forum.swarthmore.edu/epigone/modperl/zheewhahle
[15] http://perl.apache.org
[16] http://perl.apache.org/#docs
[17] http://www.perl.com/CPAN-local/modules/by-module/Apache/
[18] http://www.modperl.com
[19] http://forum.swarthmore.edu/epigone/modperl/
[20] http://archive.covalent.net/modperl/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: security suggestion

[Geoffrey Young]

> -Original Message-
> From: Adam Prime [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 16, 2000 11:46 AM
> To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Cc: Geoffrey Young
> Subject: RE: security suggestion
> 
> 
> The servers that had apache on them for users when i was at 
> school didn't
> even allow normal cgi, so i have no idea how one would approach doing
> something like this with mod_perl.

I think that's the issue...

I think my last message was misinterpreted.

I do understand why you would _want_ to have the ability to restrict things
the way richard suggests, I just don't think it is possible - there would be
far too many variables to control (PerlSetEnv, Perl*Handler 'sub {}',
, push_handler(), checking PERL5LIB, etc...)

but hey, that's just me.  if someone is brilliant enough to figure it all
out, kudos...

I think I'm done with this one...

--Geoff

RE: security suggestion

[Geoffrey Young]

> -Original Message-
> From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 16, 2000 10:11 AM
> To: [EMAIL PROTECTED]
> Cc: Geoffrey Young
> Subject: Re: security suggestion
> 
> 
> Following up on the security suggestion (I'm actually responding to
> private mail, so I'll just quote the person who wrote to me without
> giving a name) -
> 
> > Of course you can do this in an .htaccess file, too:
> >
> > 
> >   arbitrary perl code...
> > 
> 
> I'd argue that people shouldn't be able to do that - unless, 
> of course,
> they can ExecCGI.
> 
> The general idea is this:  Regular users without ExecCGI may have good
> reason to say things like,
> 
>   PerlAuthenHandler Apache::SomeNewAuthModule

but what about 
  PerlSetEnv PERL5LIB '/my/lib/'
  PerlAuthenHandler My::Handler

there's nothing that says an AuthenHandler has to authenticate :)

maybe it would be possible to limit

PerlAuthenHandler 'sub {do something desctructive};'

via a directive, but this is mod_perl - I can't see how you would be able to
allow good activity without there being some way around it for destructive
types...

at least not in a generic sense - you could write an Init handler that
pushes Your::Validator to the front of each phase which runs all configured
handlers through various checks (of course one that seemed valid could push
another bad handler to the stack on the fly)

see what I mean - protection is not guaranteed...


> Although we want those users to have access to these modules 
> (and to the
> added functionality they bring), we may not want them to be able to
> execute arbitrary Perl code.

PERL_SECTIONS=0 at build time can deactivate this across the board

--Geoff
 

RE: database access

[Geoffrey Young]

> -Original Message-
> From: Gunther Birznieks [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 16, 2000 4:04 AM
> To: Les Mikesell; [EMAIL PROTECTED]
> Cc: Tim Bunce; Aaron; [EMAIL PROTECTED]
> Subject: Re: database access
> 
> 
> 3. As a plug, I had also suggested a couple years ago that I 
> would like the 
> feature to be able to specifically not having the ping() method by 
> Apache::DBI if the database had already been pinged within a 
> set period of 
> time.
> 

Apache::DBI->setPingTimeOut($data_source, $timeout)

no?

I similarly pointed out last last year that there is a (small) bug in
Apache::DBI that when you want it to ping _every_ time it won't if two pings
are in the same 'second' due to the granularity of time() (ie, a content
handler and log handler that access the db within one second of eachother,
but in separate phases).

--Geoff

RE: AuthCookie solution

[Geoffrey Young]

> -Original Message-
> From: Michael [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 15, 2000 10:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: AuthCookie solution
> 
> 
> a little off the subject, but close.
> 
> it the pointer for login is a complete URL ie http://foo.com/login.pl
> then the $r->prev-args; seem to get lost. There is real application 
> for this sort of thing and I would like to figure out how to make it 
> work. Any ideas why it does not?

$r->prev() only knows about the previous internal redirect.
$r->header_out(Location => 'http://foo.com/login.pl'); 
results in a full redirect (ie a new request)

as an aside, I've found it safer to when using $r->prev to code like

my $query = $r->prev ? $r->prev->args : $r->args;

because $r->prev is undefined on $r->is_initial_req() which leads to runtime
errors
(beware of my $x if 0 coding, too :)

depends on your situation, though - YMMV...

--Geoff

> 
> Michael
> [EMAIL PROTECTED]
> 

RE: Environment configuration problems

[Geoffrey Young]

 
try using a startup.pl to pre-load DBD::Oracle (and 
everything else while you're at it) and set these environment variables from 
within a BEGIN block there.
 
I've found that this, along with PerlSetEnv, works fine 
on Linux.
 
if that fails, try a BEGIN block in each script as 
well...
 
HTH
 
--Geoff

  -Original Message-From: Hughes, Ralph 
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, November 16, 2000 8:00 
  AMTo: ModPerl (E-mail)Subject: Environment configuration 
  problems
  OK,
  I've 
  tried everything I can think of and I'm still having environment configuration 
  problems.
   
  I 
  have a series of scripts that access an Oracle database.  At a minimum, 
  two environment variables need to be set up for this; ORACLE_HOME and 
  LD_LIBRARY_PATH (must include $ORACLE_HOME/lib)
  I 
  set both of these in the httpd.conf file for both the CGI and mod_perl 
  environment using using SetEnv and PerlSetEnv respectively.  Looking at 
  the environment using /perl-status shows them set 
properly.
   
  Now, when I try to kick hit one of these via mod_perl, I 
  consistently get a 'failed compilation' error when the script attempts to 
  hook up to the database.  THE EXACT SAME SCRIPT will run fine as a plain 
  old CGI. 
   
   
  If I 
  shutdown the web server, set ORACLE_HOME and LD_LIBRARY_PATH in my environment 
  (root's environment actually) and restart Apache, the mod_perl references 
  start working fine.
  Is 
  there some strangeness in my current version of Apache that only allows 
  environment variables to be set for mod_perl *if* they are set in the Apache 
  startup environment first?
   
  I'm currently running Apache 1.3.12 on RedHat 
  6.0 (2.2.14) with mod_perl 1.24 build on Perl 5.00503.  Apache::DBI 
  0.87 is loaded along with DBI 1.14.
   
  Obviously the workaround for the time being is 
  to start up the server manually, but this DOES NOT help matters if the server 
  has to reboot for some reason.
  One other thing, I have an almost identical 
  configuration running on two other servers, and it seems to run fine.  
  The differences being the Linux version (Mandrake 7.0 vice RedHat) on one and 
  Apache 1.3.9 on the other.  I've 'diffed' everything I can think of and 
  just can't find the problem
   
  I'm certain that I have just missed *one 
  little line* in a config script, but try as I might, I can't find 
  it.
   
  Thanks for the 
help!
  - Ralph Hughes    
      [EMAIL PROTECTED]Sr. Systems 
  Engineer    
  334-260-3200Anteon 
  Corp.    
  DSN 596-5631Montgomery, 
  AL
   

RE: [RFC] Apache::Expires

[Geoffrey Young]

> -Original Message-
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 15, 2000 6:19 PM
> To: Geoffrey Young
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: [RFC] Apache::Expires
> 
> 
> On Wed, 15 Nov 2000, Geoffrey Young wrote:
> > I was wondering if anyone has some experience with expire 
> headers for
> > dynamic documents - kinda like mod_expires but for dynamic stuff.
> 
> We do this, and let mod_proxy use our headers to control its cache and
> handle If-Modified requests.

I guess I was thinking about sans proxy...

> 
> Um, it's pretty easy:
> 
> my $last_mod = time;
> my $expires  = time + 360; # expires in one hour
> 
> $r->header_out('Expires'   => Apache::Util::ht_time($expires));
> $r->header_out('Last-Modified' => 
> Apache::Util::ht_time($last_modified));
> 
> Or did you have something different in mind?

maybe... I might not have my head in the right place, though...

it's the lack of a 304 that's bothering me (today :)

If I just put your lines into a handler I get this from netscape:
  If-Modified-Since => Thu, 16 Nov 2000 12:48:04 GMT; length=1150

but, since there is no modification time for the 'document' to compare to
locally, 
my headers out are:

  Expires => Thu, 16 Nov 2000 12:56:45 GMT
  Last-Modified => Thu, 16 Nov 2000 12:50:45 GMT

with status 200 since the document was (again) generated (with new headers).

whereas for static documents, I see:
  If-Modified-Since => Wed, 15 Nov 2000 14:45:13 GMT; length=2057

and a 304 out that contains:
  Last-Modified => Wed, 15 Nov 2000 14:45:13 GMT
  ETag => "20f73-809-3a12a179"


I guess what I am really after is intercepting the If-Modified-Since tag and
return a 304 prior to content generation - maybe in a fixup handler...  I
think it is the entity tag stuff that is starting to throw me, too...

make sense?  It's a new day (but before my coffee) so who knows...

thanks for the input

--Geoff



> 
> - Perrin
> 

RE: [ANNOUNCE] ApacheCon USA 2001: Call For Papers

[Geoffrey Young]

> 
> Is there a way of doing mod_rewrite maps in perl?
> 

I suspect that there is little, if anything, you can do with mod_rewrite
that you can't do with a (sufficiently complex, somewhat magical)
PerlTransHandler...

Perhaps that would make for a good talk ;)

--Geoff

RE: [RFC] Apache::Expires

[Geoffrey Young]

> -Original Message-
> From: Bill Moseley [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 15, 2000 1:12 PM
> To: Geoffrey Young; '[EMAIL PROTECTED]'
> Subject: Re: [RFC] Apache::Expires
> 
> 
> At 10:26 AM 11/15/00 -0500, Geoffrey Young wrote:
> >hi all...
> >
> >I was wondering if anyone has some experience with expire headers for
> >dynamic documents - kinda like mod_expires but for dynamic stuff.
> 
> Geoff,
> 
> Are you thinking about client/browsers or proxy caching with regard to
> this?  Or does it matter?

I was thinking about client/browser stuff specifically, but I guess properly
formed headers apply to both :)

> 
> I currently use Last-modified and Content-length headers in my dynamic
> content that doesn't change much, but I've never considered 
> using Expires,
> but maybe it's because I'm not fully up on what help Expires does.

I keep forgetting that Expires is _supposed_ to be a proxy thing - the
official MS documentation says that MSIE caches based on Expires, though.
(http://support.microsoft.com/support/kb/articles/Q234/0/67.ASP)

I dunno about the rest...

--Geoff

> 
> I have assumed that most browsers cache my documents and 
> don't re-request
> them in their current session
> so am I correct that Expires 
> would only help
> for cases of browsers/clients that return to the page sometime in the
> future yet before the document Expires, and after closing 
> their browser?  I
> wonder how to determine how many requests that would save.
> 
> Also, if a cached document is past its Expired time, does 
> that force the
> client to get a new document, or can it still use If-Modified-Since?
> mod_expires indicates that a new document must be loaded, but RFC 2616
> indicates that it can use If-Modified-Since (who know what 
> the clients will
> do).
> 
> I should know this too, but what effect does the presence of 
> a query string
> in the URL have on this?
> 
> 
> Bill Moseley
> mailto:[EMAIL PROTECTED]
> 

RE: [RFC] Apache::Expires

[Geoffrey Young]

> -Original Message-
> From: Robin Berjon [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 15, 2000 12:19 PM
> To: Geoffrey Young
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: [RFC] Apache::Expires
> 
> 
> At 11:17 15/11/2000 -0500, Geoffrey Young wrote:
> >> easy to get mixed up in the details. I think Andreas wrote 
> >> something about
> >> all those issues last year, but I can't track it down right now.
> >
> >I think he wrote the section in the guide on headers - that 
> will definitely
> >help sort things out...
> 
> Ah, yes, in a place that obvious I had no chance of finding it ;)
> 
> >say you want to cache a dynamic document for a week from 
> creation - how do
> >you define when the week started?
> 
> You mean if say, on tuesday a document is generated and says 
> it will expire
> in a week, if it is rerequested on friday it will still need to say it
> expires the following tuesday right ? 

something like that...  for instance, using mod_expires you can specify a
one week from modification time for expiration.  that's more difficult to do
with dynamic stuff since you don't have a start point (the 'document' is
modified on every access).

I was thinking that to specify a one week expiration date would set the
Expires header (or Last-Modified or whatever) to "last monday + one week".
documents created on friday only really get 3 days instead of a week, but...

similarly for months, years, days, etc...

you loose true granularity of control (?) but gain some sort of caching this
way.  I dunno...

> That would require persistence,
> probably a db or dbm.

yeah, except that I suspect the overhead of that would be just as bad as the
processing to create the document in the first place... 

--Geoff


> 
> -- robin b.
> I don't suffer from insanity. I enjoy every minute of it. 
> 

RE: [RFC] Apache::Expires

[Geoffrey Young]

> -Original Message-
> From: Robin Berjon [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 15, 2000 10:43 AM
> To: Geoffrey Young
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: [RFC] Apache::Expires
> 
> 
> At 10:26 15/11/2000 -0500, Geoffrey Young wrote:
> >anyone else see an interest in an Apache::Expires (or 
> whatever)?  Is there
> >something out there already?  I was thinking of working on 
> it if there is
> >nothing out there, but it would require lots of RFC reading 
> and wrestling
> >with stuff like entity tags...
> 
> It would definitely be interesting to provide an easy to use API to
> expiration and caching (at least one that would cover common 
> needs), it's
> easy to get mixed up in the details. I think Andreas wrote 
> something about
> all those issues last year, but I can't track it down right now.

I think he wrote the section in the guide on headers - that will definitely
help sort things out...

the more I think about it, thoug, I think it will be quite difficult.

say you want to cache a dynamic document for a week from creation - how do
you define when the week started?

maybe some compromises will be needed, like generically saying "months start
at 1" and "weeks start at sunday", etc...

just thinking out loud...

--Geoff



> 
> -- robin b.
> Always remember you're unique just like everyone else. 
> 

[RFC] Apache::Expires

[Geoffrey Young]

hi all...

I was wondering if anyone has some experience with expire headers for
dynamic documents - kinda like mod_expires but for dynamic stuff.

why?  well, say I have a handler that creates, say, a css document on the
fly based upon fields in a database.  the css contents won't change
regularly (if ever) but every request results in dynamic processing.
Wouldn't it be nice to be able to cache dynamic results if I say it's ok?  

(yes, one could just spit out a static document weekly or whatever, but
that's not the point of this discussion, ok :)

anyone else see an interest in an Apache::Expires (or whatever)?  Is there
something out there already?  I was thinking of working on it if there is
nothing out there, but it would require lots of RFC reading and wrestling
with stuff like entity tags...

comments/experiences welcome...

--Geoff

RE: [ANNOUNCE] ApacheCon USA 2001: Call For Papers

[Geoffrey Young]

> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 14, 2000 12:05 PM
> To: Greg Cope
> Cc: mod_perl list
> Subject: Re: [ANNOUNCE] ApacheCon USA 2001: Call For Papers

> 
> > 
> > If any one is interested I could do something on Session 
> Manager - which
> > I've been looking at rewriting in C - but I have to learn C 
> at the same
> > time so its very slow 
> > 
> 
> Inline.pm!

you have any experience with this?  I forget where I read the article (TPJ?)
but it looks really cool...

--Geoff

> 
> -- 
> 
> 
> /||** Director and CTO **
>//||**  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** Personal Web Site: http://sergeant.org/ **
>  \\//
>  //\\
> //  \\
> 

RE: [ANNOUNCE] ApacheCon USA 2001: Call For Papers

[Geoffrey Young]

> -Original Message-
> From: Robin Berjon [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 14, 2000 7:59 AM
> To: Stas Bekman
> Cc: mod_perl list
> Subject: Re: [ANNOUNCE] ApacheCon USA 2001: Call For Papers
> 
> 
> At 11:22 14/11/2000 +0100, Stas Bekman wrote:
> >Just as with TPC our aim is to have a full double room track 
> for mod_perl
> >for all 3 days. So make sure that you submit enough mod_perl 
> material, so
> >we will have it full.
> 
> I have some experience speaking before a crowd at conferences 
> (though not
> at technical ones) or on stage and I think I know mod_perl 
> enough to be
> able to write about several aspects of using it. The one 
> thing I'm missing
> is inspiration :) Are there any subjects that desperatly beg 
> to be talked
> about but have no writer/speaker ?

well, Stas and Nathan submitted suggestions in an earlier email.  judging
from attendence last year in Orlando, I can see that the interest in getting
started with mod_perl was HUGE.  Thus, I submitted a proposal (two parts,
actually) that addresses that population - into to handlers, request cycle,
Apache API, migrating from Registry to handlers (Apache::Dispatch comes to
mind), etc... 

I think there is room, however, for more stuff like that.  In particular, a
presentation of templating techniques is very important for people to
understand so that they can make informed decisions about moving away from
bloat like CGI.pm (no flames, please) and improve the maintainability of
their application.

Personally, my C is very weak - I have wanted to see something about how
mod_perl _really_ ties in with Apache for a while now.  Not just the basic
XS stuff (though there is nothing basic about it) but perhaps detail enough
to add a new Perl* directive without using Apache::ModuleConfig.  Power user
stuff - maybe not that appropriate since mod_perl 2.0 awaits, but I 
would find it interesting anyway.

--Geoff
 

> 
> -- robin b.
> Immature poets imitate, mature poets steal. -- T.S. Eliot
> 

[DIGEST] mod_perl digest 11/5/2000

[Geoffrey Young]

--

  mod_perl digest
 
   November 5, 2000 - November 11, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o module announcements
  o mailing list highlights
  o FAQ of the week
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


module announcements

  o Apache-SimpleReplace 0.06 - A simple template framework [7]

  o Apache-Dispatch 0.07 - call PerlHandlers with the ease of 
Registry scripts [8]


mailing list highlights

  o The same thread managed to discuss the caveats of DSO as
well as compare using HUP or USR1 for log rotation [9]
A sample log rotation script was provided [10]

  o The FastDB Access thread was resurrected this week, offering
discussion on using Storable, the speed of flat file retrieval
based on filename length, and more. [11]

  o Interested in seeing a high-end ISP that knows what mod_perl
developers want?  Fill out a brief survey and maybe someday
we'll all live to see it... [12]

  o Some interesting drawbacks of Apache::DBI, such as not dealing
with table locks properly, can be found in the latter half of
this thread [13]

  o There was a short thread that started to discuss how to deal 
with spiders [14]

  o A lesson in proxying and using X-Fowarded-For [15]


FAQ of the week

  actually, two this week...

  o How can I read from POST more than once?

You can't.  But, of course, this is mod_perl so there are many
ways around the situation.  You could cache the data yourself
using pnotes or write a handler to make POST data look like it 
was a GET, for example.  Investigate use of the experimental
PERL_STASH_POST_DATA mod_perl build option, or check out some
examples in the archives, the mod_perl Guide, and third party
Apache modules on CPAN such as Apache::RequestNotes.

  o How do I unsubscribe from the mod_perl mailing list?

Why would you want to do that?  Most mailing lists these days
include unsubscribe information in the mail headers.  Were you
to look there, you would see 
  list-unsubscribe: 
Just send an empty email to that address.


links

  o The Apache/Perl Integration Project [16]
  o mod_perl documentation [17]
  o mod_perl modules on CPAN [18]
  o mod_perl homepage [19]
  o mod_perl list archives [20] [21]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://forum.swarthmore.edu/epigone/modperl/frolchunfin
[8] http://forum.swarthmore.edu/epigone/modperl/voflerdtal
[9] http://forum.swarthmore.edu/epigone/modperl/khangwhoublimp
[10] http://marc.theaimsgroup.com/?l=apache-modperl&m=97364972521630&w=2
[11] http://forum.swarthmore.edu/epigone/modperl/whalthixgrol 
[12] http://forum.swarthmore.edu/epigone/modperl/lilswanbin
[13] http://forum.swarthmore.edu/epigone/modperl/kexhoicler
[14] http://forum.swarthmore.edu/epigone/modperl/proosheeju
[15] http://forum.swarthmore.edu/epigone/modperl/snaxrunphal
[16] http://perl.apache.org
[17] http://perl.apache.org/#docs
[18] http://www.perl.com/CPAN-local/modules/by-module/Apache/
[19] http://www.modperl.com
[20] http://forum.swarthmore.edu/epigone/modperl/
[21] http://archive.covalent.net/modperl/

RE: ApacheDBI persistant connections

[Geoffrey Young]

> -Original Message-
> From: Tamas [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 13, 2000 4:46 AM
> To: Geoffrey Young
> Subject: RE: ApacheDBI persistant connections
> 
> 
> > > I have a problem with persistant connections from my 
> PerlAuthHandler.
> > > 
> > > If you request a page, then I get 2 persistant connections to the
> > > database. The quickly become sleeping connections. Fine so far.
> > > Wait around 30 seconds and then refresh the page. And get another
> > > 2 sleeping connections. Obviously something is not right.
> > 
> > Apache::DBI caches connections per-connect string and per 
> apache child -
> > thus
> > if you have 5 children and each foo.pl connects to two 
> databases, you
> > eventually will get
> > 10 database connections...
> 
> I'm following things so far :)
> I have Authen and Authz, so two objects (connections) are made
> for each 'secure' request.

not just by virtue of there being two handlers - Apache::DBI doesn't care
which handler makes the connection, just what the connect string is...

that is, any call to

my $dbh = DBI->connect('dbi:Oracle:$DBASE', $DBUSER, $DBPASS,
   {RaiseError => 1, AutoCommit => 1, PrintError => 1}) || die $DBI::errstr;

will result in the same connection (per child, of course)

as soon as you change anything (like RaiseError => 0 or $DBUSER) you get a
new connection...

If Authen and Authz each have different $dbh credentials, then yes, you
should get two connections...

once the processing is finished, each connection will sleep until one of two
things:
  you hit the same apache child again
  the database cleans them up becuase they have been idle for too long

that's the benefit/drawback of Apache::DBI

> > > 
> > > I have a DESTROY function that I call ( 
> $self->{dbh}->disconnect ),
> > > but that doesn't appear to make any difference.
> > 
> > no need to worry about that, disconnect() is a no-op under 
> Apache::DBI...
> 
> Which is what I thought, but the sleeping processes confused me.
> 
> So infact what is heppening is that Apache is spawning threads, each
> with 2 Auth connections without the old ones dying. Possibly then
> I can change the keep-alive on Apache to be less?

I don't think keep-alive has anything to do with it...

I suggest you set $Apache::DBI::DEBUG = 2 in your startup.pl and watch the
debug information under httpd -X

HTH

--Geoff

> 
> Arg, the more I delve the further round the circle I get :)
> 
> Thanks
> 
> Tom
> 

RE: Filter and directories

[Geoffrey Young]

> -Original Message-
> From: Struan Donald [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 13, 2000 8:06 AM
> To: Geoffrey Young
> Cc: [EMAIL PROTECTED]
> Subject: Re: Filter and directories
> 
> 
> * at 09/11 14:22 -0500 Geoffrey Young said:
> > 
> > > I was wondering why Apache::Filter won't deal with directories. 
> > 
> > man Apache::Filter - it's right there ;)
> 
> ah, in the bugs section. note to self: read _all_ the man page.

:)

> > why do you want to process a directory listing?  you want 
> to process the
> > files within the directory via SSI, right?
> 
> no.
> 
> i have a handler with an existing site that uses the extra_path infor
> to work out what templates it shoudl be using for it's output. the
> only problem is that i need to use existing includes that themselves
> use includes so i have to parse the output through Apache::SSI but
> it's possible that the path will be a directory which Filter just
> assumes is an actual directory so won't deal with.
> 
> i.e is /handler/subdir/ is the path then the handler will try and use 
> the template subdir but in that case i can't chain the handler as
> Filter thinks it's a directory.
> 
> does that make sense?


yeah, I think you and Adam were trying to do roughly the same thing (sorry I
didn't reply to your message Adam - it summed up the possible scenario quite
nicely)...

you may want to modify Adam's suggestion, then, and try a trans handler or
rewrite to make sure the request goes to a (possibly imaginary) file... you
may have to adjust your url scheme then, though...

off the top of my head, perhaps you can trick filter?  did you try setting
$r->filename before calling $r->register_filter (or filter_input() in
earlier versions)?  Filter will only check if it's a directory on the first
filter in the chain, and at that it calls -d $r->finfo.  I'm not sure if
setting $r->filename resets $r->finfo (probably ought to if it doesn't)...

again, just off the top - I haven't tried anything like this (yet :)

--Geoff

RE: database access

[Geoffrey Young]

I haven't followed this thread too closely, so forgive me if I'm not quite
with it...

> 
> It would be very useful to be able to specify at connect time that
> you don't want a particular connection to be persistent.  If you have
> a lot of small databases or some with different user/password
> permissions
> you accumulate too many backend servers - but if you also have one
> or more connections used all the time you don't want to give up
> Apache::DBI.  

you can already do this with Apache::DBI...

change DBI->connect() to the (undocumented) 6 parameter call:

  $dbh = DBI->connect($dbase, $user, $pass, \%attr,
  undef, "connect") || die $DBI::errstr;

which will override the default Apache::DBI behavior of caching new
connections...

HTH

--Geoff

RE: ApacheDBI persistant connections

[Geoffrey Young]

> -Original Message-
> From: Tamas [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 10, 2000 7:03 AM
> To: mod perl
> Subject: ApacheDBI persistant connections
> 
> 
> I have a problem with persistant connections from my PerlAuthHandler.
> 
> If you request a page, then I get 2 persistant connections to the
> database. The quickly become sleeping connections. Fine so far.
> Wait around 30 seconds and then refresh the page. And get another
> 2 sleeping connections. Obviously something is not right.

Apache::DBI caches connections per-connect string and per apache child -
thus
if you have 5 children and each foo.pl connects to two databases, you
eventually will get
10 database connections...

sounds like you are hitting another apache child with the refresh - try
httpd -X if you are still unsure...

> 
> Could it be anything to with the versions of the DBD, DBI, Webserver,
> mod_perl? If not, and it is just me being awful, how do I disconnect
> those pesky connections?
> 
> I have a DESTROY function that I call ( $self->{dbh}->disconnect ),
> but that doesn't appear to make any difference.

no need to worry about that, disconnect() is a no-op under Apache::DBI...

HTH

--Geoff

> 
> Thanks for any help,
> 
> Tom
> 

[OT] Raven SSL and 1.3.14

[Geoffrey Young]

given the number of Covalent people that may lurk here ;)

is anyone running Raven 1.5.X out of the box with Apache 1.3.14 and mod_perl
(static)?

just thought someone might know if it works off the top of their head before
I try to upgrade from 1.3.12...

thanks

--Geoff

RE: How to get a form variable inside PerlLogHandler

[Geoffrey Young]

> -Original Message-
> From: Luis Henrique Cassis Fagundes [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 09, 2000 11:15 AM
> To: [EMAIL PROTECTED]
> Subject: How to get a form variable inside PerlLogHandler
> 
> 
>   Hi,
>   I have a perlloghandler that needs to get a variable 
> from a form to log
> the request. To do this, I parse $r->the_request to get the variable
> from the query string, but this only works if the method of 
> the form is
> GET. Does anyone know how can I do this if the method is POST?

hehe - twice in two days :)

you need to cache the POST data yourself - try Apache::RequestNotes, it does
it for you...

HTH

--Geoff

>   Thanks.
>   []s
>   Luis
> 

RE: Filter and directories

[Geoffrey Young]

> -Original Message-
> From: Struan Donald [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 09, 2000 2:05 PM
> To: [EMAIL PROTECTED]
> Subject: Filter and directories
> 
> 
> hi,
> 
> I was wondering why Apache::Filter won't deal with directories. 

man Apache::Filter - it's right there ;)

> I
> assume it's as it makes little sense trying to do things do directory
> listings but it does result in odd things if I have a handler that is
> e.g /poll and i want to chain that through something (such as SSI).

why do you want to process a directory listing?  you want to process the
files within the directory via SSI, right?

change your (assumed)  directive to an Alias + 
directive and see if that changes things...

HTH

--Geoff

> 
> Now i can just comemnt out the relevant lines in the module and rely
> on the fact that I'll only use Filter with handlers or files but that
> seems rash without fully understanding the reasoning behind the
> restrictio in the first place.
> 
> thanks
> 
> struan
> -- 
> Struan Donald
> mailto:[EMAIL PROTECTED]
> Code Flunky, 365 Plc.
> http://www.365corp.com/
> 

[ANNOUNCE] Apache::Dispatch 0.07

[Geoffrey Young]

The URL

 
http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.07.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/G/GE/GEOFF/Apache-Dispatch-0.07.tar.gz
  size: 13251 bytes
   md5: 0ad206303d1138e70615a9763a762e3b

excerpt from the README:

NAME

Apache::Dispatch - call PerlHandlers with the ease of Registry scripts

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 Regsitry scripts without having to load your httpd.conf
with a slurry of  tags.

EXAMPLE

  in httpd.conf

PerlModule Apache::Dispatch
PerlModule Bar


  SetHandler perl-script
  PerlHandler Apache::Dispatch

  DispatchPrefix Bar


  in browser:
http://localhost/Foo/baz

  the results are the same as if your httpd.conf looked like:

  SetHandler perl-script
  PerlHandler Bar::dispatch_baz


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
 directive is be able to handle all the methods of Bar,
Bar::Baz, etc...

Changes:

0.07  10.26.2000
  - added support for output filtering
thanks to Ken Williams for additional Apache::Filter functionality
  - added FILTERING section to documentation
  - added DispatchISA functionality to set parent classes for 
dispatched module
  - added DispatchAUTOLOAD directive to make AUTOLOAD behavior user
defined
  - added AUTOLOAD section to documentation
  - more, better documentation
  - modified Apache::ModuleConfig->get() calls
thanks to Doug MacEachern for the enlightenment
  - fixed bug that allowed for duplicate DispatchExtras directives
  - fixed directive inheritance problems
  - fixed dispatch_index bug
  - fixed one minor "my $x if 0" condition
  - fixed DispatchStat ISA directive to properly recurse all levels
  - made mod_perl 1.2401 required due to DIR_MERGE memory leak in 
mod_perl < 1.24

RE: Clarification of PERL_STASH_POST_DATA

[Geoffrey Young]

> -Original Message-
> From: Paul J. Lucas [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 08, 2000 1:22 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Clarification of PERL_STASH_POST_DATA
> 
> 
> On Wed, 8 Nov 2000, Geoffrey Young wrote:
> 
> > ... Apache::RequestNotes may be able to help - it basically does
> > cookie/get/post/upload parsing during request init and then stashes
> > references to the data in pnotes.  The result is a 
> consistent interface to
> > the data across all handlers (which is the exact reason 
> this module came
> > about)
> 
>   This is /exactly/ right.  The only caveat is that its API is
>   different from Apache::Request.  

it's not really different, just different than most people are used to :)

$r->pnotes('INPUT') contains what is returned from Apache::Request::parms()
(undocumented in Apache::Request, but not in libapreq), which is an
Apache::Table reference.  those get() calls are really Apache::Table::get()

at any rate, hope you find it useful...

--Geoff

RE: Apache::Util routines

[Geoffrey Young]

> -Original Message-
> From: Edwin Pratomo [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 08, 2000 12:44 AM
> To: [EMAIL PROTECTED]
> Subject: Apache::Util routines
> 
> 
> Guys, 
> mod_perl 1.24:
> 
> perl -M'Apache::Util qw(:all)' -e '$a = parsedate("")'
> Undefined subroutine &Apache::Util::parsedate called at -e line 1.
> 
> Looks like I've been missing something?

I doubt that you can use Apache::Util outside of the mod_perl runtime
environment...

if you are seeing the same thing in your live server, then you probably
didn't compile with PERL_UTIL_API=1 or EVERYTHING=1

HTH

--Geoff

> 
> Rgds,
> Edwin.
> 

RE: Clarification of PERL_STASH_POST_DATA

[Geoffrey Young]

> -Original Message-
> From: Paul J. Lucas [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 07, 2000 7:42 PM
> To: [EMAIL PROTECTED]
> Subject: Clarification of PERL_STASH_POST_DATA
> 
> 
>   OK, so the documentation for PERL_STASH_POST_DATA reads:
> 
>   There is an experimental option for Makefile.PL
>   called PERL_STASH_POST_DATA. If you turn it on,
>   you can get at it again with 
> $r->subprocess_env("POST_DATA").
>   This is not on by default because it adds
>   overhead.
> 
>   So I rebuilt Apache and mod_perl with PERL_STASH_POST_DATA=1
>   on the perl Makefile.PL line; however:
> 
>   1. What *is* $r->subprocess_env("POST_DATA") ?  Just the entire
>  posted data squished up into a single scalar?  What about
>  file uploads?
> 
>   2. The $r->subprocess_env("POST_DATA") doesn't even seem to
>  work.  I "warn" it to the log file and I get nothing there.
> 
>   The general problem is preserving POSTed data, including file
>   uploads, for all handlers.

I don't know about PERL_STASH_POST_DATA, but Apache::RequestNotes may be
able to help - it basically does cookie/get/post/upload parsing during
request init and then stashes references to the data in pnotes.  The result
is a consistent interface to the data across all handlers (which is the
exact reason this module came about)

it requires Doug's libapreq and probably a few code changes, but it may be
somewhat helpful...

HTH

--Geoff

> 
>   - Paul
> 

RE: modperl workaround for bug in netscape-4.7x with Expires: headers?

[Geoffrey Young]

> -Original Message-
> From: Louis-David Mitterrand [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 07, 2000 11:09 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: modperl workaround for bug in netscape-4.7x with Expires:
> headers?
> 
> 
> Hello,
> 
> When sending a POST request netscape-4.7 still caches the page and
> doesn't return the updated page with the POST results.
> 
> In which mod_perl *handler would it be more appropriate to insert code
> to the effect that:
> 
> if ($r->uri =~ /login/) {
>   $r->no_cache(1)
> }
> 

any time prior to calling $r->send_http_header() should work fine.  If you
already have a PerlTransHandler that you are using you could put it there.
Maybe others have an opinion as to the 'proper' place, but I have always
included in wherever it made sense at the time, usually in PerlHandler.

> This is to override the DefaultExpires directive on certain pages with
> forms.

you may also want to search the archives concerning NS and MSIE caching
behavior - IIRC lots of people have put a good amount of time into
investigating this issue and there was a decent thread maybe 4 or 5 months
ago discussing REDIRECT to prevent caching, expire headers, etc...

HTH

--Geoff

> 
> Thanks in advance,
> 
> -- 
> Louis-David Mitterrand - [EMAIL PROTECTED] - http://www.apartia.org
> 
> How's my posting?  Call 1-800-DEV-NULL
> 

RE: Apache::Registry() and strict

[Geoffrey Young]

from the camel book: "Use of defined on aggregates (hashes and arrays) is
deprecated."

so, change

if (!defined @fields)

to

unless (@fields)

and not only be idiomatic, but exhibit the behavior you want :)

but seriously, it's a perl thing, not a mod_perl thing:

#!/usr/bin/perl
sub test {
  my @array;

  if (!defined @array) {
print "not defined\n";
  } else {
print "defined\n";
  }

  push @array, "item";
}

test();
test();

results:
not defined
defined

HTH

--Geoff


> -Original Message-
> From: Ron Rademaker [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 07, 2000 7:44 AM
> To: lporcano
> Cc: [EMAIL PROTECTED]
> Subject: Re: Apache::Registry() and strict
> 
> 
> I'm not quite looking for a workaround, I already got one, I'd like to
> know why it's going wrong.
> 
> Ron
> 
> On Sun, 7 Nov 1999, lporcano wrote:
> 
> > It looks like you are trying to determine if an array is 
> empty, in that case
> > replace
> > if (!defined(@fields))
> > with
> > if (!scalar(@fields)).
> > 
> > - Original Message -
> > From: Ron Rademaker <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Tuesday, November 07, 2000 5:26 AM
> > Subject: Re: Apache::Registry() and strict
> > 
> > 
> > > Okay, here's the part where it's going wrong:
> > >
> > > my @fields; # The variable that's causing the 
> trouble, should be
> > > undefined after this declaration
> > > my $printedfields = 0;
> > >
> > > foreach my $hash_ref (@$data_ref)
> > > {
> > > if (!defined(@fields)) # Passes the second time the child gets a
> > > request, but @fields = ()
> > > {
> > > @fields = @$hash_ref;
> > > }
[snip]

[ANNOUNCE] Apache::SimpleReplace 0.06

[Geoffrey Young]

The URL

 
http://morpheus.laserlink.net/~gyoung/modules/Apache-SimpleReplace-0.06.tar.
gz

has entered CPAN as

  file: $CPAN/authors/id/G/GE/GEOFF/Apache-SimpleReplace-0.06.tar.gz
  size: 3628 bytes
   md5: a0018cb6d18863878507bdad70f58c38


This is basically an update for Apache::Filter 1.013 - no need to upgrade
SimpleReplace until you upgrade Apache::Filter.

Changes:
0.06  11.06.2000
- make changes to fit in with Apache::Filter 1.013
- clean up output statements a bit
- changed warning to error for SERVER_ERROR
- modified pod

[DIGEST] mod_perl digest 10/29/2000

[Geoffrey Young]

--

  mod_perl digest
 
   October 29, 2000 - November 4, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o module announcements
  o mailing list highlights
  o news
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


module announcements

  o Apache-Filter 1.013 - Alter the output of previous handlers [7]

  o Apache-SSI 2.15 - Implement Server Side Includes in Perl [8]

  o Apache-Compress 1.003 - Send the content of an HTTP response as
gzip-compressed data [9]


mailing list highlights

  o A continuation from last week, there was lots of talk about 
mod_backhand, a load balancing module for apache, and how it 
compares with a mod_proxy front end to speed up mod_perl [10] [11]

  o The call is out for ideas for a mod_perl track at next year's
Open Source Conference [12]

  o Several URLs were provided for tools that integrate databases and
SQL with a web interface. [13]
  - http://www.oracletool.com/
  - http://phpwizard.net/projects/phpMyAdmin/index.html
  - http://kenny.itlab.musc.edu/phpSybaseAdmin/
  - http://www.php.net/manual/ref.oracle.php
  - http://www.wdbi.net
  - http://www.vilib.utac.net

  o A few techniques for handling exceptions deep within nested
subroutines [14]

  o Another performance thread - this time about thin servers, Squid,
mod_proxy, and solid-state disks [15]


news

  o Netcraft statistics are out for October [16]
 Apache 59.67% IIS 20.16%
 mod_perl 1597399 Domains, 183327 IP Addresses [17]

  o Security Space October statistics [18]
 Apache 57.84% IIS 28.12%
 10.11% (134,207) of Apache servers are running mod_perl [19]


links

  o The Apache/Perl Integration Project [20]
  o mod_perl documentation [21]
  o mod_perl modules on CPAN [22]
  o mod_perl homepage [23]
  o mod_perl list archives [24] [25]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://forum.swarthmore.edu/epigone/modperl/fedunglex
[8] http://forum.swarthmore.edu/epigone/modperl/yulplandsny
[9] http://forum.swarthmore.edu/epigone/modperl/brouneeglerd
[10] http://forum.swarthmore.edu/epigone/modperl/snendblahwoi
[11] http://forum.swarthmore.edu/epigone/modperl/hiltholsnoo
[12] http://forum.swarthmore.edu/epigone/modperl/shehskelfran
[13] http://forum.swarthmore.edu/epigone/modperl/vaxpranvex
[14] http://forum.swarthmore.edu/epigone/modperl/perdzusex
[15] http://forum.swarthmore.edu/epigone/modperl/dwingnibum
[16] http://www.netcraft.com/survey
[17] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=97308359210894&w=2
[18] http://www.securityspace.com/s_survey/data/index.html
[19] http://www.securityspace.com/s_survey/data/man.29/apachemods.html
[20] http://perl.apache.org
[21] http://perl.apache.org/#docs
[22] http://www.perl.com/CPAN-local/modules/by-module/Apache/
[23] http://www.modperl.com
[24] http://forum.swarthmore.edu/epigone/modperl/
[25] http://archive.covalent.net/modperl/

RE: Putting together the TPC mod_perl track

[Geoffrey Young]

I was thinking about putting together something about transitioning from
Registry to handlers

kinda the next step after folks have absorbed Stas stuff - actually using a
PerlAuthHandler to authenticate instead of
authenticate.cgi?url=place_to_go_after_authenticated.html.  maybe something
on moving from CGI.pm to templating (if I'm in the mood to start a small
war)

pretty basic, stuff like that...

--Geoff



> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 01, 2000 11:52 AM
> To: [EMAIL PROTECTED]
> Subject: Putting together the TPC mod_perl track
> 
> 
> Stas et al,
> 
> Since its getting towards the end of the year, should we be 
> thinking of
> putting together a mod_perl track for TPC?
> 
> Has anyone got any ideas on what they'd like to either a) 
> talk about, or
> b) hear talks about ?
> 
> -- 
> 
> 
> /||** Director and CTO **
>//||**  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** Personal Web Site: http://sergeant.org/ **
>  \\//
>  //\\
> //  \\
> 

RE: Page contains no data error

[Geoffrey Young]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 01, 2000 9:33 AM
> To: [EMAIL PROTECTED]
> Subject: Page contains no data error
> 
> 
> 
> I'm moving someone else's CGIs to run under mod_perl, and 
> about 95% of the time
> they work. 
> 
> The other 5% of the time Netscape gets a "Document contains 
> no data." error and
> the web page that should have been sent to the brower is 
> written into the apache
> error log. No other error is given in the error log. 
> 
> This is running on Apache 1.3.12, perl 5.004_04, and mod_perl 1.24.
> 
> I'm beginning to suspect that mod_perl and perl arn't playing 
> well together,
> since mod_perl and apache were just upgraded. After a server 
> process gives the
> error, all mod_perl requests (such as perl-status) that hit 
> that process will
> get the same error.
> 
> Any ideas what it might be or a better way to track it down?

httpd -X will help isolate the problem by running apache as a single process

use strict and PerlWarn On - then be sure to fix any errors or warnings that
crop up.

read http://perl.apache.org/guide/porting.html

HTH

--Geoff

> 
> Steve Cochran
> 

RE: Apache 1.3.14 and Apache::RegistryLoader

[Geoffrey Young]

I have no idea, but if it helps, here is a snip from my startup.pl

it works just fine on:
1.3.14/perl5.6 (-Dusethreads)/linux(RH6.2)/modperl cvs (1.24_02)
1.3.14/perl5.00503/Solaris/modperl 1.24_01

my $rl = Apache::RegistryLoader->new;

my $dh = DirHandle->new("/usr/local/apache/perl-bin") || die $!;

foreach my $file ($dh->read) {
  next unless $file =~ m/\.pl$|\.cgi$/;
  print "pre-loading $file\n";

  $rl->handler("/perl-bin/$file" => "/usr/local/apache/perl-bin/$file");
}

although hardcoded, I've never had a problem with it and it...

HTH

--Geoff

> -Original Message-
> From: Paul G. Weiss [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 31, 2000 3:37 PM
> To: '[EMAIL PROTECTED]'
> Subject: Apache 1.3.14 and Apache::RegistryLoader
> 
> 
> I tried using Apache::RegistryLoader with my
> Apache 1.3.14/mod_perl 1.24_2 installation.
> 
> I put this in a file that I PerlRequire:
> 
> use Apache::RegistryLoader ();
> 
> my $perl_dir = Apache->server_root_relative."docs";
> my $cmd = qq{find $perl_dir -follow \\( -name "*.pl" -o -name 
> "*.cgi" \\)
> -print};
> my $output = `$cmd`;
> my @files = split /\s+/, $output;
> my $rl = Apache::RegistryLoader->new;
> foreach my $file (@files)
> {
> print "pre-loading $file\n";
> $file =~ /$perl_dir(.*)/;
> my $status = $rl->handler($1, $file);
> unless($status == 200) {
> warn "pre-load of `$url' failed, status=$status\n";
> }
> }
> 
> (In other words, I load every .cgi or .pl file found under a certain 
> directory.  I've also coded it with File::Find instead of running
> find as a separate process with the same results.)
> 
> The results were not good.  This appeared in error_log:
> 
> [Tue Oct 31 15:26:32 2000] [notice] caught SIGTERM, shutting down
> signal fault in critical section
> signal number: 11, signal code: 1, fault address: 0x1a5c, 
>pc: 0xff3b9c64, sp: 0xffbef530
> libthread panic: fault in libthread critical section (PID: 
> 19927 LWP 1)
> stacktrace:
> ff3b9c30
> ff3be3a0
> ff3bd498
> ff3bd4f4
> 4bfd8
> fedc185c
> fedc189c
> 1c2c4
> 199fc
> 329f0
> 33808
> 18e98
> 0
> 
> This is under Solaris 2.7.  The perl that I used for mod_perl was not
> built with any threading options.  Is this now required, given that 
> Apache 1.3.14 appears to be using threads?
> 
> -Paul 
> 

RE: Apache::Log (v1.01) doesn't function on linux

[Geoffrey Young]

you need to make mod_perl with 

perl Makefile.PL EVERYTHING=1 

(or at least PERL_LOG_API=1)

HTH

--Geoff

> -Original Message-
> From: Pete Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 31, 2000 11:44 AM
> To: [EMAIL PROTECTED]
> Subject: Apache::Log (v1.01) doesn't function on linux
> 
> 
> I can't seem to get Apache::Log to work under linux.  I'm 
> calling it as
> 'use Apache::Log();', and I can see the module as
> /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/Log.pm, but it won't
> load.  Are other people having this problem as well?
> 
> Perl version: 5.005
> mod_perl version: 1.24
> 
> error message:
> [Tue Oct 31 09:43:53 2000] [error] Can't locate loadable object for
> module Apache::Log in @INC (@INC contains:
> /usr/local/apache/libexec/perl /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
> 
> Thanks for your help!
> 
> --
> Pete Nelson - Subjex.com
> mailto:[EMAIL PROTECTED]  http://www.subjex.com
> 
> The next generation search engine! TRY IT!
> 
> Corp HQ: 612-362-9224
> Toll Free: 800-447-0607
> Cell: 612-991-8190
> Fax: 612-362-9227
> 43 Main Street SE, Suite 508
> Minneapolis, MN  55414
> 
> 
> 

RE: Probably a really stupid question

[Geoffrey Young]

> -Original Message-
> From: Jimi Thompson [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 30, 2000 5:34 PM
> To: Geoffrey Young
> Subject: Re: Probably a really stupid question
> 
> 
> Geoffrey,
> 
> I'm still having problems, perl is installed, mod_perl is 
> installed.  I can
> call both of them directly and they work find. 

well, that's not really true - your 'can't find PerlHandler' error is a
pretty sure indication that mod_perl is not installed...

> However, when 
> I try to get
> Apache to execute the script is when it all falls apart.  I 
> have tried to
> find the module that you mentioned and I'm not able to locate 
> it.  

mod_so is part of the core apache distribution - it is one of two modules
you must compile in statically if you want other modules to be dynamically
loaded (read more about the apache DSO - dynamic sharing option in the
apache docs)


basically it boils down to this: either compile mod_perl into your apache
binary statically (which yours isn't since you get the PerlHandler error) or
enable Apache's DSO (via a complied in mod_so, which you don't have since
you get the LoadModule error) and enable mod_perl as a DSO using LoadModule.

there are instructions for both of these in perl.apache.org/guide - my
suggestion would be to compile a static mod_perl and deal with DSO later.
But the choice is yours...

HTH

--Geoff

> If you
> could provide a link, this might be helpful, especially to 
> other Solaris
> users.
> 
> No one else mentions this module in any of the install 
> instructions. 
> All
> the documentation seems to indicate you should just be able to install
> mod_perl (as long as perl is working) have it work.  Why this 
> applies to the
> entire rest of the known world and not me is a total mystery?
> 
> ACK!!
> 
> Geoffrey Young wrote:
> 
> > > -Original Message-
> > > From: Jimi Thompson [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, October 30, 2000 3:13 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Probably a really stupid question
> > >
> > >
> > > Problem - all files ending in the .pl extension display
> > > source code rather than
> > > being executed. In addition to not seeing the .pl's as
> > > executable I get this
> > > message when I try to start apache -
> > >
> > > callmaster% apachectl start
> > > Syntax error on line 793 of /usr/local/apache/conf/httpd.conf:
> > > Invalid command 'PerlHandler', perhaps mis-spelled or defined
> > > by a module not
> > > included in the server configuration
> > > apachectl start: httpd could not be started
> > >
> > > So then I change the LoadModule to
> > >
> > > LoadModule  perl_module libexec/libperl.so
> > >
> > > which then generates this error message -
> > >
> > > callmaster% apachectl start
> > > Syntax error on line 203 of /usr/local/apache/conf/httpd.conf:
> > > Invalid command 'LoadModule', perhaps mis-spelled or defined
> > > by a module not
> > > included in the server configuration
> > > apachectl start: httpd could not be started
> >
> > sounds like you don't have mod_so compiled in
> >
> > ./httpd -l
> >
> > should show mod_so.c, which is what controls the LoadModule 
> directive...
> >
> > HTH
> >
> > --Geoff
> >
> > >
> > > This would seem to indicate that mod_perl did not install
> > > correctly.  However,
> > > mod_perl states that it has installed.
> > > When I go to check the apache/libexec, it is empty - no
> > > mod-perl.  I don't
> > > understand why this isn't building properly.
> > >
> > > Any insight would be helpful...
> > >
> > > I've always done this via the RPM in Red Hat and this is on a
> > > Sparc Solaris 2.6
> > > box so maybe someone can give me a hand and tell me what I've
> > > missed.  I've
> > > attached the httpd.conf file and it appears to be correct,
> > > but it errors out (see
> > > above)
> > >
> > >
> > > Jimi Thompson
> > >
> > >
> > >
> 
> --
> Jimi Thompson
> Web Master
> L3 communications
> 
> "It's the same thing we do every night, Pinky."
> 
> 

RE: Probably a really stupid question

[Geoffrey Young]

> -Original Message-
> From: Jimi Thompson [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 30, 2000 3:13 PM
> To: [EMAIL PROTECTED]
> Subject: Probably a really stupid question
> 
> 
> Problem - all files ending in the .pl extension display 
> source code rather than
> being executed. In addition to not seeing the .pl's as 
> executable I get this
> message when I try to start apache -
> 
> callmaster% apachectl start
> Syntax error on line 793 of /usr/local/apache/conf/httpd.conf:
> Invalid command 'PerlHandler', perhaps mis-spelled or defined 
> by a module not
> included in the server configuration
> apachectl start: httpd could not be started
> 
> So then I change the LoadModule to
> 
> LoadModule  perl_module libexec/libperl.so
> 
> which then generates this error message -
> 
> callmaster% apachectl start
> Syntax error on line 203 of /usr/local/apache/conf/httpd.conf:
> Invalid command 'LoadModule', perhaps mis-spelled or defined 
> by a module not
> included in the server configuration
> apachectl start: httpd could not be started

sounds like you don't have mod_so compiled in

./httpd -l

should show mod_so.c, which is what controls the LoadModule directive...

HTH

--Geoff

> 
> This would seem to indicate that mod_perl did not install 
> correctly.  However,
> mod_perl states that it has installed.
> When I go to check the apache/libexec, it is empty - no 
> mod-perl.  I don't
> understand why this isn't building properly.
> 
> Any insight would be helpful...
> 
> I've always done this via the RPM in Red Hat and this is on a 
> Sparc Solaris 2.6
> box so maybe someone can give me a hand and tell me what I've 
> missed.  I've
> attached the httpd.conf file and it appears to be correct, 
> but it errors out (see
> above)
> 
> 
> Jimi Thompson
> 
> 
>