On Wed Nov 26 17:08:37 2014, SULLR wrote:
Show quoted text> On Mon Nov 24 10:22:31 2014, zefram@fysh.org wrote:
> > I have some code that uses $ftp->retr($file) to acquire a data
> > connection
> > handle and then calls $conn->getline repeatedly to read directly
> > from it. This used to work. But when using libnet-3.02, the getline
> > call returns undef (indicating end-of-file) without the process ever
> > actually attempting at the syscall level to read from the data socket
> > or even checking whether the socket is readable. It looks like this
> > is
> > a result of using IO::Socket::SSL to manage the data socket. This is
> > not an SSL-using session, and patching Net::FTP to use
> > IO::Socket::INET
> > instead of IO::Socket::SSL makes the code work again.
> >
> > I suggest that IO::Socket::SSL shouldn't be used unless the
> > particular
> > connection requires SSL.
>
> Thanks for reporting the problem.
> The reason for this problem was, that IO::Socket::SSL did not
> implement getline
> properly when used in plain mode. This is fixed in IO::Socket::SSL
> version 2.007.
>
>
> Some Background:
> Since version 1.994 IO::Socket::SSL can be used in SSL-mode (as
> before) and
> also in plain mode and can switch between these modes with start_SSL
> and
> stop_SSL. This was explicitly done to support modules like Net::FTP.
> While it would be nice to make Net::FTP use IO::Socket::SSL only if
> SSL
> is actually used, the current design of Net::FTP would mean that
> Net::FTP::dataconn might need to change the super class for each
> connection,
> depending on the required protection mode.
> This would be a very bad hack and would definitely cause problem when
> used
> together with threads.
>
Many thanks for looking at this, Steffen.
I agree that dynamically changing superclass would be a bad idea, so I would propose simply having libnet require IO::Socket::SSL v2.007 or higher if it uses IO::Socket::SSL at all to avoid this problem.
Zefram: Would that be acceptable to you, or would you still prefer finding some (other!) way to have it not use IO::Socket::SSL at all when no SSL is involved, if that's possible?
