Re: Best compression for mod_perl application?
--- Bill Marrs [EMAIL PROTECTED] wrote: My own personal experience with mod_deflate (in Apache/2.0.46) is that it tends to spike my server's load. My server (gametz.com) is dual http://lists.over.net/pipermail/mod_gzip/2003-June/007130.html seems to say that mod_gzip has its own implementation for compression whereas mod_deflate uses zlib. I am assuming the shared library is somehow at fault here ? Mithun __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
segmentation fault under mod_perl+XML::XPath
Hello.
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault with this peace of code:
use XML::XPath;
my $mfname='/proj/optolink/html/.meta.xml';
my $xp = XML::XPath-new(filename = $mfname);
my $ns = $xp-find('//[EMAIL PROTECTED]yes]');
Under command line and CGI it's working fine and all tests during installation of
XML::XPath were fine, but the same code crush apache+mod_perl.
Apache - with so, unique_id, no expat
mod_perl with everything as DSO
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=freebsd, osvers=4.5-stable, archname=i386-freebsd
uname='freebsd flamengo.citl.miee.ru 4.5-stable freebsd 4.5-stable #3: tue apr 23
15:48:51 msd 2002 [EMAIL PROTECTED]:usrsrcsyscompileflamengo i386 '
config_args='-de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing
-I/usr/local/include',
optimize='-O',
cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing
-I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lc -lcrypt -lutil
perllibs=-lm -lc -lcrypt -lutil
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under freebsd
Compiled at Oct 23 2002 11:00:00
@INC:
/usr/local/lib/perl5/5.8.0/i386-freebsd
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0 0x80711c5 in poolCopyString ()
#1 0x806cf71 in XML_SetBase ()
#2 0x28cfcc92 in XS_XML__Parser__Expat_SetBase ()
from
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd/auto/XML/Parser/Expat/Expat.so
#3 0x28c398fb in Perl_pp_entersub () from
/usr/local/libexec/apache/libperl.so
#4 0x28c33c28 in Perl_runops_standard ()
from /usr/local/libexec/apache/libperl.so
#5 0x28bf2f36 in S_call_body () from /usr/local/libexec/apache/libperl.so
#6 0x28bf2d16 in Perl_call_sv () from
/usr/local/libexec/apache/libperl.so
#7 0x28bd3d56 in perl_call_handler ()
from /usr/local/libexec/apache/libperl.so
#8 0x28bd359e in perl_run_stacked_handlers ()
from /usr/local/libexec/apache/libperl.so
#9 0x28bd1d64 in perl_handler () from
/usr/local/libexec/apache/libperl.so
#10 0x8052595 in ap_invoke_handler ()
#11 0x806225c in process_request_internal ()
#12 0x80622bd in ap_process_request ()
#13 0x805b52e in child_main ()
#14 0x805b6a0 in make_child ()
#15 0x805b7bd in startup_children ()
#16 0x805bcb4 in standalone_main ()
#17 0x805c397 in main ()
#18 0x804ebe1 in _start ()
Any help would be good.
Ruslan.
Re: Installation Problem
On Wed, 2003-06-18 at 06:26, Ankur Jain wrote: Hi, I have RHL 8.0 and Apache2.0 running and perl 5.8.0. I am trying to install the modperl2.0 It's going fine till the make procedure but when I run the make test it prompts that no test server configured please specify a httpd or apxs or put either in your path. Eg: t/TEST -httpd /path/to/bin/httpd I tried that and it ended with an error server server_name:8529 error running tests please examine t/logs/error_log. The error_log file contains the following error: failed to resolve handler 'TestHooks::trans' and several others. This is often a symptom of building and running tests as root. Please tell me what could be the issue?? Thank you. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: mod_perl-1.99_09 for Redhat 9
On Thu, 2003-06-26 at 06:53, Bill Marrs wrote: I'm looking for a Redhat 9 compatible mod_perl-1.99_09 rpm. If anyone has one or knows where I can get one, let me know. I've just finished building RPMs for mod_perl 1.99_09 on RH9/i386 Grab them at: http://www.apache.org/~gozer/mp2/ Thanks, -bill p.s. I did find a Rawhide (bleeding edge Red Hat release, I think) mod_perl-1.99_09, but it doesn't seem to be compatible (I got an error from Apache). signature.asc Description: This is a digitally signed message part
[mp2] BUG with mod_deflate and $|=1 (20014:Error string not specified)
When I use Apache 2.0.46, mod_deflate with mod_perl-1.99_09 (or the latest mod_perl-2.0 CVS), perl buffering is off ($|=1), and my perl script prints nothing (e.g. 'print ;'), I get the following error: [Wed Jul 02 10:10:00 2003] [error] 19513: ModPerl::RegistryBB: 20014:Error string not specified yet at /var/www/perl/test.pl line 6. If I switch to running the script under mod_cgi or if I remove the $|=1; line, I do not get an error. Here is my script: #!/usr/bin/perl $|=1; print Content-Type: text/html\n\n; print hello worldP; # This line causes the error print ; httpd.conf snipit: Alias /perl/ /var/www/perl/ Location /perl AddOutputFilterByType DEFLATE text/* SetOutputFilter DEFLATE AllowOverride None SetHandler perl-script PerlHandlerModPerl::RegistryBB PerlSendHeader On Options+ExecCGI /Location I've worked-around this problem by changing my print to print . It's not a major issue for me, I'm just letting you know. Let me know if you need any more info. -bill
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)
Hi Joe -- +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). Perhaps you could bullet-point a few of these possibilities for those of us who are confined by our lack of imagination? TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
[mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Seems to be a problem with calling IoFLUSH() on an already flushed
handle.
This patch seems to fix it for me.
Index: xs/Apache/RequestIO/Apache__RequestIO.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/RequestIO/Apache__RequestIO.h,v
retrieving revision 1.37
diff -u -I$Id -r1.37 Apache__RequestIO.h
--- xs/Apache/RequestIO/Apache__RequestIO.h 14 Mar 2003 05:33:19 - 1.37
+++ xs/Apache/RequestIO/Apache__RequestIO.h 2 Jul 2003 14:46:37 -
@@ -22,7 +22,7 @@
#define mpxs_output_flush(r, rcfg) \
/* if ($|) */ \
-if (IoFLUSH(PL_defoutgv)) { \
+if (bytes 0 IoFLUSH(PL_defoutgv)) { \
MP_FAILURE_CROAK(modperl_wbucket_flush(rcfg-wbucket, TRUE)); \
}
On Wed, 2003-07-02 at 22:18, Bill Marrs wrote:
When I use Apache 2.0.46, mod_deflate with mod_perl-1.99_09 (or the latest
mod_perl-2.0 CVS), perl buffering is off ($|=1), and my perl script prints
nothing (e.g. 'print ;'), I get the following error:
[Wed Jul 02 10:10:00 2003] [error] 19513: ModPerl::RegistryBB: 20014:Error
string not specified yet at /var/www/perl/test.pl line 6.
If I switch to running the script under mod_cgi or if I remove the $|=1;
line, I do not get an error.
Here is my script:
#!/usr/bin/perl
$|=1;
print Content-Type: text/html\n\n;
print hello worldP;
# This line causes the error
print ;
httpd.conf snipit:
Alias /perl/ /var/www/perl/
Location /perl
AddOutputFilterByType DEFLATE text/*
SetOutputFilter DEFLATE
AllowOverride None
SetHandler perl-script
PerlHandlerModPerl::RegistryBB
PerlSendHeader On
Options+ExecCGI
/Location
I've worked-around this problem by changing my print to print . It's
not a major issue for me, I'm just letting you know. Let me know if you
need any more info.
-bill
signature.asc
Description: This is a digitally signed message part
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)
On Wed, 2003-07-02 at 22:36, Jesse Erlbaum wrote: Hi Joe -- +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). Perhaps you could bullet-point a few of these possibilities for those of us who are confined by our lack of imagination? Check out the guide: http://perl.apache.org/guide/ Check out the books: http://perl.apache.org/docs/offsite/books.html Check out the success stories: http://perl.apache.org/outstanding/success_stories/index.html TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 signature.asc Description: This is a digitally signed message part
Please help newbie with Module problem.
Title: Message Dear List, I have got a problem that I can't fix no way, no how. I am porting a Linux website to xp pro. Ineed to use the Apache::Request module on a range of programs to use POST andGET methods in my HTML to process information gathered. The port I am using is theActivestate Apache/1.3.27 (Win32) mod_ssl/2.8.14 OpenSSL/0.9.7b mod_perl/1.27_01-dev I have installed 'Apache::Request with perl -MCPAN -e "shell"' and 'install Apache::Request'. and if I try to run the install I get a message saying 'Apache::Request is up to date' I dont seem to be able to test the module becuase I cannot make it with NMAKE.EXE, is this necessary. I use nmake15.exe should I be using a later one. The @INC is c:\perl\lib and c:\perl\site\lib The request.pm is in /perl/site/lib/apache however when I run the following code #!c:/perl/bin/perl -wuse Apache ();use Apache::Request ();use CGI::Carp qw(fatalsToBrowser);my $r = Apache::Request-new(shift);#my $apr = Apache::Request-new($r);print "Content-type:text/html\n\n";print "Hello, World...\n";print $r;print @INC; I receive the message Can't locate object method "new" via package "Apache::Request" (perhaps you forgot to load "Apache::Request"?) at c:\apache\cgi-bin\ap2.pl line 6. This prob has been with mea weeka nd I just don't seem to be able to find a resolution. Matt
Re: Please help newbie with Module problem.
however when I run the following code
#!c:/perl/bin/perl -w
use Apache ();
use Apache::Request ();
use CGI::Carp qw(fatalsToBrowser);
my $r = Apache::Request-new(shift);
# my $apr = Apache::Request-new($r);
print Content-type:text/html\n\n;
print Hello, World...\n;
print $r;
print @INC;
I receive the message
Can't locate object method new via package Apache::Request (perhaps
you forgot to load Apache::Request?) at c:\apache\cgi-bin\ap2.pl line
6.
mod_perl sends $r to the handler() subroutine by default. That is, if you're
using it in a PerlHandler context, like you should with anything that uses
Apache::Request.
Therefore, th ollowing should work for you.
#!/usr/bin/perl -w
use strict;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
my $result = undef;
eval { $result = inner_handler($r) };
return $result unless $@;
warn Uncaught Exception: $@;
return SERVER_ERROR;
}
sub inner_handler {
my $r = shift;
$r-content-type('text/html');
$r-status(200);
my $html = htmlheadtitleHello World!/title/headbodycenterYou
Tried To Access URI: . $r-uri ./center/body/html;
$r-send_http_header;
print $html;
}
Re: Please help newbie with Module problem.
On Wed, 2003-07-02 at 11:50, Matt Corbett wrote: I need to use the Apache::Request module on a range of programs to use POST and GET methods in my HTML to process information gathered. Actually, you don't. You can use CGI.pm, CGI::Simple, CGI_Lite, etc. for this. If you want to use Apache::Request but can't get your own compile to work, try one of the pre-compiled binaries available here: http://perl.apache.org/download/binaries.html - Perrin
Re: Please help newbie with Module problem.
this, however the line $r-content-type('text/html'); seems to be
giving my compiler some problems. You could'nt just give me a hint on
My mistake, shift key didn't get pressed hard enough =P
$r-content_type('text/html');
Dennis
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
This fixed the bug for me.
At 10:48 AM 7/2/2003, you wrote:
#define mpxs_output_flush(r, rcfg) \
/* if ($|) */ \
-if (IoFLUSH(PL_defoutgv)) { \
+if (bytes 0 IoFLUSH(PL_defoutgv)) { \
MP_FAILURE_CROAK(modperl_wbucket_flush(rcfg-wbucket, TRUE)); \
}
Re: Please help newbie with Module problem.
On Wed, 2 Jul 2003, Matt Corbett wrote: Dear List, I have got a problem that I can't fix no way, no how. I am porting a Linux website to xp pro. I need to use the Apache::Request module on a range of programs to use POST and GET methods in my HTML to process information gathered. The port I am using is the Activestate Apache/1.3.27 (Win32) mod_ssl/2.8.14 OpenSSL/0.9.7b mod_perl/1.27_01-dev I have installed 'Apache::Request with perl -MCPAN -e shell' and 'install Apache::Request' . and if I try to run the install I get a message saying 'Apache::Request is up to date' I dont seem to be able to test the module becuase I cannot make it with NMAKE.EXE, is this necessary. I use nmake15.exe should I be using a later one. To build the module, you'll need a C compiler (Visual C++ 6, if you want compatibility with ActivePerl). But since CPAN.pm believes Apache::Request is up to date, you probably have a working version, in principle. Does C:\ perl -MApache::Request -e print 1 produce any error? The @INC is c:\perl\lib and c:\perl\site\lib The request.pm is in /perl/site/lib/apache however when I run the following code #!c:/perl/bin/perl -w use Apache (); use Apache::Request (); use CGI::Carp qw(fatalsToBrowser); my $r = Apache::Request-new(shift); # my $apr = Apache::Request-new($r); print Content-type:text/html\n\n; print Hello, World...\n; print $r; print @INC; I receive the message Can't locate object method new via package Apache::Request (perhaps you forgot to load Apache::Request?) at c:\apache\cgi-bin\ap2.pl line 6. This script ran fine for me under Apache::Registry with ActivePerl 635 / mod_perl 1.27 / Apache 1.3.27. From where are you running it? And does a simple Apache::Registry script that just prints out Hello work from the same location? -- best regards, randy kobes
Re: FW: Please help newbie with Module problem.
On Wed, 2 Jul 2003, Matt Corbett wrote: Yes, mod/perl/html scripts are fine except if I try to use Apache::Request. I can even 'use' it but the problem arises when I try to utilise it with the 'new' method. The fact that you can 'use' it (without doing anything with it) is encouraging, as that means the files are probably in the expected places, and Apache/mod_perl can use/load them. Does it help if you put a PerlModule Apache::Request directive in, before the directives defining your registry location? -- best regards, randy
RE: FW: Please help newbie with Module problem.
Randy, Does'nt seem to make any difference. Matt -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED] Sent: 02 July 2003 19:39 To: Matt Corbett Cc: [EMAIL PROTECTED] Subject: Re: FW: Please help newbie with Module problem. On Wed, 2 Jul 2003, Matt Corbett wrote: Yes, mod/perl/html scripts are fine except if I try to use Apache::Request. I can even 'use' it but the problem arises when I try to utilise it with the 'new' method. The fact that you can 'use' it (without doing anything with it) is encouraging, as that means the files are probably in the expected places, and Apache/mod_perl can use/load them. Does it help if you put a PerlModule Apache::Request directive in, before the directives defining your registry location? -- best regards, randy
RE: FW: Please help newbie with Module problem.
On Wed, 2 Jul 2003, Matt Corbett wrote: -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED] Sent: 02 July 2003 19:39 To: Matt Corbett Cc: [EMAIL PROTECTED] Subject: Re: FW: Please help newbie with Module problem. Does it help if you put a PerlModule Apache::Request directive in, before the directives defining your registry location? - Randy, Does'nt seem to make any difference. Matt Strange On the off-chance, does stopping completely the server, then restarting it, plus also clearing the cache from the browser, do anything? -- best regards, randy
RE: Please help newbie with Module problem.
Dennis and Randy and others on the list that gave advice,
Thank you so much for both your help. This has sorted out the problem. I
copied the *.pl files to the c:\apache\perl directory and before I made
the change to the httpd.conf file I tried it tham again and it's
perfect. If either or both of you can recommend a good charity I will
make a small donation for your time. Again thanks
Matt
-Original Message-
From: Dennis Stout [mailto:[EMAIL PROTECTED]
Sent: 02 July 2003 19:28
To: Matt Corbett
Subject: Re: Please help newbie with Module problem.
I don't have a PerlHandler set in my httpd.conf.
How should I set this.
Edit whatever form of an httpd.conf file that Apache has under Win32
(should be hte same, location I don't know).
mv the script out of the cgi-bin and into somewhere else, like
C:/Apache/perl
Let's say the name is RequestHandler.pm
In httpd, add this line:
VirtualHost blah.yourdomain.whatever:80
Location /
SetHandler perl-script
PerlHandler RequestHandler
/Location
/VirtualHost
Restart Apache, and any access to blah.yourdomain.whatever/ should get
trapped in there.
You may need to add the other standard apache directives to that, like
ServerName blah.yourdomain.whatever and so on, but probably not.
I think we are so close I can almost feel it.
Yes, we are. The code I sent you is hte core of hte project I'm
currently programming, which includes an entire dispatch table.
Now if only I could get it to grab the right friggin string from a SQL
server to authenticate :|
-Original Message-
From: Dennis Stout [mailto:[EMAIL PROTECTED]
Sent: 02 July 2003 18:57
To: Matt Corbett
Subject: Re: Please help newbie with Module problem.
Hrm.
Off the top of my head, I've not a clue.
Did you setup Apache with a
PerlHandler /path/to/file_with_script.perl
directive?
S.T.O.U.T. = Synthetic Technician Optimized for Ultimate
Troublshooting
- Original Message -
From: Matt Corbett [EMAIL PROTECTED]
To: 'Dennis Stout' [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 09 49
Subject: RE: Please help newbie with Module problem.
Thanks Dennis, It's now giving me Premature end of script
headers:. Can you help me again.
Matt
-Original Message-
From: Dennis Stout [mailto:[EMAIL PROTECTED]
Sent: 02 July 2003 17:46
To: Matt Corbett; [EMAIL PROTECTED]
Subject: Re: Please help newbie with Module problem.
this, however the line $r-content-type('text/html'); seems to
be
giving my compiler some problems. You could'nt just give me a hint
on
My mistake, shift key didn't get pressed hard enough =P
$r-content_type('text/html');
Dennis
Re: Please help newbie with Module problem.
You can send me- er, the Help Dennis Move out of Alaska charity money by
giving your credit card number to
*grin*
Thank you, I'm sure Randy would agree when I say it's nice to be appreciated
:)
Dennis Stout
S.T.O.U.T. = Synthetic Technician Optimized for Ultimate Troublshooting
- Original Message -
From: Matt Corbett [EMAIL PROTECTED]
To: 'Dennis Stout' [EMAIL PROTECTED]; 'Randy Kobes'
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 11 55
Subject: RE: Please help newbie with Module problem.
Dennis and Randy and others on the list that gave advice,
Thank you so much for both your help. This has sorted out the problem. I
copied the *.pl files to the c:\apache\perl directory and before I made
the change to the httpd.conf file I tried it tham again and it's
perfect. If either or both of you can recommend a good charity I will
make a small donation for your time. Again thanks
Matt
-Original Message-
From: Dennis Stout [mailto:[EMAIL PROTECTED]
Sent: 02 July 2003 19:28
To: Matt Corbett
Subject: Re: Please help newbie with Module problem.
I don't have a PerlHandler set in my httpd.conf.
How should I set this.
Edit whatever form of an httpd.conf file that Apache has under Win32
(should be hte same, location I don't know).
mv the script out of the cgi-bin and into somewhere else, like
C:/Apache/perl
Let's say the name is RequestHandler.pm
In httpd, add this line:
VirtualHost blah.yourdomain.whatever:80
Location /
SetHandler perl-script
PerlHandler RequestHandler
/Location
/VirtualHost
Restart Apache, and any access to blah.yourdomain.whatever/ should get
trapped in there.
You may need to add the other standard apache directives to that, like
ServerName blah.yourdomain.whatever and so on, but probably not.
I think we are so close I can almost feel it.
Yes, we are. The code I sent you is hte core of hte project I'm
currently programming, which includes an entire dispatch table.
Now if only I could get it to grab the right friggin string from a SQL
server to authenticate :|
-Original Message-
From: Dennis Stout [mailto:[EMAIL PROTECTED]
Sent: 02 July 2003 18:57
To: Matt Corbett
Subject: Re: Please help newbie with Module problem.
Hrm.
Off the top of my head, I've not a clue.
Did you setup Apache with a
PerlHandler /path/to/file_with_script.perl
directive?
S.T.O.U.T. = Synthetic Technician Optimized for Ultimate
Troublshooting
- Original Message -
From: Matt Corbett [EMAIL PROTECTED]
To: 'Dennis Stout' [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 09 49
Subject: RE: Please help newbie with Module problem.
Thanks Dennis, It's now giving me Premature end of script
headers:. Can you help me again.
Matt
-Original Message-
From: Dennis Stout [mailto:[EMAIL PROTECTED]
Sent: 02 July 2003 17:46
To: Matt Corbett; [EMAIL PROTECTED]
Subject: Re: Please help newbie with Module problem.
this, however the line $r-content-type('text/html'); seems to
be
giving my compiler some problems. You could'nt just give me a hint
on
My mistake, shift key didn't get pressed hard enough =P
$r-content_type('text/html');
Dennis
If (!$one_thing) {$other;}
This is irking me.
$state preserves information about the request and so on. Now,
$r-whatever_method works just fine.. EXCEPT for sending headers. When I
visit my site, I get my nifty login page, and that is all. Always the login
page.
I telnetted into the thing to see what kinds of cookie strings I was getting
back and... NO HEADERS! No Content-type: 's or nothing.
$r-send_http_header; must be broken, eh? How to fix?? =P
I'll spare all of your eyes by not sending complete source, but here's the
basic idea.
#!/usr/bin/perl
package RequestHandler;
use strict;
# snipped out a lot of use vars qw();'s and $val = blah.
sub handler {
my $r = shift;
my $result = undef;
eval { $result = inner_handler($r) };
return $result unless $@;
warn Uncaught Exception: $@;
return SERVER_ERROR;
}
sub inner_handler {
my $r = shift;
my %q = ($r-args, $r-content);
my %state = (r = $r, q = \%q);
$state{login_user} = '';
$state{login_pass} = '';
$state{title} = '';
$state{template} = '';
$state{auth_status} = password_boxes(\%state);
validate_auth_cookie(\%state);
my $function = $r-uri;
$function = '/login.html' if $state{login_user} eq '';
my $func = $Dispatch{$function} || $Dispatch{DEFAULT};
return $func-(\%state);
}
sub output_html {
my $state = shift;
my %args = @_;
my $title = $state-{title};
my $r = $state-{r};
$r-status(200);
my $template = HTML::Template-new(
filename=
$Template_Dir/$state-{template},
die_on_bad_params = 0,
);
$template-param(TITLE = $title);
eval { foreach (keys %args) {
$template-param($_ = $args{$_});
}};
$template-param(ERRORS = $@) if $@;
$r-header_out( 'Set-Cookie' = $state-{cookie_out} ) if
$state-{cookie_out};
$r-send_http_header('text/html');
print $template-output();
}
sub get_password {
my $state = shift;
my $row = $Sql-select_hashref('DECODE(PWORD,\'blah\')', 'techs',
TECH=\$state-{
q}-{login_user}\);
return $row-{DECODE(PWORD,'blah')};
}
sub build_auth_string {
my $state = shift;
my $ip = shift || $ENV{REMOTE_ADDR};
my $time = shift || time;
my $login = $state-{login_user};
my $password = $state-{login_pass};
my $val = join ::, $login, $ip, $password, $time;
# Iterate thru by 8 byte hunks.
# with the added 8 spaces, do not do the last hunk
# which will be all spaces
my $blown;
my $pos;
for ( $pos = 0; (($pos + 8) length($val) ) ; $pos+=8 ) {
$blown .= $cipher-encrypt(substr($val, $pos, 8));
# encrypt this without temp vars
}
my $enc = encode_base64($blown,);
$enc;
}
sub parse_auth_string {
my $state = shift;
my $cookie = shift;
return unless $cookie;
return if $cookie =~ /logged_out/;
my $unenc= decode_base64($cookie);
my $unblown;
# start at 8, take 8 bytes at a time
# $unenc should be exactly a multiple of 8 bytes.
my $pos;
for ( $pos = 0; $poslength($unenc); $pos += 8) {
$unblown .= $cipher-decrypt(substr($unenc, $pos, 8));
}
my ($login, $ip, $password, $time)=split ( /::/, $unblown, 4);
}
sub get_auth_cookie {
my $state=shift;
my $cookie = TTMSCGI-parse_cookie($ENV{HTTP_COOKIE})-{ttms_user};
my($login, $ip, $password, $time) = parse_auth_string($state,
$cookie);
($login, $ip, $password, $time);
}
sub set_auth_cookie {
my $state = shift;
my $val = build_auth_string($state);
my $c = TTMSCGI-build_cookie(
name= 'ttms_user',
value = $val,
expires = time + 86400*30*7,
domain = $Cookie_Domain,
path= '/',
);
$state-{cookie_out} = $c;
}
sub build_logout_cookie {
TTMSCGI-build_cookie(
name = 'ttms_user',
value = logged_out,
expires= time - 86400,
domain = $Cookie_Domain,
path = '/'
);
}
sub set_logout_cookie {
my $state = shift;
$state-{cookie_out} = build_logout_cookie($state);
}
sub validate_auth_cookie {
my $state = shift;
my ($login, $ip, $pass, $time) = get_auth_cookie($state);
return unless $login $pass;
my $checkpass = get_password($state);
if ($pass eq $checkpass) {
$state-{login_user} = $login;
$state-{login_pass} = $pass;
$state-{auth_status} = Logged in as $state-{login_user};
return;
}
return;
}
if (!$one_thing) { $other; }
I suppose the subroutine that makes the call to it would help too.
I'll spare you all the dispatch routine as it's quite lengthy, but basically
the DispatchTbl::* generates webpages dynamically depending on the uri
caught by RequestHandler::handler();.
sub post_login_form {
my $state = shift;
my %args = $state-{q};
$state-{template} = 'generic.tmpl';
$state-{title} = 'TTMS Login';
my $checkpass = get_password($state);
if ($checkpass eq $state-{q}{login_pass}) {
$state-{login_user} = $state-{q}{login_user};
$state-{login_pass} = $state-{q}{login_pass};
$state-{auth_status} = Logged in as $state-{login_user};
set_auth_cookie($state);
$args{body} = Good Morning, Dave.;
} else {
set_logout_cookie($state);
$args{body} = I'm afraid I can't let you do that, Dave.;
}
return output_html($state, %args);
}
Re: If (!$one_thing) {$other;}
On Wed, 2003-07-02 at 17:44, Dennis Stout wrote: $r-send_http_header; must be broken, eh? Not likely. Your syntax looks okay to me. It probably isn't being called for some reason, or else $r is not what you think it is. Throw in some debug statements and find out what's actually happening there. - Perrin
Wierd ENV issues
Greetings,
I have a W2K box, running Win32 binary of Apache 1.3.27, and mod_perl 1.27_01.
Everything seems to be working fine (AFAIK) except for some strange
environment variable stuff going on. Here is what I'm experiencing:
- I have a PerlRequire C:/startup.pl line in my httpd.conf, which works
fine. I set some ENVs in there, one of them being $ENV{HTML_TEMPLATE_ROOT} to
use with the HTML::Template module.
- I have a standard CGI test page that does the following:
# Print out the contents of %ENV just for kicks
my @keys = keys(%ENV);
@keys = sort(@keys);
foreach my $temp (@keys) {
print($temp . = . $ENV{$temp} . \nBR);
} # end foreach loop
This CGI page prints out all of my ENVs in order, just like one would think,
and it includes the 'HTML_TEMPLATE_ROOT' as it should.
- I also have an equivalent mod_perl based page utilizing Apache::Registry
vice vanilla CGI. It contains the following:
# Get the Apache::Request object reference
my $r = shift;
# Print out $ENV{HTML_TEMPLATE_ROOT}
$r - print(HTML_TEMPLATE_ROOT = . $ENV{HTML_TEMPLATE_ROOT} . \nBR);
# Print out the entire %ENV hash
my @keys = keys(%ENV);
@keys = sort(@keys);
foreach my $temp (@keys) {
$r - print($temp . = . $ENV{$temp} . \nBR);
} # end foreach loop
This mod_perl based script also prints out everything fine, until I comment
out the line the only prints out the 'HTML_TEMPLATE_ROOT' ENV. When I comment
it out, all of the sudden, the %ENV hash dump doesn't have it anymore either.
And when I uncomment it, the %ENV hash dump magically has it again. I've even
included a count for the %ENV display dump and it even says 31 when I am
printing HTML_TEMPLATE_ROOT, and 30 when I'm not.
I still have that ENV defined in my startup.pl. I've made sure my browser is
not caching pages, and I've restarted Apache a zillion times, still the same
behavior. One thing to note is that even when I comment out that single print
line for the ENV in the mod_perl based script, the CGI based one still
displays 'HTML_TEMPLATE_ROOT' properly, irregardless of whether the mod_perl
one does or not. I really stumbled onto this from blind luck, but it seems to
me that something kind of screwy is happening inside mod_perl or Apache. Can
someone shed some light on this?
Thanks in advance,
- Jeff
Re: If (!$one_thing) {$other;}
Not likely. Your syntax looks okay to me. It probably isn't being called for some reason, or else $r is not what you think it is. Throw in some debug statements and find out what's actually happening there. Okay, I put in some code to take the generated headers and enter them into the body of the page. This had an odd effect. I got headers at hte TOP of hte page, before the html tags, and here is what it reads: HTTP/1.1 200 OK Date: Wed, 02 Jul 2003 22:33:52 GMT Server: Apache/1.3.27 (Unix) mod_perl/1.27 Connection: close Content-Type: text/html Set-Cookie: So the cookie it's trying to set is wrong, but I can work on that later. Why is it not sending it normally? More importantly, why am I seeing this when I view source? I'm not supposed to ever see header info. Dennis
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)
Philippe -- Check out the guide: Check out the books: Check out the success stories: Is that your answer? I was hoping for specific examples, not hand-waving. -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Jesse Erlbaum wrote: Philippe -- Check out the guide: Check out the books: Check out the success stories: Is that your answer? I was hoping for specific examples, not hand-waving. I like to think that Part III (Chapters 11-17) of the mod_perl Developer's Cookbook does some of that. authentication is a good example of how mod_perl enables life outside of CGI scripting. if you require authentication in your application, auth handlers allow you to entirely remove authentication from your content handlers. mod_perl allows you to let your content handlers to focus on content - all other parts of your application (authentication, session management, proxying, URL rewriting tricks, etc) can programmed at the server level via other parts of the request cycle. I'm talking about this at a very basic level at OSCon this year (as I did last year), but you might be interested in my slides from YAPC2002 to get a general feel for it (and ApacheCon if you want to see the more twisted side of what mod_perl opens up). http://www.modperlcookbook.org/~geoff/slides/ HTH --Geoff
Re: segmentation fault under mod_perl+XML::XPath
Hi there,
Haven't seen any replies, so I thought you'd like to hear from someone. :)
On Wed, 2 Jul 2003, Ruslan U. Zakirov wrote:
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault
It's not uncommon to see XML and segfaults in the same post. :(
Have you searched the archives?
Under command line and CGI it's working fine and all tests during installation of
XML::XPath were fine, but the same code crush apache+mod_perl.
[snip]
Apache - with so, unique_id, no expat
mod_perl with everything as DSO
Whenever I see segfaults in a DSO Apache I'd say try static linking if
you don't know what else to try. :)
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Did you compile this Perl yourself? The standard advice is to compile
mod_perl and Perl with the same compiler.
usemymalloc=n, bincompat5005=undef
Highly unlikely, but maybe a malloc problem?
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
You should be OK with that compiler, is that what you're using yourself?
Hope you're not using gcc 3.x with that Perl...
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Never heard of Perl (as opposed to mod_perl) dynamic linking causing a
problem, so don't worry about that. (Until later.:)
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0 0x80711c5 in poolCopyString ()
This is the code in xmlparse.c from my 1.3.27 source tree:
--
static const XML_Char *poolCopyString(STRING_POOL *pool, const XML_Char *s)
{
do {
if (!poolAppendChar(pool, *s))
return 0;
} while (*s++);
s = pool-start;
poolFinish(pool);
return s;
}
--
Assuming you're using the same thing...
As far as I can see this must mean that your pointer s is invalid, and
either the dereference *s causes a memory bound error or else the s++
increment tries to increment it off the end of the stack or something.
There's nothing else in that function that would be likely to cause the
fault, if pool were invalid I'd expect it to happen in poolAppendChar().
I have no idea why these might be but it's a bit serious of course.
You're into XS territory, the sort of thing that can easily be thrown
by struct alignment problems such as you might get on the less well
exercised configurations - which probably includes FreeBSD - and an
unsuitable combination of compilers/dso/libraries/...
You shouldn't have to be delving this deeply into these packages, but
if a static link or a compiler change doesn't fix it and you don't
mind cranking gdb a bit further you could find out what that pointer
is pointing to and if it's a valid XML_Char pointer.
Hope this gets you started in the right direction, but please don't
take it as authoritative as I've never used FreeBSD nor XML::XPath.
73,
Ged.
Re: segmentation fault under mod_perl+XML::XPath
Hello again, On Thu, 3 Jul 2003, Ged Haywood wrote: There's nothing else in that function that would be likely to cause the fault, if pool were invalid I'd expect it to happen in poolAppendChar(). Of course unless poolAppendChar() turns out to be a function defined by a macro, which it does, so forget that last bit. Could be pool too. :( 73, Ged.
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Hello, GYmod_perl allows you to let your content handlers to focus on content - GYall other parts of your application (authentication, session management, GYproxying, URL rewriting tricks, etc) can programmed at the server level GYvia other parts of the request cycle. I think the question isn't why is Apache::Registry not sufficient to handle all functions within an HTTP request but why is it bad to use Apache::Request specifically for the content generation phase? Perrin had some good practical reasons for this--caused by the generated-namespace, sub-wrapped, eval'ed nature of Apache::Registry. I totally agree with the fact that Apache::Registry can introduce many hard-to-debug-problems. I've had enough headaches debugging some of these issues myself. It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. I mean, even from the lowest common denominator CGI you can get all parts of the incoming HTTP request, plus output arbitrary headers. I have found that often the Apache::Registry functionality of not having to restart servers when simple scripts change is worth the potential of bugs tickled by the Apache::Registry sub-wrap approach. I think it's a fine tool for simple content generation scripts and that it doesn't limit you at all in that aspect. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. well, if you consider that you still get access to $r and all its treasures from Apache::Registry, then that's mostly true. I mean, even from the lowest common denominator CGI you can get all parts of the incoming HTTP request, plus output arbitrary headers. it's when you use Apache::Registry as a wrapper for your legacy CGI scripts that the difference really begins to show. consider something like this http://www.perl.com/pub/a/2002/02/20/css.html while most templating systems don't have this issue with HTML entities, using the mod_perl API gives you ways of handling tasks like CSS protection behind the scenes. and I think that's unimaginably cool. other cool stuff comes at the end of this talk, http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2002/oo-mod_perl-printable.ppt.gz which touches on Apache::Registry-as-legacy-CGI-wrapper limitations see also http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-CachePOSTRegistry-0.01.tar.gz which handles the issue of merging legacy CGI Registry scripts with POST data issues and http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-HEADRegistry-0.01.tar.gz which addresses the fact that Registry does not properly handle HEAD requests. given all of that but not wanting to speak for anyone else, I think that once you buy into the-mod_perl-API-is-better approach, there are really few reasons to use Registry over content handlers, as Registry adds an additional but unnecessary level of complexity and indirection. --Geoff
Re: Apache::Request for CGI? (was: Re: A::Registry vs.mod_perlhandler philosophy)
On Wed, 2003-07-02 at 20:38, Andrew Ho wrote: I totally agree with the fact that Apache::Registry can introduce many hard-to-debug-problems. I've had enough headaches debugging some of these issues myself. It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script I would phrase it differently and say that there are nice things you can do when you embrace the fact that you're in a persistent environment. You can do a lot of things in ways that are compatible with both CGI and mod_perl, by checking the environment and acting appropriately, but it can be a pain when you want to take advantage of cleanup handlers, preloaded data, persistent connections, etc. You can do all this from A::R, but once you've decided to write something that is not going to work under CGI I can't see any reason to use A::R anymore. At that point, it's just an artificial construct that adds complexity to your system. I have found that often the Apache::Registry functionality of not having to restart servers when simple scripts change is worth the potential of bugs tickled by the Apache::Registry sub-wrap approach. People often say this. I just don't see it. Apache::Reload works just as well. My dev server restarts in about a second, so I always restart it when I make a change just to feel confident that I'm not seeing any residual effects from previous code. The whole reload thing is not perfect anyway, and people have had problems with A::R's reload when working with code that has closures in it. My opinion is that you should use A::R if you need CGI (or SpeedyCGI, etc.) compatibility, but use handlers otherwise. - Perrin
Re: If (!$one_thing) {$other;}
Not likely. Your syntax looks okay to me. It probably isn't being called for some reason, or else $r is not what you think it is. Throw in some debug statements and find out what's actually happening there. Okay, I put in some code to take the generated headers and enter them into the body of the page. This had an odd effect. I bet I have a login problem. User tries to do whatever. Gets asked to login. Fills in login form, hits submit, but posting is a request in and of itself. So the request for the cgi is made, user doesn;'t have a valid cookie yet, gets redirected to the login page ... Dennis
Re: If (!$one_thing) {$other;}
Here is a little script I wrote a while back so that I could look at headers
being sent from my server in a browser window.
JM.
- Original Message -
From: Dennis Stout [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:44 PM
Subject: If (!$one_thing) {$other;}
This is irking me.
$state preserves information about the request and so on. Now,
$r-whatever_method works just fine.. EXCEPT for sending headers. When I
visit my site, I get my nifty login page, and that is all. Always the
login
page.
I telnetted into the thing to see what kinds of cookie strings I was
getting
back and... NO HEADERS! No Content-type: 's or nothing.
$r-send_http_header; must be broken, eh? How to fix?? =P
I'll spare all of your eyes by not sending complete source, but here's the
basic idea.
#!/usr/bin/perl
package RequestHandler;
use strict;
# snipped out a lot of use vars qw();'s and $val = blah.
sub handler {
my $r = shift;
my $result = undef;
eval { $result = inner_handler($r) };
return $result unless $@;
warn Uncaught Exception: $@;
return SERVER_ERROR;
}
sub inner_handler {
my $r = shift;
my %q = ($r-args, $r-content);
my %state = (r = $r, q = \%q);
$state{login_user} = '';
$state{login_pass} = '';
$state{title} = '';
$state{template} = '';
$state{auth_status} = password_boxes(\%state);
validate_auth_cookie(\%state);
my $function = $r-uri;
$function = '/login.html' if $state{login_user} eq '';
my $func = $Dispatch{$function} || $Dispatch{DEFAULT};
return $func-(\%state);
}
sub output_html {
my $state = shift;
my %args = @_;
my $title = $state-{title};
my $r = $state-{r};
$r-status(200);
my $template = HTML::Template-new(
filename=
$Template_Dir/$state-{template},
die_on_bad_params = 0,
);
$template-param(TITLE = $title);
eval { foreach (keys %args) {
$template-param($_ = $args{$_});
}};
$template-param(ERRORS = $@) if $@;
$r-header_out( 'Set-Cookie' = $state-{cookie_out} ) if
$state-{cookie_out};
$r-send_http_header('text/html');
print $template-output();
}
sub get_password {
my $state = shift;
my $row = $Sql-select_hashref('DECODE(PWORD,\'blah\')', 'techs',
TECH=\$state-{
q}-{login_user}\);
return $row-{DECODE(PWORD,'blah')};
}
sub build_auth_string {
my $state = shift;
my $ip = shift || $ENV{REMOTE_ADDR};
my $time = shift || time;
my $login = $state-{login_user};
my $password = $state-{login_pass};
my $val = join ::, $login, $ip, $password, $time;
# Iterate thru by 8 byte hunks.
# with the added 8 spaces, do not do the last hunk
# which will be all spaces
my $blown;
my $pos;
for ( $pos = 0; (($pos + 8) length($val) ) ; $pos+=8 ) {
$blown .= $cipher-encrypt(substr($val, $pos, 8));
# encrypt this without temp vars
}
my $enc = encode_base64($blown,);
$enc;
}
sub parse_auth_string {
my $state = shift;
my $cookie = shift;
return unless $cookie;
return if $cookie =~ /logged_out/;
my $unenc= decode_base64($cookie);
my $unblown;
# start at 8, take 8 bytes at a time
# $unenc should be exactly a multiple of 8 bytes.
my $pos;
for ( $pos = 0; $poslength($unenc); $pos += 8) {
$unblown .= $cipher-decrypt(substr($unenc, $pos, 8));
}
my ($login, $ip, $password, $time)=split ( /::/, $unblown, 4);
}
sub get_auth_cookie {
my $state=shift;
my $cookie =
TTMSCGI-parse_cookie($ENV{HTTP_COOKIE})-{ttms_user};
my($login, $ip, $password, $time) = parse_auth_string($state,
$cookie);
($login, $ip, $password, $time);
}
sub set_auth_cookie {
my $state = shift;
my $val = build_auth_string($state);
my $c = TTMSCGI-build_cookie(
name= 'ttms_user',
value = $val,
expires = time + 86400*30*7,
domain = $Cookie_Domain,
path= '/',
);
$state-{cookie_out} = $c;
}
sub build_logout_cookie {
TTMSCGI-build_cookie(
name = 'ttms_user',
value = logged_out,
expires= time - 86400,
domain = $Cookie_Domain,
path = '/'
);
}
sub set_logout_cookie {
my $state = shift;
$state-{cookie_out} = build_logout_cookie($state);
}
sub validate_auth_cookie {
my $state = shift;
Re: If (!$one_thing) {$other;}
On Wed, 2003-07-02 at 21:24, Dennis Stout wrote: Okay, I put in some code to take the generated headers and enter them into the body of the page. This had an odd effect. I bet I have a login problem. You lost me. You were having problems with headers not being sent, right? That probably means that either $r is not the Apache object you think it is, or your program is not actually calling send_http_header. Have you done enough debugging to rule both of those things out? - Perrin
Re: If (!$one_thing) {$other;}
On Wed, 2003-07-02 at 21:24, Dennis Stout wrote: Okay, I put in some code to take the generated headers and enter them into the body of the page. This had an odd effect. I bet I have a login problem. Whoops. logic problem. YAY, maybe the core of all my problems is vast amounts of typo's caused by carpal tunnel =/ You lost me. You were having problems with headers not being sent, right? That probably means that either $r is not the Apache object you think it is, or your program is not actually calling send_http_header. Have you done enough debugging to rule both of those things out? $r is indeed the correct Apache object. Where I believe hte problem exists is in the PerlSendHeaders dealybob John mentioned in a private email to me... I'm currently taking a break from that section of hte program and have disabled it with a series of #'s for now... I'm going to work more directly with the SQL interface I'm making. I think I'll junk what I have and write a new one from scratch I think when I'm done and get this roled out, I'll work on making something very similar but completely database driven. All the functions in the dispatch table will be brought in through a single SQL statement called in an eval context. I might work on that once I have sufficiently pounded my brain with enough beer. m, 4 day weekend Dennis
Re: If (!$one_thing) {$other;}
I think when I'm done and get this roled out, I'll work on making something very similar but completely database driven. All the functions in the dispatch table will be brought in through a single SQL statement called in an eval context. This also means I can write a small subroutine to eval a form that's been posted, and given the authentication passes, add code to the thing while it's running, AND save the code to the DB so it'll be around for reboots. Wouldn't that just be awesome? A totally dynamic web driven database that can be completely reconfigured on the fly. I wonder if using Perl/Perl sections in the httpd.conf file, if a guy could put the entire RequestHandler in a database as well heh I spose that might take some work, probably with vi and gcc, on apache source files. Dennis
