Ftp-WG: NLST vs MLSD

At 09:04 AM 10/15/2002, Frank da Cruz wrote:
>This is what bothers me.  Of course what you say is true, but I don't 
>think it's a good idea to ignore implementation, existing practice, and 
>widespread human behavior when modifying a key Internet protocol, if the 
>modifications can affect all that.

To an extent.  MLST / MLSD was specifically supposed to ignore 
implementation, and existing practice, because what is there at present is 
wildly unreliable.  How many versions of "ls -l" are there?  That was what 
MLST and MLSD were supposed to replace - LIST, not NLST - and they were 
supposed to replace the LIST commands in some means other than declaring 
one or other "ls -l" to be the standard.

Apparently, there is already implementation of wildcards in MLSD on two 
servers, and at least one client implementation - the question becomes 
what, if anything, should be done about that?  Should we leave an 
undocumented (and counter-document) assumption in the works, or should we 
perhaps try and re-emphasize that an FTP client "MUST NOT" pass wildcards 
to MLSD?  Sadly, I don't have access at present to a server that implements 
wildcards in MLSD so that I can discover and/or demonstrate the failings 
inherent in unplanned wildcard support in MLSD.  As I mentioned earlier, 
certain assumptions inherent in the MLSD format break as soon as you allow 
wildcards, so MLSD either needs to change to support wildcards, or the use 
of wildcards in MLSD needs to be forbidden.

>How can it?  Either the FTP client knows the file system syntax of the
>server host or it doesn't.  In common practice, most clients simply assume
>the server to be Unix, which is no basis for an open protocol.  If it
>doesn't know the host's syntax, it can't decompose strings like
>"[.blah]*.jpg" into CWD and NLST commands (or whatever).

Without TVFS, if a client user types "MGET foo", the client must "NLST 
foo", and then RETR everything that it sees in response.  The same goes no 
matter what special characters other than "\r\n" are in 'foo'.  A compliant 
MLSD should respond that there is no such directory as "[.blah]*.jpg", 
rather than try and list files matching the description.

>In other words, users are always going to have to know something about
>the platform on the other end of the connection, even if wildcards were
>abolished from the wire.

There's almost certainly room for a specification that says "this command 
takes a specification that refers to one or more files or directories, and 
lists the matching items in the following format".  MLSD isn't it - so 
perhaps you'd like to write MLSW?

>Again, undefined strings are the "escape valve" that lets users accomplish 
>what they want when the protocol or software stands in their way.  They 
>let users to "go over the head" of the client and speak directly to the 
>server. It's like the big boss having an open door policy.  It's not 
>necessarily a bad thing.  But of course it should not be the only thing.

And, where it is allowed, the results should be as useful as possible.  If 
I ask a wildcard-capable MLSD implementation for "*", am I going to get the 
names of all the files and directories in the current directory, or am I 
going to get the names of all files in the current directory as well as the 
names of all files in every subdirectory?  How, as a client, are you going 
to distinguish the files from one another?  In MLSD as it is currently 
defined, you have no hope.  So, either that support of wild-cards is going 
to be unreliable, or it's going to be to a standard that hasn't been 
documented.  If it's a standard that hasn't been documented, then the 
implementors need to explain it, and how to rely on it.  If it's 
unreliable, then it should be chopped out, and wildcards should be refused 
by the server.

Alun.
~~~~

--
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place   | http://www.wftpd.com or email [email protected]
Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.