loading of mod_perl

[shang]

Hi,  
 
I have some problem loading ApacheModulePerl.dll 
into Apache server I installed in Windows 98.  All the other *.dll in 
c:\apache\modules can be loaded but not this one.  The following is the 
error message when I typed 'apache -s' :
(The line 188 actually contains the 'LoadModule perl_module 
modules/ApacheModulePerl.dll' )
 
 
Syntax error on line 188 of 
c:/apache/conf/httpd.conf:Cannot load c:/apache/modules/ApacheModulePerl.dll 
into server:
 
If you can give me some help, it will be greated 
appreciated.
 
Thanks so much.
 
 
Xingjian 

Re: [new module] proposal Apache::DebugHeaders

[Francesc Guasch]

Stas Bekman wrote:
> 
> Did you know that CPAN tolerates even the packages with no Makefile.PL? I
> don't try to disencourage you to write Makefile.PL (feel free to "steal"
> one from your favorite module), but if you really cannot build yours
> release it as it is. It still might save one of us days of work, which in
> return might give you something that you need.
> 

A very easy way of create Makefile.PL and module files
and directories is typing this:

h2xs -X -n My::Object

-- 
 - frankie -

[PATCH 5.6.0] local $SIG{FOO} restoration

[Doug MacEachern]

when 'local $SIG{ALRM} = sub {...}' goes out of scope, magic_setsig() sets
the SIGALRM handler to SIG_DFL, rather than the original handler.  this
causes quite a bit of trouble running inside of apache, since 'local
$SIG{ALRM}' unhooks the apache SIGALRM handler for the life of that
proccess.
the original handler is already fetched by magic_getsig(), this patch
saves that pointer so it can be restored in magic_setsig().

--- mg.c~   Sat Mar 18 19:41:03 2000
+++ mg.cTue Mar 28 22:37:07 2000
@@ -967,7 +967,7 @@
if(sigstate == SIG_IGN)
sv_setpv(sv,"IGNORE");
else
-   sv_setsv(sv,&PL_sv_undef);
+   sv_setiv(sv,(IV)sigstate);
PL_psig_ptr[i] = SvREFCNT_inc(sv);
SvTEMP_off(sv);
}
@@ -1002,6 +1002,7 @@
 I32 i;
 SV** svp;
 STRLEN len;
+Sighandler_t sigstate = 0;
 
 s = MgPV(mg,len);
 if (*s == '_') {
@@ -1038,16 +1039,21 @@
*svp = SvREFCNT_inc(sv);
return 0;
 }
-s = SvPV_force(sv,len);
+if (SvIOK(sv)) {
+   sigstate = (Sighandler_t)SvIVX(sv);
+}
+else {
+   s = SvPV_force(sv,len);
+}
 if (strEQ(s,"IGNORE")) {
if (i)
(void)rsignal(i, SIG_IGN);
else
*svp = 0;
 }
-else if (strEQ(s,"DEFAULT") || !*s) {
+else if (strEQ(s,"DEFAULT") || !*s || sigstate) {
if (i)
-   (void)rsignal(i, SIG_DFL);
+   (void)rsignal(i, sigstate ? sigstate : SIG_DFL);
else
*svp = 0;
 }

Re: possible bug: mod_perl 1.22 (Perl 5.6 / Apache 1.3.12)

[Doug MacEachern]

On Tue, 28 Mar 2000, Dave Seidel wrote:

> and now everything is working correctly.  What I don't undetrstand is that
> the original code was identical in mod_perl 1.21, but I didn't have this
> problem.  Could this be due to some internal change in Perl 5.6?

probably, thanks for the fix!

Re: Signal Abort

[Doug MacEachern]

On Tue, 28 Mar 2000 [EMAIL PROTECTED] wrote:

> Hi,
> my environment is 
> Server: Apache/1.3.3 (Unix) mod_perl/1.16
> on Solaris,

you might want to upgrade to recent versions of apache and mod_perl

> #26 0xee8e86b8 in IM_FreeMbox ()
> #27 0xef4b8f14 in XS_Mailbox_DESTROY ()

if you can compile this Mailbox extension with debugging symbols (-g), the
stacktrace might give more clues.

Re: why can not test, but can run

[Doug MacEachern]

On Mon, 27 Mar 2000, David Yang wrote:
 
> I can not test my mod_perl, everytime I test my
> mod_perl, just as the document told me, it will 
> 
> letting apache warm up . failed

what does t/logs/error_log say?

Re: perl 5.6/mod_perl 1.22/apache 1.3.12

[Doug MacEachern]

On Mon, 27 Mar 2000, Charles Day wrote:

> Just spent half the day trying marry these 3.  mod_perl doesn't build.
> DSO/apxs errors as described by others.

these errors were just warnings, try cvs if you want to get rid of them.
did you have other problems too?

Re: Why 'require' required?

[Doug MacEachern]

On Sun, 26 Mar 2000, Jie Gao wrote:
 
> Another thing is, it seems there is no way to get at "allow/deny from"
> from within mod_perl. "deny from all" will work, but "deny from ip.addres."
> does not.

no, because the allowdeny typedef is private in mod_access.c
however, you can implement directive handlers for allow and deny that
capture the data into a Perl object, then return DECLINE_CMD if you want
mod_access to also pick up the allow/deny config.

Re: More segfault problems

[Doug MacEachern]

On Fri, 24 Mar 2000, Shevek wrote:
 
> Now we get rid of the DOM tree.
> 
>  44 $document->dispose;
> 
> And the child segfaults. But if I don't have the dumper, that does not
> happen. What is the best way to get around this? Is undefining $d an
> appropriate technique?


did you configure apache with RULE_EXPAT=no ?

Re: Modperl 1.22 and Perl 5.6.0

[Doug MacEachern]

On Fri, 24 Mar 2000, Ken Kosierowski wrote:

> What is the best way to compile the new Perl 5.6.0 with Modperl 1.22?

same way you compile 5.005 with mod_perl
 
> Should I use the 5.005 compatible flags or start from scratch and recompile
> the modules I use?

you don't need the 5.005 compat flags to build mod_perl-1.22

> Are there performance issues using the 5.005 compat mode?

not sure, doubt it though.

> What about malloc and malloc flags -- same as what the Guide recommends?

i the guide recommendations (TWO_POT_OPTIMIZE, etc) are the default since
5.005.  i think linux still defaults to system malloc, you might want to
configure Perl with  -Dusemymalloc

> What about issues with the upcoming Apache 2.0 and modperl 2.0?

mod_perl-2.0 will be underway soon.

Re: Re-coding some noddy routines in C

[Doug MacEachern]

On Fri, 24 Mar 2000, Dave Hodgkinson wrote:

> 
> General question:
> 
> We have two little bits of mod_perl code we run, one that pops our
> accellerating proxy IP address off the X-Forwarded-For list and the
> other that stuffs one of a variety of possible cookies into the 
> basic auth field of the logger.
> 
> I need these functions in a couple of servers, ones that don't need
> to hae mod_perl if I can re-code these modules.
> 
> How easy is it to do this in C? This is all covered in the Eagle book?

should be simple.  the api is covered in the eagle book, also have a look
at the C examples at modperl.com (which are not in the book), and libapreq
(cpan.org/modules/by-module/Apache), includes C examples for using the
cookie api.

Re: [patch] mod_perl-1.22 and SGI_BOOST

[Doug MacEachern]

On Fri, 24 Mar 2000, Ville Skyttä wrote:

> The -DSGI_BOOST option is broken in mod_perl 1.22 (minor typo), a patch
> is attached.

thanks, applied.
 
> Further, the "perl Makefile.PL" section of the installation has changed
> somewhat from 1.21_03, resulting in some strange warnings / errors.

these should all be fixed now in the cvs tree, thanks for the report!

Re: [ANNOUNCE] mod_perl-1.22

[Doug MacEachern]

On Thu, 23 Mar 2000, Ruben I Safir wrote:

> Is there any security issues forcing an upgrade?

no.

Re: [ANNOUNCE] mod_perl-1.22

[Doug MacEachern]

On Thu, 23 Mar 2000, Oleg Bartunov wrote:
> apxs:Error: /usr/local/apache/bin/httpd not found or not executable
> Writing Makefile for Apache
> apxs:Error: /usr/local/apache/bin/httpd not found or not executable
> Writing Makefile for Apache::Connection

this is fixed now in the cvs tree.

Re: Q: PerlSendHeader

[Doug MacEachern]

On Thu, 23 Mar 2000, Jaime Teng wrote:

> Hi,
> 
> Is there a setting that changes what mod_perl prints when 
> the "PerlSendHeader On" is used?

no, with 'PerlSendHeader On', mod_perl feeds headers into $r->headers_out,
then calls ap_send_http_header(), much like mod_cgi does.
ap_send_http_headers() is hardwired to send certain headers, such as
Server:, Connection:, etc., see http_protocol.c
 
> for whatever reasons, my scripts are not being accepted by 
> some browsers simply because mod_perl is sending some 
> unknown/unsupported headers.
> 
> One of these header is the "Connection: close".

eh?  this is standard http/1.1, even if the browser doesn't understand it,
it should just ignore it.  please describe what you mean by 'not being
accepted'?

possible bug: mod_perl 1.22 (Perl 5.6 / Apache 1.3.12)

[Dave Seidel]

Hi,

Please for give if this is a FAQ, but I didn't see it mentioned in the
recent list archives.

I just upgraded to 5.6, and proceeded to upgrade from mod_perl 1.32_03 to
1.22 (under Apache 1.3.12, using gcc 2.95.1).  Everything built fine, but
httpd failed to start.  The error message was:

Apache.pm version 1.26 or higher required!
/usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm is only version 1.26
Perhaps you forgot to 'make install' or need to uninstall an old version?
Found: /usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm

Odd, eh?  Since when does 1.26 != 1.26?  :-)  After trying a bunch of stuff,
I realized that the error was coming from mod_perl.c, line 538:

