Bernhard R. Link wrote:
* Adam D. Barratt <[EMAIL PROTECTED]> [080603 14:26]:
variable, it is no sane default since the days firewalls, NATs and
hosts with multiple IP addresses were invented.
uscan doesn't actually use either active or passive FTP by default,
having read the code. It uses Net::FTP and if you don't explicitly
specify that active or passive should be used then Net::FTP makes
its own mind up.
From Net::FTP(3perl):
[...]
I think this default in Net::FTP should be changed.
From a quick scan through perl-modules's bug page, #263552 ("libnet-perl
should default to passive mode on PORT failure") has been forwarded upstream
since August 2004. The forward is the last entry in the bug log.
It would be nice
if uscan would work around this problem in Net::FTP. Since it already
has an opts=active already documented, doing always passive can do no
harm.
It potentially swaps people confused by the active default for people
confused by the passive default. :-)
Even worse, when this fails, it does not even output an error
message. Even using --verbose --debug you only get:
uscan debug: received content:
[End of received content]
while the ftp server is actually sending errors:
read(4, "500 Illegal PORT command.\r\n", 1024) = 27
As far as I can see, this means that Net::FTP and/or LWP is claiming
that the request was successful.
I've uploaded a small test script to
http://alioth.debian.org/~adam-guest/ftptest.pl - could you please
run it against the ftp site you were using uscan with and let me
know the result?
Without the host changed I get:
ftp read failed: 500 LWP::Protocol::MyFTP: Bad hostname
'ftp.example.com'
Sorry; I assumed it was obvious you needed to change that :)
with ftp.gnu.org I get:
status line: 200 OK
received content:
[End of receieved content]
Strace still showing it got an error from the ftp server:
[...]
I guess that means the missing error message is a fault of Net::FTP,
too.
Either Net::FTP itself or LWP::Protcol::ftp certainly look like the culprit,
yeah.
Thanks for testing; that at least rules out a uscan bug on the error
handling side. If it was returning a useful status code or message then we
could have tried matching on that, but as it is... :-(
Regards,
Adam
--
To unsubscribe, send mail to [EMAIL PROTECTED]
