ff has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,
I need help thinking about why two invocations of the same code, using the same paramater values (?), seem to deliver such different results. The situation is that I have copied some working code over to another program I'm working on and I do everything I can think of to invoke it the same way. The original makes the web connection just fine, the non-working one fails with '500 EOF'. Thanks.

Specifically, my program makes a connection to Google's Gmail using Mail::Webmail::Gmail. In executing 'request' from UserAgent.pm, a section of which follows, the original version of the program makes a connection and proceeds to work fine. The copy uses the same values for the input parameters (I verified elsewhere) and ends up dying with the 500 code. From UserAgent.pm (to which I added a couple lines for debugging): 

sub request
{
    my($self, $request, $arg, $size, $previous) = @_;

    LWP::Debug::trace('()');

    my $response = $self->simple_request($request, $arg, $size);
my $wmsgB = Dumper( $response ); # I added this line to UserAgent.pm
print "D-rsp:\n$wmsgB\n";        # I added this line to UserAgent.pm

    my $code = $response->code;
    $response->previous($previous) if defined $previous;

print $LOGF "code: '$code'\n";   # I added this line to UserAgent.pm

[download]
The non-working invocation reports that:

D-rsp:
$VAR1 = bless( {
     '_content' => '500 EOF
',
     '_rc' => 500,
     '_headers' => bless( {
                'client-warning' => 'Internal response',
                'client-date' => 'Thu, 13 Apr 2006 05:04:04 GMT',
                'content-type' => 'text/plain'
              }, 'HTTP::Headers' ),
     '_msg' => 'EOF',
     '_request' => bless( {
                '_content' => 'Email=brig.johnson&Passwd=a3512j&null=S
+ign+in',
                '_uri' => bless( do{\(my $o = 'https://www.google.com/
+accounts/ServiceLoginBoxAuth')}, 'URI::https' ),
                '_headers' => bless( {
                           'user-agent' => 'User-Agent: Mozilla/5.0 (W
+indows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.
+0.4',
                           'content-type' => 'application/x-www-form-u
+rlencoded'
                         }, 'HTTP::Headers' ),
                '_method' => 'POST'
              }, 'HTTP::Request' )
         }, 'HTTP::Response' );

code: '500'

[download]
while the working version gives:


D-rsp:
$VAR1 = bless( {
     '_protocol' => 'HTTP/1.1',
     '_content' => '        <html> <head> <script type="text/javascrip
+t" language="JavaScript"><!--

function doRedirect(url) {
  open(url, "_top");
}
//--> </script> <script type="text/javascript" language="JavaScript1.4
+"><!--

function doRedirect(url) {
  try {
    open(url, "_top");
  } catch (xcp) {
    insertContinueLink();
  }
}
//--> </script> <script type="text/javascript" language="EcmaScript"><
+!--

etc...
code: '200'

[download]

Replies are listed 'Best First'.
Re: Why might LWP::UserAgent be failing with '500 EOF'?
by ikegami (Patriarch) on Apr 13, 2006 at 06:25 UTC
    The code giving that error is in LWP/Protocol/http.pm: 
    ...

      my $fbits = '';
      vec($fbits, fileno($socket), 1) = 1;

...

         my $rbits = $fbits;
         my $wbits = $write_wait ? undef : $fbits;
         my $nfound = select($rbits, $wbits, undef, $sel_timeout);

...

         if (defined($rbits) && $rbits =~ /[^\0]/) {
            # readable
            my $buf = $socket->_rbuf;
            my $n = $socket->sysread($buf, 1024, length($buf));
            unless ($n) {
               die "EOF";
            }

...

    [download]

    It happens when select says the socket has data to read, but sysread is unable to read from the handle.

    I have no idea what would cause that. I'm just refining the problem description.

[reply]
[d/l]
[select]
      FWIW, more clues (?):

      1) It does take longer for the 'broken' version to finally resolve itself into something, i.e. failure

      2) The working version is a .pl program that I run directly from a C:\dirA\dirB command prompt. The broken version is a .pl program that is invoked via system.

[reply]
[d/l]
      Hi ikegami,

      Thanks for the suggestion to look in file LWP/Protocol/http.pm. I started trying tricks with Dumper on various sections, and thinking and googling led to the posting of #14028: Bug (leak?) with IO::Select object creation?. There, the OP makes three different sockets and notices upon Dumping them that:

      We create three IO::Select objects in the same way but each object is slightly bigger than the last. Surely each object should be the same size? The same behavior occurs on either Win32 or Solaris.
      Graham Barr answers that
      That is because IO::select uses the system file number of the handle passed to store the filehandle reference in an array. So the array object will be as big as the file number of the filehandle passed in.
      Okay, please tell me I've misunderstood this, but suppose the file number of the filehandle passed in was "0", does that mean some kind of empty array object will be floating around causing my EOF problem? In fact, when I edit http.pm by duplicating the socket creation line, my program works, i.e.

       my $socket = $self->_new_socket($host, $port, $timeout);
 $socket = $self->_new_socket($host, $port, $timeout);   # my duplicat
+ive line
     # such that $socket clobbers the 'my $socket' and so is not based
+ on "0"?

      [download]

      So, 1) what is Graham saying above, 2) why does my "fix" work, and 3) might there be a way to avoid altering the http.pm module? I suppose submitting this as a bug is the path I will tread.... Thanks.

[reply]
[d/l]
[select]
        I realise this thread is quite old, however, the same problem and the same fix resolved the issue for me. ff - did you ever report this bug? Regards, Andy
[reply]

Back to Seekers of Perl Wisdom