Re: Registry and mod_include - multiple invocations of a script in an SSI-parsed file
Hi Brett,
My guess is that you run into a problem of the CGI module not resetting itself
between executions of your code.
As a test you could try entering the line.
CGI::initialize_globals();
explicitly in your script before calling param().
2012-01-02 22:41, Brett Lee wrote:
Hello,
First, thank you very much for your time & consideration of this problem,
Have been trying to resolve an issue without success. The issue I'm seeing is
that calling the same script several times within a SSI-parsed file
causes each invocation of the script to produce the same result even though
different results should be seen.
To clarify, please find inlined below an example SSI-parsed file and script:
#!/usr/bin/perl -w
# test.cgi
use strict;
use CGI qw(-compile :all);
my $count = param('count');
my $a = 0;
print header;
while ( $a < $count) {
print ++$a;
}
When run from the default /var/www/cgi-bin/ directory, execution works as
expected; results are 1..5, 1..10 and 1..30. However, when the executable is
run from the ModPerl Registry directory below, each invocation counts only to 5.
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
# PerlOptions +ParseHeaders (prevented 2+ invocations)
Options +ExecCGI
Sure seems like "something" is caching part or all of the command/param. Hoping
to find out what.
Once again, thanks for your time & consideration.
Note: previously posted at: http://www.perlmonks.org/?node_id=945804
Best regards,
- -
Brett Lee
Encrypt your data with PDS - http://crypto.brettlee.com/
--
Mårten Svantesson
Senior Developer
Travelocity Nordic
+46 (0)8 505 787 23
Re: Changing browser URL based on condition
2011-07-11 20:48, Jerry Pereira wrote:
Hi All,
I would like to know if there is a way to change the URL displayed on
browser without using Redirect option. The URL visible on client browser
must be based on some condition that is evaluated in my mod_perl handler.
For example -
1. User types the URL - www.example.com <http://www.example.com/>, this will
display the login page.
2. Once the user enters the credentials and hits submit, the request is
posted to www.example.com/login <http://www.example.com/login> action.
3. If the credentials entered by the user is valid then i would like to show
the home page..uri
4. I am able to show the homw page, but the URL does not change to
www.example.com/home <http://www.example.com/home>, instead it remains the same
(i.e.
www.example.com/login <http://www.example.com/login>). I am using Template
toolkit to render my pages. I
tried $req->url('/home'), but that does not change the browser URI.
Any help will be appreciated.
Telling the browser to fudge the URL is a client side thing. There is support
for this in HTML5, with varying support in different browsers.
One starting point could be this:
http://stackoverflow.com/questions/4015613/good-tutorial-for-using-html5-history-api-pushstate
--
Mårten Svantesson
Senior Developer
Travelocity Nordic
+46 (0)8 505 787 23
Re: mod_perl memory
Torsten Förtsch skrev:
On Thursday 18 March 2010 04:13:04 Pavel Georgiev wrote:
How would that logic (adding subpools and using them) be applied to my
simplified example:
for (;;) {
$request->print("--$this->{boundary}\n");
$request->print("Content-type: text/html; charset=utf-8;\n\n");
$request->print("$data\n\n");
$request->rflush;
}
Do I need to add an output filter?
No, this one does not grow here.
sub {
my ($r)=...@_;
my $ba=$r->connection->bucket_alloc;
until( -e '/tmp/stop' ) {
my $pool=$r->pool->new;
my $bb2=APR::Brigade->new($pool, $ba);
$bb2->insert_tail(APR::Bucket->new($ba, ("x"x70)."\n"));
$bb2->insert_tail(APR::Bucket::flush_create $ba);
$r->output_filters->pass_brigade($bb2);
$pool->destroy;
}
my $bb2=APR::Brigade->new($r->pool, $ba);
$bb2->insert_tail(APR::Bucket::eos_create $ba);
$r->output_filters->pass_brigade($bb2);
return Apache2::Const::OK;
}
Torsten Förtsch
I have never worked directly with the APR API but in the example above couldn't you prevent the request pool from growing by explicitly reusing the
bucket brigade?
Something like (not tested):
sub {
my ($r)=...@_;
my $ba=$r->connection->bucket_alloc;
my $bb2=APR::Brigade->new($r->pool, $ba);
until( -e '/tmp/stop' ) {
$bb2->insert_tail(APR::Bucket->new($ba, ("x"x70)."\n"));
$bb2->insert_tail(APR::Bucket::flush_create $ba);
$r->output_filters->pass_brigade($bb2);
$bb2->cleanup();
}
$bb2->insert_tail(APR::Bucket::eos_create $ba);
$r->output_filters->pass_brigade($bb2);
return Apache2::Const::OK;
}
--
Mårten Svantesson
Senior Developer
Travelocity Nordic
+46 (0)8 505 787 23
[mp2] "did not send an HTTP header" due to (involuntary) flush
We are migrating a big site from mod_perl1 to mod_perl2. The site originally was written as CGIs so headers are mostly set with print statements. The Content-Type are mostly printed in the end of the script. The problem is that we occassionally start processes from the scripts and then the output gets flushed and thus we get Internal Server Error with the message "did not send an HTTP header" in the error.log. I tried to write an output filter that merge all buckets until \n\n is encountered, but I don't seem to be able to insert the filter so that it executes before the mod_perl header parsing. Looking in the mailing list archive it seems like this problem was extensively discussed in the thread "[mp2] CGI redirects incorrectly handled?" back in March 2003. In the final mail of the thread <http://article.gmane.org/gmane.comp.apache.mod-perl/4889> Stas mentions possible future changes to alleviate the problem. Has anything of this been implemented? Or does anybody have any other idea how to solve this (without rewriting our scripts, which are *many*)? We are now running mod_perl 2.0.2 (the version available in RedHat EL) in Apache 2.2.3. Our configuration: SetHandler perl-script PerlFixupHandler Apache2::SizeLimit PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders -- Mårten Svantesson
