mod_perl and ssi

[Kenneth Lee]

which handler comes first? PerlHandler or mod_include?
i want to have my PerlHandler generate a SSI skeleton and then 
pass it the mod_include's parser to insert some existing static 
HTMLs. push_handler() and set_handler() doesn't work for me.

or is it better to parse the skeleton myself? but i still wonder 
if there's any way to chain non-perl handlers.

happy perling,
kenneth

Re: speed up/load balancing of session-based sites - POT

[Greg Cope]

From: "Perrin Harkins" <[EMAIL PROTECTED]>
To: "Greg Cope" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: 13 May 2000 01:57
Subject: Re: speed up/load balancing of session-based sites - POT


: On Sat, 13 May 2000, Greg Cope wrote:
: > : Likewise with sessions. Even if you load balance across multiple
machines
: > : you don't need to access a session database on every request. Most
load
: > : balancing systems have something so they'll send the seme "session"
: > : (typically ip address) to the same backend server for N seconds as
long as
: > : the backend server is up of course.
: > :
: > : You can then put a daemon on each backend server as a local buffer and
: > : cache between the httpds and the session database. This daemon can
even
: > : load balance the session information over several databases if it's
: > : needed.
: > :
: > : viola, a lot less "real time" lookups in the database needed and a lot
: > : less direct connections.
: [...]
: > But - is this model not transaction safe ? - It may save alot of DB use
and
: > hence be alot quicker - but what if the webserver "disappears" halfway
: > through an IP based load ballanced "sesssion" - a potential source of
: > failure - something which a load ballancer is supposed to help with..
: >
: > Also if the loadballance goes south, and a secound takes over does it
have
: > the same IP based session info (probably not - but could be wrong ...) -
: > hence another potential source of failure.
:
: You have to do a write-through cache, i.e. you must write to the database
: as well as the cache, but you only have to READ the database if you don't
: find the session in the cache.  If you have a fair amount of read-only use
: of the session this can be a big win.

Ok - but I find that most of my session stuf updates a "last access"
atribute within the session and hence is mostly read + write - not just read
but YMMV - good point tho.

Greg

:
: - Perrin
:
:

Re: speed up/load balancing of session-based sites - POT

[Perrin Harkins]

On Sat, 13 May 2000, Greg Cope wrote:
> : Likewise with sessions. Even if you load balance across multiple machines
> : you don't need to access a session database on every request. Most load
> : balancing systems have something so they'll send the seme "session"
> : (typically ip address) to the same backend server for N seconds as long as
> : the backend server is up of course.
> :
> : You can then put a daemon on each backend server as a local buffer and
> : cache between the httpds and the session database. This daemon can even
> : load balance the session information over several databases if it's
> : needed.
> :
> : viola, a lot less "real time" lookups in the database needed and a lot
> : less direct connections.
[...]
> But - is this model not transaction safe ? - It may save alot of DB use and
> hence be alot quicker - but what if the webserver "disappears" halfway
> through an IP based load ballanced "sesssion" - a potential source of
> failure - something which a load ballancer is supposed to help with..
> 
> Also if the loadballance goes south, and a secound takes over does it have
> the same IP based session info (probably not - but could be wrong ...) -
> hence another potential source of failure.

You have to do a write-through cache, i.e. you must write to the database
as well as the cache, but you only have to READ the database if you don't
find the session in the cache.  If you have a fair amount of read-only use
of the session this can be a big win.

- Perrin

Re: mod_perl-perl5.6.0

[Doug MacEachern]

On Fri, 12 May 2000, Asghar Nafarieh wrote:

> Hi,
> 
> I just upgrated my perl5.6.0 from 5.005 and I cannot get mod_perl to work for
> me. I recompiled and installed mod_perl_1.23, but I get error "document 
> contains no data" prompt from the browser when I activate the mod_perl
> module. 
> 
> Has anyone have this problem?

yes, it's been explained several times in the past few weeks, here's one
from today...

Date: Fri, 12 May 2000 11:28:08 -0700 (PDT)
From: Doug MacEachern <[EMAIL PROTECTED]>
To: Brian P Millett <[EMAIL PROTECTED]>
cc: modperl <[EMAIL PROTECTED]>
Subject: Re: [Fwd: [apache-users] Core with x86 solaris & modperl]

i'm going to release 1.24 asap to stop this madness.  looks like another
case of the 5.6.0 largefile support bug, which the patch below will fix.
for apxs, you'll need to build apache like so:
CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
./configure \
...

--- Makefile.PL 2000/04/21 19:37:45 1.159
+++ Makefile.PL 2000/04/27 22:45:30 1.160
@@ -186,7 +186,7 @@
 $PERL_DEBUG = "";
 $PERL_DESTRUCT_LEVEL = "";
 $PERL_STATIC_EXTS = "";
-$PERL_EXTRA_CFLAGS = "";
+$PERL_EXTRA_CFLAGS = $] >= 5.006 ? $Config{ccflags} : "";
 $SSLCacheServerPort = 8539;
 $SSL_BASE = ""; 
 $Port = $ENV{HTTP_PORT} || 8529;

Re: speed up/load balancing of session-based sites - POT

[Greg Cope]

POT = Possibly Off topic


: Likewise with sessions. Even if you load balance across multiple machines
: you don't need to access a session database on every request. Most load
: balancing systems have something so they'll send the seme "session"
: (typically ip address) to the same backend server for N seconds as long as
: the backend server is up of course.
:
: You can then put a daemon on each backend server as a local buffer and
: cache between the httpds and the session database. This daemon can even
: load balance the session information over several databases if it's
: needed.
:
: viola, a lot less "real time" lookups in the database needed and a lot
: less direct connections.

ironically I was thinking the same thing today (I may need to load ballance
3 webservers to one DB server).

But - is this model not transaction safe ? - It may save alot of DB use and
hence be alot quicker - but what if the webserver "disappears" halfway
through an IP based load ballanced "sesssion" - a potential source of
failure - something which a load ballancer is supposed to help with..

Also if the loadballance goes south, and a secound takes over does it have
the same IP based session info (probably not - but could be wrong ...) -
hence another potential source of failure.

If your model can accept this then fine - but this would not work in a
{few|many} ecomerce apps as session management is critical.

What do you think ?

Greg Cope
:
:
:  - ask
:
: --
: ask bjoern hansen - 
: more than 70M impressions per day, 
:
:

Re: speed up/load balancing of session-based sites

[Ask Bjoern Hansen]

On Thu, 11 May 2000, Leslie Mikesell wrote:

[...]
> else that could be done on that hardware.  However I recently inherited
> another system that is falling on its face at a much lighter load.  It
> appears to be using tmp files to sort some ORDER BY clauses that
> I haven't had time to fix yet.   Is there any efficient way to pull
> the newest N items from a large/growing table as you do a join
> with another table?  As a quick fix I've gone to a static snapshot
> of some popular lists so I can control how often they are rebuilt. 

If at all possible avoid doing the database lookups per request in the
first place.

Very very often you can design whatever you do so the data can be in
static files exported every few [timeunit]s, you summarize the big
database in smaller tables, in Storable files or something like that.

If you can get your system to something like that it will scale a lot
better.

Likewise with sessions. Even if you load balance across multiple machines
you don't need to access a session database on every request. Most load
balancing systems have something so they'll send the seme "session"
(typically ip address) to the same backend server for N seconds as long as
the backend server is up of course.

You can then put a daemon on each backend server as a local buffer and
cache between the httpds and the session database. This daemon can even
load balance the session information over several databases if it's
needed.

viola, a lot less "real time" lookups in the database needed and a lot
less direct connections.


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: mod_perl-perl5.6.0

[Ask Bjoern Hansen]

On Fri, 12 May 2000, Asghar Nafarieh wrote:

> I just upgrated my perl5.6.0 from 5.005 and I cannot get mod_perl to work for
> me. I recompiled and installed mod_perl_1.23, but I get error "document 
> contains no data" prompt from the browser when I activate the mod_perl
> module. 
> 
> Has anyone have this problem?

What does the errorlog file?

if you get a coredump then please try to make a backtrace as described in
the SUPPORT document.


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

mod_perl-perl5.6.0

[Asghar Nafarieh]

Hi,

I just upgrated my perl5.6.0 from 5.005 and I cannot get mod_perl to work for
me. I recompiled and installed mod_perl_1.23, but I get error "document 
contains no data" prompt from the browser when I activate the mod_perl
module. 

Has anyone have this problem?


Thanks,

-Asghar

Re: works on linux, doesn't work on sun.

[scotta]

Thanks people.  I totally blanked on that.

works fine now.  really appriciate the help.

Scott

___cliff rayman___ wrote:
> 
> [EMAIL PROTECTED] wrote:
> 
> > 
> > SetHandler  perl-script
> > PerlSendHeader on
> > PerlHandler Mf7
> 
>Options +ExecCGI
> 
> >
> > 
> >
> > is whats in the httpd.conf
> 
> --
> ___cliff [EMAIL PROTECTED]

Re: works on linux, doesn't work on sun.

[___cliff rayman___]

[EMAIL PROTECTED] wrote:

> 
> SetHandler  perl-script
> PerlSendHeader on
> PerlHandler Mf7

   Options +ExecCGI

>
> 
>
> is whats in the httpd.conf

--
___cliff [EMAIL PROTECTED]

Oops Re: ANNOUNCE: mod_perl guide version 1.23

[Stas Bekman]

Oops sorry for the typo... something is wrong with me... really

It's the guide... not mod_perl... luckily mod_perl 1.23 was already
announced :) 

Enjoy!

__
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
--

ANNOUNCE: mod_perl version 1.23

[Stas Bekman]

The mod_perl Guide version 1.23 is online at http://perl.apache.org/guide
and at CPAN: 
  file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.23.tar.gz
  size: 457357 bytes
   md5: 44acefc9d60a114f72f9dd0a35e152d0

(please allow a few hours for the mirrors to get oupdated with a new
version). 

The changes since the last version:

* guide's layout changed: Now there are two index files -- the default
  index.html shows only the names of the chapters in TOC, the new
  index_long.html shows the full TOC as before.

