[prev in list] [next in list] [prev in thread] [next in thread] 

List:       publicfile
Subject:    Re: FTP Listing
From:       Matthias Andree <matthias.andree () gmx ! de>
Date:       2000-08-21 17:35:25
[Download RAW message or body]

(You don't need to Cc: me, the list address suffices).

As to your original problem:

I just noticed that Squid 2.3STABLE2, which I'm currently using, is able
to parse EPLF and present it correctly, this may help you with your Red
Hat install problem. My Linux ftp client (which is a port of the NetBSD
ftp client, don't know the version) has no problem either. lftp 2.2.3 is
fine as well and has a "mirror" command.

On Mon, 21 Aug 2000, Victor STANESCU wrote:

> i am encountering some other problems which i fight with:
> 
> 1) (already corrected) - the redhat ftp installer wants the PASV answer to
> be like (x,y,z,t,u,v), instead of =x,y,z,t,u,v. I changed this..

RFC-959 is not very specific about this, regretfully. A client should be
able to extract any hm,h3,h2,hl,ph,pl sequence from the PASV reply, be
it surrounded by brackets or not. OTOH, there's nothing wrong with
(hm,h3,h2,hl,ph,pl) either.

> 2) (not sure what is in fact the problem): it sends NLST
> <something>/RedHat/base/hdlist, and it is bothered by the answer
> 426 Transmission failure: not a directory. I will compare with wu-ftpd, to
> see what answers it expects in fact from it.

Don't do that. Compare with RFC 959 to see if this is correct. Do not
copy what wuFTPd may make wrong.

I tend to see that publicfile is correct, although RFC-959 again leaves
room for interpretation.

However: (both quotes from RFC 959, p. 32f.)

"       NAME LIST (NLST)

            This command causes a directory listing to be sent from
            server to user site.  The pathname should specify a
            directory or other system-specific file group descriptor; a
            null argument implies the current directory.  The server
        [...]"

Since NLST on a file is pointless, I would rather consider Red Hat's
client buggy, not publicfile's ftpd. Why would someone list a file the
name of which he already knew? It seems to me that your Red Hat FTP
client is abusing NLST as sort of "is this file there" check in
negligence of LIST and STAT which can be used for that as per RFC-959's
sense.

Note NLST just gives file names, while LIST gives additional
information that "may be hard to use automatically in a program, but may
be quite useful to a human user".

Note also that LIST explicitly states behaviour when pathname refers to
a file, while NLST explicitly only mentions "file groups", not
individual files.

So while you're fixing for compatibility, you're actually fixing the
wrong end. Go bug Red Hat and have them fix their clients.

-- 
Matthias Andree

[prev in list] [next in list] [prev in thread] [next in thread]