develooper Front page | perl.perl5.porters | Postings from July 2019

Re: "Damaged tar archive" for perl-5.32.2 on ftp callsfromCPANmirrors

Thread Previous | Thread Next
From:
Deven T. Corzine
Date:
July 26, 2019 01:46
Subject:
Re: "Damaged tar archive" for perl-5.32.2 on ftp callsfromCPANmirrors
Message ID:
CAFVdu0TDrhdDPKW9XLgm+_STCZDeSfnLrKtxGa4MH62W6A9eQQ@mail.gmail.com
Whoops!  I didn't read through the rest of the thread, so I didn't know the
failure of "TYPE I" before login was already pointed out.  My bad.

On Thu, Jul 25, 2019 at 3:06 PM Niko Tyni <ntyni@debian.org> wrote:

> On Fri, Jul 26, 2019 at 01:49:06AM +1000, sisyphus wrote:
>
> > With ftp.pl in its original form, I always saw output of:
> > 150 Opening BINARY mode data connection for perl-5.31.1.tar.gz (17593158
> > bytes)
> > and thought that meant that I was, in fact, downloading in binary mode.
> > Apparently that's not correct. What does that output actually tell me ?
>
> That part looks weird indeed. It actually says BINARY mode even when
> specifically requesting ASCII mode. Guess it's a bug in the server code.
>

Yes, it's a very misleading message!  Since the FTP specification doesn't
dictate the text to use, technically it's not a protocol violation, but I
would still view it as a bug in the FTP server since it makes it look like
it's using binary mode when it isn't.

> The next question is "Is it fair enough that the mirrors.rit.edu server
> > requires this of my script ?"
> > Since binary() is a method that's called on the Net::FTP object I would
> > have expected that calling $ftp->binary() could be done at any time after
> > initialization of $ftp.
>
> Seems fair enough to me, particularly as binary() is returning false
> when it fails. Net::FTP is just wrapping protocol commands here.
>

I don't see anything wrong with mirrors.rit.edu refusing the "TYPE" command
before logging in.  It returns an error code, after all.  Using other
commands without logging in is a strange thing to do in the first place,
and probably shouldn't be assumed to be kosher.

I suppose Net::FTP could be enhanced to remember that binary mode was
attempted and automatically retry later, but it really shouldn't be
necessary.

> Also, note that the ftp.funet.fi server has no such requirement. The
> script
> > output reveals that on the ftp.funet.fi server the switch to binary
> mode is
> > made *after* the login, even though the script calls the binary method
> > *before* the login.
>
> Not sure how you see that the switch is made after the login.
> AFAICS it's sending 'TYPE I' and getting 200 (OK) before USER in your
> script output.
>

Yeah, it was an immediate response:

Net::FTP=GLOB(0x80151d150)>>> TYPE I
Net::FTP=GLOB(0x80151d150)<<< 200 TYPE is now 8-bit binary

I don't understand how this is switching after the login.

But it looks like ftp.funet.fi uses binary mode anyway (even if ASCII mode
> is specifically requested!) so there's no actual mode switch involved.
> --
> Niko, who thinks FTP is long obsolete and should just die...
>

I was curious about this, so I did a search.  Apparently Pure-FTPd actually
has an option (--without-ascii) to disable ASCII-mode transfers!

It's mentioned in the README:
https://download.pureftpd.org/pub/pure-ftpd/doc/README

Of course, doing this IS a protocol violation, but actually a helpful one
for people who forget to set binary mode...

Deven

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About