* guide's layout changed: Changed to simple black_on_white no fancy
  frames and colors anymore

* guide: Changed the order of the the chapters towards logical
  sequentiality. 

* snippets: new: "Sending Cookies in REDIRECT Response" (Doug)

* help: new: added the digest list info (Ask Bjoern Hansen)

* performance: new: "Limiting the Number of Processes Serving the Same
  Resource"

* troubleshooting: updated: "RegistryLoader: Translation of uri [...]
  to filename failed"

* porting: update: "using format() and write()" -- using sprintf (Matt
  Sergeant)

* perl: new: "Variables Globally, Lexically Scoped And Fully
  Qualified" (Ged W. Haywood)

* build suite: documenting the build script so others could reuse this
  code in their documentation generation chores.

* performance: a complete reorganizing of the content toward a better
  navigatibility.

* strategy: removed "Multithreading or not Multithreading" -- has
  flaws and needs a rewrite

* performance: update: "KeepAlive" -- works only if there is a
  Content-Length header (Andreas Koenig)

* help: new: "get help with CVS"

* troubleshooting: new: "Segfaults when using XML::Parser" (DeWitt
  Clinton)

* performance: new: "Do Not Run Everything on One mod_perl Server"
  (Joshua Chamas, Shane [EMAIL PROTECTED], Gunther Birznieks)
 
* minor corrections: scenario (Eric Jain), debug (Geoffrey Young).

* install: new: "mod_perl and Raven SSL" (Doug)

* scenario: new: "mod_proxy: Security Issues" (Eric Cholet)

* performance: new: "Improving Perl Code Performance Hints" =>
  "Concatination or List" (Doug)

* debug: new: "hanging processes detection: Using the Perl Trace"

* debug: new:  "Hanging because of the OS Problem" (Greg Stark)

* install: new: "About gdbm, db and ndbm libraries" (Les Mikesell)

* performance: new: "Benchmarking Apache::Registry and Perl Content
  Handler"

* performance: new: "Benchmarking CGI.pm and Apache::Request"

* porting: new: "Transitioning from Apache::Registry to Apache
  handlers"

* config: new: "Alias and Rewrite Conflicts" (Eric Cholet, Ask Bjoern
  Hansen, Vivek Vhera)

* scenario: new: "Front-end Back-end Proxying with Virtual Hosts"
  (Vivek Vhera, Eric Cholet)

* install: new: "APACHE_USER and APACHE_GROUP env" (Doug)

* config: new: "Overriding  Setting in "Sub-Location""
  (Darren Chamberlain, Vivek Vhera)

* review: Mark Summerfield has reviewed these chapters: porting,
  correct_headers, intro, multiuser, snippets and performance.

* troubleshooting: new: "Processes Get Stuck on Graceful Restart" (Doug)

* debug: updated: "Safe Resource Locking" added utils to trace the
  open files owner processes. (Doug, Eric Cholet)

* databases: new: "Database Locking Risks"

* performance: update: "Limiting the Resources Used by httpd
  Children", explanation of the soft and hard limits (Eric Cholet)

* help: added subscription info for perl5-porters mailing list

* perl: new: "Exception Handling for mod_perl" (Matt Sergeant)

* review: Ged W. Haywood was very kind to review and correct the
  config, perl, dbm, snippets, advocacy, browserbugs, download, help,
  modules, troubleshooting, multiuser, obvious, correct_headers,
  status and hardware chapters.

* modules: new: "Apache::RequestNotes" (Geoffrey Young)

See http://perl.apache.org/guide

Enjoy!

__
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
--

Re: Apache::DBI with Sybase - What's wrong?

[Manfred Dehnkamp]

"Graf, Chris" schrieb:

> Thanks Michael.
>
> If anyone can explain a little better what Apache::DBI and mod_perl are
> doing, or should be doing at this point, that may be helpful. I have been
> testing a little more and found that no errors will appear unless I am
> actually doing something with the connections. If I just initiate the
> persistent connections the first time the scripts run, and never touch them,
> they appear to stay alive (or at least restart properly) without generating
> errors.

Hy,
I had serious sockket/connect  porblems too ;-(( that was using 11.0.3.
I changed to 11.9.2 and now everything is fine
(Everything on RedHat 6.2).
My problem was somewhere in the clientlibrary : let's say a couple of
hundred/thousand queries went fine. Than my application stopped running.
The Process in the database (sp_who) was existing, and killing the DB-connection

caused the client to die. ;-))
Maybe it's worth to try an upgrade if you are running 11.0.3 ...


regards
Fred

works on linux, doesn't work on sun.

[scotta]

The company I work for bought a company with three websites.

We are having two of them point to our main server and trying to give
them a source so we knew where they came from.
the dns will point to our normal server and I've been working on putting
in the code to do the redirection.

I have tested this on my linux box, and it works perfectly.  it gets the
domains right, and declines stuff that it should use.
the problem is that when I install and run them on the sun 420 box, the
module runs fine for the re-direction, but cgi scripts inside of the
root directory don't run anymore.


SetHandler  perl-script
PerlSendHeader on
PerlHandler Mf7
   

is whats in the httpd.conf

server is apache 1.3.12 with mod_perl 1.23 installed for both my box and
the main server.

Any ideas why the cgi just sends the text and doesn't execute when I've
got the location there.

Scott

RE: Apache::DBI with Sybase - What's wrong?

[Graf, Chris]

Thanks Michael. 

If anyone can explain a little better what Apache::DBI and mod_perl are
doing, or should be doing at this point, that may be helpful. I have been
testing a little more and found that no errors will appear unless I am
actually doing something with the connections. If I just initiate the
persistent connections the first time the scripts run, and never touch them,
they appear to stay alive (or at least restart properly) without generating
errors. 

If I do queries against the connections, they will start to generate these
errors starting about 15 mins after Apache startup (with about 100-150 httpd
processes running at any given time). The errors will become more and more
frequent after they start, which leads me to believe that when the
connection goes bad in an httpd process, it doesn't correct itself. I also
have two other Apache::DBI connections to a MySQL server running in the same
connect sub which never have a problem. 

Here is the exact complete error log in sequence from the time I started
Apache until I shut it down. The first error appeared about 15 mins after
restart. The rest happened within about a minute after the first one. 

--- Apache startup 

ct_cmd_alloc failed at /home/httpd/uoboards/cgi-bin/w3t.pm line 1322.
DBD::Sybase::st execute failed: OpenClient message: LAYER = (1) ORIGIN = (1)
SEVERITY = (1) NUMBER = (50)
Message String: ct_cmd_alloc(): user api layer: external error: The
connection has been marked dead.

ct_cmd_alloc failed at
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159.
DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3)
SEVERITY = (5) NUMBER = (6)
Message String: ct_cancel(): network packet layer: internal net library
error: Net-Library operation terminated due to disconnect

ct_cmd_alloc failed at
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159.
DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3)
SEVERITY = (5) NUMBER = (6)
Message String: ct_cancel(): network packet layer: internal net library
error: Net-Library operation terminated due to disconnect

ct_cmd_alloc failed at
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159.
DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3)
SEVERITY = (5) NUMBER = (6)

Message String: ct_cancel(): network packet layer: internal net library
error: Net-Library operation terminated due to disconnect
DBD::Sybase::db ping failed: OpenClient message: LAYER = (1) ORIGIN = (1)
SEVERITY = (1) NUMBER = (60)

Message String: ct_cancel(CONN,ALL): user api layer: external error: There
is a usage error.  This routine has been called at an illegal time.
OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60)

Message String: ct_close(FORCE): user api layer: external error: There is a
usage error.  This routine has been called at an illegal time.
DBD::Sybase::db ping failed: OpenClient message: LAYER = (1) ORIGIN = (1)
SEVERITY = (1) NUMBER = (60)

Message String: ct_cancel(CONN,ALL): user api layer: external error: There
is a usage error.  This routine has been called at an illegal time.
OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60)

Message String: ct_close(FORCE): user api layer: external error: There is a
usage error.  This routine has been called at an illegal time.
DBD::Sybase::db ping failed: OpenClient message: LAYER = (1) ORIGIN = (1)
SEVERITY = (1) NUMBER = (60)

Message String: ct_cancel(CONN,ALL): user api layer: external error: There
is a usage error.  This routine has been called at an illegal time.
OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60)
Message String: ct_close(FORCE): user api layer: external error: There is a
usage error.  This routine has been called at an illegal

--- shutdown occurs here 

syb_db_disconnect(): ct_con_drop() failed
syb_db_disconnect(): ct_con_drop() faile

Thanks


> 
 > It seems that once processes start getting reused, I wind up with a ton
of
 > DB error messages in my error_log. 
 > 
 > They seem to start like this:
 > 
 > ct_cmd_alloc failed at
 > /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159.
 > DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3)
 > SEVERITY = (5) NUMBER = (6)
 > Message String: ct_cancel(): network packet layer: internal net library
 > error: Net-Library operation terminated due to disconnect

I'm not familiar with Apache::DBI, so I don't know exactly in what
situation it calls ping()... In this case it looks like ping fails (ie 
the connection to the server has been killed) but the sequence of
calls that follow is incorrect.

 > What is happening on the user end at this time - 500s? Any insight would
be
 > incredibly helpful at this point.

I think there's a good chance of 500s, but maybe not. It's possible
that these are internal warnings, and that the initial failed ping()
causes a database re

Cookies and Virtual Host ServerName

[William Rico]

I encountered a weird problem while writing a 
simple authentication handler (based on TicketTool from the eagle book again : 
).  
 
My virtual host was setup as 
follows...
DocumentRoot 
/usr/local/apache/htdocsServerName mydomain
...

 
In my authentication handler I tried setting a 
cookie with a command like this:
$r->err_headers_out->add('Set-Cookie' => 
"easy=123; domain=mydomain");
 
However, Apache would not send the cookie to 
the server.  When I removed the "domain" setting from the cookie, it 
worked, and sent over a cookie with domain "mydomain" which is exactly what I 
was trying to achieve when explicitly setting the domain.  Why wouldn't 
Apache send my original cookie?
 
After some more testing, I realized that setting my 
VirtualHost up with a fully qualified ServerName also solves the problem.  
In other words, changing the virtual host to this:

