"Michael L. Artz" <[EMAIL PROTECTED]> writes:
> For some reason, CGI.pm (2.93) does not seem to parse POST data within a
> PerlAuthenHandler. For example, the following:
>
> sub handler {
> my $r = shift;
> my $q = new CGI($r);
> my @params = $q->param;
> $r->server->log->error("
[EMAIL PROTECTED] wrote:
thnx for your reply.
I use mod_perl 2 (1.99_08) and CGI.pm 2.91 and Apache 2.0.44. I thought that CGI.pm
wouldnt work at all, so I didnt give any examples.
I wrote a simply script that checks if running under mod_perl,
displays some parameter and evaluates/presents a f
thnx for your reply.
I use mod_perl 2 (1.99_08) and CGI.pm 2.91 and Apache 2.0.44. I thought that CGI.pm
wouldnt work at all, so I didnt give any examples.
I wrote a simply script that checks if running under mod_perl,
displays some parameter and evaluates/presents a form.
This script (sourc
Hi!
On Wed, Apr 02, 2003 at 12:49:56AM +0200, [EMAIL PROTECTED] wrote:
> Is the O'Reilly about apache-modules what I'm looking for ? I've the
> small O'reilly about mod_perl but it raises more questions than its
> answers.
The "Eagle" book is definitly very interesting (if a little bit old - B
[EMAIL PROTECTED] wrote:
I used CGI.pm in my mod_perl-application to get 'path_info', 'param',
print out headers and more.
None of this works inside my own handlers any more.
Which mod_perl generation are you using? mod_perl 1.0 (1.27?) or mod_perl 2.0
(1.99_08?). I suspect that you use mp2, sinc
At least with some versions of perl, the require gets evaluated at compile
time and raises an exception even if it is enclosed by the eval {} braces.
The only way to get around this is to eval the string.
I'm not sure whether this is a current issue or was a problem with 5.00503,
but I've kept
Lincoln Stein wrote:
Sorry for the slow turnaround, but it's an aspect of having 200 new e-mails
every day.
Here's a new version of CGI.pm 2.92 prerelease. Please give it a try on
mod_perl1 and mod_perl2 systems.
It passes all tests on linux. Hopefully others will test on other platforms.
Lincoln Stein wrote:
Did I send out something weird? My version looks like this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
eval "require mod_perl";
if (defined $mod_perl::VERSION) {
Did I send out something weird? My version looks like this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
eval "require mod_perl";
if (defined $mod_perl::VERSION) {
if ($mod_perl::VERS
Stas Bekman wrote:
Stas Bekman wrote:
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would
appreciate it if people could test it on both mod_perl 1 and mod_perl
2, as well as under normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2
Ah
Stas Bekman wrote:
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would
appreciate it if people could test it on both mod_perl 1 and mod_perl
2, as well as under normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2
Ah, no it doesn't pass 1
On Fri, Mar 14, 2003 at 10:31:25AM +1100, Carl Brewer wrote:
>
>
> Stas Bekman wrote:
> >Lincoln Stein wrote:
> >
>
> >You want to move to MP2, if one of the following reasons apply:
> >
> >- you are stuck with Apache2
> >- you want to use i/o filters
> >- you want to write your own protocol han
Stas Bekman wrote:
Lincoln Stein wrote:
You want to move to MP2, if one of the following reasons apply:
- you are stuck with Apache2
- you want to use i/o filters
- you want to write your own protocol handlers
- you want to use a threaded mod_perl
- you are stuck with win32 (mp1 is unusable on
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would appreciate it if
people could test it on both mod_perl 1 and mod_perl 2, as well as under
normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2, however the test suites
aren't exhaustively
Lincoln Stein wrote:
Hi Stas,
Thanks. I'll fold these changes and release on CPAN. I'll also remove the
$|=1 setting, since that was globally needed for FastCGI compatibility, and I
don't think that anyone uses it anymore.
Lincoln
They have came out with a fastcgi (mod_fastcgi-2.4.0) rele
Hi Stas,
Thanks. I'll fold these changes and release on CPAN. I'll also remove the
$|=1 setting, since that was globally needed for FastCGI compatibility, and I
don't think that anyone uses it anymore.
Lincoln
On Monday 10 March 2003 08:43 pm, Stas Bekman wrote:
> Hi Lincoln,
>
> > I'm not i
On Tue, 14 Jan 2003 [EMAIL PROTECTED] wrote:
> I try this simple module:
>
> #!/usr/bin/perl
> package My;
> use strict;
> use warnings;
> use Apache::RequestRec ();
> use Apache::RequestIO ();
> use Apache::RequestUtil (
[EMAIL PROTECTED] sent the following bits through the ether:
> What I'm doing wrong? How to parse urlecnoded?
Have you put the following into httpd.conf?:
PerlModule Apache2
Leon
--
Leon Brocard.http://www.astray.com/
scribot.http:/
Jeff wrote:
> I am gradually moving to mod_Perl using Apache::PerlRun instead of
> Apache::Registry. I am also considering switching from cgi-lib.pl to
> CGI.pm however I hear CGI.pm takes longer to load. Will CGI.pm
> automatically be cached, thereby eliminating the performance hit, by
> ha
Hi there,
On Wed, 20 Mar 2002, Vuillemot, Ward W wrote:
> > On Tue, 19 Mar 2002 14:06:15 -0800 Vuillemot, Ward W wrote:
> > > why would it work for cgi and not mod_perl?
> > >
> > From: Ged Haywood [Replying privately because of large attachment]
> > Does the attached version of CGI.pm help? (I
On 6 Dec 2001, David Shrewsbury wrote:
> Solved it... apparently, if you upgrade CGI.pm while your web
> server is running, a restart is not good enough. You have to
> shutdown completely and then start it back up.
yeah, especially if you're using mod_perl and have pre-loaded modules at
server s
Solved it... apparently, if you upgrade CGI.pm while your web
server is running, a restart is not good enough. You have to
shutdown completely and then start it back up.
*Sigh*
-David
On Thu, 2001-12-06 at 10:43, David Shrewsbury wrote:
Hey gang,
I just upgraded the CGI.pm perl mo
er 2001 12:24 AM
To: James Wilson
Cc: [EMAIL PROTECTED]
Subject: Re: CGI.pm - Unnamed parameter
On Fri, 2 Nov 2001, James Wilson wrote:
> Date: Fri, 2 Nov 2001 01:42:13 + (GMT)
> From: James Wilson <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: CGI.pm - Unnamed pa
On Fri, 2 Nov 2001, James Wilson wrote:
> Date: Fri, 2 Nov 2001 01:42:13 + (GMT)
> From: James Wilson <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: CGI.pm - Unnamed parameter
>
> Hi,
>
> Hopefully a quick and easy question...
>
> I'm accessing as follows:
>
> /cgi-bin/script.pl?data
On Wed, 31 Oct 2001 02:31, you wrote:
> Hello,
>
> When I try to make a CGI object in my Apache/mod_perl handler a la $q =
> CGI->new(); The server just don't reply. Actually it works just fine
> until I try to submit a form, then it just hangs and Apache doesn't send
> anything back. If I remove
On Tue, 30 Oct 2001, Viljo Marrandi wrote:
> Date: Tue, 30 Oct 2001 17:31:15 +0200
> From: Viljo Marrandi <[EMAIL PROTECTED]>
> To: modperl list <[EMAIL PROTECTED]>
> Subject: CGI.pm problem
>
> Hello,
>
> When I try to make a CGI object in my Apache/mod_perl handler a la $q =
> CGI->new(); The s
> -Original Message-
> From: Ken Williams [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 02, 2001 6:24 PM
> To: Geoffrey Young; 'Perrin Harkins '
> Cc: '[EMAIL PROTECTED] '
> Subject: RE: CGI.pm params not being cleared?
>
>
> Hi
> It doesn't much matter whether you're using stacked handlers or not, or
> pushing vs. replacing, because the $r->child_terminate method seems to
> simply call the C exit(0) function under certain conditions (Win32, old
> version of apache, anything else?). Not much chance of any further action
al Message-
>> From: Perrin Harkins
>> To: Alex Harper
>> Cc: Daniel; [EMAIL PROTECTED]
>> Sent: 10/1/01 11:35 PM
>> Subject: Re: CGI.pm params not being cleared?
>>
>> Alex Harper wrote:
>>>
>>> Aha! That's where the problem lies.
> If I install Apache::Sizelimit as a cleanup handler, neither
> Apache::SizeLimit::exit_if_too_big() or CGI::_reset_globals() are ever
> called. CGI::initialize_globals (which is what _reset_globals calls) is
> called once, at compile time for CGI.pm.
[...]
> If I put Apache::SizeLimit in as a Fi
Does this help?
Alex
--
Alex Harper
Configuration Management
[EMAIL PROTECTED]
"Use whatever you think of first" -- Larry Wall
> -Original Message-
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 01, 2001 11:43 PM
> To: Alex Harper
Alex Harper wrote:
>
> I'm using a mod_perl 1.26 RPM I built using the RedHat RPM prep files
> and dropping in the 1.26 code. I believe it is built EVERYTHING=1.
>
> Apache::Status indicates all hooks are enabled, including:
> PerlStackedHandlers Enabled
Okay. Would you mind putting some d
Monday, October 1, 2001 7:42 PM
> To: Perrin Harkins
> Cc: Alex Harper; [EMAIL PROTECTED]
> Subject: Re: CGI.pm params not being cleared?
>
> Did you compile mod_perl with PERL_STACKED_HANDLERS?
>
> Perrin Harkins wrote:
>
> > Alex Harper wrote:
> &
Did you compile mod_perl with PERL_STACKED_HANDLERS?
Perrin Harkins wrote:
> Alex Harper wrote:
>
>>Aha! That's where the problem lies. I had recently added:
>>PerlCleanupHandler +Apache::Sizelimit
>>
>>to my httpd.conf. I placed it there so the sizelimit would be enforced
>>post-reques
>-Original Message-
>From: Perrin Harkins
>To: Alex Harper
>Cc: Daniel; [EMAIL PROTECTED]
>Sent: 10/1/01 11:35 PM
>Subject: Re: CGI.pm params not being cleared?
>
>Alex Harper wrote:
>>
>> Aha! That's where the problem lies. I had recently add
Alex Harper wrote:
>
> Aha! That's where the problem lies. I had recently added:
> PerlCleanupHandler +Apache::Sizelimit
>
> to my httpd.conf. I placed it there so the sizelimit would be enforced
> post-request. Removing the line fixed my problem.
Whoa! This could be bad. Apache::Size
L PROTECTED]]
> Sent: Monday, October 01, 2001 6:35 PM
> To: Alex Harper; [EMAIL PROTECTED]
> Subject: Re: CGI.pm params not being cleared?
>
>
> Odd, checking into my version CGI.pm (which I dont use), it cleans up
> it's own globals by installing a cleanup handle
Odd, checking into my version CGI.pm (which I dont use), it cleans up
it's own globals by installing a cleanup handler:
Apache->request->register_cleanup(\&CGI::_reset_globals);
so either your version of CGI.pm is broken or your mod_perl was somehow
compiled without PERL_CLEANUP.
Alex Harper w
Thanks, I looked and we're not. Here's the simplest case:
use CGI;
my $cgi = new CGI;
my @params = $cgi->Vars();
print $cgi->header(-type => 'text/html');
print $cgi->start_html();
print "Process: $$\n";
print "Query String:\n";
print $ENV{QUERY_STRING} . "\n";
print "Params:\n";
pri
Make sure you're not doing:
use CGI;
my $cgi = new CGI;
if ($cgi->param("dataaction") eq "whatever") {
&do_whatever_without_passing_cgi();
}
elsif ($cgi->param("dataaction") eq "passcgi") {
&pass_it_cgi($cgi);
}
sub do_whatever_without_passing_cgi {
#using origi
se whatever you think of first" -- Larry Wall
> -Original Message-
> From: Ken Y. Clark [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 01, 2001 4:25 PM
> To: Alex Harper
> Cc: [EMAIL PROTECTED]
> Subject: Re: CGI.pm params not being cleared?
>
>
> On
On Mon, 1 Oct 2001, Alex Harper wrote:
> Date: Mon, 1 Oct 2001 16:16:34 -0500
> From: Alex Harper <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: CGI.pm params not being cleared?
>
> I'm sure this is a FAQ somewhere, but I'm not finding it...
>
> In our switch to mod_perl we're seeing two
hi again,
I've made some tests and debuging, the problem seems to be in CGI module...
first of all in eg/file_upload.asp this :
print $q->start_multipart_form();
returns this :
do U see no POST (the interesting thing is that $r->method returns GET in
this case i didn't knowed that :") )..
Ah, so there is. I grep'd an older version which didn't since I'd never
heard of it before.
You use Apache::Request to get query parameters the same way you do with
CGI.pm's param() method. perldoc Apache::Request.
Did you could try just importing the CGI.pm HTML functions?
Personally, I pref
On 30 Aug 2000, Alexei V. Barantsev wrote:
> Jeff Beard <[EMAIL PROTECTED]> writes:
>
> > There isn't a Vars() function in CGI.pm. If you're looking for the query
> > string try param(). Or if you want to make it a mod_perl program (which is
> > what you would normally discuss on this list) Ap
Jeff Beard <[EMAIL PROTECTED]> writes:
> There isn't a Vars() function in CGI.pm. If you're looking for the query
> string try param(). Or if you want to make it a mod_perl program (which is
> what you would normally discuss on this list) Apache::Request::param().
>
> --Jeff
There is such a f
Rick Myers <[EMAIL PROTECTED]> writes:
> On Aug 29, 2000 at 16:11:39 +0400, Alexei V. Barantsev twiddled the keys to say:
> > Dear mod_perl'ers!
> >
> > I have found strange difference between object and func modes of CGI
> > library. More precisely - I have a problem with Vars function.
On Aug 29, 2000 at 16:11:39 +0400, Alexei V. Barantsev twiddled the keys to say:
> Dear mod_perl'ers!
>
> I have found strange difference between object and func modes of CGI
> library. More precisely - I have a problem with Vars function.
>
> #use CGI qw(:standard :cgi-lib);
CGI::_re
There isn't a Vars() function in CGI.pm. If you're looking for the query
string try param(). Or if you want to make it a mod_perl program (which is
what you would normally discuss on this list) Apache::Request::param().
--Jeff
At 04:11 PM 8/29/00 +0400, Alexei V. Barantsev wrote:
> De
Hasanuddin Tamir <[EMAIL PROTECTED]> writes:
> >> No wonder Alexei V. Barantsev on Jul 8 said that,
>
> AVB] Playing with CGI I have found that real behaviour of start_form
> AVB] without parameters does not correspond to documentation.
> AVB]
> AVB] >From the documentation:
> AVB]
> AVB] The
>> No wonder Alexei V. Barantsev on Jul 8 said that,
AVB] Playing with CGI I have found that real behaviour of start_form
AVB] without parameters does not correspond to documentation.
AVB]
AVB] >From the documentation:
AVB]
AVB] The defaults are:
AVB] method: POST
AVB] action: this scri
On 25 May 2000, Randal L. Schwartz wrote:
> I got no "no warnings". this is still 5.5.3 :)
There's always the time-honored
{
local $^W;
}
- Perrin
> "Doug" == Doug MacEachern <[EMAIL PROTECTED]> writes:
Doug> On 25 May 2000, Randal L. Schwartz wrote:
>> Yeah, it's CGI.pm alright. So do I complain to Lincoln to fix it, or
>> is it just a synergy thing between mod_perl, Apache, and CGI.pm that I'll
>> have to live with?
Doug> are you re
On 25 May 2000, Randal L. Schwartz wrote:
> Yeah, it's CGI.pm alright. So do I complain to Lincoln to fix it, or
> is it just a synergy thing between mod_perl, Apache, and CGI.pm that I'll
> have to live with?
are you re-loading CGI.pm? that's the only way this warning can be
triggered, from
On Tue, 25 Jan 2000, Bill Moseley wrote:
> Ok, this seems to work, but perldoc Apache doesn't say anything about
> setting it. Is this at risk of not working in the future?
you can set $r->args, that won't be going away in the future.
On Mon, 24 Jan 2000, Bill Moseley wrote:
...
> Under mod_cgi I can clean up $ENV{QUERY_STRING} at the start of a program
> by removing leading '&' and double '&', but that doesn't work, obviously,
> under mod_perl.
>
> Could someone suggest a way to clean up the query string from within an
> Apa
Ok, this seems to work, but perldoc Apache doesn't say anything about
setting it. Is this at risk of not working in the future?
if ( $RUNNING_MOD_PERL && (my $query = Apache->request->args() ) ) {
for ( $query ) {
tr/&/&/s; # no muliple &
s/^&//;
You may not actually want these pages to run under mod_perl at all. I've
decided that my big uploads & downloads will run under regular CGI, since I
don't want to tie up one of my precious mod_perl backend server children doing
something as long and dumb as transfering a file.
Also, the user w
[EMAIL PROTECTED] (Jesse Erlbaum) writes:
> Hello Lincoln & Mod_Perl-ers!
>
> I have a REALLY WIERD bug for you, regarding UPLOADING FILES via MSIE 4.
>
> Red Hat Secure Server 2.0
> CGI.pm: 2.56
> mod_perl 1.15
>
Have you verified you aren't hitting up against any disk spac
Ofer Inbar wrote:
> book. I happened to stumble across this bug before I'd read that
> chapter, and it took literally something like 20 hours of coding and
> debugging time to figure out what was going on. Then I saw it in the
Only 20 hours? Man, I burned more hours than that! If only we
coul
Ofer Inbar <[EMAIL PROTECTED]> writes:
> Alex Krohn <[EMAIL PROTECTED]> wrote:
> (mis)handles lexically scoped variables. This oddity only comes into
> play if you use a lexical variable in a block *and* a sub-block of
> that block, and you run that same code multiple times, and the values
> are
On Fri, 05 Nov 1999 14:12:43 -0500
Eugene Miretskiy <[EMAIL PROTECTED]> wrote:
> Take a look at:
> http://perl.apache.org/guide/obvious.html#my_scoped_variable_in_nested_s
Thanks, that was just the part I was looking for.
Cheers,
Alex
Gossamer Threads Inc. -
did you read
http://perl.apache.org/guide/obvious.html#my_scoped_variable_in_nested_s
I know this has been on the list before ;)
try:
use CGI;
use strict;
my $in = new CGI;
print $in->header();
print "Init Value: ", $in->param('val'), "\n";
&foobar($in->param('val'));
sub foobar {
my @arg
Alex Krohn <[EMAIL PROTECTED]> wrote:
> #!/usr/local/bin/perl
> #
> use CGI;
> use strict;
> my $in = new CGI;
> print $in->header();
> print "Init Value: ", $in->param('val'), "\n";
> &foobar();
>
> sub foobar {
>print "Sub Val
You read through the guide? Well, you must have missed this section :-)
http://perl.apache.org/guide/porting.html#Sometimes_it_Works_Sometimes_it_
Tobias
At 10:54 AM 11/5/99 -0800, you wrote:
>Hi,
>
>I've read through the guide, and tried to search through the list, but
>CGI.pm is a pretty comm
Alex,
check out http://perl.apache.org/guide/obvious.html#my_scoped_variable_in_nested_s
Cheers,
-Christoph
Alex Krohn wrote:
>
> Hi,
>
> I've read through the guide, and tried to search through the list, but
> CGI.pm is a pretty common keyword, ;). This script which I thought
> should work
66 matches
Mail list logo
