This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: uninitialized value at ... CGI/Cookie.pm line 70.
From: Drew Taylor <dtaylor@vialogix.com>
Date: Wed, 14 Jun 2000 09:59:34 -0400
Ronald Schmidt wrote:
>
> The warning seems to be coming from inside the standard module CGI::Cookie -
> not from inside the driver code included with my message.
You're right. What version of CGI::Cookie are you using?
How much work would it be to explicitly pass $q to each subroutine? That
really is a better way to do things anyway - globals can cause MUCH
frustration and headaches under Apache::Registry if you're not careful.
Make $q a lexical, and pass it around to each subroutine that needs it.
Any other suggestions from the real gurus out there? (A guru I'm not!)
===
Subject: Re: uninitialized value at ... CGI/Cookie.pm line 70.
From: darren chamberlain <darren@boston.com>
Date: Wed, 14 Jun 2000 10:39:13 -0400
Ronald Schmidt (rschmidt@net2phone.com) said something to this effect:
> The full warning message on our system (Solaris, Apache 1.3.3, mod_perl
> 1.21?, perl 5.005_02) is:
>
> [Tue Jun 13 17:37:25 2000] null: Use of uninitialized value at
> /usr/local/lib/perl5/5.00502/CGI/Cookie.pm line 70.
>
> We are porting perl/cgi scripts to run under Apache;:Registry and in the
> process of porting I am getting the warning above from one of the scripts.
> In investigating the problem I went to
> http://perl.apache.org/guide/porting.html to look for examples of cookie use
> with mod_perl. I found that with slight modification to one of the samples
> I could re-produce the problem. The modification involved moving the
> initialization of a CGI object reference out of a subroutine. Initializing
> our $q = new CGI; in a subroutine would mean re-arranging a fair amount of
> code in our scripts. Has anyone hit this before? Does anyone have a
> suggestion for getting around the problem? The code that reproduces the
> problem follows.
>
> Ronald Schmidt
I always find it easier to parse the cookies myself, rather than rely on
{Apache,CGI}::Cookie. I use something like:
my %cookies = map { $1 => $2 if (/([^=]+)=(.*)/) }
grep !/^$/, split /;\s*/,$r->header_in('cookie');
and then %cookies has the names as keys, and the values as values. Creating
cookies is a matter; I usually join vars on '; '.
I would try using this method to fetch the cookies, and then dump them
to STDERR and see what you have. I have found that browsers can mangle
cookies, and then of course no cookie parsing module will help.
darren
===
Subject: Re: uninitialized value at ... CGI/Cookie.pm line 70.
From: Adriano Nagelschmidt Rodrigues <anr@ime.usp.br>
Date: Wed, 14 Jun 2000 15:19:04 -0300
Ronald Schmidt writes:
> The full warning message on our system (Solaris, Apache 1.3.3, mod_perl
> 1.21?, perl 5.005_02) is:
>
> [Tue Jun 13 17:37:25 2000] null: Use of uninitialized value at
> /usr/local/lib/perl5/5.00502/CGI/Cookie.pm line 70.
Hi,
I see this too. In my case I think Netscape's the culprit. It is sending
Apache the following (malformed?) cookie:
Cookie: SITESERVER=ID=72da5a605e8cda8a2592065373b1f4c2; SafiraSID=1%3Ac8887045f923541e; 700:c318af8d6350ce2c
CGI then splits pairs on ';' and keys and values on '='. You end up with a key
(700:c318af8d6350ce2c) without value. Then, line 70,
my(@values) = map CGI::unescape($_),split('&',$value);
triggers the warning.
===
Subject: Re: uninitialized value at ... CGI/Cookie.pm line 70.
From: Drew Taylor <dtaylor@vialogix.com>
Date: Wed, 14 Jun 2000 16:28:03 -0400
Adriano Nagelschmidt Rodrigues wrote:
>
> Ronald Schmidt writes:
> > The full warning message on our system (Solaris, Apache 1.3.3, mod_perl
> > 1.21?, perl 5.005_02) is:
> >
> > [Tue Jun 13 17:37:25 2000] null: Use of uninitialized value at
> > /usr/local/lib/perl5/5.00502/CGI/Cookie.pm line 70.
>
> Hi,
>
> I see this too. In my case I think Netscape's the culprit. It is sending
> Apache the following (malformed?) cookie:
>
> Cookie: SITESERVER=ID=72da5a605e8cda8a2592065373b1f4c2; SafiraSID=1%3Ac8887045f923541e; 700:c318af8d6350ce2c
Well, that is certainly a malformed cookie! It should be "name=value",
so this cookie will obviously fail normal cookie parsing. The question
is: is Netscape or the original server the culprit? Who first mangled
the cookie? :-)
===
Subject: [Slashcode] funky apache error: Broken pipe; rwrite
From: Brian Aker <brian@tangent.org>
Date: Thu, 29 Jun 2000 09:14:25 -0700
slashcode-admin@lists.slashdot.org wrote:
> We're getting a funky problem with our slash site. Netscape complains
> "document contained no data" over and over, while the access log claims
> that everything is OK. The error log gets this, but only sometimes:
>
> [Thu Jun 29 00:02:20 2000] [info] [client 208.151.124.166] (32)Broken
> pipe: client stopped connection before rwrite completed
> [Thu Jun 29 00:02:20 2000] [debug] Apache.xs(361): (32)Broken pipe:
> mod_perl: rwrite returned -1 (fd=3, B_EOUT=8)
>
> Restarting apache helps temporarily.
Check to see if you compiled mod_perl as a complete DSO. mod_perl
(and therefor slash) will work fairly flakey if you do.
===
Subject: Re: [Slashcode] funky apache error: Broken pipe; rwrite
From: Nathan Vonnahme <nathan@thethirdsector.com>
Date: Thu, 29 Jun 2000 09:10:58 -0800 (AKDT)
Nope, everything's compiled together and it's been working fine for a
couple of weeks. We've been modifying the code some though. It's not an
apache compilation problem.
===
Subject: [Slashcode] Re: funky apache error: Broken pipe; rwrite
From: Nathan Vonnahme <nathan@thethirdsector.com>
Date: Thu, 29 Jun 2000 14:22:05 -0800 (AKDT)
I found what sounds like it may be a solution. On
http://perl.apache.org/guide/debug.html#Handling_the_User_pressed_Stop_ :
"When Apache's SIGPIPE handler is used, Perl may be left in the middle of
it's eval context, causing bizarre errors during subsequent requests are
handled by that child. When Apache::SIG is used, it installs a different
SIGPIPE handler which rewinds the context to make sure Perl is back to
normal state, preventing these bizarre errors. " [quoted from the
Apache::SIG POD I think]
I've turned this on in my config with
PerlFixupHandler Apache::SIG
Now, hopefully it will help. We haven't been having the problem so far
today though so who knows if it will make a difference...
===