DocumentRoot 
/usr/local/apache/htdocsServerName www.mydomain.com
...

 
...allows me to set the domain in my cookie (e.g. "domain=mydomain.com") 
and have it sent.  Checking the Apache documentation, I found that the 
syntax for ServerName requires it to be fully qualified.  However, not 
using a fully qualified domain name seems to work for other purposes, and I 
can't figure out the reason for a conflict with cookies.  I know it's not 
going to get the lost hair back on my head, but I'd still like to understand 
what's going on.
 
Thanks,
Will
 
 

Re: [Fwd: [apache-users] Core with x86 solaris & modperl]

[Doug MacEachern]

> Did this.  Recompiled Apache, modperl, jserv.  Same results. :-(

what if you use Perl 5.005_03?  or 5.006 Configure-d with -Uuselargefiles?

Re: Apache::DBI with Sybase - What's wrong?

[Michael Peppler]

Graf, Chris writes:
 > 
 > It seems that once processes start getting reused, I wind up with a ton of
 > DB error messages in my error_log. 
 > 
 > They seem to start like this:
 > 
 > ct_cmd_alloc failed at
 > /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159.
 > DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3)
 > SEVERITY = (5) NUMBER = (6)
 > Message String: ct_cancel(): network packet layer: internal net library
 > error: Net-Library operation terminated due to disconnect

I'm not familiar with Apache::DBI, so I don't know exactly in what
situation it calls ping()... In this case it looks like ping fails (ie 
the connection to the server has been killed) but the sequence of
calls that follow is incorrect.

 > What is happening on the user end at this time - 500s? Any insight would be
 > incredibly helpful at this point.

I think there's a good chance of 500s, but maybe not. It's possible
that these are internal warnings, and that the initial failed ping()
causes a database reconnect and that things continue cleanly...

Michael
-- 
Michael Peppler -||-  Data Migrations Inc.
[EMAIL PROTECTED]-||-  http://www.mbay.net/~mpeppler
Int. Sybase User Group  -||-  http://www.isug.com
Sybase on Linux mailing list: [EMAIL PROTECTED]

Re: [Fwd: [apache-users] Core with x86 solaris & modperl]

[Brian P Millett]

Doug MacEachern wrote:

> i'm going to release 1.24 asap to stop this madness.  looks like another
> case of the 5.6.0 largefile support bug, which the patch below will fix.
> for apxs, you'll need to build apache like so:
> CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
> ./configure \
> ...
>
> --- Makefile.PL 2000/04/21 19:37:45 1.159
> +++ Makefile.PL 2000/04/27 22:45:30 1.160
> @@ -186,7 +186,7 @@
>  $PERL_DEBUG = "";
>  $PERL_DESTRUCT_LEVEL = "";
>  $PERL_STATIC_EXTS = "";
> -$PERL_EXTRA_CFLAGS = "";
> +$PERL_EXTRA_CFLAGS = $] >= 5.006 ? $Config{ccflags} : "";
>  $SSLCacheServerPort = 8539;
>  $SSL_BASE = "";
>  $Port = $ENV{HTTP_PORT} || 8529;

