Re: weird problem. Lost of the POST data (SOLUTION)
On Mon, 2002-02-04 at 11:12, Oscar Serrano wrote: > Hi: > some days ago I wrote to ask for this problem: The CGI.pm (sometimes) could > not receive the POST data. I tried all you recomended me here in the list. > But I still had the problem. Finally I decide to kick out CGI.pm and start > to use the old cgi-lib.pl. But I still had the same problem. Then I turnet > to Apache::Request, and since I use it, I've never had the same problem. > I just tell you because perphaps somebody may have the same problem. I > don't really understan if the problem is in mod_perl, in Apache, in Templat > Toolkit, in my ultrasecure patched kernel, in CGI.pm, but the point is that > Apache::Request seems not to loose any post data :-? > > Thank you all. > > Oscar Serrano. > > > Did anyone of you guys by chacne compile PERL 5.6.1 with 'threading'. Cuz I had the EXACT same porblem. The problem was 'fixable' in CGI.pm. Look at the init() procedure. scroll down to line 453 where is calls read_from_client() (version 2.79 but is in all versions of CGI.pm). Now what I did was remove the reference to the STDIN filehandle and BINGO. things worked fine. But I found that that was unacceptable to modify the CGI.pm source. But that means reference handling was incorrect. I went and put alot of debugging stuff in read_from_client() and confirmed that the read() call was getting nothing returned becuase there wasn anything in the file handle that was passed to it. I 'thought' I had 2 exact matching systems. the one on the web server (that was having this problem) and my workstation/dev box. My dev box worked perfectly fine. At this point I was fed up with this and I started recompiling things. :) started with perl. This time I just ran ./configure and held down the "Enter" button (making sure I compiled libperl.so tho). remove the current perl tree frm the system compleatly. installed it. reinstalled all modules that I needed. That solved any problems. things run perfectly now. The only differnece is that I must of enabled multi-threading support because there was that 'thread' directory tree present. -- Jason Czerak
Re: weird problem. Lost of the POST data
I had similar problems not too long ago.
The reason i believe is - 'You can only read POST data from STDIN
_once_'.
Aka, in a mod_perl script if you do something like:
my $q1 = new CGI;
my $q2 = new CGI;
my $name1 = $q1->param("name");
my $name2 = $q2->param("name");
$name2 will not be set if the data was POST'ed. This is because the $q1
object would have already read in data from STDIN and its now no longer
available to any other objects (including $q2). If it was a 'GET'
request, you would have no such problem as GET request query strings are
in $ENV{'QUERY_STRING'} and you can read from that as many times as you
like.
The moral of the story being, for a single request never use more than
one CGI object (instantiate one and then pass it around)
cheers,
simran.
On Tue, 2002-02-05 at 03:31, Brett W. McCoy wrote:
> On Mon, 4 Feb 2002, Oscar Serrano wrote:
>
> > some days ago I wrote to ask for this problem: The CGI.pm (sometimes) could
> > not receive the POST data. I tried all you recomended me here in the list.
> > But I still had the problem. Finally I decide to kick out CGI.pm and start
> > to use the old cgi-lib.pl. But I still had the same problem. Then I turnet
> > to Apache::Request, and since I use it, I've never had the same problem.
> > I just tell you because perphaps somebody may have the same problem. I
> > don't really understan if the problem is in mod_perl, in Apache, in Templat
> > Toolkit, in my ultrasecure patched kernel, in CGI.pm, but the point is that
> > Apache::Request seems not to loose any post data :-?
>
> I had a similar problem a few days ago with a form processing engine I
> developed with mod_perl & Text::Template. It takes a sequence of states
> out of a database and generates a 'wizard' to lead a user through a set of
> forms for, say, an employment application, membership application, etc.
> It uses a combination of CGI.pm for some of the high-level front end
> stuff, and uses the Apache::* modules for the lower level stuff (cookies,
> session management, etc). Anyway, I had this wierd bug that instead of
> the straight sequence of forms, it would do the first form, then the
> second, the the first again, then the third, then the first again, then
> the fourth, and so on. POST data was either missing, or incomplete, or
> was picking up values from several pages back.
>
> I discovered what the problem was: I had a hash in one of my top-level
> class files (the system is object-oriented) that was being used as a
> global variable, a hash that had data that changed a lot. Bad juju with
> mod_perl! Moving the hash into the class constructor and making sure it
> got properly blessed into that class fixed the problem.
>
> Another issue that can cause problems, especially using the OOP interface
> to CGI.pm under mod_perl, is using a global CGI object and using it inside
> of subroutines:
>
> my $cgi = new CGI;
>
> ...
>
> sendmail('A message');
>
> ...
>
> sub send_mail {
>
> my $msg = shift;
> print $cgi->h1('Something');
> print $cgi->p;
> ...
> }
>
> This will cause some wierd problems. The solution is to not use globals
> inside your subroutine, but pass what you need into it:
>
> sendmail($cgi, 'A Message');
>
> sub send_mail {
> my $q = shift;
> my $msg = shift;
> ...
> }
> http://www.chapelperilous.net/
>
> When the wind is great, bow before it;
> when the wind is heavy, yield to it.
Re: weird problem. Lost of the POST data
On Mon, 4 Feb 2002, Oscar Serrano wrote:
> some days ago I wrote to ask for this problem: The CGI.pm (sometimes) could
> not receive the POST data. I tried all you recomended me here in the list.
> But I still had the problem. Finally I decide to kick out CGI.pm and start
> to use the old cgi-lib.pl. But I still had the same problem. Then I turnet
> to Apache::Request, and since I use it, I've never had the same problem.
> I just tell you because perphaps somebody may have the same problem. I
> don't really understan if the problem is in mod_perl, in Apache, in Templat
> Toolkit, in my ultrasecure patched kernel, in CGI.pm, but the point is that
> Apache::Request seems not to loose any post data :-?
I had a similar problem a few days ago with a form processing engine I
developed with mod_perl & Text::Template. It takes a sequence of states
out of a database and generates a 'wizard' to lead a user through a set of
forms for, say, an employment application, membership application, etc.
It uses a combination of CGI.pm for some of the high-level front end
stuff, and uses the Apache::* modules for the lower level stuff (cookies,
session management, etc). Anyway, I had this wierd bug that instead of
the straight sequence of forms, it would do the first form, then the
second, the the first again, then the third, then the first again, then
the fourth, and so on. POST data was either missing, or incomplete, or
was picking up values from several pages back.
I discovered what the problem was: I had a hash in one of my top-level
class files (the system is object-oriented) that was being used as a
global variable, a hash that had data that changed a lot. Bad juju with
mod_perl! Moving the hash into the class constructor and making sure it
got properly blessed into that class fixed the problem.
Another issue that can cause problems, especially using the OOP interface
to CGI.pm under mod_perl, is using a global CGI object and using it inside
of subroutines:
my $cgi = new CGI;
...
sendmail('A message');
...
sub send_mail {
my $msg = shift;
print $cgi->h1('Something');
print $cgi->p;
...
}
This will cause some wierd problems. The solution is to not use globals
inside your subroutine, but pass what you need into it:
sendmail($cgi, 'A Message');
sub send_mail {
my $q = shift;
my $msg = shift;
...
}
http://www.chapelperilous.net/
When the wind is great, bow before it;
when the wind is heavy, yield to it.
Re: weird problem. Lost of the POST data
Hi: some days ago I wrote to ask for this problem: The CGI.pm (sometimes) could not receive the POST data. I tried all you recomended me here in the list. But I still had the problem. Finally I decide to kick out CGI.pm and start to use the old cgi-lib.pl. But I still had the same problem. Then I turnet to Apache::Request, and since I use it, I've never had the same problem. I just tell you because perphaps somebody may have the same problem. I don't really understan if the problem is in mod_perl, in Apache, in Templat Toolkit, in my ultrasecure patched kernel, in CGI.pm, but the point is that Apache::Request seems not to loose any post data :-? Thank you all. Oscar Serrano.
Re: weird problem. Lost of the POST data
> Well all my modules are written in Perl. When you say some C code you mean > the C code in DBI, or CGI or Template, don't you? Yes. That's why I suggest trying Template with the Perl stash instead of the XS one. - Perrin
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 17 de enero de 2002 1:01 > Para: Oscar Serrano; [EMAIL PROTECTED] > Asunto: Re: weird problem. Lost of the POST data > > > > Ummm yes... you know, I'm using the Template Toolkit. > > Try using the Perl stash instead of the XS stash, and see if your problem > goes away. > > > It seems as if the > > httpd child executes the processing of the template so fast that CGI.pm > has > > no time to get the POST data. > > I don't think so. It seems to me like your processes are getting > corrupted > by some C code or an improperly shared file handle or socket. I > doubt this > has anything to do with CGI.pm, since so many people use it and > don't report > having the same problem. Well all my modules are written in Perl. When you say some C code you mean the C code in DBI, or CGI or Template, don't you? I know many people uses CGI.pm but not so many with Template Toolkit and mod_perl... > > If you want to experiment, you could replace CGI.pm and see if it improves > thing for you. There are plenty of other modules you can use to > parse POST > data. Yes, I'm doing that now in some CGIs. Thank you, and you all that are helping me with this problem. Oscar Serrano. > - Perrin > >
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Robert Landrum [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 17 de enero de 2002 0:26 > Para: Oscar Serrano; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Asunto: Re: weird problem. Lost of the POST data > > > At 3:11 PM +0100 1/16/02, Oscar Serrano wrote: > >Here I put the beggining of the file: > > > >#!/usr/bin/perl -w > >use CGI; > >use strict; > >use varcomunes; #library of my own > >use lib $LIBRERIAS_AT; > >use EnlacesAT; #library of my own > >use Idioma; #library of my own > >use DBI; > >use OrdenesComunes; #library of my own > >use Template; #template toolkit 2.03 > >my ($rentafijapup, $rentafijapumm, $accionesp, $accionesmm); > >#many other my (whatever) definitions... > >my($query,$in); > > > >print "Content-type: text/html\nPragma: no-cache\n\n"; > > > >$query=new CGI; > >$in=$query->Vars(); > > > > > Check to make sure that you do not have some strange version of CGI > in $LIBRERIAS_AT. I've been bitten by this in the past when a > developer pointed some code to his home directory and had bad/debug > copied of modules in there. Thank you for your advice. But that's not my case. in $LIBRERIAS_AT I only have Idioma.pm OrdenesComunes.pm and other modules of my own. Thanks. > Rob > > -- > When I used a Mac, they laughed because I had no command prompt. When > I used Linux, they laughed because I had no GUI. >
Re: weird problem. Lost of the POST data
> Ummm yes... you know, I'm using the Template Toolkit. Try using the Perl stash instead of the XS stash, and see if your problem goes away. > It seems as if the > httpd child executes the processing of the template so fast that CGI.pm has > no time to get the POST data. I don't think so. It seems to me like your processes are getting corrupted by some C code or an improperly shared file handle or socket. I doubt this has anything to do with CGI.pm, since so many people use it and don't report having the same problem. If you want to experiment, you could replace CGI.pm and see if it improves thing for you. There are plenty of other modules you can use to parse POST data. - Perrin
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 17 de enero de 2002 0:06 > Para: [EMAIL PROTECTED]; Oscar Serrano > Asunto: Re: weird problem. Lost of the POST data > > > > There is something that may give a clue. When I restart apache, it takes > > some minutes to throw the first error. But the error get more and more > > frecuently. But not always I get the error. It seems as if some httpd > child > > get corrupted and then, when one of those corrupted childs processes a > > request, it throws this error. > > I've seen that sort of thing before. A common cause of this is > opening some > resource before the fork that shouldn't be shared across processes, like a > file handle or a socket. Check for that. Also, are you using any cleanup > handlers? Do you have any in-house code that uses XS to call C libraries? Ummm yes... you know, I'm using the Template Toolkit. It seems as if the httpd child executes the processing of the template so fast that CGI.pm has no time to get the POST data. I has no sense, because the script, the first thing it does is the $in=$query->Vars(), and the last thing it does is to process a template. But it seems as if it could process the template before getting the POST data. And that would explain why the POST data is mantained in STDIN and then appears concatenated to the very next request: a .gif file the template calls. But I repeat, it has no sense the script processing the template before reading the POST data :-? I'm not using any cleanup handlers. Somebody suggested me to use one to destroy CGI.pm data. But, the true is that the problem is CGI.pm I'll kick CGI.pm away because I only use it to get the variables from a GET or POST data. Thank you very much. > - Perrin > >
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Ged Haywood [mailto:[EMAIL PROTECTED]] > Enviado el: miercoles, 16 de enero de 2002 23:30 > Para: Oscar Serrano > CC: [EMAIL PROTECTED] > Asunto: Re: weird problem. Lost of the POST data Thank you Ged for your detailled information. I'm now debugging my scripts. I'm still not sure if the problem is in the way I code, in CGI.pm or in the Template Toolkit. Thank you very much. > > Hi Oscar, > > On Wed, 16 Jan 2002, Oscar Serrano wrote: > > > So, one mod_perl CGi can cache several modules and several > mod_perl cgis? > > It's not really a "mod_perl CGI", it's an Apache child process with > its own built-in (persistent) Perl interpreter. In that sense it's an > ordinary copy of the Perl interpreter which can load whatever Perl > modules you have the memory for. The child sits around waiting for > something to do. You give it something to do by handing a request to > Apache (usually from a browser) which may or may not be configured to > cause the Perl interpreter to do something with it. If it does > something with the request it may change things inside the memory > pages of that child's Perl interpreter which aren't changed in the > interpreters of any of the other apache children. > > > Apache::Registry which I'm interested in. > > Apache::Registry provides the Apache+mod_perl process with an environment > similar to what you see when you use mod_cgi in an ordinary (non-mod_perl) > process. But it's only similar, it's not identical. There are all sorts > of things (mentioned in the Guide) that you have to look out for, mostly > because it's only similar and because the Perl interpreter is persistent. > There are alternatives to Apache::Registry which might be better for you, > but none provides an exact replica of the CGI environment. > > > So the maximum size the httpd can grow is the size of all modules and > > mod_perl cgis cached in memory. Am I right? > > Not quite, there are reasons for example why the child might grow > without bound. It's covered in the Guide in great detail, including > methods of calculating the process sizes and ways of dealing with > any processes which misbehave. > > > print "Content-type: text/html\nPragma: no-cache\n\n"; > > $query=new CGI; > > $in=$query->Vars(); > > > > Now I have everything in $in. > > To be sure of it, why not print everything in $in to the error_log or > something like that? (There's a whole chapter on debugging techniques > in the Guide. :) > > > 501 Apache Error? > > In a properly written program, the ideal would be that no request > could cause a server error. I suspect that there's something wrong > with the way your code handles the request or (less likely) there's > something wrong with the build of the server. > > 73, > Ged. > >
Re: weird problem. Lost of the POST data
At 3:11 PM +0100 1/16/02, Oscar Serrano wrote: >Here I put the beggining of the file: > >#!/usr/bin/perl -w >use CGI; >use strict; >use varcomunes; #library of my own >use lib $LIBRERIAS_AT; >use EnlacesAT; #library of my own >use Idioma; #library of my own >use DBI; >use OrdenesComunes; #library of my own >use Template; #template toolkit 2.03 >my ($rentafijapup, $rentafijapumm, $accionesp, $accionesmm); >#many other my (whatever) definitions... >my($query,$in); > >print "Content-type: text/html\nPragma: no-cache\n\n"; > >$query=new CGI; >$in=$query->Vars(); > Check to make sure that you do not have some strange version of CGI in $LIBRERIAS_AT. I've been bitten by this in the past when a developer pointed some code to his home directory and had bad/debug copied of modules in there. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
