Apache::Cookie under mod_perl
Using mod_perl, I am serving my pages from port 8050 - how can I ensure that the cookies I send using Apache::Cookie appends this port on to the end of the domain in the cookie that I send back to the browser? Thanks PC
Re: [ANNOUNCE] Apache::DBI 0.89
Ask Bjoern Hansen wrote: Since early 1997 Edmund Mergl has been developing and maintaining Apache::DBI. I would think that it's now one of the most used Apache related modules (and one of the most stable!) In the last almost 3 years only two bugs has been found. Edmund no longer has time to make releases and such, so I fixed the last bug and made a new release which is available on CPAN. hi ask... there is at least one bug still outstanding that I know about http://marc.theaimsgroup.com/?l=apache-modperlm=98167628923815w=2 doug's follow-up is here http://marc.theaimsgroup.com/?l=apache-modperl-devm=98168434608627w=2 (though doug meant can_stack_handlers instead of can_push_handlers) HTH --Geoff
Re: Apache::Request - Win32
That worked!! I had installed the ActiveState libapreq. Thanks for your help on this! On Sun, 23 Jun 2002, Levon Rubin Barker wrote: Hello. I'm sure this is a simple problem, but I'm a noob at mod_perl and could use some help. I am running WinXP, Apache 1.3.26, Mod_perl 1.27_01-dev with libapreq 0.31/ The problem I am having is ... I get the following in the Apache Error log. [Sun Jun 23 08:44:06 2002] [error] Can't locate object method new via package Apache::Request (perhaps you forgot to load Apache::Request?) at (eval 12) line 9. Did you get libapreq from ActiveState's repository? This one just has the .pm files - none of the C stuff - which might also explain this error. Try the libapreq available from ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/libapreq.ppd best regards, randy _ Sign up for your Free RecHockey email at http://www.rechockey.net.
Preserving POST data on external redirect?
Hi all, my content handler does some work with POSTed data, and at the end
wants to redirect to a totally unrelated server, preserving the POST data
that the client originally sent, so that the unrelated server can do its
own further processing with its own mod_perl, cgi, or whatever.
I can't get it to work, as I think I'm getting confused by some
pre-Apache::Request hints that I've seen for this. This is the mess I've
got so far (condensed):
sub handler
{
my $r = Apache::Request->new(shift);
... some calls to other subs here to do work ...
$r->method("POST");
$r->method_number(M_POST);
$r->headers_in->unset("Content-length");
$r->args($content);
$r->header_out('Location' => "http://j.random.server.com/foo.cgi");
$r->status(REDIRECT);
$r->send_http_header;
return REDIRECT;
}
It redirects, but doesn't pass the POST data. I thought it may have been
due to the original post data being deleted because I use it, so I tried
using Request->instance instead of Request->new, but that made no
difference either. Is it actually possible to do it if I'm using the
Request object?
Cheers
Re: Preserving POST data on external redirect?
On Mon, 24 Jun 2002, Kirk Bowe wrote:
Date: Mon, 24 Jun 2002 16:22:42 +0100 (BST)
From: Kirk Bowe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Preserving POST data on external redirect?
Hi all, my content handler does some work with POSTed data, and at the
end
wants to redirect to a totally unrelated server, preserving the POST data
that the client originally sent, so that the unrelated server can do its
own further processing with its own mod_perl, cgi, or whatever.
I can't get it to work, as I think I'm getting confused by some
pre-Apache::Request hints that I've seen for this. This is the mess I've
got so far (condensed):
sub handler
{
my $r = Apache::Request-new(shift);
... some calls to other subs here to do work ...
$r-method(POST);
$r-method_number(M_POST);
$r-headers_in-unset(Content-length);
$r-args($content);
$r-header_out('Location' = http://j.random.server.com/foo.cgi;);
$r-status(REDIRECT);
$r-send_http_header;
return REDIRECT;
}
It redirects, but doesn't pass the POST data. I thought it may have been
due to the original post data being deleted because I use it, so I tried
using Request-instance instead of Request-new, but that made no
difference either. Is it actually possible to do it if I'm using the
Request object?
Cheers
I think this is what you want:
http://theoryx5.uwinnipeg.ca/cgi-bin/guide-filter?page=snippets/Redirect_a_POST_Request_Forward.html;query=GET%20POST;match=and;where=all;stem=no
ky
Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
This stack trace is all I have. I cannot reproduce this SEGV at will, so it will be difficult to obtain additional information. All I can do is let the webserver run in -X mode and wait. I have no hints (yet) what kind of request triggers it. Again, as in my older posted SEGV, the line numbers are wrong, I do not know why. I'd appreciate any hint what I could try to come closer to a real bugreport. Program received signal SIGSEGV, Segmentation fault. 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x8907350) at malloc.c:3097 3097malloc.c: No such file or directory. (gdb) bt #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x8907350) at malloc.c:3097 #1 0x400d7f5a in __libc_free (mem=0x8907c88) at malloc.c:3023 #2 0x400d044b in _IO_new_fclose (fp=0x8907c88) at iofclose.c:61 #3 0x820c861 in PerlIOStdio_close (my_perl=0x82fc9c8, f=0x8303a00) at perlio.c:2638 #4 0x820a329 in Perl_PerlIO_close (my_perl=0x82fc9c8, f=0x8303a00) at perlio.c:1206 #5 0x8208b81 in PerlIO_cleantable (my_perl=0x82fc9c8, tablep=0x82fd3a0) at perlio.c:498 #6 0x820baa2 in PerlIO_cleanup (my_perl=0x82fc9c8) at perlio.c:2124 #7 0x810d298 in perl_destruct (my_perl=0x82fc9c8) at perl.c:490 #8 0x8099039 in perl_shutdown (s=0x82f140c, p=0x88f9c24) at mod_perl.c:294 #9 0x809b373 in perl_child_exit (s=0x82f140c, p=0x88f9c24) at mod_perl.c:958 #10 0x809afce in perl_child_exit_cleanup (data=0x88f9db4) at mod_perl.c:926 #11 0x80ddc8e in run_cleanups () #12 0x80dc4bd in ap_clear_pool () #13 0x80dc531 in ap_destroy_pool () #14 0x80e945b in clean_child_exit () #15 0x80ec707 in child_main () #16 0x80eccb0 in make_child () #17 0x80ece09 in startup_children () #18 0x80ed466 in standalone_main () #19 0x80edc33 in main () #20 0x4009698b in __libc_start_main (main=0x80ed8dc main, argc=4, argv=0xbcd4, init=0x807a6f8 _init, fini=0x828da5c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xbccc) at ../sysdeps/generic/libc-start.c:92 # /usr/local/perl-5.8.0-RC2/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.2.18pre15, archname=i686-linux-multi uname='linux pause.perl.org 2.2.18pre15 #5 fri oct 13 21:59:16 cest 2000 i686 unknown ' config_args='-des -Dprefix=/usr/local/perl-5.8.0-RC2 -Dinstallusrbinperl=n -Uversiononly -Dusemultiplicity -Doptimize=-g' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)', 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 =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.1.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Jun 24 2002 06:49:05 INC: /usr/local/perl-5.8.0-RC2/lib/5.8.0/i686-linux-multi /usr/local/perl-5.8.0-RC2/lib/5.8.0 /usr/local/perl-5.8.0-RC2/lib/site_perl/5.8.0/i686-linux-multi /usr/local/perl-5.8.0-RC2/lib/site_perl/5.8.0 /usr/local/perl-5.8.0-RC2/lib/site_perl . -- andreas
Re: Preserving POST data on external redirect?
Hi, yes that's one of the pages that I've been looking at, and the code is
almost identical (I've tried M_GET / GET as well). Still nothing
happening for me :-)
Cheers
Kirk.
On Mon, 24 Jun 2002, Ken Y. Clark wrote:
On Mon, 24 Jun 2002, Kirk Bowe wrote:
Date: Mon, 24 Jun 2002 16:22:42 +0100 (BST)
From: Kirk Bowe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Preserving POST data on external redirect?
Hi all, my content handler does some work with POSTed data, and at the
end
wants to redirect to a totally unrelated server, preserving the POST data
that the client originally sent, so that the unrelated server can do its
own further processing with its own mod_perl, cgi, or whatever.
I can't get it to work, as I think I'm getting confused by some
pre-Apache::Request hints that I've seen for this. This is the mess I've
got so far (condensed):
sub handler
{
my $r = Apache::Request-new(shift);
... some calls to other subs here to do work ...
$r-method(POST);
$r-method_number(M_POST);
$r-headers_in-unset(Content-length);
$r-args($content);
$r-header_out('Location' = http://j.random.server.com/foo.cgi;);
$r-status(REDIRECT);
$r-send_http_header;
return REDIRECT;
}
It redirects, but doesn't pass the POST data. I thought it may have been
due to the original post data being deleted because I use it, so I tried
using Request-instance instead of Request-new, but that made no
difference either. Is it actually possible to do it if I'm using the
Request object?
Cheers
I think this is what you want:
http://theoryx5.uwinnipeg.ca/cgi-bin/guide-filter?page=snippets/Redirect_a_POST_Request_Forward.html;query=GET%20POST;match=and;where=all;stem=no
ky
Re: Preserving POST data on external redirect?
A few things to note here...
You cannot post to a remote server in this fashion. You can take a POST
request to your server and convert it to a GET request to another server,
which may not be what you want.
To take POST content and POST it to another server you must proxy the request.
By proxy, I mean using LWP to make the request to the remote server via POST,
and delivering that returned content back to the user.
That's the easy part. Now you'll have to fix all the relative URLs within that
document so that they point to the remote server rather than to your server,
which is further complicated by things like CSS and Javascript.
Look into libwww-perl (LWP) and HTML::TreeBuilder (for fixing the links). I'm
sure that there is stuff in this lists' archives which go into more detail on
both of those...
Hope that helps,
Rob
On Mon, Jun 24, 2002 at 12:03:50PM -0400, Ken Y. Clark wrote:
On Mon, 24 Jun 2002, Kirk Bowe wrote:
Date: Mon, 24 Jun 2002 16:22:42 +0100 (BST)
From: Kirk Bowe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Preserving POST data on external redirect?
Hi all, my content handler does some work with POSTed data, and at the
end
wants to redirect to a totally unrelated server, preserving the POST data
that the client originally sent, so that the unrelated server can do its
own further processing with its own mod_perl, cgi, or whatever.
I can't get it to work, as I think I'm getting confused by some
pre-Apache::Request hints that I've seen for this. This is the mess I've
got so far (condensed):
sub handler
{
my $r = Apache::Request-new(shift);
... some calls to other subs here to do work ...
$r-method(POST);
$r-method_number(M_POST);
$r-headers_in-unset(Content-length);
$r-args($content);
$r-header_out('Location' = http://j.random.server.com/foo.cgi;);
$r-status(REDIRECT);
$r-send_http_header;
return REDIRECT;
}
It redirects, but doesn't pass the POST data. I thought it may have been
due to the original post data being deleted because I use it, so I tried
using Request-instance instead of Request-new, but that made no
difference either. Is it actually possible to do it if I'm using the
Request object?
Cheers
I think this is what you want:
http://theoryx5.uwinnipeg.ca/cgi-bin/guide-filter?page=snippets/Redirect_a_POST_Request_Forward.html;query=GET%20POST;match=and;where=all;stem=no
ky
Re: Preserving POST data on external redirect?
Hi,
The RFC 2068 (HTTP/1.1) specify that:
301 e 302 responses to POSTs shouldn't be redirected unless they can
be
confirm by user.
Also notes that some UA transform the POST to a GET, erroniously.
Merlin, The Mage
On Monday 24 June 2002 11:50 am, Kirk Bowe wrote:
: Hi, yes that's one of the pages that I've been looking at, and the code is
: almost identical (I've tried M_GET / GET as well). Still nothing
: happening for me :-)
:
: Cheers
:
: Kirk.
:
: On Mon, 24 Jun 2002, Ken Y. Clark wrote:
: On Mon, 24 Jun 2002, Kirk Bowe wrote:
: Date: Mon, 24 Jun 2002 16:22:42 +0100 (BST)
: From: Kirk Bowe [EMAIL PROTECTED]
: To: [EMAIL PROTECTED]
: Subject: Preserving POST data on external redirect?
:
:
:
: Hi all, my content handler does some work with POSTed data, and at the
: end
: wants to redirect to a totally unrelated server, preserving the POST
: data that the client originally sent, so that the unrelated server can
: do its own further processing with its own mod_perl, cgi, or whatever.
:
: I can't get it to work, as I think I'm getting confused by some
: pre-Apache::Request hints that I've seen for this. This is the mess
: I've got so far (condensed):
:
: sub handler
: {
: my $r = Apache::Request-new(shift);
:
: ... some calls to other subs here to do work ...
:
: $r-method(POST);
: $r-method_number(M_POST);
: $r-headers_in-unset(Content-length);
: $r-args($content);
: $r-header_out('Location' = http://j.random.server.com/foo.cgi;);
: $r-status(REDIRECT);
: $r-send_http_header;
:
: return REDIRECT;
: }
:
: It redirects, but doesn't pass the POST data. I thought it may have
: been due to the original post data being deleted because I use it, so I
: tried using Request-instance instead of Request-new, but that made no
: difference either. Is it actually possible to do it if I'm using the
: Request object?
:
: Cheers
:
: I think this is what you want:
:
: http://theoryx5.uwinnipeg.ca/cgi-bin/guide-filter?page=snippets/Redirect_
: a_POST_Request_Forward.html;query=GET%20POST;match=and;where=all;stem=no
:
: ky
--
Merlin, The Mage
themage.camelot.co.pt
Re: Preserving POST data on external redirect?
Ken Y. Clark [EMAIL PROTECTED] wrote:
On Mon, 24 Jun 2002, Kirk Bowe wrote:
Hi all, my content handler does some work with POSTed data, and at
the end wants to redirect to a totally unrelated server, preserving
the POST data that the client originally sent, so that the
unrelated server can do its own further processing with its own
mod_perl, cgi, or whatever.
I can't get it to work, as I think I'm getting confused by some
pre-Apache::Request hints that I've seen for this. This is the mess
I've got so far (condensed):
sub handler
{
my $r = Apache::Request-new(shift);
... some calls to other subs here to do work ...
$r-method(POST);
$r-method_number(M_POST);
$r-headers_in-unset(Content-length);
$r-args($content);
$r-header_out('Location' = http://j.random.server.com/foo.cgi;);
$r-status(REDIRECT);
$r-send_http_header;
return REDIRECT;
}
It redirects, but doesn't pass the POST data.
It can't, because this is the browsers job. Your script doesn't make a
connection the other server. You have to do transparent proxying or
depend on the browser.
I think this is what you want:
http://theoryx5.uwinnipeg.ca/cgi-bin/guide-filter?page=snippets/Redirect_a_POST_Request_Forward.html;query=GET%20POST;match=and;where=all;stem=no
Host not found...
--Nikolaus
Apache 2.0.39 and mod_perl
Greetings, Attempting to build mod-perl with Apache-2.0.39 Following the instructions on: http://perl.apache.org/release/docs/2.0/user/install/install.html When I get to CREATE THE BUILD ENVIRONMENT and run % perl Makefile.PL MP_AP_PREFIX=/home/stas/src/httpd-2.0.39 Get!!! Unable to open /users/webuser/src/httpd-2.0.39/include/apr.h: No such file or directory !!! Unable to open /users/webuser/src/httpd-2.0.39/include/apr.h: No such file or directory !!! Unable to open /users/webuser/src/httpd-2.0.39/include/apr.h: No such file or directory Repeated ... /users/webuser/src/httpd-2.0.39/include is there, there just isn't any apr.h file. There is an ap_release.h file, should I copy that to apr.h? Thank you, John Kent Webmaster Naval Research Laboratory, Monterey, CA
Reproductable Segmentation Fault
Hello. First, my configuration (i snipped as much as possible). DocumentRoot /home/nikratio/Projekte/www-testing Perl use lib '/home/nikratio/Projekte/www-testing/lib'; /Perl #PerlRequire debug.pl PerlModule CGI PerlModule Apache::Registry PerlModule SSIChainNG Directory /home/nikratio/Projekte/www-testing Options Includes Indexes ExecCGI Files *.pl SetHandler perl-script PerlSendHeader On PerlHandler SSIChainNG Apache::Registry /Files Files minitest.pl # PerlFixupHandler Apache::DB /Files AddHandler server-parsed .shtml Order deny,allow Allow from all AllowOverride None /Directory msg28533/pl0.pl Description: Test script msg28533/pl1.pl Description: support file 1 Include File 2 msg28533/pl2.pl Description: Custom module 1 msg28533/pl3.pl Description: Custom module 2 So far so good. Here are the versions: Apache/1.3.24 (Unix) Debian GNU/Linux mod_perl/1.26 PHP/4.2.1 mod_fastcgi/2.2.10 mod_ssl/2.8.7 OpenSSL/0.9.6c mod_jk/1.1.0 Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.13, archname=i386-linux uname='linux duende 2.4.13 #1 wed oct 31 19:18:07 est 2001 i686 unknown ' config_args='-Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.6.1 -Darchlib=/usr/lib/perl/5.6.1 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.6.1 -Dsitearch=/usr/local/lib/perl/5.6.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Duseshrplib -Dlibperl=libperl.so.5.6.1 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-DDEBIAN -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.4 (Debian prerelease)', 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, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldb -ldl -lm -lc -lcrypt perllibs=-ldl -lm -lc -lcrypt libc=/lib/libc-2.2.4.so, so=so, useshrplib=true, libperl=libperl.so.5.6.1 Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Jan 11 2002 04:09:18 INC: /usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/lib/site_perl . Basically, SSIParser is a Subclass of Apache::SSI. It parses text for SSI commands and executes them. It waqs modified to call a special method instead of printing to STDOUT, which would cause loops. SSIChainNG is a Subclass of Apache::OutputChain. It ties STDOUT to itself and searches all received data for SSI tags using SSI parser. minitest.pl causes a segfault on execution: , | [Mon Jun 24 19:35:09 2002] [notice] child pid 4575 exit signal | Segmentation fault (11) ` I couldn't solve this problem. But here are my various attempts to track the bug: 1. Joining the two print commands into one avoids the segfault: , | print(header(), | start_html(), | '!--#include virtual=t1.pl--', | h1(Main file). | '!--#include virtual=t2.html--', | end_html); ` (painless execution). 2. tied *STDOUT refers to an other object after the first print commmand. 3. Debugging session 4. Ah, the sub-request invoiced by Apache::SSI ties *STDOUT also. Therefore it is tied to the wrong request object after execution of the sub request. But protecting STDOUT with local(*STDOUT) during the sub request doesn't help. Any ideas to fix the problem? Thanks, --Nikolaus
Re: Preserving POST data on external redirect?
The link asks to change POST to GET. However, there is a limit on the length
of the URL so the POST data may be truncated and the redirect action may not
work properly.
Also, make sure to escapeURL() in the URL (which will also add extra chars
in the URL).
Peter Bi
- Original Message -
From: Kirk Bowe [EMAIL PROTECTED]
To: Ken Y. Clark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, June 24, 2002 8:50 AM
Subject: Re: Preserving POST data on external redirect?
Hi, yes that's one of the pages that I've been looking at, and the code is
almost identical (I've tried M_GET / GET as well). Still nothing
happening for me :-)
Cheers
Kirk.
On Mon, 24 Jun 2002, Ken Y. Clark wrote:
On Mon, 24 Jun 2002, Kirk Bowe wrote:
Date: Mon, 24 Jun 2002 16:22:42 +0100 (BST)
From: Kirk Bowe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Preserving POST data on external redirect?
Hi all, my content handler does some work with POSTed data, and at the
end
wants to redirect to a totally unrelated server, preserving the POST
data
that the client originally sent, so that the unrelated server can do
its
own further processing with its own mod_perl, cgi, or whatever.
I can't get it to work, as I think I'm getting confused by some
pre-Apache::Request hints that I've seen for this. This is the mess
I've
got so far (condensed):
sub handler
{
my $r = Apache::Request-new(shift);
... some calls to other subs here to do work ...
$r-method(POST);
$r-method_number(M_POST);
$r-headers_in-unset(Content-length);
$r-args($content);
$r-header_out('Location' = http://j.random.server.com/foo.cgi;);
$r-status(REDIRECT);
$r-send_http_header;
return REDIRECT;
}
It redirects, but doesn't pass the POST data. I thought it may have
been
due to the original post data being deleted because I use it, so I
tried
using Request-instance instead of Request-new, but that made no
difference either. Is it actually possible to do it if I'm using the
Request object?
Cheers
I think this is what you want:
http://theoryx5.uwinnipeg.ca/cgi-bin/guide-filter?page=snippets/Redirect_a_P
OST_Request_Forward.html;query=GET%20POST;match=and;where=all;stem=no
ky
Re: Any known good configuration for mod_perl DSO?
We built our own RPM that did source level builds on our entire system. So you load the rpm and it in turn executes a build script that built our entire system. Not just apache, modperl and mason but also it rebuilt all the modules that were needed, compiled external binaries, installed the Oracle libs and drivers and auto configured all configuration files based on the host it was on and a host-configuration mapping. Seemed to work well. John- On Mon, 24 Jun 2002 17:07:52 -0400 Wilbur, Charlton [EMAIL PROTECTED] wrote: Hello collective wisdom, I have the task of making Apache, mod_perl, and HTML::Mason work together under RedHat. I know this is a problem; the most frequently recommended solution that I've found is to build everything from scratch and link it all together, without using DSOs. However, my constraints are that all configuration management must be handled using RPMs, because we have a multitude of web servers that must all be maintained in parallel. My order of preference is for using downloadable binary RPMs, followed by using SRPMs and building from scratch, and finally followed by rolling my own RPMs. So I have a couple of questions that I'm currently researching, and if anybody here knows the answers, I'd be grateful to hear them: First, is there a known good binary RPM configuration, a combination of mod_perl and apache RPMs, from RedHat or another vendor that doesn't suffer from the silent-segfault problem? Second, is it possible that building from source RPMs would prevent the problem? Occasionally I've seen problems like this arise due to differing versions of the toolchain, and building from source RPMs would ensure that the same toolchain was used to build all of the components. If I find answers to these questions elsewhere before I receive answers from this list, I'll follow up to myself and share the wisdom. Thanks, Charlton -- Charlton Wilbur [EMAIL PROTECTED]
RewriteRule and AccelPass conflict
I'm trying to add a RewriteRule, but it's not working:
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www.animewallpapers.com(:80)?$
RewriteCond %{HTTP_HOST} !^64.246.28.97(:80)?$
RewriteRule ^/(.*) http://www.animewallpapers.com/$1 [L,R]
I want to make it so that if someone accesses that website via any
hostname other than www.animewallpapers.com or 64.246.28.97, then it
will redirect them to http://www.animewallpapers.com/. I copied those
rules exactly from another httpd.conf where it works.
However, the directives were being ignored. I realized the problem is
probably because of this line:
AccelPass / http://127.0.0.1:8010/
The site has a mod_perl backend running on port 8010. Apache is
proxying those connections to port 8010 before it has a chance to
invoke the RewriteRule above.
I thought of putting the RewriteRule on the backend mod_perl, but I
don't think it will work there because the HTTP_HOST would have been
changed to 127.0.0.1.
Any suggestions on how I can get the RewriteRule to take precedence
over the AccelPass?
Re: RewriteRule and AccelPass conflict
On Mon, Jun 24, 2002 at 05:37:51PM -0400, Philip Mak wrote:
I'm trying to add a RewriteRule, but it's not working:
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www.animewallpapers.com(:80)?$
RewriteCond %{HTTP_HOST} !^64.246.28.97(:80)?$
RewriteRule ^/(.*) http://www.animewallpapers.com/$1 [L,R]
I want to make it so that if someone accesses that website via any
hostname other than www.animewallpapers.com or 64.246.28.97, then it
will redirect them to http://www.animewallpapers.com/. I copied those
rules exactly from another httpd.conf where it works.
However, the directives were being ignored. I realized the problem is
probably because of this line:
AccelPass / http://127.0.0.1:8010/
I would think that you would need something like the following.
Location /
SetHandler rewrite accel
# rewrite rules and accel rules
/Location
Or something like that... Your goal is to stack these handlers, so that
rewrite happens first and accel second.
I've never tried this, but it might work
Rob
--
Robert Landrum
Systems Programmer
liapreq problems
I'm not sure if this is the right place to request assistance with this perl module installation issue. Please direct me to the proper person if possible. I have been trying to install the libapreq-1.0 module through CPAN and through the tar (Makefile.PL) to no avail. I keep getting various errors. The following error is what I get when trying to install through the Makefile.PL method. Any ideas on how to fix this? Is there a global variable called INC that has to include the i386 directory? --- [root@borg libapreq-1.0]# perl Makefile.PL make install Can't locate mod_perl.pm in INC (INC contains: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 12. BEGIN failed--compilation aborted at Makefile.PL line 12. [root@borg libapreq-1.0]# slocate mod_perl.pm /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm --- Thanks for your time, Brian.
Re: RewriteRule and AccelPass conflict
On Mon, Jun 24, 2002 at 06:12:04PM -0400, Robert Landrum wrote: I would think that you would need something like the following. Location / SetHandler rewrite accel # rewrite rules and accel rules /Location Or something like that... Your goal is to stack these handlers, so that rewrite happens first and accel second. That doesn't work: $ apachectl configtest Syntax error on line 1011 of /usr/local/apache/conf/httpd.conf: SetHandler takes one argument, a handler name
Re: Knowing your limitation - was Re: [JOB] Crack OOP Perl whitebox tester wanted
My point is still the same, and you both concede that the problem is ultimately your lack of management ability. The point I was trying to illustrate was that it's really not OK for you to just say, Yup, that's my limitation, so be it. In every way conceivable, that's wrong in that it goes against necessary Due Diligence in fulfilling your mission/vision, not to mention the negligence to your stock holders/investors... You wouldn't hire a PM who said, I don't know how to manage critical path, so I'm just going to need lots and lots of bodies and money to get this project done. What you're both saying equates to the same thing. I accept your points that there are going to be barriers to just picking any body to fill a position, but during the interview process you should establish skills, abilities, compatibility, and affordability. Whether that person ultimately sits in the cube next to you or in a home office on the other side of the planet shouldn't be one of the factors in deciding whom you'll hire IF they have the skills, abilities, compatibility, and you can afford them to get the job done. Any other consideration is just putting an arbitrary quota on the type of people you'll have in your organization. When we look back 20 years ago many things were considered ok to hire based upon (sex, race, sexual orientation, etc), and it won't be too long before location will be considered just as pejorative, and those organizations that see that trend NOW and train their managers and teams to work virtually are the organizations that are going to be successful tomorrow. This is all ESPECIALLY critical to small companies in the current market. Why would any one choose a small company (who might not be around tomorrow) as a provider *OR* client/employer, when they can have a giant who's at least got the best chance to be around? I'll tell you why, because those small companies that can show they can do something better, more efficient, more *NIMBLE* and *ADAPTABLE* those are going to be the companies that people are willing to take risks on. Now this might all seem a bit off topic to some for this list but I think it's very relevant. I say that because in supporting something like mod_perl, or even just PERL in general, we are all the type of people that say: Yes, we realize this is not the hottest buzz word technology, and Yes, we realize that *arbitrary* standards like MCSE and J2EE say that Perl doesn't have a place, but I think we all know that's just crap. We program in Perl because it is the absolute best suited solution to a huge variety of problems. But, as these people have wonderfully illustrated we live in a world of perceptions, expectations, and assumption that often have little or nothing to do with doing what's best. The only way that these non-buzz technologies are going to stay around, stay staffed, and stay viable is if we as developers have a market, and I think the days were we get hired by company A and work until retirement are long gone. This means we ALL need to learn to be adaptable, pragmatic, and focused on standard ways of getting jobs done, and challenge every old world philosophy that holds that back. -Zac - Original Message - From: Gunther Birznieks [EMAIL PROTECTED] To: Tom Mornini [EMAIL PROTECTED]; Zac Morris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 21, 2002 11:36 PM Subject: Re: Knowing your limitation - was Re: [JOB] Crack OOP Perl whitebox tester wanted I agree with Tom but for different reasons. I would almost never accept a telecommuter I didn't know and that may even be if he or she came recommended. Everyone has different personalities and cultures and it takes time to really get to know how to effectively communicate with someone because everyone has different vocabulary even coming from the same country. And vice versa. Every person is an individual and it's really tough to find out the individual way someone needs to be managed over long distances. Face to face communication is the quickest most efficient way to learn how best to communicate (and hence manage) with most people and vice versa. eg You need to learn to read between the lines of how someone writes. One person's friendly sarcasm may be another person's insult. Without figuring these things out in person first, frictions can result at worst and usually at best, there will be inefficiency in communication (o, THAT'S what you meant...). We have accepted some of our employees telecommuting from the other side of the world but our best success has come from people who have been in our office physically for 3 months at minimum and then go back to where they came from to work. But people who we don't know their work habits... that is much more difficult to manage. For someone who wants to telecommute from the other side of the world, bringing them here for 3 months and housing them and then topping it up with long distance
Re: Any known good configuration for mod_perl DSO?
Hi there,
On Mon, 24 Jun 2002, Wilbur, Charlton wrote:
I have the task of making Apache, mod_perl, and HTML::Mason work together
under RedHat. I know this is a problem;
Not necessarily; look at this thread for example...
73,
Ged.
--
From [EMAIL PROTECTED] Tue Jun 25 00:08:24 2002
Date: 22 Jun 2002 23:23:01 -0400
From: Chip Turner [EMAIL PROTECTED]
To: Zac Morris [EMAIL PROTECTED]
Cc: Jeremy Weatherford [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Fascinating segfault at Apache startup
Zac Morris [EMAIL PROTECTED] writes:
Honestly though Chip I have to pipe up here.
I was a gung ho RedHat supporter when I first got involved in the
linux world, and I still believe with it's RPMs and GUI tools it's
still the best for both new users and corporate environments, but
man, if you wanna do something that not the EXACT OS version-RPM
based software version, (hmmm, like DEVELOPMENT) you are SERIOUSLY
screwed with RPM more times than not.
It depends. Usually it isn't RPM that is the problem, it's the
-other- software you've installed with RPM. Dependencies tend to be
an all-or-nothing affair, though, which makes the situation more
complicated.
So I have spent the last FIVE full days about 10 hours a day setting
up redhat 7.3 (sans as many of the RPMs as I could possible get away
with). Now granted perl 5.6.1 was one of the RPMs I *did* install,
as was sendmail (since Redhat has REALLY whacked that one up with
the assumed workstation mode, but I at least know how to FIX
that), but my apache, mod_perl, java, tomcat, etc I built entirely
from source utilizing my /opt/{appname} everything all together
strategy.
I now have a pretty swank lil server setup here. I just
successfully tested my perl/DBD::Pg connections and i'll confirm
jdbc to Pg tomorrow and I'll be set for some major develpment
efforts.
I'm not familiar with tomcat, so I can't really comment on it
specifically. But, before I came to Red Hat, I was a compile from
source guy, even on production servers. Lots of reasons, but one was
that I didn't know RPM. It seemed like a hassle to deal with it for
little things, etc... so I didn't.
My personal suggestion would be to try to work with the default OS
instead of against it. Sometimes this is impossible, but sometimes it
isn't so bad. For instance, instead of compiling straight from
source, you could take our RPMs, modify them (such as making apache
live in /opt), maybe throw in a more recent version, and see how it
works. Likewise, building tomcat, java, etc, as RPMs may save you
time later when you need to rebuild a box, or clone the system, or
should disaster strike. Recompiling, checking dependencies by hand,
etc, really is time consuming. But, of course, so is learning RPM :)
It definitely is a difficult road. Having travelled it myself,
though, I find it to be tremendously better than how I used to do
things. It depends on your own personal preferences, though, as well
as company policies, your peers' skillsets, etc. No one answer fits
everything, but I really do think that package management of some kind
(RPMs, debian, etc) offers many superiorities over recompiling from
source. YMMV :) There's no one single answer (too much context), but
in general, whatever OS you use, it usually is easier to work with it
and the tools it provides than against it.
When it comes to perl and mod_perl, we've been working to try to make
sure it works reliably from RPMs. RH 7.3 should work well out of the
box, as should 7.2, once all errata applied. The rest of this thread
points out a few issues, though, but I think that tends to be issues
with other perl modules that have shared library components. If you
(or anyone else!) have specific failures or test cases you've seen,
though, I'll look into it and see if it is something we can fix.
Cheers,
Chip
--
Chip Turner [EMAIL PROTECTED]
Red Hat, Inc.
(Beginning of?) english translation for mod_deflate
Hi all (If I haven't missed it, there's still no alternative mod_[accel|deflate] discussion list.) I have recently installed mod_accel and mod_deflate, and since there seems to be no english documentation of mod_deflate around, I have made a translation with the help of babelfish, which is still rather bad but useful enough for me, and put it up here: http://pflanze.mine.nu/~chris/mod_deflate/mod_deflate_readme_EN.html Hope it's useful to others, too. Christian. (I assume Igor Sysoev will see this mail anyway so I'm saving the copy :)
OT - Looking for Information
We have a database here that we manage all of our inventory in (using mod_perl, of course), but our management is thinking of implementing Marimba. I've been all over the web and the news groups and no one seems to have anything to say. I was wondering if any of you out there on the mod_perl list, experienced as you are in the ways of management, have any ideas on where to find people who have actually used this product? ANY assistance apprecaited I'm terribly sorry for the off topic post, Jimi
RE: when to mod_perl?
You don't mention what OS you're using, but with Linux, 256mb just running httpd seems quite generous whether you're using mod_perl or not. From what I know, mod_perl is going to give you more performance on any given box. And now, I can't resist: When should you? Why, when you're in the mod of course ;) David LeBlanc Seattle, WA USA -Original Message- From: md [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 19:22 To: [EMAIL PROTECTED] Subject: when to mod_perl? Hello, I'm working on a dynamic site that I originally thought I would do with mod_perl. Now after reviewing the requirements and available hardware, I wonder if mod_perl will be my best solution. The machine will not be a huge box (though I wasn't provided much in the way of specs) and will only have 256M of RAM. There will be static content, incuding 5-10 images per page. The client has only given me sparse information, but claimed that he currently had 4,000 unique visitors a day and wanted to move to 10,000-15,000 unique visitors per day (he didn't give me page view stats). I may or may not be able to set up multiple instances of Apache. Given limited hardware (esp. RAM), am I better off to go with mod_perl (larger Apache processes with limited RAM) or CGI (smaller apache processes but the usual cons)? Thanks... __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: when to mod_perl?
Quoting md [EMAIL PROTECTED]: Hello, I'm working on a dynamic site that I originally thought I would do with mod_perl. Now after reviewing the requirements and available hardware, I wonder if mod_perl will be my best solution. The machine will not be a huge box (though I wasn't provided much in the way of specs) and will only have 256M of RAM. There will be static content, incuding 5-10 images per page. The client has only given me sparse information, but claimed that he currently had 4,000 unique visitors a day and wanted to move to 10,000-15,000 unique visitors per day (he didn't give me page view stats). I may or may not be able to set up multiple instances of Apache. Given limited hardware (esp. RAM), am I better off to go with mod_perl (larger Apache processes with limited RAM) or CGI (smaller apache processes but the usual cons)? You can easily build an application that uses the best of both worlds. The biggest benefit of mod_perl is speed, but you don't have to tie yourself tightly to mod_perl to get that benefit. I would build your application using plain old CGI, following the guidlines that mod_perl provides for running CGI applications under the Apache::Registry module. If you properly analyse your application, and build small tight CGI scripts, then when the load goes up, you can pick and choose the heaviest hit scripts and run them under Apache::Registry for the performance boost. Also, if the load goes really high, you can ask for more hardware, and run the entire site under Apache::Registry without any code changes. I would recommend taking a look at CGI::Application. It provides a very clean framework for building CGI programs, and by using it, you will avoid most if not all of the pitfalls that most CGI programs have that require them to be recoded, or cleaned up for use with Apache::Registry. Good luck... Cees
(newbie) Problems compiling XML::LibXSLT
Hello, I'm having some problems compiling the XML::LibXSLT module and was wondering if anyone could help. I've successfully compiled and tested libxml2 2.4.22 and libxslt 1.0.18, and have been able to get the make procedures to find libxml when compiling things like Sablotron, etc. However, I can't get the XML::LibXSLT makefile to find my libxslt libraries. No matter what options I pass for LIBS and INC, I keep getting the following result: running xslt-config... failed using fallback values for LIBS and INC options: LIBS='-L/usr/local/lib -L/usr/lib -lxslt -lxml2 -lz -lm' INC='-I/usr/local/include -I/usr/include' If this is wrong, Re-run as: $ perl5 Makefile.PL LIBS='-L/path/to/lib' INC='-I/path/to/include' looking for -lxslt... no libxslt not found Try setting LIBS and INC values on the command line Or get libxslt and libxml2 from http://www.libxml.org/ If you install via RPMs, make sure you also install the -devel RPMs, as this is where the headers (.h files) are. I installed libxml2 and libxslt from tar.gz files on a FreeBSD 4.4 system, but it's set up a bit strangely... It's on a virtual server, so / actually maps to /usr/home/username/. Libxml is installed at (using the virtual directory structure) /usr/local/libxml2-2.4.22 and libxslt is installed at /usr/local/libxslt-1.0.18. Additionally, I have soft links in the /usr/local directory (libxml - libxml2-2.4.22, libxslt - libxslt-1.0.18). I've tried passing LIBS='-L/usr/home/username/usr/local/libxslt/lib' INC='-I/usr/home/username/usr/local/libxslt/include' on the command line as suggested, as well as variants omitting the /usr/home/username part and using the full directory names instead of the links. Same results each time. I'm not too familiar with passing compiler flags, though. Am I passing the wrong values, or is there something I'm missing? TIA. Sincerely, Scott G. Kearn
Re: when to mod_perl?
--- Cees Hek [EMAIL PROTECTED] wrote: I would build your application using plain old CGI, following the guidlines that mod_perl provides for running CGI applications under the Apache::Registry module. If you properly analyse your application, and build small tight CGI scripts, then when the load goes up, you can pick and choose the heaviest hit scripts and run them under Apache::Registry for the performance boost. Thanks...that sounds reasonable. I doubt that all the dynamic pieces of this site would really require mod_perl. To answer another's reply, this will run on either Linux or BSD. Also, if the load goes really high, you can ask for more hardware, and run the entire site under Apache::Registry without any code changes. Upgrading hardware once the load gets high was discussed...This would make the migration easier, as I have told the client that we may start with CGI then move to mod_perl later. I've never used Apache::Registry before, but this sounds like a good solution. I would recommend taking a look at CGI::Application. It provides a very clean framework for building CGI programs, and by using it, you will avoid most if not all of the pitfalls that most CGI programs have that require them to be recoded, or cleaned up for use with Apache::Registry. I normally use CGI::Application, but in this case I'll also need something like CGI::Session as well, not to mention either Template-Toolkit or HTML::Template. Are there any gotchas with CGI::Session and Apache::Registry? And yes, I'll read The Guide :) Good luck... Thanks for the help! __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: liapreq problems
Brian Zammit wrote: I'm not sure if this is the right place to request assistance with this perl module installation issue. Please direct me to the proper person if possible. I have been trying to install the libapreq-1.0 module through CPAN and through the tar (Makefile.PL) to no avail. I keep getting various errors. The following error is what I get when trying to install through the Makefile.PL method. Any ideas on how to fix this? Is there a global variable called @INC that has to include the i386 directory? the issue is clear. You've installed perl and mod_perl from RPM (or other) packages compiled on different machine. So your perl package is using i686-linux for its arch specific libs, but on the machine mod_perl was compiled on it was i386-linux. recompile the mod_perl package (SRPM?) and then proceed to install apreq again. you could probably do some manual moves but I don't advise you to do that. --- [root@borg libapreq-1.0]# perl Makefile.PL make install Can't locate mod_perl.pm in @INC (@INC contains: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 12. BEGIN failed--compilation aborted at Makefile.PL line 12. [root@borg libapreq-1.0]# slocate mod_perl.pm /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm --- Thanks for your time, Brian. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2.0.39 and mod_perl
Kent, Mr. John wrote:
Greetings,
Attempting to build mod-perl with Apache-2.0.39
Following the instructions on:
http://perl.apache.org/release/docs/2.0/user/install/install.html
When I get to
CREATE THE BUILD ENVIRONMENT
and run
% perl Makefile.PL MP_AP_PREFIX=/home/stas/src/httpd-2.0.39
Get!!! Unable to open /users/webuser/src/httpd-2.0.39/include/apr.h: No such
file or directory
!!! Unable to open /users/webuser/src/httpd-2.0.39/include/apr.h: No such
file or directory
!!! Unable to open /users/webuser/src/httpd-2.0.39/include/apr.h: No such
file or directory
Repeated ...
/users/webuser/src/httpd-2.0.39/include is there, there just isn't any apr.h
file.
There is an ap_release.h file, should I copy that to apr.h?
Because in the source it's in httpd-2.0/srclib/apr/include/apr.h and
once installed it's in where_installed/include/apr.h
The install is indeed borked with MP_AP_PREFIX. I've never noticed this
problem since I'm still using MP_APXS, so for now try using MP_APXS
instead of MP_AP_PREFIX which is the path to the installed apxs, e.g. on
my machine it's MP_APXS=/home/stas/httpd/prefork/bin/apxs. This other
option was needed because of win32 and supposed to become the only
option to simplify things.
I've patched Build.pm to find apr.h and complete the build, but not sure
if that's the right thing. It's still incomplete since 'make test' won't
find apxs|httpd.
Index: lib/Apache/Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.102
diff -u -r1.102 Build.pm
--- lib/Apache/Build.pm 23 Jun 2002 21:46:09 - 1.102
+++ lib/Apache/Build.pm 25 Jun 2002 03:33:43 -
@@ -764,7 +764,9 @@
my $dir = $self-ap_includedir;
-my $header = $dir/apr.h;
+my $header = $self-{MP_AP_PREFIX}
+? $dir/../srclib/apr/include/apr.h
+: $dir/apr.h;
open my $fh, $header or do {
error Unable to open $header: $!;
return undef;
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: when to mod_perl?
md wrote: Hello, I'm working on a dynamic site that I originally thought I would do with mod_perl. Now after reviewing the requirements and available hardware, I wonder if mod_perl will be my best solution. The machine will not be a huge box (though I wasn't provided much in the way of specs) and will only have 256M of RAM. There will be static content, incuding 5-10 images per page. The client has only given me sparse information, but claimed that he currently had 4,000 unique visitors a day and wanted to move to 10,000-15,000 unique visitors per day (he didn't give me page view stats). I may or may not be able to set up multiple instances of Apache. Given limited hardware (esp. RAM), am I better off to go with mod_perl (larger Apache processes with limited RAM) or CGI (smaller apache processes but the usual cons)? Don't get mislead by the memory requirements. If your code will run 10 times faster you will need *at least* 10 times less servers to do the job. But it's not uncommon to get even better speedups. So chances are that mod_perl will be a win in any case. Read the guide for restricting the memory used, shared memory, etc., and you are all set. It includes some numbers, showing how much memory you really need if you follow the guidelines. The only situation when mod_cgi could be a win over mod_perl is when you have almost zero code loaded and most of your operations are CPU or IO/bound, so mod_perl's precompilation/caching won't help much. but that's a very rare situation. In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: (newbie) Problems compiling XML::LibXSLT
Sorry Scott, this is the *mod_perl* list. And this kind of questions is very non-desired here, since it has absolutely nothing to do with mod_perl. The XML::LibXSLT manpage includes the email of the author (hey Matt :) and he will be able to help you directly or point you to the mailing list that is created for this purpose if any. Please refrain from posting this kind of questions to this list in the future and stick to the mod_perl topics. Thanks. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: when to mod_perl?
--- Stas Bekman [EMAIL PROTECTED] wrote: In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. Actually at first I was planning to do full fledged mod_perl handlers, so that's why I wanted to plan before I coded. I was just a bit worried about the amount of static content. In the past I've had a lot more hardware to work with and I never had to worry about it much. I think you all have answered my question well enough that I feel confortable sticking with straight mod_perl. Thanks... __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: when to mod_perl?
wait a second ... don't forget using proxy: it saves you a lot of dynamical calls, especially if you have also a database. Peter Bi - Original Message - From: md [EMAIL PROTECTED] To: Stas Bekman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 24, 2002 9:36 PM Subject: Re: when to mod_perl? --- Stas Bekman [EMAIL PROTECTED] wrote: In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. Actually at first I was planning to do full fledged mod_perl handlers, so that's why I wanted to plan before I coded. I was just a bit worried about the amount of static content. In the past I've had a lot more hardware to work with and I never had to worry about it much. I think you all have answered my question well enough that I feel confortable sticking with straight mod_perl. Thanks... __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: when to mod_perl?
Peter Bi wrote: wait a second ... don't forget using proxy: it saves you a lot of dynamical calls, especially if you have also a database. good point, Peter. And there are many others. It's the best if you can take some time and read the guide before you start coding. It includes a big chunk of the wisdow that passed through this list in the last 5 years. In your case I'd suggest reading at least: http://perl.apache.org/release/docs/1.0/guide/strategy.html http://perl.apache.org/release/docs/1.0/guide/scenario.html http://perl.apache.org/release/docs/1.0/guide/performance.html and probably these two: http://perl.apache.org/release/docs/general/perl_reference.html http://perl.apache.org/release/docs/1.0/guide/porting.html __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
