CGI param persists when used with FastCGI

I've read similar posts in the past, but never saw a good answer.

With the script posted below, run under Apache 2.0.54/mod_fastcgi
2.42/perl 5.8.4/CGI 3.04/FCGI 0.67, I get the following results:

http://myserver/test.fcgi?isin=1
1 Request N - 1
http://myserver/test.fcgi?isin=2
1 Request N - 2
http://myserver/test.fcgi?isin=99
1 Request N - 3
RESTART APACHE
http://myserver/test.fcgi?isin=100
100 Request N - 1
http://myserver/test.fcgi?isin=200
100 Request N - 2
http://myserver/test.fcgi?isin=300
100 Request N - 3

For some reason, param seems to cache the original QUERY_STRING. I
even put a print statement deep inside CGI.pm where QUERY_STRING is
accessed, and it is only called once. Ideas?

---
#!/usr/local/bin/perl -w
use FCGI;
use CGI;
$n=0;

while (FCGI::accept >= 0) {
my $q = new CGI;
my $isin=$q->param('isin');
print "Content-type: text/html\r\n\r\n";
++$n;
print "$isin Request N - $n \n";
$q->delete_all(); # try 1
$q->DESTROY(); # try 2
undef $q; # try 3
}

Re: CGI param persists when used with FastCGI

Not sure if this is the correct way to do it, but adding this at the
bottom of my loop seems to help.

undef @CGI::QUERY_PARAM;

This forces each init call to reinspect QUERY_STRING.

Re: CGI param persists when used with FastCGI

The right way to do it:

=cut

#! /usr/local/bin/perl -w

use strict;

use FCGI;
use CGI::Fast;

my $n=0;

while (my $q=new CGI::Fast) {
my $isin=$q->param('isin');
print "Content-type: text/plain\r\n\r\n";
++$n;
print "$isin Request N - $n \n";
}

=pod

The CGI::Fast subclass overrides the save_request method to prevent
the unwanted effect you observed.


/Bo Lindbergh

Re: CGI param persists when used with FastCGI

Thank you, that works. Another question though. Why is the loop
driven by CGI::Fast rather than FCGI::Accept? Isn't the latter the
correct way to interface with mod_fastcgi?

Re: CGI param persists when used with FastCGI

In article <1128953844.177241.54610@g43g2000cwa.googlegroups.com>,
id2001@cablelabs.com wrote:

> Thank you, that works. Another question though. Why is the loop
> driven by CGI::Fast rather than FCGI::Accept? Isn't the latter the
> correct way to interface with mod_fastcgi?

Since there's a one-to-one correspondence between FastCGI requests
and CGI::Fast objects, CGI::Fast::new calls FCGI::accept for you.
It's convenient and it works.


/Bo Lindbergh