Hmm, I found this snippet of code, which can be found in the init sub in the raw CGI.pm you can download from there:

METHOD: {

      # avoid unreasonably large postings
      if (($POST_MAX > 0) && ($content_length > $POST_MAX)) {
      $self->cgi_error("413 Request entity too large");
      last METHOD;
      }
[download]

So it's not as if the POST_MAX functionality has been stripped from CGI.pm 3.01 in all versions. Maybe there's a glitch in the tarball? (which I'm assuming you used).

I'd be interested to see what happens if the module is in fact *installed* rather than (as appears to have been the case here) just taking the CGI.pm file from the tarball and placing it in the same directory as the CGI script. After all, you gotta leave something for Makefile.PL to do =)

update : here's a thought. Try :

grep 'POST_MAX' *
[download]

in the directory where you unpacked the tarball.

perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); 
+$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth
+er_name\n"'
[download]

Yes I downloaded the tarball - the CGI.pm contained within does not have this METHOD. Nor does it have the string $content_length. As noted the only place $POST_MAX appears is in the pod with a reference to the missing initialise_globals() sub.

iakobski points out that Object.pm uses State.pm. In State.pm you can find the missing references to $POST_MAX. It must therfore be an installation problem. The pod has just not been updated yet to reflect the new postioning of $POST_MAX. The fact that you seem to be able to do a hand install that gives a functioning (sort of) CGI.pm is a bit worrying as *some* people still insist on hand installs and CGI.pm is so popular this is bound to happen. Oh well what do you expect if you don't read the instructions!

I was having nightmares as I have been pestering my sysadmin to upgrade from 2.75 to 3.01 as the upload method is broken on our 2.75 (you just have to get your file handle the old way).

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Did you at least contact Lincoln Stein (the author) about this?

No, I have not emailed Lincoln rrwo. Unfortunately I have internet connectivity at work but no outgoing email :-( I presumed that there was no way an oversight this big could have occurred so put it up for discussion. It got moved here by one of the editors. It seems the problem is a bad (hand) install as noted above. Still cause for concern as the hand install seems to run (kinda)!

I am a convert of CGI.pm, although as I don't use the HTML display part feel (like others) that it might be better split into two modules - a CGI data parsing part and an HTML generating part. Yes, I know there are alternatives but this module is the *gold standard* that comes with Perl so it is concerning than someone seems to have devised a way to silently break it through a bad install. Some code at the begining of the module like:

die "Bad install detected" unless module_checks_out();
[download]

might be nice if this is indeed the case. It would be trivial to include some code that adds a __DATA__ element that CGI.pm could have added to it during a proper install and read before running via the module_checks_out() sub postulated above. The speed penalty would be negligible as no system call would be required, just a read off the <DATA> filehandle.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Im sorry for starting a big problem with the cgi thing :)
So it wasnt me being thick after all?
I thought maybe you had to create the cgi.pm yourself by using the makefile.pl.

Anyway, I've decided to just use a CGI.pm that arturo advised. (tan-ku)
Seems to be working ok now.
Why do things have to be so complex?, to be honest I don't like using the CGI.pm as I like making code myself and planning where it goes, how i get it etc. Im one of these people who likes to know i did it all, typed every character of it.
Its as though the CGI.pm interupts the way i should think. (even though im sure it does everything perfectly well). I know I'll never use the HTML part of it either. Mind you, the things I'm creating arent massive as Im a learner. Im sure its more useful for programmers designing MASSIVE systems... saves typing as much. (or maybe its just for lazy people.. or even people who don't know html).

Im talking arse aren't I?,
I'll stop now :))

ThAtH0M

Thanks $code_or_die, didn't know that. Old saying "No read manual, no have clue". That probably explains my sysadmins reluctance to install it! I just worry about a broken method, he gets to worry about the whole system.

I'm sure the problem just relates to a hand install but it seems odd to have moved this particular code into a module to me, especially as it is important. But then again, I have never found the coding style in CGI.pm all that transparent. I will give it a day or two to see what gets added here and would like to see for myself if you can generate a functional but broken CGI.pm 3.01 with a hand install and a fully functional one with a regular install before I pester Lincoln.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

#!/usr/bin/perl -w
BEGIN # run before anything
{
  my $POST_MAX = -1;
  my $CL = defined($ENV{'CONTENT_LENGTH'}) ? $ENV{'CONTENT_LENGTH'} : 
+0;

    if(($POST_MAX > 0) and ($CL > $POST_MAX))
    {
        print "Content-Type: text/plain\n",
              "Status: 413\n\n",
              "413 Request entity too large";
        exit;
    }
}
[download]

 
___crazyinsomniac_______________________________________
Disclaimer: Don't blame. It came from inside the void
perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"