Did this.  Recompiled Apache, modperl, jserv.  Same results. :-(

Modperl & Apache without Raven does work.  But Raven, Modperl, Apache =
core.

--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
[EMAIL PROTECTED]   Greg Glenn

Segmentation fault (11) with mod_perl 1.23...

[Mark Haviland]

Hey all...

I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with
mod_perl (1.23) as a DSO (outside the Apache tree using apxs).  Now,
modules that use to work are suddenly causing seg faults.  The one in
particular that doens't seem to jive with mod_perl is Sybase::CTlib.
Has anybody else seen this problem ?

Here's a dump of my apache start-up (with MOD_PERL_TRACE=all).  Can
anyone give me a clue as to what's going on ?

-Mark Haviland

start up...

 /usr/hsi/apache-1.3.12/bin/hsi-httpd -f
/usr/hsi/apache-1.3.12/conf/hsi-httpd.conf.2080

perl_parse args: '/dev/null' ...allocating perl interpreter...ok
constructing perl interpreter...ok
ok
running perl interpreter...ok
mod_perl: 0 END blocks encountered during server startup
loading perl module 'Apache'...loading perl module
'Apache::Constants::Exports'...ok
ok
loading perl module 'Tie::IxHash'...ok
perl_section: 
perl_section: 
perl_section: 
perl_section: 
perl_section: 
perl_section: 
perl_section: 
PerlRequire: arg=`conf/startup_cfg.pl'
attempting to require `conf/startup_cfg.pl'
fetching PerlChildInitHandler stack
PerlChildInitHandler handlers stack undef, creating
pushing CODE ref into `PerlChildInitHandler' handlers
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Apache::Status'
pushing `Apache::Status' into `PerlHandler' handlers
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Apache::Status'
pushing `Apache::Status' into `PerlHandler' handlers


-- from the apache error_log file ---

loading perl module 'Apache'...ok
perl_startup: perl aleady running...ok
[Fri May 12 14:34:43 2000] [info] mod_unique_id: using ip addr
10.251.1.193
cleanup_av: SvREFCNT(0x816d338)==1
cleanup_av: SvREFCNT(0x816d320)==1
Sybase::CTlib dl handle == 0x81b29f0
running 0 END blocks for perl_shutdown
destructing and freeing Perl interpreter (level=0)...ok
unload_xs_so: 0x81b29f0
perl_parse args: '/dev/null' ...allocating perl interpreter...ok
constructing perl interpreter...ok
ok
running perl interpreter...ok
mod_perl: 0 END blocks encountered during server startup
loading perl module 'Apache'...loading perl module
'Apache::Constants::Exports'...ok
ok
loading perl module 'Tie::IxHash'...ok
perl_section: 
perl_section: 
perl_section: 
perl_section: 
perl_section: 
perl_section: 
perl_section: 
PerlRequire: arg=`conf/startup_cfg.pl'
attempting to require `conf/startup_cfg.pl'
fetching PerlChildInitHandler stack
PerlChildInitHandler handlers stack undef, creating
pushing CODE ref into `PerlChildInitHandler' handlers
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Apache::Status'
pushing `Apache::Status' into `PerlHandler' handlers
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Apache::Status'
pushing `Apache::Status' into `PerlHandler' handlers
loading perl module 'Apache'...ok
perl_startup: perl aleady running...ok
[Fri May 12 14:34:44 2000] [info] mod_unique_id: using ip addr
10.251.1.193
[Fri May 12 14:34:45 2000] [info] created shared memory segment #21762
[Fri May 12 14:34:45 2000] [notice] Apache/1.3.12 (Unix) mod_perl/1.23
configured -- resuming normal operations
[Fri May 12 14:34:45 2000] [info] Server built: May 11 2000 16:47:45
perl_init_ids: uid=99, euid=99, gid=99, egid=99
running 1 pushed (stacked) handlers for PerlChildInitHandler...
calling &{PerlChildInitHandler->[0]} (1 total)
perl_call: handler is a cached CV
blessing request_rec=(0x848a064)
[Fri May 12 14:34:45 2000] [notice] 6987 Apache::Sybase::CTlib
PerlChildInitHandler
perl_init_ids: uid=99, euid=99, gid=99, egid=99
running 1 pushed (stacked) handlers for PerlChildInitHandler...
calling &{PerlChildInitHandler->[0]} (1 total)
perl_call: handler is a cached CV
blessing request_rec=(0x848a064)
[Fri May 12 14:34:45 2000] [notice] 6988 Apache::Sybase::CTlib
PerlChildInitHandler
perl_init_ids: uid=99, euid=99, gid=99, egid=99
running 1 pushed (stacked) handlers for PerlChildInitHandler...
calling &{PerlChildInitHandler->[0]} (1 total)
perl_call: handler is a cached CV
blessing request_rec=(0x848a064)
[Fri May 12 14:34:45 2000] [notice] 6989 Apache::Sybase::CTlib
PerlChildInitHandler
perl_init_ids: uid=99, euid=99, gid=99, egid=99
running 1 pushed (stacked) handlers for PerlChildInitHandler...
calling &{PerlChildInitHandler->[0]} (1 total)
perl_call: handler is a cached CV
blessing request_rec=(0x848a064)
[Fri May 12 14:34:45 2000] [notice] 6990 Apache::Sybase::CTlib
PerlChildInitHandler
perl_init_ids: uid=99, euid=99, gid=99, egid=99
running 1 pushed (stacked) handlers for PerlChildInitHandler...
calling &{PerlChildInitHandler->[0]} (1 total)
perl_call: handler is a cached CV
blessing request_rec=(0x848a064)
[Fri May 12 14:34:45 2000] [notice] 6991 Apache::Sybase::CTlib
PerlChildInitHandler
[Fri May 12 14:34:46 2000] [notice] child pid 6991 exit signal
Segmentation fault (11)
[Fri May 12 14:34:46 2000] [notice] child pid 6990 exit signal
Segmentation fault (11)
[Fri May 12 14:34:46 2000] [notice] child pid 6989 exit signal
Segme

Re: Best approach for loading several modules

[Drew Taylor]

Martin Wood wrote:
> 
> > but code isn't duplicated if you pre-load your modules:
> >
> http://perl.apache.org/guide/performance.html#Preload_Perl_Modules_at_Server
> > _S
> 
> I realise the actual code isn't duplicated  - but the script itself still
> needs the list of  "use" directives regardless of whether you pre-load them
> and there doesn't seem to be an easy way to factor this common block of
> unsightly directives out into one file for use in multiple scripts that
> share the same resources.
Are you using OO perl and inheritance? I'm late on this thread, but what
about use'ing a common module which then use'es all the other modules
you need? It's well worth the effort IMHO...

-- 
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/

Apache::DBI with Sybase - What's wrong?

[Graf, Chris]

It seems that once processes start getting reused, I wind up with a ton of
DB error messages in my error_log. 

They seem to start like this:

ct_cmd_alloc failed at
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Sybase.pm line 159.
DBD::Sybase::db ping failed: OpenClient message: LAYER = (5) ORIGIN = (3)
SEVERITY = (5) NUMBER = (6)
Message String: ct_cancel(): network packet layer: internal net library
error: Net-Library operation terminated due to disconnect

Then a whole host of these start popping up:

DBD::Sybase::db ping failed: OpenClient message: LAYER = (1) ORIGIN = (1)
SEVERITY = (1) NUMBER = (60)
Message String: ct_cancel(CONN,ALL): user api layer: external error: There
is a usage error.  This routine has been called at an illegal time.

OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (60)
Message String: ct_close(FORCE): user api layer: external error: There is a
usage error.  This routine has been called at an illegal time.



What is happening on the user end at this time - 500s? Any insight would be
incredibly helpful at this point.


Thanks

Chris

Re: PerlSetVar revisited

[Doug MacEachern]

> Oh, the patch... I've missed this detail, sorry.
> I understand that it'll enter the soon to be released 1.24, right?

not sure if it'll be in 1.24 yet.

Re: Newbie Question -

[Doug MacEachern]

> > not compiled, but the all the code lives in a BIG hash table for CGI.pm to
> > autoload from.  the export lists take up alot of space too.  regardless if
> > you're using html routines or not.
> 
> As I have replied to FEITO Nazareno today, this happens only if you
> precompile CGI.pm's functions at the server startup. I've used B::Terse in
> /perl-status to check that. Refer to the post with subject "[iso-8859-1]
> Whats better?program with C" for a complete showcase.
> 
> If you don't precompile them, only the minumum set of functions will be
> inherited, so it's possible to exclude the html generation functions.

re-read what i said, i'm talking about variables in CGI.pm like
%EXPORT_TAGS, %SUBS, etc.

Re: PerlSetVar revisited

[Stas Bekman]

On Fri, 12 May 2000, Doug MacEachern wrote:

> On Fri, 12 May 2000, Stas Bekman wrote:
> 
> > 
> > Doug MacEachern wrote:
> > 
> > > > OK, if this is the case, I'd prefer to have only one variable type -- an
> > > > array - so $r->dir_config will always return a list. So if it's a
> > > > sigular value, it'll be the first element. If you want it to be a hash
> > > > -- you can have it as well. This makes thing simple and even eliminates
> > > > the need for PerlSetVar, you can have only PerlAddVar for everything. 
> > > 
> > > my @values = $r->dir_config->get('Key');
> > > and
> > > my %hash = $r->dir_config->get('Key');
> > > 
> > > already does that, regardless of using PerlSetVar or PerlAddVar. 
> > > although, PerlSetVar would end up with odd number of elements for %hash. 
> > 
> > Well, it doesn't work for me. It returns a stringified version of the ref
> > to a hash or an array. I think you have already mentioned this before, I
> > thought it was changed since than.
> > 
> > 
> > 
> >   my %hash = qw(a b c d);
> >   push @{ $Location{"/perl"}->{PerlSetVar} }, [ hashkey => \%hash ];
> > 
> >   my @arr = qw(e f g h);
> >   push @{ $Location{"/perl"}->{PerlSetVar} }, [ arrkey => \@arr ];
> > 
> > 
> 
> why do you expect that to work?  PerlSetVar is TAKE2, so those references
> are stringified (watch the output with MOD_PERL_TRACE s).  you can't test
> the multi-value dir_config->get without the PerlAddVar patch i posted
> anyhow, unless you add at request time like the example below.
> 
> my $r = shift;
> 
> $r->send_http_header;
> 
> for (qw(one two)) {
> $r->dir_config->add(Test => $_);
> }
> 
> my @vars = $r->dir_config->get('Test');
> 
> print "@vars\n";

Oh, the patch... I've missed this detail, sorry.
I understand that it'll enter the soon to be released 1.24, right?

__
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
--

Re: Newbie Question -

[Stas Bekman]

On Fri, 12 May 2000, Doug MacEachern wrote:

> On Sat, 6 May 2000, Gunther Birznieks wrote:
> 
> > At 06:56 PM 5/5/00 -0400, Jim Winstead wrote:
> > >On May 05, Adi wrote:
> > > > You can still use CGI.pm from within mod_perl (and you should).  There is
> > > > nothing better at handling data passed from a browser via HTTP POST and/or
> > > > GET.  If you currently use CGI.pm, I think you'll find that a lot of your
> > > > current code can simply be cut-and-pasted into a mod_perl setup.
> > >
> > >Well, arguably Apache::Request is better at handling data passed
> > >from a browser via HTTP POST and/or GET in a mod_perl environment.
> > >And it has the advantage that is entirely focused on request
> > >handling, and doesn't have any of the HTML generation cruft like
> > >CGI.pm.
> > 
> > The "HTML Generation cruft" is optional "cruft" and doesn't have to be 
> > compiled in.
> 
> not compiled, but the all the code lives in a BIG hash table for CGI.pm to
> autoload from.  the export lists take up alot of space too.  regardless if
> you're using html routines or not.

As I have replied to FEITO Nazareno today, this happens only if you
precompile CGI.pm's functions at the server startup. I've used B::Terse in
/perl-status to check that. Refer to the post with subject "[iso-8859-1]
Whats better?program with C" for a complete showcase.

If you don't precompile them, only the minumum set of functions will be
inherited, so it's possible to exclude the html generation functions.

__
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
--

Re: PerlSetVar revisited

[Doug MacEachern]

On Fri, 12 May 2000, Stas Bekman wrote:

> 
> Doug MacEachern wrote:
> 
> > > OK, if this is the case, I'd prefer to have only one variable type -- an
> > > array - so $r->dir_config will always return a list. So if it's a
> > > sigular value, it'll be the first element. If you want it to be a hash
> > > -- you can have it as well. This makes thing simple and even eliminates
> > > the need for PerlSetVar, you can have only PerlAddVar for everything. 
> > 
> > my @values = $r->dir_config->get('Key');
> > and
> > my %hash = $r->dir_config->get('Key');
> > 
> > already does that, regardless of using PerlSetVar or PerlAddVar. 
> > although, PerlSetVar would end up with odd number of elements for %hash. 
> 
> Well, it doesn't work for me. It returns a stringified version of the ref
> to a hash or an array. I think you have already mentioned this before, I
> thought it was changed since than.
> 
> 
> 
>   my %hash = qw(a b c d);
>   push @{ $Location{"/perl"}->{PerlSetVar} }, [ hashkey => \%hash ];
> 
>   my @arr = qw(e f g h);
>   push @{ $Location{"/perl"}->{PerlSetVar} }, [ arrkey => \@arr ];
> 
> 

why do you expect that to work?  PerlSetVar is TAKE2, so those references
are stringified (watch the output with MOD_PERL_TRACE s).  you can't test
the multi-value dir_config->get without the PerlAddVar patch i posted
anyhow, unless you add at request time like the example below.

my $r = shift;

$r->send_http_header;

for (qw(one two)) {
$r->dir_config->add(Test => $_);
}

my @vars = $r->dir_config->get('Test');

print "@vars\n";

Re: [Fwd: [apache-users] Core with x86 solaris & modperl]

[Doug MacEachern]

i'm going to release 1.24 asap to stop this madness.  looks like another
case of the 5.6.0 largefile support bug, which the patch below will fix.
for apxs, you'll need to build apache like so:
CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
./configure \
...

--- Makefile.PL 2000/04/21 19:37:45 1.159
+++ Makefile.PL 2000/04/27 22:45:30 1.160
@@ -186,7 +186,7 @@
 $PERL_DEBUG = "";
 $PERL_DESTRUCT_LEVEL = "";
 $PERL_STATIC_EXTS = "";
-$PERL_EXTRA_CFLAGS = "";
+$PERL_EXTRA_CFLAGS = $] >= 5.006 ? $Config{ccflags} : "";
 $SSLCacheServerPort = 8539;
 $SSL_BASE = ""; 
 $Port = $ENV{HTTP_PORT} || 8529;

Re: About $r->connection->user

[Doug MacEachern]

On Fri, 12 May 2000, Kenneth Lee wrote:

> hi modperlers,
> 
> If I call $r->connection->user(something) in a PerlAccessHandler,
> besides I can see that user name in the access log, will $ENV{HTTP_USER} 
> be set by Apache or the subsequent handlers, like the default auth and 
> authz modules? 

yep.

Re: Source Code Shows Up in IE But Not Netscape

[Doug MacEachern]

On Wed, 10 May 2000, Bri Carey wrote:

> I realize that this is not an ePerl forum, but since ePerl runs as part of 
> mod_perl, I thought it couldn't hurt to at least ask here.
> 
> I must be missing something obvious.
> 
> I've installed Apache::ePerl.
> 
> I've configured httpd.conf according to the instructions:
> 
> 
> Options +ExecCGI
> SetHandler perl-script
> PerlHandler Apache::ePerl
> 
> 
> When I display an .iphtml page in Netscape, everything seems to be fine.
> 
> When I display it in IE (4.72), I get a plain text output of the source
> code, including html tags.
> 
> Why this discrepancy?

sounds like an http headers problem.  what do you see with a telnet
request?  probably not a complete set of httpd headers, try adding:
PerlSendHeader On
in your config

Re: how to get Devel::Symdump working with mod_perl code?

[Doug MacEachern]

On Tue, 9 May 2000, Tom Roche wrote:
 
> despite the fact that Symbol.pm is in
> c:/Perls/ActivePerl522/site/lib/Apache, which is in @INC. Which returns
> me to the original problem:

ok, most Apache:: modules that have xs code need to run inside httpd to
work properly.  you'll notice that most have this line:
__PACKAGE__->mod_perl::boot($VERSION);

mod_perl::boot will not try to bootstrap the xs code unless you're running
inside httpd, so everybody is happy.  Apache::Symbol and Apache::Leak are
the two exceptions, they should run outside of httpd.  however, i'm
guessing your ActivePerl was not able to build Apache::Symbol for some
reason.  ActivePerl isn't happy with mod_perl at all last i checked.

Re: "make test" fails, httpd fails to start

[Doug MacEachern]

On Mon, 8 May 2000, Stas Bekman wrote:

