Skip Menu |
 

This queue is for tickets about the IO-Socket-SSL CPAN distribution.

Report information
The Basics
Id: 46927
Status: rejected
Priority: 0/
Queue: IO-Socket-SSL

People
Owner: Nobody in particular
Requestors: jettero [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: EOF conspicuously absent from IO::Socket::SSL::SSL_HANDLE
Download (untitled) / with headers
text/plain 844b
I tried to come up with a few things on my own. It seems like this aught to work, but it causes an infinite loop instead. sub EOF { ${shift()}->eof(@_) } I suspect there simply isn't a meaningful way to provide EOF. The following solution is just fine... if( $fh = $io_select->can_read(1) ) { if( $fh->getline ) { # blah } else { die "socket is apparently closed." } } I do wish there were a way to detect that the socket was closed on the remote end before trying to read from the socket. It seems like that's something the kernel would tell the socket about. I wish you could do this: if( $sock->eof() ) { die "socket is apparently closed." } return $sock->getline; -- If riding in an airplane is flying, then riding in a boat is swimming. 107 jumps, 43.5 minutes of freefall, 83.4 freefall miles.
Download (untitled) / with headers
text/plain 415b
There is no way to know if the other end of a TCP connection (and thus a SSL connection) closed then to read data from it. Even a select will only tell you, that there is a read event on the socket, and only if you then read and get 0 bytes you know, that the socket was closed. The only thing a eof could do to check, if the filedescriptor is closed locally (with close()), which is apparently not what you need.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.