Re: Generic Server

1999-10-31 Thread Matt Sergeant

On Sat, 30 Oct 1999, Leslie Mikesell wrote:
 According to Matt Sergeant:
 
   Would it be possible to have a generic server, like Apache, but not just
   for HTTP - something that could also serve up NNTP connections, FTP
   connections, etc. It seems to me at first look this should be possible.
   
   As I can see it there's a few key components to Apache:
   
   forking tcp/ip server
   file caching/sending
   header parsing
   logging
   
   Sounds a lot like inetd to me, IMHO.
  
  Maybe I'm wrong, but inetd is just #1 of those points. And slow too.
 
 Inetd just decides which server to start for which protocol, and
 the only slow part is starting up a large program which may need
 to read a config file.  However you didn't explain why you would
 like to replace these typically small and fast programs with
 a 10-20Meg mod_perl process.  I can see where having a common
 modular authentication method would be useful, but what else would
 they have in common?

Well I'll show by example. Take slash (the perl scripts for slashdot.org) -
it's got a web front end and now available is an NNTP front end. Wouldn't
it be nice to run both in-process under mod_perl, so you could easily
communicate between the two, use the same logging code, use the same core
modules, etc. That's what I'm thinking of.

Besides that, with a mod_perl enabled generic server rather than an inetd
server there's no loading config files for each request, no starting a
process, and Apache 2.0 (and I'm assuming mod_perl) will be available as a
threaded server, so it's only 1 10-20M process, not 100+.

--
Matt/

Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.



RE: Embperl - where are the cookies ? Success....

1999-10-31 Thread Gerald Richter

 $Apache::Session::SysVSemaphoreLocker::nsems = 16;

 (note - I'm running Solaris so I gotta have the nsems argument)

I put the hint with nsems and Solaris in the Embperl docs (the missing BEGIN
block is already added)

Thanks for the hint

Gerald



RE: optredirectstdout not working.

1999-10-31 Thread Gerald Richter

Hi,

 Even with optRedirectStdout set, I'm still seeing HTTP headers in
 my Embperl

strange, with a similar setup I don't get these problems...

Could you try the following modifications:

 html
 head
titleStuff/title
 /head
 body
 p
 [+ $ENV{EMBPERL_OPTIONS} +]
 br

optRedirectStdout: [+ $optRedirectStdout +] BR

[- print OUT "Now we print to filehandle OUT" ; -] BR

[- print "And Now we print to STDOUT" ; -] BR

 [- Axis::printHeader -]
 p
 bSome Docs/b

What is the output now?

BTW. Do you have build mod_perl with USE_DSO? If so make sure you do _not_
load Embperl at server startup time!

Gerald



---
Gerald Richter  ecos electronic communication services gmbh
Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl

E-Mail: [EMAIL PROTECTED] Tel:+49-6133/925151
WWW:http://www.ecos.de  Fax:+49-6133/925152
---



RE: optredirectstdout not working.

1999-10-31 Thread randyboy

 BTW. Do you have build mod_perl with USE_DSO? If so make sure you do _not_
 load Embperl at server startup time!

Yes I do, but I was following along with the guide and loaded everything at
startup.  The embperl faq didn't give any reasons (that I can find) as to
why I shouldn't or too many examples on what would go wrong.  Since I wasn't
having problems (up until now) I just kept loading at startup.  Oh well, I
guess now I know what at least one practical ramification is.

FWIW the output is below.

thanx Gerald

r.


output (netscape source)

And now we print to STDOUT
table border=0 cellspacing=0 cellpadding=0 bgcolor=e8d35etr
tda href=/Home/a/tdtd:/td
tda href=/section1Section 1/a/tdtd:/td
tda href=/section2Section 2/a/tdtd:/td
tda href=/section3Section 3/a/td
/tr/table

HTTP/1.1 200 OK
Date: Sat, 30 Oct 1999 17:20:08 GMT
Server: Apache/1.3.9 (Unix) mod_perl/1.21 mod_ssl/2.4.2 OpenSSL/0.9.4
Content-Length: 5254
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

html
head
titleStuff/title
/head
body
p
16400   br
optRedirectStdout: br
NOW we print to filehandle OUTbr
br
p
bSome Docs/b



RE: optredirectstdout not working.

1999-10-31 Thread Gerald Richter


  BTW. Do you have build mod_perl with USE_DSO? If so make sure
 you do _not_
  load Embperl at server startup time!

 Yes I do, but I was following along with the guide and loaded
 everything at
 startup.  The embperl faq didn't give any reasons (that I can find) as to
 why I shouldn't or too many examples on what would go wrong.
 Since I wasn't
 having problems (up until now) I just kept loading at startup.  Oh well, I
 guess now I know what at least one practical ramification is.


When mod_perl is compiled with USE_DSO and you load Embperl on server
startup, some parts of Embperl will not work correctly.

One example we see here:

 optRedirectStdout: br

also the EMBPERL_OPTIONS are set correctly, the optRedirectStdOut isn't
set!! That's why it doesn't work! So please do not load Embperl at server
startup time. After that your code will work.

You can find a hint in the faq at

http://perl.apache.org/embperl/Faq.pod.1.html#How_do_I_load_Embperl_at_serve
r_

but I will add it in the documentation as well, to make it easier to see

GErald


 FWIW the output is below.

 thanx Gerald

 r.


 output (netscape source)
 
 And now we print to STDOUT
 table border=0 cellspacing=0 cellpadding=0 bgcolor=e8d35etr
 tda href=/Home/a/tdtd:/td
 tda href=/section1Section 1/a/tdtd:/td
 tda href=/section2Section 2/a/tdtd:/td
 tda href=/section3Section 3/a/td
 /tr/table

 HTTP/1.1 200 OK
 Date: Sat, 30 Oct 1999 17:20:08 GMT
 Server: Apache/1.3.9 (Unix) mod_perl/1.21 mod_ssl/2.4.2 OpenSSL/0.9.4
 Content-Length: 5254
 Keep-Alive: timeout=15, max=100
 Connection: Keep-Alive
 Content-Type: text/html

 html
 head
 titleStuff/title
 /head
 body
 p
 16400   br
 optRedirectStdout: br
 NOW we print to filehandle OUTbr
 br
 p
 bSome Docs/b




Profiling

1999-10-31 Thread Greg Stark


Does anyone have any idea how much overhead Apache::DProf or Apache::SmallProf
add? Will it be possible to use these on a production system without having a
severe impact?

And has anyone used DBIx::Profile with mod_perl ? All I keep getting is:
 Can't locate object method "printProfile" via package "DBI::db" at (eval 35) line 4.

I can't figure out if this is due to the way i'm loading modules or calling
connect or what. I think I've removed all references to Apache::DBI and even
made it avoid doing a "use DBI" in case that interferes, but it still does
this.

-- 
greg



Embperl: Installation woes

1999-10-31 Thread Anthony Gardner

The following error msg appears while trying to install.

upload.htmERR:Internal Server Error
Input:  ./test/html/upload.htm
Output: ./test/tmp/out.htm
Compared to:./test/cmp/post.htm
Log:./test/tmp/test.log

ERRORS detected! NOT all test have been passed successfully


Found unexpected output in httpd errorlog:
[Sun Oct 31 19:39:56 1999] [error] require CGI failed: Insecure dependency 
in require while running with -T switch at (eval 467) line 3.

Last line from ./test/tmp/test.log

[5501]MEM: Reload 
/home/anthonyg/PERL_DOWNLOADS/EMBPERL/HTML-Embperl-1.1.1/test/html/upload.htm 
in HTML::Embperl::DOC::_23

I've reinstalled Perl/mod_perl/Apache but it makes no difference.

I can require/use CGI with -T in other scripts and am at a loss as to what's 
happening. @INC is fine.

OS: Linux 2.2.10
Perl: 5.005_3
Apache 1.3.9
mod_perl: 1.21
Embperl 1.1.1


Any pointers please.


Thanks in advance

-Ants.

__
Get Your Private, Free Email at http://www.hotmail.com



Re: Generic Server

1999-10-31 Thread Siracusa

On 10/31/99 4:23 AM, Matt Sergeant wrote:
 Well I'll show by example. Take slash (the perl scripts for slashdot.org)

I'm assuming you wanted this read like the classic:

"Take my wife...please!"

I mean, have you actually looked at the code here?

http://www.slashdot.org/code.shtml

It's a horror show, truly.  Return values go unchecked, quoting
operators are ignored, subroutine naming conventions are
nonexistent, "use" statements are buried in subroutines as if
they were runtime directives, etc. etc.  Slashdot has much bigger
problems than a lack of a "generic server" architecture, IMO ;)

-John



Re: Apache::SSI pain

1999-10-31 Thread Vassilii Khachaturov

Hi, I have had a similar problem and didn't overcome it.
I am running apache 1.3.6 and the latest Bundle::Apache, mod-perl-1.21
and Apache::SSI-2.08 (all the dependants are from yesterday's CPAN).

When I use the (deprecated according to this Ken's message)
Apache-OutputChain-0.07, I also have the included file prepended before
the output of the script that spits out the include directive. (I didn't
notice it at first as the rendered output looked just like expected in
my browser -- only the HTML source is messed :-) )

However, when I use Filter as suggested in Apache::Filter(3) (see the
config snippet below), the include directive gets propagated on to the
user agent and not expanded. Try http://win.tarunz.org/test.html to see
:-(

VirtualHost 194.90.246.9
ServerName win.tarunz.org
Options +Includes -Indexes
PerlModule Apache::Filter;
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch

RewriteEngine On
Alias /perl/ /home/www/tarunz/perl/
RewriteRule (^/.*html?$) /perl/code.pl/win$1 [L]
Directory /home/www/tarunz/perl
Options +ExecCGI
PerlSendHeader On
SetHandler perl-script
PerlSetVar Filter On
#PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
PerlHandler Apache::Registry Apache::SSI
/Directory
/VirtualHost

At http://www.tarunz.org/test.html you see the same thing passing only
the SSI filter w/o the chaining/Filter approach, and at, say,
http://lat.tarunz.org/test.html, you have the wrong order via the
chaining module. Config excerpts of these two vhosts follow.

VirtualHost 194.90.246.9
ServerName www.tarunz.org
Options +Includes -Indexes
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch
/VirtualHost

VirtualHost 194.90.246.9
ServerName lat.tarunz.org
Options +Includes -Indexes
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch

RewriteEngine On
Alias /perl/ /home/www/tarunz/perl/
RewriteRule (^/.*html?$) /perl/code.pl/vol$1 [L]
Directory /home/www/tarunz/perl
SetHandler  perl-script
PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Directory
/VirtualHost

What can be wrong?

TIA for any hints,
Vassilii

 Subject:  Re: Apache::SSI pain
 Author:   Ken Williams [EMAIL PROTECTED]
 Date: Tue, 12 Oct 1999 22:13:54 -0500

 The latest version of Apache::Filter has Apache::PerlRunFilter, which
is (to my
 knowledge) the first Filter-aware version of Registry or PerlRun.  Try
giving
 that a shot.

 The SSIChain  OutputChain side of things isn't so well supported
anymore, it
 may not be worth going in that direction.


 [EMAIL PROTECTED] (Christopher Hicks) wrote:
 I've used the lines below and the various other provided incantations
for
 using Apache::SSI or Apache::SSIChain.
 
 PerlModule Apache::SSIChain
 PerlModule Apache::Filter
 PerlModule Apache::SSI
 PerlModule Apache::OutputChain
 Alias /ssiperl/ /www/perl/ssibin/
 Location /ssiperl
SetHandler perl-script
 #  PerlSendHeader On
PerlSetVar Filter On
 #  PerlHandler Apache::OutputChain Apache::SSIChain
Apache::Registry
 #  PerlHandler Apache::SSIChain Apache::Registry
PerlHandler Apache::Registry Apache::SSI
Options +ExecCGI
 /Location
 
 The SSI's get included, but they're all at the top of the file.  Both
of
 the PerlHandler lines commented out above have SSIChain as the last
thing
 which is what the docs say to do.  But the includes still get
included
 before the rest of the file.
 
 I've scoured the modperl archives.  I've read through the source and
 documentation to Apache::SSI*.  Does anyone have any ideas?



Re: Apache::SSI pain

1999-10-31 Thread Ken Williams

One problem is that Apache::Registry doesn't work with Apache::Filter.  You
have to use a modified version (a subclass) to get it to work.  The subclass is
Apache::PerlRunFilter (which is actually a subclass of Apache::PerlRun, not
Apache::Registry, so it doesn't do any caching.  I'll find time sometime to
make a subclass of Registry...), included with Apache::Filter.  So your config
should look something like this:

Directory /home/www/tarunz/perl
 Options +ExecCGI +Includes
 PerlSendHeader On
 SetHandler perl-script
 PerlSetVar Filter On
 PerlHandler Apache::PerlRunFilter Apache::SSI
/Directory


[EMAIL PROTECTED] (Vassilii Khachaturov) wrote:
Hi, I have had a similar problem and didn't overcome it.
I am running apache 1.3.6 and the latest Bundle::Apache, mod-perl-1.21
and Apache::SSI-2.08 (all the dependants are from yesterday's CPAN).

When I use the (deprecated according to this Ken's message)
Apache-OutputChain-0.07, I also have the included file prepended before
the output of the script that spits out the include directive. (I didn't
notice it at first as the rendered output looked just like expected in
my browser -- only the HTML source is messed :-) )

However, when I use Filter as suggested in Apache::Filter(3) (see the
config snippet below), the include directive gets propagated on to the
user agent and not expanded. Try http://win.tarunz.org/test.html to see
:-(

VirtualHost 194.90.246.9
ServerName win.tarunz.org
Options +Includes -Indexes
PerlModule Apache::Filter;
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch

RewriteEngine On
Alias /perl/ /home/www/tarunz/perl/
RewriteRule (^/.*html?$) /perl/code.pl/win$1 [L]
Directory /home/www/tarunz/perl
Options +ExecCGI
PerlSendHeader On
SetHandler perl-script
PerlSetVar Filter On
#PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
PerlHandler Apache::Registry Apache::SSI
/Directory
/VirtualHost

At http://www.tarunz.org/test.html you see the same thing passing only
the SSI filter w/o the chaining/Filter approach, and at, say,
http://lat.tarunz.org/test.html, you have the wrong order via the
chaining module. Config excerpts of these two vhosts follow.

VirtualHost 194.90.246.9
ServerName www.tarunz.org
Options +Includes -Indexes
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch
/VirtualHost

VirtualHost 194.90.246.9
ServerName lat.tarunz.org
Options +Includes -Indexes
FilesMatch ".html?$"
SetHandler perl-script
PerlHandler Apache::SSI
/FilesMatch

RewriteEngine On
Alias /perl/ /home/www/tarunz/perl/
RewriteRule (^/.*html?$) /perl/code.pl/vol$1 [L]
Directory /home/www/tarunz/perl
SetHandler  perl-script
PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Directory
/VirtualHost

What can be wrong?

TIA for any hints,
Vassilii

 Subject:  Re: Apache::SSI pain
 Author:   Ken Williams [EMAIL PROTECTED]
 Date: Tue, 12 Oct 1999 22:13:54 -0500

 The latest version of Apache::Filter has Apache::PerlRunFilter, which
is (to my
 knowledge) the first Filter-aware version of Registry or PerlRun.  Try
giving
 that a shot.

 The SSIChain  OutputChain side of things isn't so well supported
anymore, it
 may not be worth going in that direction.


 [EMAIL PROTECTED] (Christopher Hicks) wrote:
 I've used the lines below and the various other provided incantations
for
 using Apache::SSI or Apache::SSIChain.
 
 PerlModule Apache::SSIChain
 PerlModule Apache::Filter
 PerlModule Apache::SSI
 PerlModule Apache::OutputChain
 Alias /ssiperl/ /www/perl/ssibin/
 Location /ssiperl
SetHandler perl-script
 #  PerlSendHeader On
PerlSetVar Filter On
 #  PerlHandler Apache::OutputChain Apache::SSIChain
Apache::Registry
 #  PerlHandler Apache::SSIChain Apache::Registry
PerlHandler Apache::Registry Apache::SSI
Options +ExecCGI
 /Location
 
 The SSI's get included, but they're all at the top of the file.  Both
of
 the PerlHandler lines commented out above have SSIChain as the last
thing
 which is what the docs say to do.  But the includes still get
included
 before the rest of the file.
 
 I've scoured the modperl archives.  I've read through the source and
 documentation to Apache::SSI*.  Does anyone have any ideas?


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum




Re: Apache::SSI pain

1999-10-31 Thread Vassilii Khachaturov

 However, when I use Filter as suggested in Apache::Filter(3) (see the
 config snippet below), the include directive gets propagated on to the
 user agent and not expanded. Try http://win.tarunz.org/test.html to see

oops. It turns out that it has been specifically stated in the docs that
Apache::Registry is not yet filter-aware :-(( Tough luck. (When will
RegistryNG include it?) O.K., meanwhile I will use Apache::PerlRunFilter
instead of Apache::Registry. Nevertheless, I wonder if there is a simple
patch possible to the OutputChain to fix the other way :-( I don't want to
miss the caching support of ::Registry in the general case for some
third-party CGI stuff which could benefit from mod_perl. Also, how can one
cope with third party scripts which output their "Content-type:" via usual
print STDOUT so that it doesn't pop up into the filtered pipeline in
addition to the one supplied by the Filter mechanism??

Of course, for my case I do have several workarounds. E.g., the script can
be easily converted to a proper handler without a need to wrap it by all
this Registry/etc stuff. It will improve the performance, won't it?

I will notify this thread when I close the published links/alter the configs
-- and tell which solution was better and why.

To future archive visitors: check if Apache::Registry supports Filter at the
time you read this, then all my pain with the "Filter" version is
obsolete...

V.



Re: Make errors

1999-10-31 Thread Doug MacEachern

On Fri, 15 Oct 1999, John Whitehead wrote:

 I can succesfully make Apache and perl with the following versions ;
  
 apache_1.2.6
 perl5.004_05
 
 when trying to make mod_perl-1.21

mod_perl no longer supports 1.2.x, try 1.3.9 instead.



Re: setting cookies?

1999-10-31 Thread Doug MacEachern

On Mon, 18 Oct 1999, Wyman Eric Miles wrote:

 
 System:
 
 Solaris 2.6
 Apache 1.3.9/mod_perl 1.19/gcc 2.8.1/perl-5.004.04
 
 I'm using SecurID to authenticate for an Apache proxy server.  I've
 written a little perl module that uses a username/tokencode returned by
 basic auth to validate a user and return a session cookie.  The SecurID
 auth works fine and I'm able to generate a cookie for the user.  
 
 The problem is, I can't get the module to return the cookie to the browser
 before the proxy request is completed.

mod_proxy doesn't look at r-headers_out table, it just passing along the
headers from the downstream server.



Re: mod_perl with APXS plus Raven equals segfault

1999-10-31 Thread Doug MacEachern

try building Perl with Configure -Uusemymalloc, solaris+perl malloc don't
seem to get along when mod_perl is a dso.  you're better off to link
static though, solaris system malloc is 25%-30% slower than using Perl's
malloc

On Mon, 18 Oct 1999, Steve Snodgrass wrote:

 I've been using mod_perl with Raven's SSL package for some time now, but I'm
 building a refresh of our environment with new versions of everything and I
 ran into trouble.  I decided to use APXS this time instead of building
 mod_perl statically.  Everything compiled and installed fine but Apache
 immediately segfaults on startup.  The details:
 
 Sun Ultra Enterprise 3500
 Solaris 7 (HW 5/99)
 Apache 1.3.9 (built from Raven pre-patched source)
 Raven SSL 1.4.1
 mod_perl 1.21
 perl 5.005_03
 gcc 2.95.1 (regular Solaris ld, GNU ld is not even on the system)
 
 I guess I can go back to compiling mod_perl statically, but it would be nice
 to get this fixed.  Any thoughts?  Thanks.
 
 -- 
 Steve "Pheran" Snodgrass * [EMAIL PROTECTED] * FORE Systems Unix Administrator
 Geek Code: GCS d? s: a- C++ US$ P+++ L+ w PS+ 5++ b++ DI+ D++ e++ r++ y+*
 "What to do I find it hard to know/The road I walk is not the one I chose" -Yes
 



Re: redirect after POST again?

1999-10-31 Thread Doug MacEachern

if you read POST data, then redirect, you need to do this before the
redirect or apache will hang:
$r-method_number(M_GET);
$r-method('GET');
$r-headers_in-unset('Content-length');

On Wed, 20 Oct 1999, Ilya Obshadko wrote:

 Hello,
 
   Weird things: this simple  plain code
 
 $req-header_out('Location' = $ENV{SCRIPT_NAME});
 $req-status(REDIRECT);
 $req-send_http_header;
 
   in POST script doesn't work with Netscape. It results in 'document
   contains no data' message. If $req-send_http_header is omitted,
   Netscape waits indefinitely until timeout. With IE, it's all ok.
   
   Even more strange - some weeks ago I've installed a VERY similar
   server with the same mod_perl  apache, and all such scripts
   worked fine. But don't advice to diff on all the config files -- it
   would take too long ;)
 
 Best regards,
  Ilya  mailto:[EMAIL PROTECTED]
 
 



Re: Problem at startup (Apache.pm)

1999-10-31 Thread Doug MacEachern

try adding to httpd.conf:
PerlModule Apache


On Thu, 21 Oct 1999, Alessio Bragadini wrote:

 I am sorry to bother you with what seems a FAQ, but the solutions found
 on the list archive (do make install, check permissions, use PerlSetEnv
 PERL5LIB) are not working for me:
 
 after make  make install I have the perl modules in
 /usr/local/apache+mod_perl/lib/site_perl/5.005/alpha-dec_osf
 
 put server startup fails with
 
 Apache.pm failed to load!
 
 Looks like I am missing sometimes, but I cannot find what, probabily
 because it's my firtst mod_perl build.
 
 Apache 1.3.9, mod_perl 1.21, perl 5.005_03, Digital Unix 4.0, Digital cc
 
 Thanks in advance
 
 -- 
 Alessio F. Bragadini  [EMAIL PROTECTED]
 APL Financial Serviceshttp://staff.dsnet.it/~alessio
 Nicosia, Cyprus   phone: +357-2-750652
 
 You are welcome, sir, to Cyprus. -- Shakespeare's "Othello"
 



Re: undefined reference problem

1999-10-31 Thread Doug MacEachern


On Thu, 21 Oct 1999, Scott Anderson wrote:

  am having the following errors trying to compile apache with mod_perl
 
 my mod perl configuration script looks like this
 
 perl Makefile.PL \
 APACHE_SRC=/usr/local/src/apache_1.3.9 \
 NO_HTTPD=1 \
 PREP_HTTPD=1 \
 EVERYTHING=1
 
 i answer yes when it asks about the src dir and no when it asks me if i want to 
build httpd.
 then i do
 make
 make install
 
 and everything seems to be ok
 
 then i goto the apache dir and use this configure script
 
 CC=cc \
 ./configure \
 --prefix=/usr/local/apache \
 --enable-rule=SHARED_CORE \
 --enable-module=so \
 --enable-module=auth_dbm \
 --enable-module=auth_db \
 --enable-module=rewrite \
 --enable-module=info \
 --activate-module=src/modules/jserv/mod_jserv \
 --activate-module=src/modules/php3/libphp3.a \
 --activate-module=src/modules/perl/libperl.a

you're better off to let Makefile.PL do all the work, you can pass those
options to Apache via APACI_ARGS, see also: makepl_args.mod_perl




mod_perl usage survey

1999-10-31 Thread Stas Bekman


The graph/usage data is updated, the ramp is getting bigger and bigger :)
http://perl.apache.org/netcraft/

October 1999: 342285 Domains, 55688 IP Addresses

Unfortunately after speaking with Mike Prettejohn, I found out that
netcraft doesn't poll port other than 80, unless you submit your site by
hand e.g. singlesheaven.com:8080. But, if your site will get accessed at
port 80 later, the non-80 port will be overwritten by 80 and your entry
will be lost ;(

Still we have pretty good numbers :)

___
Stas Bekman  mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas  
Perl,CGI,Apache,Linux,Web,Java,PC at  www.singlesheaven.com/stas/TULARC
www.apache.org   www.perl.com  == www.modperl.com  ||  perl.apache.org
single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com





Re: Apache-read timed out?

1999-10-31 Thread Doug MacEachern

sounds like somebody has already read the POST data before your code is
reached.

On Fri, 22 Oct 1999, Marler, Gordon wrote:

 I'm running mod_perl 1.21, Apache 1.39 on Solaris 2.5.1.
 
 I'm using the proxy example from pp. 374-381 of the "Writing Apache Modules"
 book, and I've come up with a strange case in handling a POST request in the
 following part of the code (explained on page 377).  Here's my doctored
 version of the code snippet:
 
  # Copy POST data, if any
   if ($r-method eq 'POST') {
 $log-debug("Posting!");
 my $len = $r-header_in('Content-length');
 $log-debug("Got the content length for POSTing: $len");
 my $buf;
 $r-read($buf,$len);
 $log-debug("Read the content for POSTing into a buffer");
 $request-content($buf);
 $log-debug("Copied POSTed data into the LWP request");
   }
 
 Turns out that this code hangs (just for this particular POST) at the
 $r-read($buf,$len) for a few minutes, then I get the
 "Apache-read timed out" message in the Apache error log.
 
 Any ideas in what I could look for in the URI or the headers that might give
 me a clue on why this is happening or how I could debug this?  Since the
 Content-length is greater than 0, I can't imagine why this would time out!
 I'm sure this is a special case, since most POSTs work just fine with this
 code.
 
 Gordon Marler
 ATT Wireless Services, WLTG
 Unix System Architect
 [EMAIL PROTECTED]
 Phone: 425 702 2980
 FAX: 425 702 2568
 



Re: Hanging process: detection and determination (was Re: Runawayprocesses)

1999-10-31 Thread Doug MacEachern

 I've checked the Apache::SIG and $r-connection-aborted, but is there a
 way to "write" without actually writing, probably some control char will
 do? Something like:
 
   while(1){
 $r-print("\0");
 last if $r-connection-aborted;
 $i++;
 sleep (1);
   }

have a look at what Eric recently added to the api:

=item $c-fileno( [$direction] )

Returns the client file descriptor. If $direction is 0, the input fd
is returned. If $direction is not null or ommitted, the output fd is
returned.

This can be used to detect client disconnect without doing any I/O,
e.g. using IO::Select.
 
 See the output of strace, when I press Stop - it detects the SIGPIPE but
 doesn't quit!
... 
 So Apache::SIG doesn't set correctly the mod_perl's default behaviour,
 since when I add: 
 
 use Apache::SIG ();
 Apache::SIG-set;

hmm, I thought we were done with SIGPIPE, the patch below will re-enable
auto-calling of Apache::SIG-set

Index: mod_perl.c
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.c,v
retrieving revision 1.91
diff -u -u -r1.91 mod_perl.c
--- mod_perl.c  1999/08/16 07:50:15 1.91
+++ mod_perl.c  1999/11/01 07:15:47
@@ -484,14 +484,12 @@
 exit(1);
 }
 
-#if !HAS_MMN_136
 static void set_sigpipe(void)
 {
 char *dargs[] = { NULL };
 perl_require_module("Apache::SIG", NULL);
 perl_call_argv("Apache::SIG::set", G_DISCARD, dargs);
 }
-#endif
 
 void perl_module_init(server_rec *s, pool *p)
 {
@@ -543,9 +541,7 @@
 if(PERL_RUNNING()  PERL_STARTUP_IS_DONE) {
saveINC;
mp_check_version();
-#if !HAS_MMN_136
set_sigpipe();
-#endif
 }
 
 if(perl_is_running == 0) {



Re: Apache::SSI and lookup_uri and POST req fails

1999-10-31 Thread Doug MacEachern

On Tue, 26 Oct 1999, Pouneh Mortazavi wrote:

 i'm so close to getting apache::ssi to work correctly but right now my
 work has come to a halt... 
 
 I've tracked the problem down to POST-ed forms + SSI + virtual includes +
 $r-lookup_uri, but i don't know how to fix it!
 
 I use Apache::SSI to parse the contents of an HTML string and include any
 ssi variables, templates etc before printing to the screen.
 
 my modperl handler has a snippet of code like this:
 
my $ssi = Apache::SSI-new($output_html, $r);
$output_html = $ssi-output();
 
 
 the modperl handler is used to
 
 - display a login page
 - authenticate the user and display any error information
 
 I have  a POST form  for people to type in username,password and trigger
 off this handler. i'm noticing that if i use a POST request, the returned
 page just hangs forever, in the $r-lookup_uri stage of implementing a
 virtual include via SSI. If I use a GET request, $r-lookup_uri completes
 normally.

after the first time you read post data, you need the code below to
prevent somebody else from trying to read post data that's already been
read.
$r-method_number(M_GET);
$r-method('GET');
$r-headers_in-unset('Content-length');



Re: suggestion about PerlRun

1999-10-31 Thread Doug MacEachern

On Thu, 28 Oct 1999, Yasushi Nakajima wrote:

 Hello All
 
 I have made a module derived from PerlRun. It overrides only readscript()
 method in PerlRun. First I wrote as follows (essencial part only)
 
 package Apache::PerlRunFake;
 use Apache::PerlRun;
 @ISA = qw(Apache::PerlRun);
 sub readscript {
   ...
 }
 *handler = \Apache::PerlRun::handler;
 
 But Apache::PerlRun::handler() inclueds following code.
 
 my $pr = Apache::PerlRun-new($r);

the handler() in Apache::PerlRun was not originally indended to be
subclassed.  however, if somebody submits a patch to make is
subclass-able that doesn't break the way Apache::PerlRun currently works,
that would be fine.



Re: forking from the main Apache process

1999-10-31 Thread Doug MacEachern

On Sat, 23 Oct 1999, Stas Bekman wrote:

 
 After investigating deeper into a hanging detection problem, I understood
 that I can quite easily write a monitor that will detect these processes
 and kill them off. I wrote a module Apache::SafeHang with help of
 Apache::Scoreboard that should solve the problem.
 
 The only problem I have with this module, is that it should be forked from
 the main process after the server has completed the configuration. I've
 tried to fork it during the startup (from startup.pl), but then I don't
 get a valid Apache::Scoreboard image, so it's like starting it from shell.
 Is it possible to execute some perl code in the parent process, a moment
 before a first child starts or any time after that?

if you put your code in a Perl section and wait until the second time it
is called, apache will have initialized the scoreboard by then.  if you
use a PerlRequire script, that's only call during the first init-modules
call, before the scoreboard is created.
 
 The third question is again regarding the main process. If I fork the
 process during a startup, when I perform 'apachectl stop' all the
 processes die but the one I've forked. Is there any way to install END{}
 block in the parent main process, so the children wouldn't inherit it?
 Otherwise if they do and it supposed to kill the forked process, a first
 child that quits will kill off the monitor. (I could probably test the pid
 of the process that executes the END block, since I know the pid of the
 parent, I could execute the block only if it's parent process...)

not really, you'd have to put logic in the END routines to do things (or
not do things) based on pid or some other flag.



Re: Intentional Premature Finish in an Apache Module

1999-10-31 Thread Doug MacEachern

On Thu, 28 Oct 1999, Public Interactive wrote:

 I'd like to be able to prematurely end the thread of execution
 within a Perl apache module from someplace *other than* the
 PerlHandler entry point subroutine (usually "handler()").  That is,
 when I'm a few subroutines deep inside my module, I want to be able
 to spit out an error page and have the module finish as if handler()
 had returned OK.  Right now I'm painstakingly propagating return
 values back up to my handler() subroutine, but I'm hoping there's a
 better way.

here's a possible option (from my Mail/.sent-mail a few weeks back):
...
or use this undocumented feature:

$Apache::ERRSV_CAN_BE_HTTP = 1; #set this anywhere, startup script is best
die FORBIDDEN;

mod_perl peeks at $@, if it's a 3 digit http status code, it propagates
that value to Apache.



Re: Memory Leaks?

1999-10-31 Thread Doug MacEachern

sounds like you have PerlFreshRestart On, try turning it Off.  scan the
archives for more info.

On Fri, 29 Oct 1999, Ben Bell wrote:

 Hi,
 
 I'm using the Debian package of mod_perl (1.21) and apache 1.3.9 and
 I've noticed quite nasty memory leaks on server restart. I've noticed
 unresolved bug reports on the Debian pages about this. Is it a known
 issue with this version?
 
 The leak is ca. 2MB each restart (or graceful) with my startup script
 enabled (which queries a database, and uses the following modules:
  Apache
  Apache::PerlSections
  Apache::DBI
  Data::Dumper
  Carp
  VI::Utils
 
 All my vars are declared as "my".
 When I disable all Perl stuff (my startup script, the perl sections etc)
 I still see a memory leak, albeit a smaller one.
 
 Can anyone shed any light on this?
 
 Cheers,
 Ben
 
 
 -- 
 +-Ben Bell - "A song, a perl script and the occasional silly sig.-+
   ///  email: [EMAIL PROTECTED]www: http://www.deus.net/~bjb/
   bjbDon't try to drive me crazy... 
   \_/...I'm close enough to walk. 
 



Re: Profiling

1999-10-31 Thread Doug MacEachern

On 31 Oct 1999, Greg Stark wrote:

 
 Does anyone have any idea how much overhead Apache::DProf or Apache::SmallProf
 add? Will it be possible to use these on a production system without having a
 severe impact?

I wouldn't using profiling on a production site, there is considerable
overhead involved with profiling.  and, as you've seen, possible oddities,
such as random core dumps.  I've seen cases such this code:
my $len = $#array + 1; #dump core
vs.
my $len = scalar @array; #no problem