> > httpd fails to start because of the following.
> > > > will write error_log to: t/logs/error_log
> > > > Syntax error on line 3 of /tmp/mod_perl-1.23/t/conf/httpd.conf:
> > > > Invalid command '=pod', perhaps mis-spelled or defined by a module not
> > > > included in the server configuration

> > > Yeah, how about:
> > > > server failed to start! (please examine t/logs/error_log) at t/TEST line

but he already gave all the info we need above.  steve, the httpd being
used to run the tests does not have mod_perl configured.  which means
there's a flaw in the steps you took to configure/build.  try
INSTALL.simple or the appropriate section of the guide.

Re: Getting ENV in PerlTransHandler

[Doug MacEachern]

On Mon, 8 May 2000, sadhanandham balaraman wrote:

> Hi,
> 
>   How do I get ENV variables values in my PerlTransHandler. I want to 
>know 
> the HTTP_USER_AGENT in my PerlTransHandler.

try staying away from %ENV unless you want cgi compat, which you can't
have for a transhandler of course.  try $r->headers_in->{'User-Agent'}

Re: apache1.3.12, modperl1.23, perl5.6, ApacheJServ1.1, OpenSSL0.9.4, modssl

[Doug MacEachern]

have you tried this patch?  see threads on largefile support for details.

--- Makefile.PL 2000/04/21 19:37:45 1.159
+++ Makefile.PL 2000/04/27 22:45:30 1.160
@@ -186,7 +186,7 @@
 $PERL_DEBUG = "";
 $PERL_DESTRUCT_LEVEL = "";
 $PERL_STATIC_EXTS = "";
-$PERL_EXTRA_CFLAGS = "";
+$PERL_EXTRA_CFLAGS = $] >= 5.006 ? $Config{ccflags} : "";
 $SSLCacheServerPort = 8539;
 $SSL_BASE = ""; 
 $Port = $ENV{HTTP_PORT} || 8529;

Re: Apache::Registry and clearing package name space

[Doug MacEachern]

On Sun, 7 May 2000, Richard Chen wrote:

> Instead of the line
>   undef &$fullname;
> which undef's the source subroutine, one should use
>   *{$fullname}=sub {};

ah, good trick!  this also solves the problem for aliased
arrays/hashes/scalars

> This fix is obvious because that is the way how a code alias is
> generated in the first place. In order to undef this alias,
> just let it point to an anonymous subroutine which does nothing.
> 
> Since this does not involve B.pm, it is more efficient than

yeah, i didn't like pulling in B.pm, but it was a quick hack,
flush_namespace should have been written in c to begin with.  i've
modified the Perl version for now (in cvs) to use your suggestion and drop
B.pm.

Re: CGI::Delete for Apache::Request

[Doug MacEachern]

On Sat, 6 May 2000, Michael Blakeley wrote:

> I've been migrating some code off of the ENV-dependent methods in 
> CGI.pm, so I can turn of PerlSetupEnv. Anyway, I couldn't find an 
> Apache::Request method that had the functionality of CGI::Delete. 
> Since I use Delete extensively, I coded a replacement based on the 
> param() prototype in Apache::Request. This may be useful to other 
> programmer porting CGI.pm code.
> 
> # for compatibility with CGI::Delete - call with $apr->Delete("foo")
> sub Delete {
>  my $self = shift;
>  my $tab = $self->parms;
>  for (@_) {
>  $tab->unset($_);
>  }
> } # end sub Delete
> 
> Trivial, once you know how. But maybe worth including in a future rev 
> of Apache::Request? Or at least documenting? I spent some time just 
> finding "unset".

i would like to document the $self->parms table, and point to the
Apache::Table docs.

> It'd be even better if unset() would take a list argument, of course

that can be arranged :)  i would prefer this, rather than adding the
Delete method to Apache::Request.

Re: Re: mod_perl-1.99_01-dev

[Doug MacEachern]

On Sat, 6 May 2000, Greg Cope wrote:

> : > > But you will be not able to tune the two types of the threads to have
> : > > different Apache parameters (MaxRequests and others) so I'm not sure
> you
> : > > will get rid of the dual setup, unless these will be taken care of by
> : > > mod_perl.
> : >
> : >well, there is a PerlInterpMaxRequests parameter in 1.99_01-dev, which
> : >knocks off the Perl clone after x number of requests.  in addition, the
> : >pool of interpreters are pulled and putback from the head of the list, so
> : >you are getting re-used allocations (e.g. padlists aka lexicals).  that
> : >is, say you configured PerlInterpStart to 10, but average no more than 5
> : >concurrent requests.  you have 5 clones with allocated padlists, and 5
> : >which are much smaller (but ready for conncurrent requests > 5).  this is
> : >unlike 1.3 where you have 10 children, chances are high each of them will
> : >endup will allocated padlists, as there's no control over which child
> : >handles a request.
> : >
> : >i'm not saying 2.0 will rid the need for a dual setup, but the Perl side
> : >is looking a whole lot smaller (er, less fat) at this point.
> 
> If using the threaded model can we not configure say:
> 
> 10 apache children (fixed)
> X number of threads
> Y PerlInterpStart

yes.
 
> This would (if my understanding is correct) result in a request arriving and
> being :
> 
> - either be dealt with by a normal apache thread if  not a mod_perl
> handler - i.e {html|gif|png|jpeg}
> - or a by a light apache thread that calls a perlInterpreter from the pool
> to handle the mod_perl handler

there's no 'normal apache thread' or 'light apache thread', just 'apache
thread'.  all requests are handled the sameway thread-wise.  the only
difference for Perl requests is that an interpreter is plucked from the
pool and callbacks into that Perl runtime are made.
 