if(SvNV(version) >= MP_APACHE_VERSION) /*no worries*/
   return;

After looking up SvNV() to find that it produces a float, I changed line 526
from
#define MP_APACHE_VERSION 1.26
to
float MP_APACHE_VERSION = 1.26;

and now everything is working correctly.  What I don't undetrstand is that
the original code was identical in mod_perl 1.21, but I didn't have this
problem.  Could this be due to some internal change in Perl 5.6?

-- Dave

---
Dave Seidel
[EMAIL PROTECTED]
www.superluminal.com/dave/

Fulltime employment opportunities in Melbourne, Oz.

[Peter Skipworth]

The following two mod_perl-centric positions are now available at
Australia's premier online realestate company, realestate.com.au. Please
forward enquiries and applications to [EMAIL PROTECTED]

Perl Programmer 1 Duties:
The Perl Programmer is responsible for the:
·   Development of Perl code to ensure the timely completion of set tasks
·   Technical documentation of all code produced
·   Completion of individual projects
·   Completion of maintenance tasks
·   Development of unique solutions for novel requirements
·   Liaison with design teams and internal customers where required
·   Participation in team work and active communication with others in the
team
Required skill set:
·   Excellent internet knowledge
·   Excellent HTML skills
·   More than two years Perl 5 experience, preferably with object oriented
experience
·   Excellent Unix skills
·   Client server development skills
·   XML experience an advantage
·   Oracle experience an advantage
·   Unix administration (web/ security) an advantage
·   Excellent communication skills, written and verbal
·   Concise clear technical written and verbal skills
·   Good team player
·   Excellent time management skills
·   Able to multitask
·   Testing experience
·   Common sense
·   Assertive
·   Work within guidelines
·   Creative

 
Perl Programmer 2
Duties:
The Perl Programmer is responsible for the:
·   Development of Perl code to ensure the timely completion of set tasks
·   Technical documentation of all code produced
·   Completion of individual projects
·   Completion of maintenance tasks
·   Development of unique solutions for novel requirements
·   Liaison with design teams and internal customers where required
·   Participation in team work and active communication with others in the
team
Required skill set:
·   Excellent internet knowledge
·   Excellent HTML skills
·   More than two years Perl 5 experience, preferably with object oriented
experience
·   Oracle experience
·   Excellent Unix skills
·   Client server development skills an advantage
·   Unix administration (web/ security) an advantage
·   Excellent communication skills, written and verbal
·   Concise clear technical written and verbal skills
·   Good team player
·   Excellent time management skills
·   Able to multitask
·   Testing experience
·   Common sense
·   Assertive
·   Work within guidelines
·   Creative

Re: Easy Examples to Get Started

[James G Smith]

