Re: LWP::Protocol::http bug with SSL returning 500 Can't read entity body

>> I'm using libwww-perl-5.805.tar.gz.
>>
>> Running code like this to get a page:
>> 
>>     use WWW::Mechanize;
>>     our $Mech = WWW::Mechanize->new();
>>     #$Mech->get("https://library.minlib.net:443/patroninfo/");
>> 
>> Returns a "500 Can't read entity body: " error.
>
>It doesn't fail when I tried it (even after uncommenting the get
>line).  I used Crypt::SSLeay; what SSL module did you use?

Net::SSLeay 1.30.

>> This is because the read_entity_body loop can't cope with a multi sysread
>> where the last packet returned is the EOF alone.
>
>I don't understand this.  What is the sequence of sysread returns in
>this case?  EOF is different from a failed read.

sysread of EOF is supposed to return zero, but in other network programs
I've seen a IO::Socket->sysread return of undef treated as == a EOF.  (Don't
ask me to prove the reasoning... :)  It may be when the EOF was detected by
an earlier read, and then the next sysread comes and the socket is now
fully closed, so returns undef for reading the closed socket.

Anyhow, here's the calls:

 calling read_entity_body(size=4096), returned 823
  my_read calls sysread(buf, 4096) returns r=4096, $!=''
 calling read_entity_body(size=4096), returned 4096
  my_read calls sysread(buf, 4096) returns r=1388, $!=''
 calling read_entity_body(size=4096), returned 1387
  my_read calls sysread(buf, 4096) returns r=undef, $!=''
 calling read_entity_body(size=4096), returned undef

The second sysread returns a buffer ending in '<!--this is customized
<screens/pverify_web.html>-->' and a newline.  Looking at the page source
in firefox, that is the end of the page.

>> It's the first time I've poked in this code, so this may be off, but one
>> possible patch that fixes it is below.
>
>The loop in LWP::Protocol::http is correct so I will not patch it.
>The error is at a different level; either in read_entity_body() or
>in the SSL module.

Quite likely, as I stated I have little clue what the internals do, all I
know is it fixed - or at least hid - my case :)

Maybe read_entity_body should then return 0 in the last packet?

-Wilson