> Combine with a garbage collector thread this would be excellent as it would
> seriously reduce memory consumption (one of mod_perl's present weaknesses)

indeed.

Re: Newbie Question -

[Doug MacEachern]

On Sat, 6 May 2000, Gunther Birznieks wrote:

> At 06:56 PM 5/5/00 -0400, Jim Winstead wrote:
> >On May 05, Adi wrote:
> > > You can still use CGI.pm from within mod_perl (and you should).  There is
> > > nothing better at handling data passed from a browser via HTTP POST and/or
> > > GET.  If you currently use CGI.pm, I think you'll find that a lot of your
> > > current code can simply be cut-and-pasted into a mod_perl setup.
> >
> >Well, arguably Apache::Request is better at handling data passed
> >from a browser via HTTP POST and/or GET in a mod_perl environment.
> >And it has the advantage that is entirely focused on request
> >handling, and doesn't have any of the HTML generation cruft like
> >CGI.pm.
> 
> The "HTML Generation cruft" is optional "cruft" and doesn't have to be 
> compiled in.

not compiled, but the all the code lives in a BIG hash table for CGI.pm to
autoload from.  the export lists take up alot of space too.  regardless if
you're using html routines or not.

Re: Can't use Apache::exit() in command-line scripts

[Doug MacEachern]

On Fri, 5 May 2000, Bill Moseley wrote:

> At 12:05 AM 05/04/00 -0700, Doug MacEachern wrote:
> >you're calling exit in a module?  shame on you.  if you call exit() from a
> >script that is compiled by Apache::Registry (not include *.pm), exit()
> >will be overridden for you to call Apache::exit, no changes needed.
> >if you really want to call it in a module, which you really don't, do you?
> 
> I'm a bit confused.
> 
> When you say "module" you mean a module use'd by the Apache::Registry
> script?  Because exit() is overridden in those modules, too, no?
> 
> I can call exit() fine in a module, but if I say CORE::exit() the child is
> killed off.

yeah, i forgot, mod_perl uses CORE::GLOBAL:: to override it everywhere.

[FYI] ApacheCon Europe 2000: Call for Participation (fwd)

[Stas Bekman]

-- Forwarded message --
Date: Fri, 12 May 2000 12:47:23 -0400
From: Rodent of Unusual Size <[EMAIL PROTECTED]>
Reply-To: ApacheCon Planning Ctte <[EMAIL PROTECTED]>
To: ApacheCon Announcements <[EMAIL PROTECTED]>,
Apache Announcements <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: ApacheCon Europe 2000: Call for Participation
Newsgroups: comp.infosystems.www.servers.unix,comp.infosystems.www.servers.ms-windows

-BEGIN PGP SIGNED MESSAGE-

Call for Presenters: ApacheCon Europe 2000
==
Olympia Conference Centre, London, United Kingdom

Conference: October 23-25, 2000
Exhibition: October 24-25, 2000

http://ApacheCon.Com/
Presented by the Apache Software Foundation
Produced by Camelot Communications

SUBMISSION DEADLINE: Friday, 16 June 2000, 17:00 EDT  [-0400]

Come share your knowledge of Apache at this educational
and fun-filled gathering of Apache users, vendors and friends.
ApacheCon 2000 in Orlando was a huge success and attracted
over 1,000 Apache users and supporters including:

o Open source software developers
o Apache software developers
o Web site administrators
o Technical managers responsible for running Web sites

Apache Software Foundation members are designing the technical
program for ApacheCon Europe 2000 that will include several
tracks and over 40 sessions planned.

Topics likely to be covered include:

o Security and eCommerce
o Securing Apache on Unix and Windows
o Java, PHP, Perl, TCL, Python
o XML, XSL
o Performance, load balancing
o Case studies

We are particularly interested in session proposals covering:

o basic Apache topics (installation, compilation, configuration)
o scripting languages and dynamic content (mod_perl, mod_php,
  mod_jserv, Tcl, Python, ASP, et cetera)
o tips for writing Apache modules

If you would like to be a speaker at the ApacheCon Europe 2000
event, please go to the ApacheCon Web site and complete the form
there:

 

IF YOU WERE AN ATTENDEE OR A SPEAKER AT ORLANDO:  Please
log in first to submit a CFP; this will remember your
information and pre-load the CFP form for you.  Go to:

 

Only educational sessions will be considered; no product-specific
sales or marketing sessions, please. Course material will be made
available to the public after the conference.

Acceptance notification by: 3 July 2000
- -- 
#kenP-)}

Ken Coar
Apache Software Foundation  
"Apache Server for Dummies" 
"Apache Server Unleashed"   

-BEGIN PGP SIGNATURE-
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBORw1VprNPMCpn3XdAQE+PQQAoK45obZX9hL9z3xxcG+C6fb0acqBLCJF
Cc1se+dMBQKwiLIlQlPNEVldRhfavM2iYNee4I0z5C/Ko27RlJepOeJzT/TP5HD9
KGHnuoRts5PAbndNaXRHYTj1gAwge8CJ5/m8tu+HmAiaG1tNeEJ2cfOEAYp+nA0O
UzErgr33bqA=
=cqiM
-END PGP SIGNATURE-

Re: [TOOT]: Dyslectics untie!

[Kee Hinckley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At 8:39 AM -0700 5/12/00, Tobias Hoellrich wrote:
>I'm simply blown away by the number of bounced/wrong/undelivered emails I
>receive every morning. It looks like close to 50% of all emails get
>returned to us for one or the other reason. Is it really possible that so
>many people don't know their email-address, cannot type, have buggy
>mail-gateways, etc. ?

First of all.  Do you make it clear that they won't receive 
authorization until they receive the mail?  Secondly, do they get any 
access at all if they give you a fake email address?

It's not at all surprising to me, but that's because I'm on the 
receiving side of a lot of those registration bounces.  People very 
commonly use fake domain names, and somewhere.com is one of the real 
popular ones.

What amazes me is the number of sites that send email to "users" and 
don't check for bounces.  So over and over I get subscription 
notices, advertisements and other junk addressed to (usually) 
non-existent email addresses at somewhere.com.  I bounce more than 
100,000 messages a month.

This is true of even some of the so-called "opt-in" mail services 
like yesmail.com.  I got around 1000 email messages from them last 
week, all addressed to bogus somewhere.com addresses.  In their case, 
that means they're defrauding their advertisers.  But they didn't 
respond to my complaints.
- -- 

Kee Hinckley - Somewhere Consulting Group - Cyberspace Architects(rm)

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.2 for non-commercial use 

iQA/AwUBORw0iiZsPfdw+r2CEQJR8gCaA1BpeQNzC1bq3Z3efDthdC/NFaMAnAva
+EGZqjyJODJaykdH3aaeAege
=v9zZ
-END PGP SIGNATURE-

Re: talking about cookies (was: session something...)

[Stas Bekman]

On Fri, 12 May 2000, Jay Jacobs wrote:

> The issue isn't the technical aspects of the bug, or even the fact that
> users don't have to turn off cookies to fix the bug... the issue is that
> this, with help from the talented press, will cause more people to simply
> disable cookies whether right or wrong.  

I second that.

> This ties back into a previous discussion about storing sessions (or
> session_id) in a cookie and how reliable (or unreliable) that is.

I think a hybrid of cookie/URI_embedding is the only way to go. If a user
supports cookie, shoot it out, if not rewrite URIs. I know it sucks but
JavaScript and HTML designers are always developing a different version of 
their work for each platform...

> Jay Jacobs
> LachNet Inc.
> 
> 
> On Fri, 12 May 2000, Keith G. Murphy wrote:
> 
> > "Jeffrey W. Baker" wrote:
> > > 
> > > On Thu, 11 May 2000, Marc Slemko wrote:
> > > 
> > > > In reality, IE's recently publicized hole (which I reported to them, in a
> > > > slightly modified form, months ago but they didn't see fit to release a
> > > > patch...) doesn't change much.
> > > >
> > > > Hotmail?  Yahoo mail?  amazon.com?  etc.  Your cookies for all those sites
> > > > are vulnerable anyway due to the "cross site scripting" issue.  This
> > > > particular hole in IE doesn't change things too much.  Sure, there may be
> > > > the rare site that isn't vulnerable to cross site scripting.  But that is
> > > > the very rare site, and most sites that think they aren't vulnerable are.
> > > >
> > > > Cookies are not secure and will never be secure.  I have said it before
> > > > and will say it again many times before I die.  Unfortunately, it isn't as
> > > > simple as saying "well, don't use cookies".  There isn't much in the way
> > > > of alternatives for a lot of things...
> > > 
> > > Cross-site scripting attacks are hard for most people to wrap their minds
> > > around.  There are a zillion sites that are vulnerable, mainly because
> > > they parrot back to the user whatever they submitted without doing any
> > > validation or HTML/URL escaping.  Then there are browser bugs that don't
> > > treat excaped character properly.  Sigh.
> > > 
> > Whether we're talking about the IE bug, or cross-site scripting issues,
> > wouldn't the whole thing be solved by users turning *off* scripting and
> > leaving the cookies *on*?  I.e., in what ways are cookies not safe if
> > scripting is turned off?
> > 
> > What great functionality is lost if users turn off their scripting?
> > 
> > Of course, this may be an abstract question in terms of programming, if
> > users *do* insist on enabling scripting.
> > 
> > I do notice that both Microsoft and CERT, in their different ways,
> > recommend that folks turn off scripting for best protection against
> > cross-site scripting attacks:
> > 
> > http://www.cert.org/advisories/CA-2000-02.html
> > http://www.microsoft.com/technet/security/crsstQS.asp
> > 
> > So maybe some will get the message.
> > Though making ridiculous recommendations like avoiding "promiscuous
> > browsing" (CERT's words) doesn't help.
> > And MS's recommendation simply eliminates E-mail-based attacks using
> > their product (Outlook), while leaving others exposed.  They make it
> > ridiculously hard to turn off scripting, then show you how to do it only
> > in a limited way.
> > 
> > But it does seem like not even MS is saying "Don't accept cookies". 
> > Though they're still pretty quiet on the latest IE hole.
> > 
> 
> 



__
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
--

Re: talking about cookies (was: session something...)

[Mike Miller]

On Fri, 12 May 2000 11:15:02 -0500, Keith G. Murphy wrote:

>
>What great functionality is lost if users turn off their scripting?
>
>Of course, this may be an abstract question in terms of programming, if
>users *do* insist on enabling scripting.
>

Some applications (for better or worse) support the use of Javascript/VB script to do 
client side 
processing/validations, which allow for example, data ranges to be checked without 
returning data back 
to the server, insure that all form fields were filled in, etc.  These would not work 
with scripting 
disabled, unless I am missing something (quite possible, though )

Granted you could force (and should anyway, as you should never accept user input 
verbatim ) all 
such validation logic back at the server, but this gets into UI/look and feel issues 
as every data entry 
screen would require a trip back to the server, and not give the user the illusion of 
"real-time" 
validations, reformatting, etc., that they have come to expect using windows/mac/X 
applications.

I might be veering off-topic into a general web based design philosophy discussion, so 
forgive me if 
this is the case ... but it answered the question of the types of things that might be 
lost.

Brgds,

Mike.

Re: [Summation] 100% sessions?

[Jay Jacobs]

I really liked this solution... here is the simple mod_rewrite stuff I've
stuck into my httpd.conf to pull out the session_id:

RewriteEngine On
RewriteCond /your/doc_root/%{REQUEST_FILENAME} !-f
RewriteRule ^/S=([^/]+)/(.*)/$2 [E=SESSION_ID:$1]

When you set your session_id, be sure to prepend the "S=" to it.  I
figured that was a much better solution then just looking for 16
characters, although I put the !-f condition in there to test if it was a
file... by the slim chance that the S={session_id} pattern is actually a
real file... it could be done away with.

After this rewrite rule there will be a $ENV{SESSION_ID} variable set for
use in any application (regular cgi included)

This will also set the $r->filename to not include the session_id which
means that mason and the like won't break down looking for the file.

Note: This does NOT change $r->uri which will still contain the session
stuff in it.

Jay Jacobs
LachNet Inc.


On Thu, 11 May 2000, Gunther Birznieks wrote:

> At 01:21 PM 5/10/00 -0500, Jay Jacobs wrote:
> >I embedded notes into this with a short book at the end...
> >
> >On Wed, 10 May 2000, Gunther Birznieks wrote:
> >
> > > There is a strong reason for cookies only. Intranets and other controlled
> > > environments.
> >
> >
> >I'm trying to satisfy as many clents as possible in the chaos of the
> >uncontrolled world of a public site.
> 
> I was under the impression that this thread is about general session 
> architectures... and someone appeared to be arguing that there are no 
> situations where cookies alone would not cut it. The reality is that there 
> are quite a few developers who develop using cookies alone and accept it as 
> their user constraint. In an intranet with controlled users where the 
> business wants an app out quickly, they don't care about the flexibility 
> for the future especially if the apps are re-engineered to new business 
> requirements every 6 months anyway.
> 
> > > >User makes request:
> > > >   if a cookie exists with session_id
> > > > then verify it is a valid session_id
> > > > if a session-url exists remove it and rely on cookies
> > >
> > > Why would both exist?
> >
> >Becuase they're both set on an initial request, that way if the cookie
> >fails, the session is still in the url... again, uncontrolled, sloppy
> >world.
> >
> > > > if session is expired   # timed expirations as a security measure
> > > >   auth them again if needed and/else redirect to requested page.
> > > >
> > > >   else if a session_url exists with no cookie
> > > > verify validity and exipiration as above
> > > >
> > > >   else if no cookie and no url session
> > > > new session, set cookie and set session-url
> > > >
> > > >   timestamp the session for expiration.
> > > >
> > > >
> > > >Other notes:
> > > >   Having to re-write site-wide urls seems like a bad idea.  It 
> > negates any
> > > >caching (on both server and client sides), and forces all the pages to be
> > > >dynamic.  Relative links (although not the ../../prettiest thing) seems
> > > >like the best route.
> > >
> > > I don't get this. It's still a different URL whether the id is at the end
> > > of the URL or the beginning. Also, the pages are not dynamic with
> > > mod_rewrite... mod_rewrite (in this case) is just acting upon a data
> > > structure on the server.  The HTML files are still served as HTML files
> > > whether the root dir is shown as a session id
> > >
> > > The caching that you are ruining is the proxy caching. But the browsers
> > > will still cache the HTML and images (one would presume that multimedia
> > > content -- which benefits the most from a proxy cache would not go through
> > > the URL mangling if possible).
> >
> >
> >The thing about putting the session_id in the front is that the whole site
> >can then just do *static* relative linking.  The problem isn't using
> >mod_rewrite to get to the page, the problem is linking from that page to
> >another while maintaining the session_id in the url.  If I'm understanding
> >you wrong let me know, I'd be quite interested in a solution just using
> >mod_rewrite.
> Of course, if you put the session id at the front of the URL, then the 
> relative links will all work (unless they are absolute with regards to the 
> host).
> 
> However, it should be relatively easy to make this a lot cleaner in 
> conjunction with mod_rewrite... You have the URL (seen below) as 
> /abcdef123456abcdef/index.html
> 
> But there is no primer... If we change the URL to
> 
> /sessionid/abcdef123456abcdef/index.html
> 
> Then you can create a mod_rewrite rule that checks for /sessionid/(.*)endid/.*
> 
> And then takes the equivalent of $1 and pushes it into an environment 
> variable (lets call it $ENV{SESSIONID}).
> 
> Then have mod_rewrite strip the sessionid crap out of the URL and pass the 
> rest to the server as the TRUE url.
> 
> Then even CGI scripts (not just mod_perl ones) can take advantage of using 
> the $ENV{SESSIONID} to s

Re: talking about cookies (was: session something...)

[Stas Bekman]

On Fri, 12 May 2000, Keith G. Murphy wrote:

> "Jeffrey W. Baker" wrote:
> > 
> > On Thu, 11 May 2000, Marc Slemko wrote:
> > 
> > > In reality, IE's recently publicized hole (which I reported to them, in a
> > > slightly modified form, months ago but they didn't see fit to release a
> > > patch...) doesn't change much.
> > >
> > > Hotmail?  Yahoo mail?  amazon.com?  etc.  Your cookies for all those sites
> > > are vulnerable anyway due to the "cross site scripting" issue.  This
> > > particular hole in IE doesn't change things too much.  Sure, there may be
> > > the rare site that isn't vulnerable to cross site scripting.  But that is
> > > the very rare site, and most sites that think they aren't vulnerable are.
> > >
> > > Cookies are not secure and will never be secure.  I have said it before
> > > and will say it again many times before I die.  Unfortunately, it isn't as
> > > simple as saying "well, don't use cookies".  There isn't much in the way
> > > of alternatives for a lot of things...
> > 
> > Cross-site scripting attacks are hard for most people to wrap their minds
> > around.  There are a zillion sites that are vulnerable, mainly because
> > they parrot back to the user whatever they submitted without doing any
> > validation or HTML/URL escaping.  Then there are browser bugs that don't
> > treat excaped character properly.  Sigh.
> > 
> Whether we're talking about the IE bug, or cross-site scripting issues,
> wouldn't the whole thing be solved by users turning *off* scripting and
> leaving the cookies *on*?  I.e., in what ways are cookies not safe if
> scripting is turned off?

