in reply to Why might LWP::UserAgent be failing with '500 EOF'?

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"; } ...

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.

Replies are listed 'Best First'.
Re^2: Why might LWP::UserAgent be failing with '500 EOF'?
by ff (Hermit) on Apr 13, 2006 at 06:40 UTC
    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.

Re^2: Why might LWP::UserAgent be failing with '500 EOF'?
by ff (Hermit) on Apr 18, 2006 at 04:11 UTC
    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"?

    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.

      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