Can't redirect a POST request and forwarding the content.
Hello
I'm trying to Redirect a POST request and forwarding the content, but I
can't make it work.
I use the following code:
---
use Apache::Request ();
use Apache::Constants qw(:common :methods MOVED);
sub handler {
my $r= shift;
my $query= Apache::Request-new($r);
my $content = $r-content;
$r-method_number(M_GET);
$r-method(GET);
$r-headers_in-unset(Content-length);
$r-args($content);
return $r-internal_redirect(/RedirectHandler/);
---
My redirect works but when I read the $r-as_string in the RedirectHandler I
see a POST /post HTTP/1.1. That should be a GET right?
I can't read any content in the RedirectHandler either.
Many thanks,
-Nick
Re: Speed of downloading problem.
On Mon, 4 Feb 2002 08:37:52 -0600 , Purcell, Scott [EMAIL PROTECTED] said: The test is taking a 50mb file and placing it in the doc root of the IIS and Apache/htdocs. Then just having a href link pointing to it. We have ruled out the firewall and any networking. I know nothing about NT, but I'd play with the SendBufferSize config variable. -- andreas
image corruption
I'm attempting to use mod_perl and Template Toolkit to serve up
templates. However, I'm having a problem with the images in those
templates: They're passing through the content handler, and thus getting
corrupted.
My first thought was to return DECLINED from the content handler if the
request is not for text/html content; however, since I'm using a
Location directive, the content_type is always empty since there's no
direct mapping to an actual image file. I could use an Alias to map the
URI to the file, but then I wouldn't have the path_info that I'm using
to call the template.
Since my test code, using path_info, is based on an example from the
Template Toolkit docs, I feel like I'm probably overlooking something
basic. So, I'd appreciate it if someone could show me the error of my
ways. :-)
Here are the relevant chunks of config and code:
from httpd.conf
---
...
Location /tt
SetHandler perl-script
PerlHandler Apache::Test::Mod
PerlSetVar WEBROOT /usr/local/apache/tt/html
/Location
...
Apache::Test::Mod
-
...
sub handler {
my $r = shift;
# this doesn't work
#return DECLINED unless $r-content_type eq 'text/html';
my $WEBROOT = $r-dir_config('WEBROOT')
or return fail( $r, SERVER_ERROR, 'WEBROOT' not specified );
my $file = $r-path_info;
my $vars = {
content = $r-content_type,
};
$r-content_type('text/html');
$r-no_cache(1);
my $template = Template-new( {
INCLUDE_PATH = $WEBROOT:$WEBROOT/include,
OUTPUT = $r,
} );
$template-process( $file, $vars, $r)
or return fail( $r, SERVER_ERROR, $template-error );
$r-send_http_header();
$r-print( $output );
return OK;
}
...
index.html (test template)
--
html
head
titletest/title
/head
body
pcontent_type: [% content %]/p
pimage: img src=images/hello.gif/p
/body
/html
Thanks.
-Tim
Re: image corruption
Tim,
I don't know a lot about mod_perl, but I would guess you may want to look
at
invoking a subrequest via lookup_file or lookup_uri. E.g.
my $ct = $r-lookup_uri('images/logo.tif')-content_type;
regards
John
John Kelly
IBM Hursley
Tim Noll [EMAIL PROTECTED]
05/02/2002 12:21
To: [EMAIL PROTECTED]
cc:
Subject:image corruption
I'm attempting to use mod_perl and Template Toolkit to serve up
templates. However, I'm having a problem with the images in those
templates: They're passing through the content handler, and thus getting
corrupted.
My first thought was to return DECLINED from the content handler if the
request is not for text/html content; however, since I'm using a
Location directive, the content_type is always empty since there's no
direct mapping to an actual image file. I could use an Alias to map the
URI to the file, but then I wouldn't have the path_info that I'm using
to call the template.
Since my test code, using path_info, is based on an example from the
Template Toolkit docs, I feel like I'm probably overlooking something
basic. So, I'd appreciate it if someone could show me the error of my
ways. :-)
Here are the relevant chunks of config and code:
from httpd.conf
---
...
Location /tt
SetHandler perl-script
PerlHandler Apache::Test::Mod
PerlSetVar WEBROOT /usr/local/apache/tt/html
/Location
...
Apache::Test::Mod
-
...
sub handler {
my $r = shift;
# this doesn't work
#return DECLINED unless $r-content_type eq 'text/html';
my $WEBROOT = $r-dir_config('WEBROOT')
or return fail( $r, SERVER_ERROR, 'WEBROOT' not specified );
my $file = $r-path_info;
my $vars = {
content = $r-content_type,
};
$r-content_type('text/html');
$r-no_cache(1);
my $template = Template-new( {
INCLUDE_PATH = $WEBROOT:$WEBROOT/include,
OUTPUT = $r,
} );
$template-process( $file, $vars, $r)
or return fail( $r, SERVER_ERROR, $template-error );
$r-send_http_header();
$r-print( $output );
return OK;
}
...
index.html (test template)
--
html
head
titletest/title
/head
body
pcontent_type: [% content %]/p
pimage: img src=images/hello.gif/p
/body
/html
Thanks.
-Tim
RE: Speed of downloading problem.
Thanks Perrin, Here is the part of the httpd.conf that I believe you wanted to see. # # Apache on Win32 always creates one child process to handle requests. If it # dies, another child process is created automatically. Within the child # process multiple threads handle incoming requests. The next two # directives control the behaviour of the threads and processes. # # # MaxRequestsPerChild: the number of requests each child process is # allowed to process before the child dies. The child will exit so # as to avoid problems after prolonged use when Apache (and maybe the # libraries it uses) leak memory or other resources. On most systems, this # isn't really needed, but a few (such as Solaris) do have notable leaks # in the libraries. For Win32, set this value to zero (unlimited) # unless advised otherwise. # # NOTE: This value does not include keepalive requests after the initial # request per connection. For example, if a child process handles # an initial request and 10 subsequent keptalive requests, it # would only count as 1 request towards this limit. # MaxRequestsPerChild 0 # # Number of concurrent threads (i.e., requests) the server will allow. # Set this value according to the responsiveness of the server (more # requests active at once means they're all handled more slowly) and # the amount of system resources you'll allow the server to consume. # #ThreadsPerChild 1 # broke the IO socket #Should be on 50 like below ThreadsPerChild 50 -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 10:10 AM To: Purcell, Scott; [EMAIL PROTECTED] Subject: Re: Speed of downloading problem. I have Apache/mod_perl installed on a NT box, and I am allowing customers to do downloads of High-Resolution assets. My problem is the speed of downloads is about 1/3 slower than the same box running IIS. Can you post your httpd.conf? Or at least the parts of it about threads and processes? It is possible that Apache is just not that fast on NT. NT support is experimental in the 1.3 series. One thought here was to go to 2.0 You can't run mod_perl 1.x on Apache 2.0. Another thing you could try is having multiple servers. One could handle static requests and proxy the dynamic ones to mod_perl. I don't know if IIS knows how to do this or not, but there's probably something available for NT that does it. - Perrin
Re: mod_perl, OpenPGP Math::Pari
[snip]
perl -V
That's lower case perl, upper case V.
[snip]
now that's funny!
ok, so I was babbling.. try this. A simple perl script useing
Crypt::OpenPGP runs fine from the command line while the same subroutine
used in a mod_perl module on the same machine crashes. Why? Its nothing
to do with global variables, multiple runs, or random occurances.
I put a warn statement into Crypt::Primes to show the offending variable
$B represented as 'B'. The only line I can find in Crypt::Primes that
sets the value of $B is:
my $B = floor ( $c_opt * ( $k ** 2 ) );
'floor' is imported from Math::Pari which according to the docs does not
use any enviromental variables.
Throughout the run from the commandline $B remains an everchanging
integer, while during the mod_perl run it suddenly becomes something
else (37e5156f in the example below) subsequently crashing the program
when it is involved in a numeric comparison.
and, yeh, if no one else has any suggestions this time, I'll drop it.
Thanks, Tom, for the nudge I needed to get this far..
cheers,
J
run from the commandline (test_pgp_gen.pl):
my $attrib = {
Size = '2048',
Identity = 'PGP EzyDVD [EMAIL PROTECTED]',
Password = 'a new passphrase for you',
};
my $self = {
EV_config = {
PGPKeyLoc = 'd_main/data/.pgptest',
},
};
# test Key Generation
($self) = pgp_keygen($self,$attrib);
exit;
sub pgp_keygen{
##
my ($self,$attrib) = @_;
my $file = time;
warn Generating Keys;
use Crypt::OpenPGP;
warn Creating Keychain;
my $keychain = Crypt::OpenPGP-new;
warn Generating Keys with:\n\tType = 'RSA'\n\tSize =
$attrib-{'Size'}\n\tIdentity = $attrib-{'Identity'}\n\tPassphrase =
$attrib-{'Password'};
my ($public, $private) = $keychain-keygen (
Type = 'RSA',
Size = $attrib-{'Size'},
Identity = $attrib-{'Identity'},
Passphrase = $attrib-{'Password'},
#
Verbosity = 1,
) or die $keychain-errstr();
warn Generating complete. Saving..;
$public = $public-save;
open(PUBLIC,'',$$self{'EV_config'}{'PGPKeyLoc'}/$file.'.public');
print PUBLIC $public;
close(PUBLIC);
$private = $private-save;
open(PRIVATE,'',$$self{'EV_config'}{'PGPKeyLoc'}/$file.'.private');
print PRIVATE $private;
close(PRIVATE);
warn Saving complete.;
return ($self);
}
[]$ perl test_pgp_gen.pl
Generating Keys at test_pgp_gen.pl line 29.
Creating Keychain at test_pgp_gen.pl line 31.
Generating Keys with:
Type = 'RSA'
Size = 2048
Identity = PGP EzyDVD [EMAIL PROTECTED]
Passphrase = a new passphrase for you at test_pgp_gen.pl line 33.
B = 43, r = 0.5, k = 22, q = 5347 at
/usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 151, r = 0.506631180276321, k = 41, q = 2267129 at
/usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 506, r = 0.53037992595081, k = 75, q = 2196811726937 at
/usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 1520, r = 0.562081100800386, k = 130, q = 26428241092041745277471 at
/usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 3352, r = 0.667875988226359, k = 193, q =
688430562782715717240302427312908015051 at
/usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 9564, r = 0.588637765080919, k = 326, q =
965545119950202842999573881663024114299390132769541041 at
/usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 29240, r = 0.56933184524636, k = 570, q =
1079008567477111753397094310847156029079713553247572710822855637214539638256680204084416659
at /usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 94371, r = 0.554913243836389, k = 1024, q =
2738877267722396215978314103886896155676111721678953257651796203192310298619466435015458288033302116849702218709734148499773910739678380930731862293431860017467060796038877
at /usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 60, r = 0.5, k = 26, q = 24359 at
/usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 190, r = 0.533359128724712, k = 46, q = 48084667 at
/usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 610.
B = 392, r = 0.674066449056276, k = 66, q = 43830135663841 at
Re: Speed of downloading problem.
Here is the part of the httpd.conf that I believe you wanted to see. Hmmm... I don't see anything wrong with this. It seems like the problem is simply that Apache 1.3.x is not as fast as IIS at sending static files on NT. Not too surprising. I've been told that Apache 2 is significantly better about this, but that won't help you right now. If this is a big problem for your application, my advice would be to either use a proxying system so that IIS (or something else) can send the static files and mod_perl can handle the dynamic stuff, or look at mod_perl alternatives for Win32 like PerlEx and FastCGI. - Perrin
Re: image corruption
When I try this example, I find that this line
my $file = $r-path_info;
will set $file to /index.html when I request the URL /tt/index.html
which leads to an error message that says,
reason: file error - /index.html: absolute paths are not allowed (set ABSOLUTE option)
You may want to clip off the leading slash or set the Template Toolkit
option ABSOLUTE, depending on which suits your needs.
Quoting Tim Noll ([EMAIL PROTECTED]):
I'm attempting to use mod_perl and Template Toolkit to serve up
templates. However, I'm having a problem with the images in those
templates: They're passing through the content handler, and thus getting
corrupted.
My first thought was to return DECLINED from the content handler if the
request is not for text/html content; however, since I'm using a
Location directive, the content_type is always empty since there's no
direct mapping to an actual image file. I could use an Alias to map the
URI to the file, but then I wouldn't have the path_info that I'm using
to call the template.
Since my test code, using path_info, is based on an example from the
Template Toolkit docs, I feel like I'm probably overlooking something
basic. So, I'd appreciate it if someone could show me the error of my
ways. :-)
Here are the relevant chunks of config and code:
from httpd.conf
---
...
Location /tt
SetHandler perl-script
PerlHandler Apache::Test::Mod
PerlSetVar WEBROOT /usr/local/apache/tt/html
/Location
...
Apache::Test::Mod
-
...
sub handler {
my $r = shift;
# this doesn't work
#return DECLINED unless $r-content_type eq 'text/html';
my $WEBROOT = $r-dir_config('WEBROOT')
or return fail( $r, SERVER_ERROR, 'WEBROOT' not specified );
my $file = $r-path_info;
my $vars = {
content = $r-content_type,
};
$r-content_type('text/html');
$r-no_cache(1);
my $template = Template-new( {
INCLUDE_PATH = $WEBROOT:$WEBROOT/include,
OUTPUT = $r,
} );
$template-process( $file, $vars, $r)
or return fail( $r, SERVER_ERROR, $template-error );
$r-send_http_header();
$r-print( $output );
return OK;
}
...
index.html (test template)
--
html
head
titletest/title
/head
body
pcontent_type: [% content %]/p
pimage: img src=images/hello.gif/p
/body
/html
Thanks.
-Tim
Re: image corruption
Another obvious option would be to put your images in a different directory, e.g. /images rather than /tt/images. Or, add another Location directive for /tt/images, and set the handler to the default handler. -Dave
Re: image corruption
Whoops, I hacked up my example a little to make it easier it to read,
and I accidentally removed the line:
$file =~ s{^/}{};
But, it was in the original. Really. :-)
-Tim
- Original Message -
From: Lyle Brooks [EMAIL PROTECTED]
To: Tim Noll [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, February 05, 2002 4:42 PM
Subject: Re: image corruption
When I try this example, I find that this line
my $file = $r-path_info;
will set $file to /index.html when I request the URL /tt/index.html
which leads to an error message that says,
reason: file error - /index.html: absolute paths are not allowed (set
ABSOLUTE option)
You may want to clip off the leading slash or set the Template Toolkit
option ABSOLUTE, depending on which suits your needs.
Quoting Tim Noll ([EMAIL PROTECTED]):
I'm attempting to use mod_perl and Template Toolkit to serve up
templates. However, I'm having a problem with the images in those
templates: They're passing through the content handler, and thus
getting
corrupted.
My first thought was to return DECLINED from the content handler if
the
request is not for text/html content; however, since I'm using a
Location directive, the content_type is always empty since there's
no
direct mapping to an actual image file. I could use an Alias to map
the
URI to the file, but then I wouldn't have the path_info that I'm
using
to call the template.
Since my test code, using path_info, is based on an example from the
Template Toolkit docs, I feel like I'm probably overlooking
something
basic. So, I'd appreciate it if someone could show me the error of
my
ways. :-)
Here are the relevant chunks of config and code:
from httpd.conf
---
...
Location /tt
SetHandler perl-script
PerlHandler Apache::Test::Mod
PerlSetVar WEBROOT /usr/local/apache/tt/html
/Location
...
Apache::Test::Mod
-
...
sub handler {
my $r = shift;
# this doesn't work
#return DECLINED unless $r-content_type eq 'text/html';
my $WEBROOT = $r-dir_config('WEBROOT')
or return fail( $r, SERVER_ERROR, 'WEBROOT' not specified );
my $file = $r-path_info;
my $vars = {
content = $r-content_type,
};
$r-content_type('text/html');
$r-no_cache(1);
my $template = Template-new( {
INCLUDE_PATH = $WEBROOT:$WEBROOT/include,
OUTPUT = $r,
} );
$template-process( $file, $vars, $r)
or return fail( $r, SERVER_ERROR, $template-error );
$r-send_http_header();
$r-print( $output );
return OK;
}
...
index.html (test template)
--
html
head
titletest/title
/head
body
pcontent_type: [% content %]/p
pimage: img src=images/hello.gif/p
/body
/html
Thanks.
-Tim
Re: image corruption
Ok, a couple of things...
1) You want to move the $r-send_http_header; call up before calling
$template-process();
2) Modify $template-process( $file, $vars, $r) to
$template-process( $file, $vars) since you specify OUTPUT = $r
when you create the Template object (so it's re-dundant).
3) get rid of the $r-print( $output ) line as well, $template-process()
is going to send the output to Apache the way you have it setup.
4) As David Ranney pointed out in a previous post, you might want to
put your images somewhere else, or adjust your URL
You get a path_info part only for the virtual component of your URL
(ie. there's no filesystem component beyond /tt ), but your URL for
images/hello.gif is relative to /tt, which means your handler for
Location /tt has got to fix things up.
...or..
If you make the URL hello.gif to resolve to something outside /tt,
then Apache should serve it up as a regular file, which I suspect is
what you want.
HTH
Lyle
Quoting Tim Noll ([EMAIL PROTECTED]):
Whoops, I hacked up my example a little to make it easier it to read,
and I accidentally removed the line:
$file =~ s{^/}{};
But, it was in the original. Really. :-)
-Tim
- Original Message -
From: Lyle Brooks [EMAIL PROTECTED]
To: Tim Noll [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, February 05, 2002 4:42 PM
Subject: Re: image corruption
When I try this example, I find that this line
my $file = $r-path_info;
will set $file to /index.html when I request the URL /tt/index.html
which leads to an error message that says,
reason: file error - /index.html: absolute paths are not allowed (set
ABSOLUTE option)
You may want to clip off the leading slash or set the Template Toolkit
option ABSOLUTE, depending on which suits your needs.
Quoting Tim Noll ([EMAIL PROTECTED]):
I'm attempting to use mod_perl and Template Toolkit to serve up
templates. However, I'm having a problem with the images in those
templates: They're passing through the content handler, and thus
getting
corrupted.
My first thought was to return DECLINED from the content handler if
the
request is not for text/html content; however, since I'm using a
Location directive, the content_type is always empty since there's
no
direct mapping to an actual image file. I could use an Alias to map
the
URI to the file, but then I wouldn't have the path_info that I'm
using
to call the template.
Since my test code, using path_info, is based on an example from the
Template Toolkit docs, I feel like I'm probably overlooking
something
basic. So, I'd appreciate it if someone could show me the error of
my
ways. :-)
Here are the relevant chunks of config and code:
from httpd.conf
---
...
Location /tt
SetHandler perl-script
PerlHandler Apache::Test::Mod
PerlSetVar WEBROOT /usr/local/apache/tt/html
/Location
...
Apache::Test::Mod
-
...
sub handler {
my $r = shift;
# this doesn't work
#return DECLINED unless $r-content_type eq 'text/html';
my $WEBROOT = $r-dir_config('WEBROOT')
or return fail( $r, SERVER_ERROR, 'WEBROOT' not specified );
my $file = $r-path_info;
my $vars = {
content = $r-content_type,
};
$r-content_type('text/html');
$r-no_cache(1);
my $template = Template-new( {
INCLUDE_PATH = $WEBROOT:$WEBROOT/include,
OUTPUT = $r,
} );
$template-process( $file, $vars, $r)
or return fail( $r, SERVER_ERROR, $template-error );
$r-send_http_header();
$r-print( $output );
return OK;
}
...
index.html (test template)
--
html
head
titletest/title
/head
body
pcontent_type: [% content %]/p
pimage: img src=images/hello.gif/p
/body
/html
Thanks.
-Tim
Re: mod_perl, OpenPGP Math::Pari
Hi there, On Wed, 6 Feb 2002, Jason Galea wrote: now that's funny! ok, so I was babbling.. try this. A simple perl script useing Crypt::OpenPGP runs fine from the command line while the same subroutine used in a mod_perl module on the same machine crashes. Why? There's a file in the mod_perl directory called SUPPORT. (That bit about 'perl -V' was taken from there. :) SUPPORT contains detailed instructions about what to do when mod_perl crashes, including what information to provide and how to generate a stack backtrace. 73, Ged.
Re: modperl growth
Rod Butcher wrote: My .05... I run a small communal webserver. Software had to be free, secure, stable, support Perl, multiple domains and ASP, be reasonably simple, originally run on Win32 and be capable of migration to Linux later. Nobrainer -- Apache, mod_perl, Apache::ASP. Only difficulty was getting mod_perl installed, it helped that I had a background in IT, I suspect a non-professional would find it impossible. Which is a shame because Win$ users expect everything to work out of the box wihout having to know anything. That's not meant as a criticism, but I think it's the reality now. I was thinking that too, but then I remembered that if you're not from an IT background, you're probably not going to be able to write a line of mod_perl code anyhoo. But, yeah, the installation/compilation process is daunting for a javascript/html jockey who is trying to pick which server side language (PHP, Perl, Python, JSP, etc.) to learn.
Re: modperl growth
Mark Maunder [EMAIL PROTECTED] writes: I was thinking that too, but then I remembered that if you're not from an IT background, you're probably not going to be able to write a line of mod_perl code anyhoo. No, but you can pick up Mason, embperl, or Apache::Template (the TT loaded into Apache). -- Dave Hodgkinson, Wizard for Hire http://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Interim Technical Director, Web Architecture Consultant for hire
perl cgi's and apache
I am having a problem getting my cgi script to complete processing when it is launched via apache server. The script itself runs fine from the command line. It is a script that processes a long array of values and interacts with a database per value. When the array is relatively short, the program will complete and everything is fine (even when launched through the browser). When the array is larger, and only when launched through the browser, the perl.exe on the Windows 2000 machine just seems to hang after about 30 seconds or so and if I stop apache server, it will start processing again and finish its job. I think I have all the apache timeout parameters set long enough. Can anyone help me out on this? Thanks
Re: perl cgi's and apache
On Tue, 5 Feb 2002, Jeff wrote: Date: Tue, 5 Feb 2002 19:21:39 -0500 From: Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: perl cgi's and apache I am having a problem getting my cgi script to complete processing when it is launched via apache server. The script itself runs fine from the command line. It is a script that processes a long array of values and interacts with a database per value. When the array is relatively short, the program will complete and everything is fine (even when launched through the browser). When the array is larger, and only when launched through the browser, the perl.exe on the Windows 2000 machine just seems to hang after about 30 seconds or so and if I stop apache server, it will start processing again and finish its job. I think I have all the apache timeout parameters set long enough. Can anyone help me out on this? Thanks Jeff, The browser may be what's timing out the process. There are many things you can do to work around such problem. Did you look in the guide (http://perl.apache.org/guide)? I searched for timeout, and the first suggestion is this: http://thingy.kcilink.com/modperlguide/debug/Handling_Server_Timeout_Cases_an.html However, you never mentioned that you're using mod_perl -- just Perl -- so the guide may not help all that much. (This is a *mod_perl* list you wrote to, you know. :) Regardless, one thing you can always do is to throw more hardware at the problem (bigger, faster machine; more memory; split up the load to a dedicated database server/light-weight frontend mod_perl-less Apache/big, fat mod_perl server backend). Or try to streamline your code -- maybe make one big SQL query for all your values rather than individual calls for each one. If none of that works for you, you may need to pass off the long-running process to a queue for a cronjob to pick up (well, maybe not cron if you're on Windows) or you spin it off to an external script to do the work. Search the guide. HTH, ky
Re: perl cgi's and apache
Perhaps you could give us some idea of your input set and how you interact with the database. Have you determined the break-point? At what array size? 10, 100, 1000, 10k, etc Also how do you interact with the DB? Do connect-disconnect? Do you 'prepare' your statement and use binding parameters? What Database engine are you using? Is it local or accross the LAN? And who is your web server running as? Perhaps you are hitting a quota for that user. Ken Y. Clark wrote: On Tue, 5 Feb 2002, Jeff wrote: Date: Tue, 5 Feb 2002 19:21:39 -0500 From: Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: perl cgi's and apache I am having a problem getting my cgi script to complete processing when it is launched via apache server. The script itself runs fine from the command line. It is a script that processes a long array of values and interacts with a database per value. When the array is relatively short, the program will complete and everything is fine (even when launched through the browser). When the array is larger, and only when launched through the browser, the perl.exe on the Windows 2000 machine just seems to hang after about 30 seconds or so and if I stop apache server, it will start processing again and finish its job. I think I have all the apache timeout parameters set long enough. Can anyone help me out on this? Thanks Jeff, The browser may be what's timing out the process. There are many things you can do to work around such problem. Did you look in the guide (http://perl.apache.org/guide)? I searched for timeout, and the first suggestion is this: http://thingy.kcilink.com/modperlguide/debug/Handling_Server_Timeout_Cases_an.html However, you never mentioned that you're using mod_perl -- just Perl -- so the guide may not help all that much. (This is a *mod_perl* list you wrote to, you know. :) Regardless, one thing you can always do is to throw more hardware at the problem (bigger, faster machine; more memory; split up the load to a dedicated database server/light-weight frontend mod_perl-less Apache/big, fat mod_perl server backend). Or try to streamline your code -- maybe make one big SQL query for all your values rather than individual calls for each one. If none of that works for you, you may need to pass off the long-running process to a queue for a cronjob to pick up (well, maybe not cron if you're on Windows) or you spin it off to an external script to do the work. Search the guide. HTH, ky -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering -
libapreq problem and mozilla 0.97
Just wondering if anyone has encountered this before and if it's been fixed
in libapreq for the upcoming release.
Basically, whenever I try and use Mozilla 0.97 with a file upload field on a
form and don't select any file in the field, libapreq seems to hang on the
$R-parse() call. Mozilla 0.98 seems to work fine, but 0.97 doesn't. While
it's easy enough to just say upgrade, it's still annoying that it hangs a
process for a while until our alarm goes off.
A couple of things I've noticed, the Mozilla 0.97 file fields might be a bit
broken. The raw POST request data is:
... stuff deleted ...
-5965166491649760492719885386
Content-Disposition: form-data; name=FMC-UploadFile1; filename=
Content-Type: application/octet-stream
-5965166491649760492719885386
... more stuff deleted ...
While under Mozilla 0.98, which doesn't hang libapreq, the request data is:
... stuff deleted ...
-20448977631102520059783368690
Content-Disposition: form-data; name=FMC-UploadFile1; filename=
Content-Type: application/octet-stream
-20448977631102520059783368690
... more stuff deleted ...
Note the extra blank line, which I think the lack of is causing the problem
under 0.97.
I did an strace under 0.97 and got:
read(4, POST /mail/~354ad16bd30a20352/ H..., 4096) = 2621
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL) = 1012943782
alarm(60) = 60
alarm(0)= 60
rt_sigaction(SIGALRM, NULL, {0x80ee530, [], SA_INTERRUPT|0x400}, 8) = 0
dup2(15, 2) = 2
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
brk(0x9574000) = 0x9574000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigaction(SIGALRM, {0x81c7c1c, [], SA_RESTART|0x400}, {0x80ee530, [],
SA_INTERRUPT|0x400}, 8) = 0
alarm(60) = 0
brk(0x9575000) = 0x9575000
brk(0x9576000) = 0x9576000
alarm(60) = 60
read(4,
So, it seems to be hanging because it's trying to read more data when there
isn't any. If I do basically the same request under IE I get:
read(4, POST /mail/~354ad16bd30a20352/ H..., 4096) = 2536
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL) = 1012944362
alarm(60) = 60
alarm(0)= 60
rt_sigaction(SIGALRM, NULL, {0x80ee530, [], SA_RESTART|0x400}, 8) = 0
dup2(15, 2) = 2
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigaction(SIGALRM, {0x81c7c1c, [], SA_RESTART|0x400}, {0x80ee530, [],
SA_RESTART|0x400}, 8) = 0
alarm(60) = 0
alarm(60) = 60
and it keeps going and works fine. Anyone know what might be happening? How
to fix it?
Rob
Re: libapreq problem and mozilla 0.97
On Tue, 2002-02-05 at 20:43, Rob Mueller (fastmail) wrote: Just wondering if anyone has encountered this before and if it's been fixed in libapreq for the upcoming release. Basically, whenever I try and use Mozilla 0.97 with a file upload field on a form and don't select any file in the field, libapreq seems to hang on the $R-parse() call. Mozilla 0.98 seems to work fine, but 0.97 doesn't. While it's easy enough to just say upgrade, it's still annoying that it hangs a process for a while until our alarm goes off. ... This is a known (and amazingly frustrating) bug in Mozilla rather than libapreq. It affects browsers based on mozilla (Galeon, etc.) as well, but it's been fixed (as you noted) in 0.9.8. For more info: http://bugzilla.mozilla.org/show_bug.cgi?id=116210 Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: [OT] RE: modperl growth
On Tue, 5 Feb 2002, Dave Rolsky wrote: On Mon, 4 Feb 2002, Andrew Ho wrote: One last thing that is hard is where is your DocumentRoot? This is a huge problem for web applications being installable out of the box. Perl can't necessarily figure that out by itself, either. You take a guess and then ask the user to confirm. And you can't guess you just ask. That's a good strategy (assuming a missing if in there somewhere). It can be augmented with the tactic of check for a running apache, see where it gets its config file from, and parse the config file to get the initial guess. (Note that I wouldn't want this to be a final guess; I'm using mod_perl in a virtual host config; the main apache config doesn't use it, and has a completely unrelated docroot (/usr/local/apache/htdocs as opposed to /home/appname/public_html)) There's nothing wrong with an interactive installer. What kills mod_perl apps is they simply have a README or INSTALL that says Copy all the template files to a directory called 'app-root' under your document root. My what? Which files are templates? I don't know this unix stuff; copy doesn't work right. I think we've all probably heard these words before... I guess my point is that installation is hard. Rather than trying to make it work for everybody out of the box, you should make it work for the typical case out of the box, and then provide hooks for installing it in custom places. I think the best installer is an interactive installer that tries really hard to provide good defaults. I agree; while I frequently leave unimportant considerations alone (note my main docroot above), I tend to have very poor luck with the works with the typical case out of the box, and then provides hooks which change with every bloo^W^W^W^W^Wfor installing it in custom places. I won't go into speculations why. Ed
Re: mod_perl, OpenPGP Math::Pari
Ged Haywood wrote: There's a file in the mod_perl directory called SUPPORT. (That bit about 'perl -V' was taken from there. :) SUPPORT contains detailed instructions about what to do when mod_perl crashes, including what information to provide and how to generate a stack backtrace. 73, Ged. yeh, read that... I guess I shoudn't have used the word crashes as it's really dies when it tries to do a numeric comparison on an alphanumeric string, which is entirely reasonable, so I'm not getting a core dump, and I don't think mod_perl itself is at fault. I suspect the implementation of GP/Pari as I ended up with the worst case as mentioned in the Math::Pari install and manually copied (as instructed) what I guess is a 'C' library file of some description (paricfg.h - I am by no stretch a C programmer..) to the proper location. It all seemed to work ok after that and as I had had troubles prior I already had my test scripts which all ran fine so I thought Hooray! Then I implemented the real system and got the errors mentioned. What I still don't understand is why the test scripts run ok, but the mod_perl implementation doesn't. (But on my dev server everything works as it should..) I'm going to reinstall GP/Pari on the production server using the src.rpm I found on the Pari site, then if that goes ok I might be able to install/update Math::Pari without errors, then maybe it'll all work.. that's the plan anyway.. cheers, -- J Web Developer Eight Degrees Off Centre http://www.eightdegrees.com.au/
Server error log says Accept mutex: sysvsem
The following message keeps appearing in my server error log after building a newer version of Apache (v.1.3.23) and mod_perl (v.1.26) than I had been running. I never saw this before (I think I had Apache 1.3.20 with mod_perl 1.24 most recently). What does it mean and should I worry? [Tue Feb 5 11:44:46 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) Thanks in advance. -al Al Pacifico Seattle, WA
Re: [OT] modperl growth (installers)
On Tue, 5 Feb 2002, Ed Grimm wrote: That's a good strategy (assuming a missing if in there somewhere). It can be augmented with the tactic of check for a running apache, see where it gets its config file from, and parse the config file to get the initial guess. (Note that I wouldn't want this to be a final guess; I'm using mod_perl in a virtual host config; the main apache config doesn't use it, and has a completely unrelated docroot (/usr/local/apache/htdocs as opposed to /home/appname/public_html)) Yep, been there, done that ;) The installer I mentioned for WeBoard UX was really pretty smart. It would look for the Apache binary (and ask if it couldn't find it), figure out if it had mod_perl (and ask for a different one if that binary didn't have mod_perl), check the Apache version, check the mod_perl version, find that Apache binary's config file (and ask...), figure out what user group that Apache ran as (to change certain permissions), tweak the Apache and config file to load WebBoard. And that's just what it did for Apache. It did a lot of other install/config tasks as well. Hmm, I really feel that this has gotten quite off-topic. Maybe I should create a Perl installer project on Sourceforge that'd attempt to take these types of things and create various useful modules for them, like Installer::Apache, Installer::Alzabo, Installer::RDBMS::MySQL, etc. -dave /*== www.urth.org we await the New Sun ==*/