Fabrice Scemama <[EMAIL PROTECTED]> wrote:
>Hi Mod_Perlers!
>
>I'm currently reading Stas's book (big thanks to all of you who
>contributed to this masterpiece -- it's great). But you never
>get tired of Good Things, and I was wondering if some very
>easy and commented mod_perl scripts were available, as a
>way to get started faster and better.

I'm working on it...  not sure when I'll be at the point of
an announcement, but hopefully within a few days to a couple
of weeks.
+-
James Smith - [EMAIL PROTECTED] | http://www.jamesmith.com/
[EMAIL PROTECTED] | http://sourcegarden.org/
  [EMAIL PROTECTED]  | http://cis.tamu.edu/systems/opensystems/
+--

Easy Examples to Get Started

[Fabrice Scemama]

Hi Mod_Perlers!

I'm currently reading Stas's book (big thanks to all of you who
contributed to this masterpiece -- it's great). But you never
get tired of Good Things, and I was wondering if some very
easy and commented mod_perl scripts were available, as a
way to get started faster and better.

Fabrice
-- 
"Tout  penseur avare  de ses  pensees est  un penseur  de  Radin."  --
Pierre Dac

RE: Set DocumentRoot from modperl

[Serge]

Thanks everybody for your suggestions. I actually went through the past
threads on that topic, and it seems to me it always sparks much
discussion!!

Karyn> I believe he is trying to do this 'on the fly' without reboot for
Karyn> the new configs.

Exactly.

Karyn> I beat my head on this pretty good before and ended having to invest
Karyn> in the development to make it work, but the development really
Karyn> wasn't that ugly and it works like a champ.  Just make sure you have
Karyn> some kind of caching mechanism (or figure out how to use the apache
Karyn> pools) so that you aren't hitting the database for every http
Karyn> request.

I actually use some caching, so I don't expect to have much penalties from 
it.

I finally decided to rewrite the URI translation handler in perl
at first, and later on directly in C for best performance. This approach
will also allow me to tune the translation stage to my particular case
and remove all the little inefficiencies (extra stat()'s) there.
As opposed to your case I don't have downstream frontpage or CGI, so I
guess I don't need to worry about passing along the DOCUMENT_ROOT correctly.
Though as you say it would be nice to simplify the whole process in
the future.

Cheers,
Serge

Karyn> I didn't find too many people who really understood what the
Karyn> benefits are of doing this.  I guess if someone did, it would be
Karyn> more accessible in Apache itself.  The benefits in management,
Karyn> scalability, and minimizing downtime by those idiots ... I mean
Karyn> customers ... who do stupid things like delete their htdocs
Karyn> directories and cause the whole rebooting process to fail.
Karyn> If any of the big guys are listening, this is big on my wish list
Karyn> for upcoming apache adds.  I've committed myself to bellying up to
Karyn> the bar to learn C just so I can do something like this using the
Karyn> apache engine.

Karyn> - Karyn

Karyn> -Original Message- From: Michael
Karyn> [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 28, 2000 2:03
Karyn> PM To: [EMAIL PROTECTED] Subject: RE: Set DocumentRoot from modperl


>> Sergio,
>> 
>> I just walked this route...
>> 
>> The long and short is that it can't be done anything close to feasably.

Karyn> There is a work around to this. If you use the syntax


Karyn> perlcode perlcode require 'somefile.cgi'; more perl more perl

Karyn> then the cgi script gets imported into the environment and RUN with
Karyn> the current document root rather than the one for modperl for the
Karyn> whole system. Yeah, it's messy and require was not intended to be
Karyn> used quite that way, but it works!

>>  You'll have to write your own URI Translator and alter some code so
>> that you can introduce your DOCUMENT_ROOT down the line to things like
>> the mod_cgi etc.  If you search the mod_perl forum, you'll see some
>> handy code that one of the gurus around here provided me use the NOTES
>> table.
>> 
>> BTW, if you're introducing FrontPage to your masses.  You'll have to
>> re-write your own fpcount.exe.  The codes not available and it's
>> anybody's guess where the hell it actually gets the document root from
>> (I even encoded it into the mod_frontpage.c module without success) and
>> naturally the source isn't available.
>> 
>> Have fun.  I did!
>> 
>> 
>> - Best regards,
>> 
>> Karyn Ulriksen Chief Systems Architect PublicHost 22 Mauchly, Suite 200
>> Irvine, California 92618 USA Phone: (949) 743-2000 email:
>> [EMAIL PROTECTED] URL: http://www.publichost.com
>> 
>> 
>> 
>> -Original Message- From: Serge > [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 28, 2000 1:45 PM To:
>> [EMAIL PROTECTED] Subject: Set DocumentRoot from modperl
>> 
>> 
>> 
>> Hi, I am trying to find a way of setting DocumentRoot (and possibly
>> Alias) directly from modperl in order to implement dynamically generated
>> virtual hosting. The thing is that my virtualhost parameters comes from
>> a database and may change anytime (so I can't restart Apache in
>> general), so it is difficult to implement with Apache virtual host
>> rewrite, mod_rewrite or even  directives in httpd.conf. I tried to
>> use subprocess_env to set this variable, but it is useful only for
>> cgi-scripts, not perl or C handlers since it sets the Environment
>> variable only.
>> 
>> Is the only solution to rewrite the URI translation phase so it does not
>> use DocumentRoot directive??
>> 
>> -- 
>> Serge Barbosa Da Torre - [EMAIL PROTECTED]
>> 
>> "It's not easy, being green."  -- Kermit the Frog
>> 

-- 
Serge Barbosa Da Torre  -  [EMAIL PROTECTED]

"It's not easy, being green."
-- Kermit the Frog

Re: [OT slightly] mod_perl developers (do they exist?)

[Bill Jones]

Re:  Subject line...

$_ = "mod_perl Developer";
print "If I Perl & I Apache, then am I a ",
  (/^mod\_perl\sDeveloper$/) ? $_ : " ... ", "?\n";

HTH,  -Sneex-  :]
- FCCJ * 501 W State St * Jacksonville, Fl 32202 * 904/632-3089 -

RE: Set DocumentRoot from modperl

[Michael]

> I believe he is trying to do this 'on the fly' without reboot for
> the new configs.
> 
Oh, maybe I misunderstood. 
The problem I had was executing code that needed to know the document 
root which seems to point to the main mod_perl doc root rather than 
the root of the particular virtual root. That is what my work around 
covers.

Michael

[EMAIL PROTECTED]

RE: Set DocumentRoot from modperl

[Karyn Ulriksen]

I believe he is trying to do this 'on the fly' without reboot for the new
configs.

If you know how to do this with a require in the configs, I'd sure like to
hear more.

I beat my head on this pretty good before and ended having to invest in the
development to 
make it work, but the development really wasn't that ugly and it works like
a champ.  Just make sure you have some kind of caching mechanism (or figure
out how to use the apache pools) so that you aren't hitting the database for
every http request.

I didn't find too many people who really understood what the benefits are of
doing this.  I guess if someone did, it would be more accessible in Apache
itself.  The benefits in management, scalability, and minimizing downtime by
those idiots ... I mean customers ... who do stupid things like delete their
htdocs directories and cause the whole rebooting process to fail.

If any of the big guys are listening, this is big on my wish list for
upcoming apache adds.  I've committed myself to bellying up to the bar to
learn C just so I can do something like this using the apache engine.

- Karyn

-Original Message-
From: Michael [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 28, 2000 2:03 PM
To: [EMAIL PROTECTED]
Subject: RE: Set DocumentRoot from modperl


> Sergio,
> 
>I just walked this route...
> 
>The long and short is that it can't be done anything close to
>feasably.

There is a work around to this. If you use the syntax


perlcode
perlcode
require 'somefile.cgi';
more perl
more perl

then the cgi script gets imported into the environment and RUN with 
the current document root rather than the one for modperl for the 
whole system. Yeah, it's messy and require was not intended to be 
used quite that way, but it works!

> 
>You'll have to write your own URI Translator and alter some code
>so that
> you can 
>introduce your DOCUMENT_ROOT down the line to things like the
>mod_cgi
> etc.  If you 
>search the mod_perl forum, you'll see some handy code that one of
>the
> gurus 
>around here provided me use the NOTES table.
> 
>BTW, if you're introducing FrontPage to your masses.  You'll have
>to
> re-write your 
>own fpcount.exe.  The codes not available and it's anybody's
>guess where
> the hell 
>it actually gets the document root from (I even encoded it into
>the
> mod_frontpage.c
>module without success) and naturally the source isn't available.
> 
>Have fun.  I did!
> 
> 
> - Best regards,
> 
> Karyn Ulriksen
> Chief Systems Architect
> PublicHost
> 22 Mauchly, Suite 200
> Irvine, California  92618 USA
> Phone: (949) 743-2000
> email: [EMAIL PROTECTED]
> URL:  http://www.publichost.com
> 
> 
> 
> -Original Message-
> From: Serge mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 28, 2000 1:45 PM To: [EMAIL PROTECTED]
> Subject: Set DocumentRoot from modperl
> 
> 
> 
> Hi,
> I am trying to find a way of setting DocumentRoot (and possibly
> Alias) directly from modperl in order to implement dynamically
> generated virtual hosting. The thing is that my virtualhost
> parameters comes from a database and may change anytime (so I can't
> restart Apache in general), so it is difficult to implement with
> Apache virtual host rewrite, mod_rewrite or even  directives
> in httpd.conf. I tried to use subprocess_env to set this variable,
> but it is useful only for cgi-scripts, not perl or C handlers since
> it sets the Environment variable only.
> 
> Is the only solution to rewrite the URI translation phase so it does
> not use DocumentRoot directive??
> 
> -- 
> Serge Barbosa Da Torre-  [EMAIL PROTECTED]
> 
> "It's not easy, being green."
>   -- Kermit the Frog
> 

Re: [new module] proposal Apache::DebugHeaders

[Stas Bekman]

Hi, Geoff

> ok, this isn't all that clever, but recently I got tired of writing
> loops of warnings to debug headers_in and headers_out over and over
> again... 
> 
> all this one does is spit out headers_in in the init phase and headers_out
> in the cleanup phase.  Not terribly extensible, but perhaps practical
> 
> if anyone thinks it worthy of CPAN, I'll throw it up.  If folks are real
> interested, maybe it can be altered somewhat to start an Apache::Debug::
> series with stuff working toward similar ends...

Every code snippet that you produce and find it useful, at some point
might be useful to other programmers. Therefore it's a good idea to make
it available even if there is no interest when you post it (I don't say
there is not :) So if no one replies with naming suggestion or else, go
ahead and release it on CPAN. 

Did you know that CPAN tolerates even the packages with no Makefile.PL? I
don't try to disencourage you to write Makefile.PL (feel free to "steal"
one from your favorite module), but if you really cannot build yours
release it as it is. It still might save one of us days of work, which in
return might give you something that you need.

> Otherwise, feel free to discard it at will...
> 
> --Geoff
> 
> package Apache::DebugHeaders;
> 
> #-
> #
> # usage: PerlInitHandler Apache::DebugHeaders
> #
> #-
> 
> use 5.004;
> use mod_perl 1.21;
> use Apache::Constants qw( OK );
> use Apache::Log;
> use strict;
> 
> $Apache::DebugHeaders::VERSION = '0.01';
> 
> # set debug level
> #  0 - messages at info or debug log levels
> #  1 - verbose output at info or debug log levels
> $Apache::DebugHeaders::DEBUG = 1;
> 
> sub handler {
> #-
> # initialize request object
> #-
>   
>   my $r   = shift;
>   my $log = $r->server->log;
> 
> #-
> # do some preliminary stuff...
> #-
> 
>   $log->info("Using Apache::DebugHeaders") 
>  if $Apache::DebugHeaders::DEBUG;
> 
> #-
> # push the PerlFixupHander and PerlCleanupHandler onto the stack
> #-
> 
>   $r->push_handlers(PerlInitHandler=> 'Apache::DebugHeaders::in');
>   $r->push_handlers(PerlCleanupHandler => 'Apache::DebugHeaders::out');
> 
> #-
> # wrap up...
> #-
> 
>   $log->info("Exiting Apache::DebugHeaders")
>  if $Apache::DebugHeaders::DEBUG;
> 
>   return OK;
> }
> 
> sub in {
> #-
> # initialize request object
> #-
>   
>   my $r   = shift;
>   my $log = $r->server->log;
> 
> #-
> # print $r->headers_in in a pretty format
> #-
> 
>   my $headers_in = $r->headers_in;
> 
>   $log->info("headers_in:");
> 
>   $headers_in->do(sub {
> my ($field, $value) = @_;
> if ($field =~ m/Cookie/) {
>   my @values = split /; /, $value;
>   foreach my $cookie (@values) {
> $log->info("\tfield = $field, value = $cookie");
>   }
> }
> else { 
>   $log->info("\tfield = $field, value = $value");
> }
> 1;
>   });   
> 
> #-
> # wrap up...
> #-
> 
>   return OK;
> }
> 
> sub out {
> #-
> # initialize request object
> #-
>   
>   my $r   = shift;
>   my $log = $r->server->log;
> 
> #-
> # print $r->headers_out in a pretty format
> #-
> 
>   my $headers_out = $r->headers_out;
> 
>   $log->info("headers_out:");
> 
>   $headers_out->do(sub {
> my ($field, $value) = @_;
> if ($field =~ m/Cookie/) {
>   my @values = split /;/, $value;
>   $log->info("\tfield = $field, value = $values[0]");
>   for (my $i=1;$i < @values; $i++) {
> $log->info("\t\t\t\t   $values[$i]");
>   }
> }
> else { 
>   $log->info("\tfield = $field, value = $value");
> }
> 1;
>   });   
> 
> 

RE: Set DocumentRoot from modperl

[Michael]

> Sergio,
> 
>I just walked this route...
> 
>The long and short is that it can't be done anything close to
>feasably.

There is a work around to this. If you use the syntax


perlcode
perlcode
require 'somefile.cgi';
more perl
more perl

then the cgi script gets imported into the environment and RUN with 
the current document root rather than the one for modperl for the 
whole system. Yeah, it's messy and require was not intended to be 
used quite that way, but it works!

> 
>You'll have to write your own URI Translator and alter some code
>so that
> you can 
>introduce your DOCUMENT_ROOT down the line to things like the
>mod_cgi
> etc.  If you 
>search the mod_perl forum, you'll see some handy code that one of
>the
> gurus 
>around here provided me use the NOTES table.
> 
>BTW, if you're introducing FrontPage to your masses.  You'll have
>to
> re-write your 
>own fpcount.exe.  The codes not available and it's anybody's
>guess where
> the hell 
>it actually gets the document root from (I even encoded it into
>the
> mod_frontpage.c
>module without success) and naturally the source isn't available.
> 
>Have fun.  I did!
> 
> 
> - Best regards,
> 
> Karyn Ulriksen
> Chief Systems Architect
> PublicHost
> 22 Mauchly, Suite 200
> Irvine, California  92618 USA
> Phone: (949) 743-2000
> email: [EMAIL PROTECTED]
> URL:  http://www.publichost.com
> 
> 
> 
> -Original Message-
> From: Serge mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 28, 2000 1:45 PM To: [EMAIL PROTECTED]
> Subject: Set DocumentRoot from modperl
> 
> 
> 
> Hi,
> I am trying to find a way of setting DocumentRoot (and possibly
> Alias) directly from modperl in order to implement dynamically
> generated virtual hosting. The thing is that my virtualhost
> parameters comes from a database and may change anytime (so I can't
> restart Apache in general), so it is difficult to implement with
> Apache virtual host rewrite, mod_rewrite or even  directives
> in httpd.conf. I tried to use subprocess_env to set this variable,
> but it is useful only for cgi-scripts, not perl or C handlers since
> it sets the Environment variable only.
> 
> Is the only solution to rewrite the URI translation phase so it does
> not use DocumentRoot directive??
> 
> -- 
> Serge Barbosa Da Torre-  [EMAIL PROTECTED]
> 
> "It's not easy, being green."
>   -- Kermit the Frog
> 

Re: [RFI] URI escaping modules?

[Adi]

I use URI::Escape.  Check CPAN.  It allows you to customize which characters
to escape if you don't like the default.

-Adi

Ed Loehr wrote:
> 
> I just noticed that Apache::Util::escape_uri does not escape embedded '&'
> characters as I'd expected.  What is the preferred module for escaping
> '&', '?', etc. when embedded in strings?
> 
> Regards,
> Ed Loehr

[RFI] URI escaping modules?

[Ed Loehr]

I just noticed that Apache::Util::escape_uri does not escape embedded '&'
characters as I'd expected.  What is the preferred module for escaping
'&', '?', etc. when embedded in strings?

Regards,
Ed Loehr

Re: Set DocumentRoot from modperl

[Rodney Broom \(OE\)]

- Original Message -
From: "Serge 


> ...parameters comes from a database
> ...so I can't restart Apache in general

I'll readilly admit that I don't actually know about the specific
performance hits here, but at my last job we did our entire config in Perl.
Yes, we just kicked the server after changes. In fact, the jobs that made
the changes kicked the server them selves.

If you are only having to restart a few times a day, this may be a fast way
to avoid a bunch of devel.

Rodney

RE: Set DocumentRoot from modperl

[Karyn Ulriksen]

Sergio,

   I just walked this route...

   The long and short is that it can't be done anything close to feasably.

   You'll have to write your own URI Translator and alter some code so that
you can 
   introduce your DOCUMENT_ROOT down the line to things like the mod_cgi
etc.  If you 
   search the mod_perl forum, you'll see some handy code that one of the
gurus 
   around here provided me use the NOTES table.

   BTW, if you're introducing FrontPage to your masses.  You'll have to
re-write your 
   own fpcount.exe.  The codes not available and it's anybody's guess where
the hell 
   it actually gets the document root from (I even encoded it into the
mod_frontpage.c
   module without success) and naturally the source isn't available.

   Have fun.  I did!

-
Best regards,

Karyn Ulriksen
Chief Systems Architect
PublicHost
22 Mauchly, Suite 200
Irvine, California  92618 USA
Phone: (949) 743-2000
email: [EMAIL PROTECTED]
URL:  http://www.publichost.com



-Original Message-
From: Serge mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 28, 2000 1:45 PM
To: [EMAIL PROTECTED]
Subject: Set DocumentRoot from modperl



Hi,
I am trying to find a way of setting DocumentRoot (and possibly Alias)
directly from modperl in order to implement dynamically generated 
virtual hosting.
The thing is that my virtualhost parameters comes from a database and
may change anytime (so I can't restart Apache in general), so it is 
difficult to implement with Apache virtual host rewrite, mod_rewrite 
or even  directives in httpd.conf.
I tried to use subprocess_env to set this variable, but it is useful
only for cgi-scripts, not perl or C handlers since it sets the Environment
variable only.

Is the only solution to rewrite the URI translation phase so it does not
use DocumentRoot directive??

-- 
Serge Barbosa Da Torre  -  [EMAIL PROTECTED]

"It's not easy, being green."
-- Kermit the Frog

Set DocumentRoot from modperl

[Serge]

Hi,
I am trying to find a way of setting DocumentRoot (and possibly Alias)
directly from modperl in order to implement dynamically generated 
virtual hosting.
The thing is that my virtualhost parameters comes from a database and
may change anytime (so I can't restart Apache in general), so it is 
difficult to implement with Apache virtual host rewrite, mod_rewrite 
or even  directives in httpd.conf.
I tried to use subprocess_env to set this variable, but it is useful
only for cgi-scripts, not perl or C handlers since it sets the Environment
variable only.

Is the only solution to rewrite the URI translation phase so it does not
use DocumentRoot directive??

-- 
Serge Barbosa Da Torre  -  [EMAIL PROTECTED]

"It's not easy, being green."
-- Kermit the Frog

[PATCH] in memory $Application object for Apache::ASP

[Joel Reed]

this may be a dumb patch to Apache::ASP (at least it is my first).

Rationale:

i have the following issues with the current implementation of $Application

1. everything you store in $Application->{foo} must be 
serializable my MLDBM. (right?) i have SWIG'd c++ classes for
which this will not work.

2. limitation #1 seems to limit Apache:ASP's usefulness as a
cross-platform solution to ActivePerl/IIS/ASP scripts you 
want to move to linux, etc. i want to do this - not sure if
this is really a key thing for joshua though...

So the following patch (which i really hope joshua comments on ;)
fixes my problems (or so it seems). i've made an $Application2 object
which uses the implementation from the mod_perl guide to make a
global variable accessible by all scripts. (i'd love for this to become
the real $Application). It doesn't do everything else $Application
does at this point, but does demonstrate the idea & works on my SWIG'd 
c++ stuff.

i'd love to know if i'm totally of the wall or how to improve this
idea. seems like it would be faster, more like IIS/ASP, and remove
the serializable requirement, although it would jack up memory 
requirements i would imagine. i'd be glad to incorporate any suggested
improvements to make it acceptable to Joshua for inclusion in
Apache::ASP...

--- ASP.pm  Thu Feb  3 20:35:08 2000
+++ /usr/lib/perl5/site_perl/5.005/Apache/ASP.pmTue Mar 28 16:00:19 2000
@@ -1154,6 +1154,8 @@
 # "use vars qw(\$".join(" \$",@Apache::ASP::Objects).');',
   "sub $subid { ",
   ' return(1) unless $_[0]; ', #@_ = ();',
+  "use vars qw(%Application2);",
+  "*Application2 = \\%Apache::ASP::InMemoryApplicationObject::Application2;",
   $$script,
   '}',
  );
@@ -2115,6 +2117,8 @@
 $strict,
 "use vars qw(\$".join(" \$",@Apache::ASP::Objects).');',
 "use lib qw($self->{asp}->{global});",
+"use vars qw(%Application2);",
+"*Application2 = 
+\\%Apache::ASP::InMemoryApplicationObject::Application2;",
 $code,
 'sub exit { $main::Response->End(); } ',
 '1;',
@@ -4464,6 +4468,13 @@
 
 sub connection { shift; }
 
+1;
+
+package Apache::ASP::InMemoryApplicationObject;
+use strict;
+use vars qw(%Application2);
+%Application2 = (
+);
 1;
 
 __END__


-- 

Joel W. Reed  http://ruby.ddiworld.com/jreed
Daddy, why doesn't this magnet pick up this floppy disk?

Re: Apache::StatINC.pm

[Oleg Bartunov]

Sorry for a little off-thread.
What will happen if I use shared library
generated by SWIG when it's updated but
perl module, which is just a wrapper, doesn't
changed. Does Apache::StatINC.pm will take care ?
Do I need just 'touch' perl module.

regards,
Oleg
On Mon, 27 Mar 2000, Ask Bjoern Hansen wrote:

> Date: Mon, 27 Mar 2000 23:56:58 -0800 (PST)
> From: Ask Bjoern Hansen <[EMAIL PROTECTED]>
> To: "[iso-8859-1] René Seindal" <[EMAIL PROTECTED]>
> Cc: Ken Williams <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: Apache::StatINC.pm
> 
> On Mon, 27 Mar 2000, Ask Bjoern Hansen wrote:
> 
> [...]
> > > setting a variable with PerlSetVar would change it to what we have
> > > proposed.
> > 
> > Or maybe it could try the other if the first doesn't work. (Except that
> > might get very confusing.. hmn).
> 
> Sorry about following up to my own message.
> 
> Maybe the clued thing to do would be making our own "require" and add the
> functionality that is like doing a bare "do" of the old filename. (And
> change everything so it would end up doing both what you and Ken is
> proposing and the old thing.
> 
> 
>  - ask
> 
> -- 
> ask bjoern hansen - 
> more than 70M impressions per day, 
> 

_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Signal Abort

[kevin . luo]

Hi,
my environment is 
Server: Apache/1.3.3 (Unix) mod_perl/1.16
on Solaris,

There are message writing to my error-log file again and again
, like below

[Tue Mar 28 17:12:44 2000] [notice] httpd: child pid 1539 exit signal
Abort (6),
 possible coredump in /home/imail/httpd-kevinl

Colud anybody get clue?
Thanks very much.
Below is the output from gdb.

(gdb) where
#0  0xef654c74 in __sigprocmask ()
#1  0xef64b9ac in _resetsig ()
#2  0xef64b0f4 in _sigon ()
#3  0xef64df48 in _thrp_kill ()
#4  0xef5ba608 in abort ()
#5  0xee5ca9b4 in __0FIdumpCorev ()
#6  0xee5ccfbc in __0fILogEventSabortOrExitIfFatalv ()
#7  0xee5cd2b8 in __0fILogEventGhandlev ()
#8  0xee5ce948 in __0fILogEventFraiseUclTCeT ()
#9  0xee6e8d14 in __0FWRAISE_ProcLockAcqOrderUcPCcTC ()
#10 0xee6e1ca4 in __0fGThreadRcheckLockingOrderP6FMutex ()
#11 0xee6e3d84 in __0fFMutexElockRUc ()
#12 0xee6e752c in __0fELockHacquirev ()
#13 0xee6d1af4 in __0fESockGdoSendPUcl ()
#14 0xee6d1fb4 in __0fESockJ_flushBufPUci ()
#15 0xee6d1df8 in __0fESockG_flushUc ()
#16 0xee59fed0 in __0FFflushR6HByteSnk ()
#17 0xee6a68b8 in __0oHByteSnkltPFR6HByteSnk_R6HByteSnk ()
#18 0xee6a4450 in __0fHRMESockLcloseSocketUc ()
#19 0xee6a3ddc in __0oHRMESockdtv ()
#20 0xee67281c in __0fHMSSRMIdPcloseConnectionv ()
#21 0xee8f6f00 in __0oHMSSRMIddtv ()
#22 0xee8f733c in __0oOConnectionInfodtv ()
---Type  to continue, or q  to quit---
#23 0xee8e6d1c in __0FQflushConnectionsv ()
#24 0xee8e7304 in __0FPcacheConnectionR6HMSSRMId ()
#25 0xee8e7574 in __0oPim_MboxInternaldtv ()
#26 0xee8e86b8 in IM_FreeMbox ()
#27 0xef4b8f14 in XS_Mailbox_DESTROY ()
#28 0xf16b0 in Perl_pp_entersub ()
#29 0xb4a74 in perl_call_sv ()
#30 0xf8270 in Perl_sv_clear ()
#31 0xf86c0 in Perl_sv_free ()
#32 0xf8480 in Perl_sv_clear ()
#33 0xf86c0 in Perl_sv_free ()
#34 0xe9a18 in Perl_hv_free_ent ()
#35 0xe9c44 in hfreeentries ()
#36 0xe9c94 in Perl_hv_undef ()
#37 0xf8418 in Perl_sv_clear ()
#38 0xf86c0 in Perl_sv_free ()
#39 0x10d084 in Perl_free_tmps ()
#40 0xeb748 in Perl_pp_nextstate ()
#41 0xeb638 in Perl_runops ()
#42 0xb4a98 in perl_call_sv ()
#43 0x2af2c in perl_call_handler ()
#44 0x29b6c in perl_handler ()
#45 0x683f8 in ap_invoke_handler ()
---Type  to continue, or q  to quit---
#46 0x8d590 in process_request_internal ()
#47 0x8d660 in ap_process_request ()
#48 0x7e4b4 in child_main ()
#49 0x7e95c in make_child ()
#50 0x7eab8 in startup_children ()
#51 0x7fb5c in standalone_main ()
#52 0x80a00 in httpd_main ()
#53 0x27aa8 in main ()

begin:vcard 
n:Luo;Kevin
tel;cell:0937409397
tel;fax:886-02-23686172
tel;work:886-02-23686171 ext 395
x-mozilla-html:FALSE
version:2.1
email;internet:[EMAIL PROTECTED]
title:You Got @mail
adr;quoted-printable:;;12F, No 100, Section 2, Roosevlet RD.,Taipei, Taiwan, R.O.C.=0D=0A=A5x=A5_=A5=AB=C3=B9=B4=B5=BA=D6=B8=F4=A4G=ACq100=B8=B913FTaiwan
x-mozilla-cpt:;-23840
fn:Kevin Luo (ù±Ò»Ê)
end:vcard

RE: :ShareLite with 5.6

[jason kirtland]

The following has cleared up most module problems for me-

Build Perl 5.6 like so:

  Configure -Dbincompat5005 -Accflags=-DPERL_POLLUTE

And then for modules:

  perl Makefile.PL POLLUTE=1

On Linux, IPC::ShareLite passes all tests using the above.

-=j

> -Original Message-
> From: Paul G. Weiss [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 28, 2000 4:18 AM
> To: [EMAIL PROTECTED]
> Subject: IPC::ShareLite with 5.6
> 
> 
> I have been unsuccessful in building IPC::ShareLite,
> which is used by HTML::Template under 5.6.  Two problems:
> 
> (1) It won't build at all w/o adding 
>   #define PERL_POLLUTE 
> 
> before the 
>  
>   #include "EXTERN.h"
>   #include "perl.h"
>   #include "XSUB.h"
> 
> in ShareLite.xs.
> 
> (2) After building it, test fails:
> 
> 1..8
> ok 1
> ok 2
> ok 3
> Bad realloc() ignored at
> /usrl1/home/pweiss/perl-56/lib/site_perl/5.6.0/sun4-solari
s/IPC/ShareLite.pm
> line 111.
> Segmentation Fault (core dumped)
> 
> 
> This also occurs if I build the extension under 5.00503 
> and run in under
> 5.6.  
> 
> Can anyone confirm this problem and suggest a workaround?
> 
> -Paul
> 

Re: [OT slightly] mod_perl developers (do they exist in Buffalo NY?)

[Robert Monical]

Hello,

Looking for a mod_perl developer in Buffalo.
The site is www.destinations.com. The booking
engine bit is mod_perl.
Several new products are in the pipeline.

Please respond to [EMAIL PROTECTED]

Thanks

Have a great day!

--Robert Monical
--Director of CRM Development
[EMAIL PROTECTED]
--Work: 206-855-8222

"The Truth is Out There"

Perl 5.6 issues?

[Aaron Johnson]

I have a sucessfully compiled on Linux (Slackware 3.5) 5.6/1.22/1.3.12 with no
modifications.  All these items worked fine together with 100% pass rate on
tests.

mod_perl - perl Makefile.PL EVERYTHING=1
NON DSO

I have it installed and serving pages with numerous Perl modules.

The two remanining issues for me are HTML::Embperl and SSI.

I have been in contact with Gerald Richter (the author of HTML::Embperl) and he
is looking into it.  See the [EMAIL PROTECTED] mailling list for more
information.

So until that is resolved each child can only serve one request and then dies.
Which is not good if you are running a high traffic site.

I have also noticed that SSI pages are not working.  I notice in the compile
that it says USE_PERL_SSI or something similar, does that in fact mean that SSI
is handled by mod_perl on a mod_perl enabled httpd?  It handles the first SSI
fine, but the page that is called has SSIs inside of it and these cause the page
to "stop". I removed these and then when the included page finishes it does not
return and finish the opening page it "stops" at the end of the include file.  I
believe it causes a segmentation fault and kills the apache child at this point.

Could the segmentation fault be due to the mod_perl code (or more likely changes
in the Perl 5.6 code) and in turn cause the Embperl problems? The Embperl issue
is on file cleanup/close so I am thinking that the same area is handling the
clean up on the SSI page, but the mod_perl test suite shows a pass on SSI. Of
course I am totally guessing here.  (See
http://www.mail-archive.com/embperl@perl.apache.org/ for more information. The
subject is "Compile problems")

I tried the compile with Apache 1.3.9 and it had the same results.

Aaron Johnson

Charles Day wrote:

> H, I removed .../apache/src/modules and it failed "couldn't find
> .../apache/src/modules/standard directory"
>
> Here was my apache configure script...
>
> ./configure \
> --prefix=/usr/local/apache \
> --activate-module=src/modules/perl/libperl.a
>
> There is no libperl.a and here's the ole error message...
>
> mod_perl.c: In function `perl_handler':
> mod_perl.c:783: `PL_siggv' undeclared (first use in this function)
> mod_perl.c:783: (Each undeclared identifier is reported only once
> mod_perl.c:783: for each function it appears in.)
> make[4]: *** [mod_perl.o] Error 1
> make[3]: *** [all] Error 1
> make[2]: *** [subdirs] Error 1
> make[2]: Leaving directory `/usr/src/apache_1.3.12/src'
> make[1]: *** [build-std] Error 2
> make[1]: Leaving directory `/usr/src/apache_1.3.12'
> make: *** [build] Error 2
>
> There is a libperl.module, so I tried agian, with...
>
> --acitvate-module=src/modules/perl/libperl.module
>
> and low an behold, I get an error message "coundn't find libperl.a"
>
> LOL
>
> It installs fine without this --activate-module line, but I think I need
> this.
>
> I'm trying AddModule modules/perl/libperl.a into Configuration now.
>
> apache 1.3.12
> mod_perl 1.21
> perl 5.6
>
> >
> > -Original Message-
> > From: Jim Serio [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, March 27, 2000 4:08 PM
> > To: Charles Day
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: perl 5.6/mod_perl 1.22/apache 1.3.12
> >
> >
> > > Just spent half the day trying marry these 3.  mod_perl doesn't build.
> > > DSO/apxs errors as described by others.  Went back to 1.21, apache
> doesn't
> > > build, PL_siggv errors as described by others.  Don't know what to do
> with
> > > the modperl 2.0XXX.  I think I'll head back to Mr. stable 5.00503.  Sure
> > > wish I knew C.
> >
> > I had initial problems with Apache 1.3.12 and mod_perl 1.21
> > but after removing the perl modules dir and installing
> > mod_perl 1.22 things compiled without any problems. I
> > suggest you try a clean Apache and mod_perl source tree.
> >
> > Jim
> >
>
> --
> Jim Serio - [EMAIL PROTECTED]
> Producer, World of Coasters

Re: [OT slightly] mod_perl developers (do they exist?)

[Stas Bekman]

> > "Jeffrey W. Baker" wrote:
> 
> 
> > > I can't answer your population questions, but I would say that I am an
> > > expert in mod_perl.  I hired two develoeprs who didn't know a whole hell
> > > of a lot about mod_perl, and I taught them all about it in five two-hour
> > > tutorials.  Maybe you could hire some smart guys and teach them the way
> > > of truth.
> 
> 
> I consider myself a perl/mod_perl newbie (have been for a long time, still
> trying to make that leap from "easy things are easy -> difficult things
> possible  :-) I get the sense that more than a few of the gurus on this list
> go thro this tutorial path for new hirees to bring them up to speed.
> 
> My suggestion would be to capture one of two of these tutorial sessions on
> audio tape(assuming employer consent), edit and sync them to a bunch of HTML
> slides and put the whole shebang on the Net...preferably right next to Stas'
> great guide. Some nifty examples of this are at...

Hmm, that's what ORA did at the last Perl conference, although not with
mod_perl talks... They have prepared the audio/video recording of the most
popular sessions and made them available to the public. Not for free of
course.

You probably could have done the same at the ApacheCon, but it's over
already.  Your next chance is the summer's OpenSource conference in
Monterey and the autumn's next ApacheCon in London.

> http://developer.java.sun.com/developer/onlineTraining/webcasts/
> http://www.eckelobjects.com/TIJ2/index.html (Bruce Eckel's nice Java into
> tutorial in PDF with audio)
> I for one find these audio/slide presentations the next best thing to being
> there, less the huge expense of being there.
> 
> I would be willing to contribute my time to this project, which will help me
> along my learning curve. I have a friend who is a TV producer (anyone
> remember Milton Friedman's Free to Choose series on PBS a long time ago?)
> from whom I might perhaps mooch some free audio digitizing/editing time (not
> a promise)...If none of this can be done on an 'open source' basis, as does
> Bruce Eckel, then we can do it on a cost recovery basis so the time
> contributed by various folks (especially the Gurus) could be re-imbursed
> from a reasonable subscription rate. This approach could serve the Perl
> community at large if we do other topics as well. I am very curious to find
> out the opinions of the folks on this list.
> 
> Just my 2cents worth.
> 
> bakki
> 
> Bakki Kudva
> Navaco
> (Electronic Document Management Solutions)
> phone: (814) 833-2592
> fax:  (603) 947-5747
> http://www.navaco.com/
> 
> 



__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/  | mod_perl Guide http://perl.apache.org/guide/ 
mailto:[EMAIL PROTECTED]  | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--

[new module] proposal Apache::DebugHeaders

[Geoffrey Young]

ok, this isn't all that clever, but recently I got tired of writing loops of
warnings to debug headers_in and headers_out over and over again...

all this one does is spit out headers_in in the init phase and headers_out
in the cleanup phase.  Not terribly extensible, but perhaps practical

if anyone thinks it worthy of CPAN, I'll throw it up.  If folks are real
interested, maybe it can be altered somewhat to start an Apache::Debug::
series with stuff working toward similar ends...

Otherwise, feel free to discard it at will...

--Geoff

package Apache::DebugHeaders;

#-
#
# usage: PerlInitHandler Apache::DebugHeaders
#
#-

use 5.004;
use mod_perl 1.21;
use Apache::Constants qw( OK );
use Apache::Log;
use strict;

$Apache::DebugHeaders::VERSION = '0.01';

# set debug level
#  0 - messages at info or debug log levels
#  1 - verbose output at info or debug log levels
$Apache::DebugHeaders::DEBUG = 1;

sub handler {
#-
# initialize request object
#-
  
  my $r   = shift;
  my $log = $r->server->log;

#-
# do some preliminary stuff...
#-

  $log->info("Using Apache::DebugHeaders") 
 if $Apache::DebugHeaders::DEBUG;

#-
# push the PerlFixupHander and PerlCleanupHandler onto the stack
#-

  $r->push_handlers(PerlInitHandler=> 'Apache::DebugHeaders::in');
  $r->push_handlers(PerlCleanupHandler => 'Apache::DebugHeaders::out');

#-
# wrap up...
#-

  $log->info("Exiting Apache::DebugHeaders")
 if $Apache::DebugHeaders::DEBUG;

  return OK;
}

sub in {
#-
# initialize request object
#-
  
  my $r   = shift;
  my $log = $r->server->log;

#-
# print $r->headers_in in a pretty format
#-

  my $headers_in = $r->headers_in;

  $log->info("headers_in:");

  $headers_in->do(sub {
my ($field, $value) = @_;
if ($field =~ m/Cookie/) {
  my @values = split /; /, $value;
  foreach my $cookie (@values) {
$log->info("\tfield = $field, value = $cookie");
  }
}
else { 
  $log->info("\tfield = $field, value = $value");
}
1;
  });   

#-
# wrap up...
#-

  return OK;
}

sub out {
#-
# initialize request object
#-
  
  my $r   = shift;
  my $log = $r->server->log;

#-
# print $r->headers_out in a pretty format
#-

  my $headers_out = $r->headers_out;

  $log->info("headers_out:");

  $headers_out->do(sub {
my ($field, $value) = @_;
if ($field =~ m/Cookie/) {
  my @values = split /;/, $value;
  $log->info("\tfield = $field, value = $values[0]");
  for (my $i=1;$i < @values; $i++) {
$log->info("\t\t\t\t   $values[$i]");
  }
}
else { 
  $log->info("\tfield = $field, value = $value");
}
1;
  });   

#-
# wrap up...
#-

  return OK;
}

1;

__END__

=head1 NAME

Apache::DebugHeaders - log the incoming and outbound HTTP headers

=head1 SYNOPSIS

  httpd.conf:

PerlInitHandler Apache::DebugHeaders

=head1 DESCRIPTION

  Apache::DebugHeaders merely itterates through $r->headers_in and
  $r->headers_out and prints them to the error_log.  It provides an
  easy way to quickly enable and disable debugging behavior - that's
  all.

=head1 NOTES

  Verbose debugging is enabled by setting the variable
  $Apache::DebugHeaders::DEBUG=1 to or greater. To turn off all debug
  information (including the header info, which is the point of this
  module), set your apache LogLevel above info level.

  This is alpha software, and as such has not been tested on multiple
  platforms or environments.  It requi

Re: Apache::GzipChain and Netscape 4.7 doesnt work with hugefiles??

[Bill Jones]

on 3/27/00 10:05 AM, Janning Vygen at [EMAIL PROTECTED] wrote:

> i´ve just downloaded gzipChain and enjoyed the benefits of fast downloads.
> it works fine with lynx, but doesnt work with netscape 4.7 on linux 2.x
> 
> so netscape 4.7 sends a wrong accept-encoding header ??
> 


I haven't had any trouble with Netscape in that regard.  Is the GZIP
decompressor INFOZIP or GZIP ?

But then again, I used GZip to compress the files, not GZipChain.


???
- FCCJ * 501 W State St * Jacksonville, Fl 32202 * 904/632-3089 -

RE: perl 5.6/mod_perl 1.22/apache 1.3.12

[Charles Day]

H, I removed .../apache/src/modules and it failed "couldn't find
.../apache/src/modules/standard directory"

Here was my apache configure script...

./configure \
--prefix=/usr/local/apache \
--activate-module=src/modules/perl/libperl.a

There is no libperl.a and here's the ole error message...

mod_perl.c: In function `perl_handler':
mod_perl.c:783: `PL_siggv' undeclared (first use in this function)
mod_perl.c:783: (Each undeclared identifier is reported only once
mod_perl.c:783: for each function it appears in.)
make[4]: *** [mod_perl.o] Error 1
make[3]: *** [all] Error 1
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/usr/src/apache_1.3.12/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/usr/src/apache_1.3.12'
make: *** [build] Error 2

There is a libperl.module, so I tried agian, with...

--acitvate-module=src/modules/perl/libperl.module

and low an behold, I get an error message "coundn't find libperl.a"

LOL

It installs fine without this --activate-module line, but I think I need
this.

I'm trying AddModule modules/perl/libperl.a into Configuration now.



apache 1.3.12
mod_perl 1.21 
perl 5.6

> 
> -Original Message-
> From: Jim Serio [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 27, 2000 4:08 PM
> To: Charles Day
> Cc: [EMAIL PROTECTED]
> Subject: Re: perl 5.6/mod_perl 1.22/apache 1.3.12
> 
> 
> > Just spent half the day trying marry these 3.  mod_perl doesn't build.
> > DSO/apxs errors as described by others.  Went back to 1.21, apache
doesn't
> > build, PL_siggv errors as described by others.  Don't know what to do
with
> > the modperl 2.0XXX.  I think I'll head back to Mr. stable 5.00503.  Sure
> > wish I knew C.
> 
> I had initial problems with Apache 1.3.12 and mod_perl 1.21
> but after removing the perl modules dir and installing
> mod_perl 1.22 things compiled without any problems. I
> suggest you try a clean Apache and mod_perl source tree.
> 
> Jim
> 


-- 
Jim Serio - [EMAIL PROTECTED]
Producer, World of Coasters

RE: retrieving LogLevel?

[Geoffrey Young]

thanks guys - I'm a novice to xs, but I'll give it a whirl (good learning)
and let you know how it goes...

--Geoff

> -Original Message-
> From: Eric Cholet [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 28, 2000 8:35 AM
> To: 'Geoffrey Young'
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: retrieving LogLevel?
> 
> 
> > hi all...
> > 
> > I've hunted around and can't find a method that retrieves the
> > LogLevel directive setting.  Is there one?  If not, is 
> there a record
> > somewhere that can make this available, maybe through 
> Apache::Server?
> 
> It's not there currently but could easily be. Try this patch:
> 
> Index: Server.xs
> ===
> RCS file: /home/cvs/modperl/src/modules/perl/Server.xs,v
> retrieving revision 1.6
> diff -b -u -r1.6 Server.xs
> --- Server.xs   1999/08/20 08:34:43 1.6
> +++ Server.xs   2000/03/28 13:33:34
> @@ -113,6 +113,18 @@
>
>  #  char *error_fname;
>  #  FILE *error_log;
> +#  int loglevel;
> +
> +int
> +loglevel(server)
> +Apache::Server server
> +
> +CODE:
> +RETVAL = server->loglevel;
> +
> +OUTPUT:
> +RETVAL
> +
>  
>  #  /* Module-specific configuration for server, and defaults... */
> 
> 
> To be complete I'd also patch Constants.xs to import the relevant
> LOGLEVEL_XXX constants.
> 
> Let me know if this works,
> 
> --
> Eric
> 

RE: retrieving LogLevel?

[Eric Cholet]

> hi all...
> 
>   I've hunted around and can't find a method that retrieves the
> LogLevel directive setting.  Is there one?  If not, is there a record
> somewhere that can make this available, maybe through Apache::Server?

It's not there currently but could easily be. Try this patch:

Index: Server.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Server.xs,v
retrieving revision 1.6
diff -b -u -r1.6 Server.xs
--- Server.xs   1999/08/20 08:34:43 1.6
+++ Server.xs   2000/03/28 13:33:34
@@ -113,6 +113,18 @@
   
 #  char *error_fname;
 #  FILE *error_log;
+#  int loglevel;
+
+int
+loglevel(server)
+Apache::Server server
+
+CODE:
+RETVAL = server->loglevel;
+
+OUTPUT:
+RETVAL
+
 
 #  /* Module-specific configuration for server, and defaults... */


To be complete I'd also patch Constants.xs to import the relevant
LOGLEVEL_XXX constants.

Let me know if this works,

--
Eric

Re: retrieving LogLevel?

[James G Smith]

Geoffrey Young <[EMAIL PROTECTED]> wrote:
>hi all...
>
>   I've hunted around and can't find a method that retrieves the
>LogLevel directive setting.  Is there one?  If not, is there a record
>somewhere that can make this available, maybe through Apache::Server?

Looks like it is in the C API - but don't see a documented reference
to it in the Perl API.

The following might get you started (in src/modules/perl/Server.xs):

 int
 loglevel(server)
 Apache::Server  server
 
 CODE:
 RETVAL = server->loglevel;
 
 OUTPUT:
 RETVAL

I couldn't find any mention of loglevel in the .xs files in such a way
that Perl code would have access to it.  I've also never coded with XS,
so the above is based on the pattern established in Server.xs.
+-
James Smith - [EMAIL PROTECTED] | http://www.jamesmith.com/
[EMAIL PROTECTED] | http://sourcegarden.org/
  [EMAIL PROTECTED]  | http://cis.tamu.edu/systems/opensystems/
+--

RE: :ShareLite with 5.6

[Paul G. Weiss]

By the way, this is under Solaris 2.6, with none
of the threading options selected in the build.

-Paul

> -Original Message-
> From: Paul G. Weiss 
> Sent: Tuesday, March 28, 2000 7:18 AM
> To: [EMAIL PROTECTED]
> Subject: IPC::ShareLite with 5.6
> 
> 
> I have been unsuccessful in building IPC::ShareLite,
> which is used by HTML::Template under 5.6.  Two problems:
> 
> (1) It won't build at all w/o adding 
>   #define PERL_POLLUTE 
> 
> before the 
>  
>   #include "EXTERN.h"
>   #include "perl.h"
>   #include "XSUB.h"
> 
> in ShareLite.xs.
> 
> (2) After building it, test fails:
> 
> 1..8
> ok 1
> ok 2
> ok 3
> Bad realloc() ignored at
> /usrl1/home/pweiss/perl-56/lib/site_perl/5.6.0/sun4-solaris/IP
> C/ShareLite.pm
> line 111.
> Segmentation Fault (core dumped)
> 
> 
> This also occurs if I build the extension under 5.00503 and 
> run in under
> 5.6.  
> 
> Can anyone confirm this problem and suggest a workaround?
> 
> -Paul
> 

Re: problem with Apache::Status and geting memory usage mod_perl 1.22/Apache.1.3.12

[Stas Bekman]

> From:
> http://myhost.mydomain.com/perl-status?Apache::DBI
> 
> I click on :
> Memory Usage 
> 
> I get :
> Memory Usage for package Apache::DBI
> 
> HTTP/1.1 500 Internal Server Error
> Date: Mon, 27 Mar 2000 20:36:23 GMT
> Server: Apache/1.3.12 (Unix) mod_perl/1.22
> Connection: close
> Content-Type: text/html
> 
> >From the error_log:
> [Mon Mar 27 12:33:50 2000] [error] Undefined subroutine
> &B::TerseSize::package_size called at
> /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/Status.pm line 380.
> 
> The module is installed:
> find /usr/lib/perl5/. -name "*TerseSize*" -print
> /usr/lib/perl5/./man/man3/B::TerseSize.3
> /usr/lib/perl5/./site_perl/5.005/i386-linux/B/TerseSize.pm
> 
> Any idea what the problem is?

Try to preload the module:
 PerlModule B::TerseSize

See
http://perl.apache.org/guide/performance.html#Measuring_the_Subroutines_Memory

__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/  | mod_perl Guide http://perl.apache.org/guide/ 
mailto:[EMAIL PROTECTED]  | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--

retrieving LogLevel?

[Geoffrey Young]

hi all...

I've hunted around and can't find a method that retrieves the
LogLevel directive setting.  Is there one?  If not, is there a record
somewhere that can make this available, maybe through Apache::Server?

thanks

--Geoff

IPC::ShareLite with 5.6

[Paul G. Weiss]

I have been unsuccessful in building IPC::ShareLite,
which is used by HTML::Template under 5.6.  Two problems:

(1) It won't build at all w/o adding 
#define PERL_POLLUTE 

before the 
 
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

in ShareLite.xs.

(2) After building it, test fails:

1..8
ok 1
ok 2
ok 3
Bad realloc() ignored at
/usrl1/home/pweiss/perl-56/lib/site_perl/5.6.0/sun4-solaris/IPC/ShareLite.pm
line 111.
Segmentation Fault (core dumped)


This also occurs if I build the extension under 5.00503 and run in under
5.6.  

Can anyone confirm this problem and suggest a workaround?

-Paul

Re: [asp] $Response->{FontFace} ?

[Ime Smits]

- Original Message -
From: Joshua Chamas <[EMAIL PROTECTED]>
To: Mod Perl <[EMAIL PROTECTED]>
Sent: Tuesday, March 28, 2000 09:45
Subject: [asp] $Response->{FontFace} ?


| I have a huge site that I want to apply a generic font face
| to with Apache::ASP.  Has anyone here ever been bothered before
| that you can't just wrap the body doc with a default font and
| have that be it.

Hi,

There is a HTML tag for it, but as far is I know it isn't really part of the
W3 standard:



Put this in your document just between  and  and for MSIE 4+
and some of the newer
Netscapes, this will set the global font, even within tables.

I think implementing something like a $Response->{FontFace} tag or the like
which automagically inserts tags after each
 tag is a general bad idea, because it can easily break things and it
won't produce good HTML, because then you also should make Apache::Asp to
also insert closing tags, meaning it should have at least some sense what is
going on, causing everything to slow down. If some browsers (especially
Netscape) already give very unpredictable results if one messes a bit with
the closing order of tags (try to do a BoldItalicPlain and see for yourself), I
think you would agree on me.

Ime

Re: [asp] $Response->{FontFace} ?

[G.W. Haywood]

Hi Joshua,

On Mon, 27 Mar 2000, Joshua Chamas wrote:

> I have a huge site that I want to apply a generic font face to with
> Apache::ASP.  Has anyone here ever been bothered before that you
> can't just wrap the body doc with a default font and have that be
> it.  No CSS please.  But what about those pesky s that seem
> to break it all?

Yeah, I've bothered.  I really don't care about the font face, but I
want to talk about the SIZE.  But it *has* to be configurable per
client.  When you get to my age, the fine print on the majority of Web
sites is completely illegible with the default browser text sizes.
Young whipper-snappers writing HTML don't realize what a problem that
can be.  So I want my older users (they have more money...) to be able
to read my sites.

There are millions of visually impaired people (ten percent of males
are red/green colour blind) who would bless you if they knew you had
done a little something to make the Web more accessible to them.  They
could choose their own colours as well as text size and font.

So please, Joshua, do it, or I'll have to invent my own tags.  I was
thinking of something like a chained Apache::Footer with some sort of

s//<$FONT_TAG_per_client_session_or_maybe_loginid>/;

construct in it so that users could click on

Bigger Text

or

Smaller Text

but I'm well aware that this would be a crude implementation of what
could be a really nifty feature.

> {FontFace}> at the start of a 
> Script_OnFlush hook,

Don't have any strong feelings on the implementation.  I would use
extra path info, probably with handlers to strip out the mush, but I
suppose you'd want to make it cookie based?

73,
Ged.