You are absolutely right. The question is who is going to explain this to
users, MS? 

> [snipped]

> But it does seem like not even MS is saying "Don't accept cookies". 
> Though they're still pretty quiet on the latest IE hole.

Heh, you probably have never didn't do support :) it's enough for them to
see the two words: "cookies" and "evil" in the same sentence, you know how
most of them will conceive it, you shouldn't think twice. I doubt they
know what "scripting" is. Also remember the bad history cookies carry with
them. 


__
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
--

Re: talking about cookies (was: session something...)

[Jay Jacobs]

The issue isn't the technical aspects of the bug, or even the fact that
users don't have to turn off cookies to fix the bug... the issue is that
this, with help from the talented press, will cause more people to simply
disable cookies whether right or wrong.  

This ties back into a previous discussion about storing sessions (or
session_id) in a cookie and how reliable (or unreliable) that is.

Jay Jacobs
LachNet Inc.


On Fri, 12 May 2000, Keith G. Murphy wrote:

> "Jeffrey W. Baker" wrote:
> > 
> > On Thu, 11 May 2000, Marc Slemko wrote:
> > 
> > > In reality, IE's recently publicized hole (which I reported to them, in a
> > > slightly modified form, months ago but they didn't see fit to release a
> > > patch...) doesn't change much.
> > >
> > > Hotmail?  Yahoo mail?  amazon.com?  etc.  Your cookies for all those sites
> > > are vulnerable anyway due to the "cross site scripting" issue.  This
> > > particular hole in IE doesn't change things too much.  Sure, there may be
> > > the rare site that isn't vulnerable to cross site scripting.  But that is
> > > the very rare site, and most sites that think they aren't vulnerable are.
> > >
> > > Cookies are not secure and will never be secure.  I have said it before
> > > and will say it again many times before I die.  Unfortunately, it isn't as
> > > simple as saying "well, don't use cookies".  There isn't much in the way
> > > of alternatives for a lot of things...
> > 
> > Cross-site scripting attacks are hard for most people to wrap their minds
> > around.  There are a zillion sites that are vulnerable, mainly because
> > they parrot back to the user whatever they submitted without doing any
> > validation or HTML/URL escaping.  Then there are browser bugs that don't
> > treat excaped character properly.  Sigh.
> > 
> Whether we're talking about the IE bug, or cross-site scripting issues,
> wouldn't the whole thing be solved by users turning *off* scripting and
> leaving the cookies *on*?  I.e., in what ways are cookies not safe if
> scripting is turned off?
> 
> What great functionality is lost if users turn off their scripting?
> 
> Of course, this may be an abstract question in terms of programming, if
> users *do* insist on enabling scripting.
> 
> I do notice that both Microsoft and CERT, in their different ways,
> recommend that folks turn off scripting for best protection against
> cross-site scripting attacks:
> 
> http://www.cert.org/advisories/CA-2000-02.html
> http://www.microsoft.com/technet/security/crsstQS.asp
> 
> So maybe some will get the message.
> Though making ridiculous recommendations like avoiding "promiscuous
> browsing" (CERT's words) doesn't help.
> And MS's recommendation simply eliminates E-mail-based attacks using
> their product (Outlook), while leaving others exposed.  They make it
> ridiculously hard to turn off scripting, then show you how to do it only
> in a limited way.
> 
> But it does seem like not even MS is saying "Don't accept cookies". 
> Though they're still pretty quiet on the latest IE hole.
> 

Re: talking about cookies (was: session something...)

[Keith G. Murphy]

"Jeffrey W. Baker" wrote:
> 
> On Thu, 11 May 2000, Marc Slemko wrote:
> 
> > In reality, IE's recently publicized hole (which I reported to them, in a
> > slightly modified form, months ago but they didn't see fit to release a
> > patch...) doesn't change much.
> >
> > Hotmail?  Yahoo mail?  amazon.com?  etc.  Your cookies for all those sites
> > are vulnerable anyway due to the "cross site scripting" issue.  This
> > particular hole in IE doesn't change things too much.  Sure, there may be
> > the rare site that isn't vulnerable to cross site scripting.  But that is
> > the very rare site, and most sites that think they aren't vulnerable are.
> >
> > Cookies are not secure and will never be secure.  I have said it before
> > and will say it again many times before I die.  Unfortunately, it isn't as
> > simple as saying "well, don't use cookies".  There isn't much in the way
> > of alternatives for a lot of things...
> 
> Cross-site scripting attacks are hard for most people to wrap their minds
> around.  There are a zillion sites that are vulnerable, mainly because
> they parrot back to the user whatever they submitted without doing any
> validation or HTML/URL escaping.  Then there are browser bugs that don't
> treat excaped character properly.  Sigh.
> 
Whether we're talking about the IE bug, or cross-site scripting issues,
wouldn't the whole thing be solved by users turning *off* scripting and
leaving the cookies *on*?  I.e., in what ways are cookies not safe if
scripting is turned off?

What great functionality is lost if users turn off their scripting?

Of course, this may be an abstract question in terms of programming, if
users *do* insist on enabling scripting.

I do notice that both Microsoft and CERT, in their different ways,
recommend that folks turn off scripting for best protection against
cross-site scripting attacks:

http://www.cert.org/advisories/CA-2000-02.html
http://www.microsoft.com/technet/security/crsstQS.asp

So maybe some will get the message.
Though making ridiculous recommendations like avoiding "promiscuous
browsing" (CERT's words) doesn't help.
And MS's recommendation simply eliminates E-mail-based attacks using
their product (Outlook), while leaving others exposed.  They make it
ridiculously hard to turn off scripting, then show you how to do it only
in a limited way.

But it does seem like not even MS is saying "Don't accept cookies". 
Though they're still pretty quiet on the latest IE hole.

[TOOT]: Dyslectics untie!

[Tobias Hoellrich]

For one of our web services we ask people for a valid email-address to
access the service. Once the address passes an initial RFC822 check we send
a message to the user which contains an activation link. Once the user
receives the message and clicks on the link we consider the email address
valid and he/she can use the service. 
I'm simply blown away by the number of bounced/wrong/undelivered emails I
receive every morning. It looks like close to 50% of all emails get
returned to us for one or the other reason. Is it really possible that so
many people don't know their email-address, cannot type, have buggy
mail-gateways, etc. ?
I would really like to hear if other people have similar experiences and
knowing that this is a question with very high OT-factor feel free to send
responses to me directly rather than the mod_perl list. 

Thanks
  Tobias 

PS: TOOT = totally off-off topic

Re: What´s better?program with CGI or use handl er without CGI?

[Gunther Birznieks]

At 10:13 AM 5/12/00 -0300, FEITO Nazareno wrote:
>Correct me if I mistake, but i want to know what´s better...
>Cause with CGI is a little more difficult make forms and with handlers
>isn´t, i supposse i can use CGI and handlers at the same time.
>I´ve read that CGI object oriented programming just use 2 k of resource of
>the system and not object oriented consume 17k... may be somebody can
>explain me that, i´m referring to the conflict that i got between cgi and
>handlers...

With mod_perl it doesn't matter because the modules get cached. So the only 
difference is the algorithm for parsing the form elements... CGI.pm is more 
standard and x-platform, but Apache::Request is faster, but ties you to 
mod_perl (a bit).

Re: PerlSetVar revisited

[Stas Bekman]

Doug MacEachern wrote:

> > OK, if this is the case, I'd prefer to have only one variable type -- an
> > array - so $r->dir_config will always return a list. So if it's a
> > sigular value, it'll be the first element. If you want it to be a hash
> > -- you can have it as well. This makes thing simple and even eliminates
> > the need for PerlSetVar, you can have only PerlAddVar for everything. 
> 
> my @values = $r->dir_config->get('Key');
> and
> my %hash = $r->dir_config->get('Key');
> 
> already does that, regardless of using PerlSetVar or PerlAddVar. 
> although, PerlSetVar would end up with odd number of elements for %hash. 

Well, it doesn't work for me. It returns a stringified version of the ref
to a hash or an array. I think you have already mentioned this before, I
thought it was changed since than.



  my %hash = qw(a b c d);
  push @{ $Location{"/perl"}->{PerlSetVar} }, [ hashkey => \%hash ];

  my @arr = qw(e f g h);
  push @{ $Location{"/perl"}->{PerlSetVar} }, [ arrkey => \@arr ];



In the code:

  my @values = $r->dir_config->get('arrkey');
  my %hash   = $r->dir_config->get('hashkey');

returns a stringified:

values: ARRAY(0x82ee120)
hash:   HASH(0x82ee090)

which cannot be dereferenced.

Do I miss something?


__
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
--

[Fwd: [apache-users] Core with x86 solaris & modperl]

[Brian P Millett]

I've installed the raven 1.4.2 with Apache 1.3.11 for solaris 8  on a
x86 platform.  It works just fine.

When I add Apache JServ 1.1, it still works OK.

When I add modperl 1.23, it cores.

Apache 1.3.11 & modperl 1.23 works just grand.

Modperl & raven = core.

Here are the particulars & a core dump:

shaka: gcc -v
Reading specs from /opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.2/specs
gcc version 2.95.2 19991024 (release)

shaka: uname -a
SunOS shaka 5.8 Generic i86pc i386 i86pc

shaka: perl -v

This is perl, v5.6.0 built for i86pc-solaris

Copyright 1987-2000, Larry Wall

Perl may be copied only under the terms of either the Artistic License
or the
GNU General Public License, which may be found in the Perl 5.0 source
kit.

Complete documentation for Perl, including FAQ lists, should be found on

this system using `man perl' or `perldoc perl'.  If you have access to
the
Internet, point your browser at http://www.perl.com/, the Perl Home
Page.

mod_perl_1.23,raven_ssl-1.4.2-1.3.11-x86-solaris-2.x, apache-1.3.11,
JServ 1.1

Script used to make & install code:
--BEGIN--
#!/bin/sh
#

JAVAHOME=/usr/java
JSDK=/opt/java/JSDK2.0/lib/jsdk.jar
PREFIX=/opt/apache
SRC_DIR=/home/bpm/compile_area
MODPERL_DIR=$SRC_DIR/modperl
APACHE_DIR=$SRC_DIR/apache
JSERV_DIR=$SRC_DIR/jserv
LAYOUT=Apache
MAKE=`which make`

 NOTHING MORE TO CONFIGURE ##

# FOR FIRST CLEAN SOURCES DO:
echo "Going to $APACHE_DIR"
cd $APACHE_DIR

./configure --prefix=$PREFIX \
--with-layout=$LAYOUT

if [ $? -ne 0 ]; then
echo "Configure Apache failure!!!"
exit 1
fi

# FOR MOD_PERL FIRST DO:

echo "Going to $MODPERL_DIR"
cd $MODPERL_DIR

perl Makefile.PL \
APACHE_SRC=$APACHE_DIR/src \
DO_HTTPD=1 \
USE_APACI=1 \
PREP_HTTPD=1 \
EVERYTHING=1

if [ $? -ne 0 ]; then
echo "Configure Mod Perl failure!!!"
 exit 1
fi

echo "Making modperl"
$MAKE && $MAKE install

#THEN GO TO JSERV AND DO:

echo "Going to $JSERV_DIR"
cd $JSERV_DIR

./configure --prefix=$PREFIX/jserv \
--enable-apache-conf \
--with-apache-src=$APACHE_DIR \
--with-jdk-home=$JAVAHOME \
--with-JSDK=$JSDK \
--disable-debugging

if [ $? -ne 0 ]; then
echo "Failure to configure JServ"
exit 1
fi
echo "Making JServ java src & installing"
$MAKE

if [ $? -ne 0 ]; then
echo "Falure to make ApacheJServ!!"
exit 1
fi

$MAKE install
#THEN GO BACK TO APACHEXXX AND DO:

echo "Going back to $APACHE_DIR"
cd $APACHE_DIR

./configure --prefix=$PREFIX \
--with-layout=$LAYOUT \
--activate-module=src/modules/perl/libperl.a \
--activate-module=src/modules/jserv/libjserv.a \
--activate-module=src/modules/raven_ssl/libraven_ssl.a \
--enable-module=most \
--enable-module=auth_dbm

if [ $? -ne 0 ]; then
echo "Unable to configure Apache/ModPerl/JServ/RavenSSL!!"
exit 1
fi
echo "Making the final Apache/ModPerl/JServ/RavenSSL"
$MAKE

if [ $? -ne 0 ]; then
echo "Unable to make Apache/JServ/SSL!!"
exit 1
fi

 INSTALL FINALLY!!!

$MAKE install
--END--

shaka: /opt/apache/bin/httpd -X -DSSL
Segmentation Fault (core dumped)

shaka: gdb /opt/apache/bin/httpd core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-pc-solaris2.8"...
(no debugging symbols found)...
Core was generated by `/opt/apache/bin/httpd -X'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols
found)...
done.
Reading symbols from
/opt/perl/lib/5.6.0/i86pc-solaris/CORE/libperl.so...
(no debugging symbols found)...done.
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libc.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcrypt_i.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libsec.so.1...(no debugging symbols
found)...
done.
---Type  to continue, or q  to quit---
Reading symbols from /usr/lib/libmp.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols
found)...
done.
#0  0x817039c in ap_ctx_set ()
(gdb) bt
#0  0x817039c in ap_ctx_set ()
#1  0x8086f02 in ssl_hook_ReadReq ()
#2  0x814d797 in ap_create_per_dir_config ()
#3  0x814d8ee in ap_run_post_read_re

Re: What´s better?program with CGI or use handler without CGI?

[Stas Bekman]

> Correct me if I mistake, but i want to know what´s better...
> Cause with CGI is a little more difficult make forms and with handlers
> isn´t, i supposse i can use CGI and handlers at the same time.
> I´ve read that CGI object oriented programming just use 2 k of resource of
> the system and not object oriented consume 17k... may be somebody can
> explain me that, i´m referring to the conflict that i got between cgi and
> handlers...

What a coincedence. I'm working this exact section you read the above info
from. You've misinterpreted it of course, I was talking about CGI's OO
interface vs procedural interface. I didn't mention handlers at all in
this section.  We are talking about: 
http://perl.apache.org/guide/performance.html#Measuring_the_Memory_Usage_of_Su
(apache.org is down now, it's handled now)

The chapter http://perl.apache.org/guide/performance.html answers your
quiestion quite well. 

But as Mark Summerfield pointed out, the numbers aren't exactly correct.

The numbers are shown there were taken with:

  use CGI  qw(-compile :all);

at the server startup, therefore the usage of CGI.pm has added 2k for OO
CGI.pm and 18k for procedural interface. Notice that the whole CGI's
namespace is inhereted in if you precompiled functions at the startup. So
having:

  use CGI qw(header);

or

  use CGI qw(:all);

is essientially the same. You will have all the precompiled at the startup
symbols imported even if you ask only for one symbol.  It seems to me like
a bug, but probably that's how CGI.pm works. 

If you don't precompile methods at the server startup, you will get only
5k vs 2k overhead with these two scripts respectively:

  cgi_mtd.pl
  -
  use CGI qw(header b);
  print header();
  print b("Hello");

  cgi_oo.pl
  -
  use CGI ();
  my $q = CGI->new;
  print $q->header;
  print $q->b("Hello");

The numbers were taken by using B::Terse.


__
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
--

What´s better?program with CGI or use handler without CGI?

[FEITO Nazareno]

Correct me if I mistake, but i want to know what´s better...
Cause with CGI is a little more difficult make forms and with handlers
isn´t, i supposse i can use CGI and handlers at the same time.
I´ve read that CGI object oriented programming just use 2 k of resource of
the system and not object oriented consume 17k... may be somebody can
explain me that, i´m referring to the conflict that i got between cgi and
handlers...



*
  Nazareno Feito


 Perl
Programmer


   
[EMAIL PROTECTED]

*

strange behaviour about CGI::Cookie and CGI

[Kenneth Lee]

hi all,

(i couldn't find any hints on this in the docs, so here it goes)

consider these two one-liners,

  perl -MCGI -MCGI::Cookie -e'$q=new CGI;print $q->param("foo")' foo=bar
  perl -MCGI=:standard -MCGI::Cookie -e'print param("foo")' foo=bar

it doesn't print "bar" as expected. it doesn't prompt me also for input 
when no argument is provided. i.e. it doesn't try to populate param()

it prompts only when i remove the -MCGI::Cookie. strange?

of coz i can use CGI->cookie to fetch and create cookies, but it 
doesn't make sense if i can't use these two modules together.

if they're really bugs, it may have potential problems with mod_perl
scripts when both modules are (pre-)loaded in Apache.

regards,
kenneth

PS. my kit: perl-5.6.0/rh6.1

Re: Apache::AutoIndex patch

[Alexei V. Barantsev]

By the way, there exists one difference between mod_autoindex and
Apache::Autoindex in DirectoryIndex option. I should write

DirectoryIndex "index.html index.htm index.shtml index.phtml index.pl"

for Apache::Autoindex and the same but without quotes for
mod_autoindex. If I omit quotes Apache::Autoindex handles only the
first name and ignores others.

Does anybody know where is the problem? Apache? mod_perl? Module?

-- 
ab
ICQ: 3959207

About $r->connection->user

[Kenneth Lee]

hi modperlers,

If I call $r->connection->user(something) in a PerlAccessHandler,
besides I can see that user name in the access log, will $ENV{HTTP_USER} 
be set by Apache or the subsequent handlers, like the default auth and 
authz modules? Or I have to set it myself explicitly?

kenneth