TANNERC@CRL.AECL.CA (CHRISTOPHER TANNER) (02/11/91)
Hi all We are running WIN/TCP vs 5.1 on VMS 5.4 and are using the secure vs of FTP as recommended by Wollongong. One problem that we have seen is that when I am FTP'ing from VMS to another machine, the 'ls' command is actually sent as 'ls<space><space>' (ls followed by 2 blanks). This causes unknown directory errors on NOS/VE, IRIS (r3.3), but not on SUN, Ultrix or PC/TCP from FTP. (The command 'ls directory' works properly). Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE being too fussy? Thanks in advance for your help. Chris Tanner TANNERC@CRL.AECL.CA AECL Research
imp@Solbourne.COM (Warner Losh) (02/12/91)
In article <09F0D6D7E020051A@crl.aecl.ca> TANNERC@CRL.AECL.CA (CHRISTOPHER TANNER) writes: >I am FTP'ing from VMS to another machine, the 'ls' command is actually sent >as 'ls<space><space>' (ls followed by 2 blanks). Are you sure? I'm about 99% positive that it sends out an NLST command when you type 'ls' to the prompt and a LIST command when you type 'dir'. I wouldn't doubt that it is putting an extra space at the end, however. >Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE >being too fussy? SGI and NOS/VE appear to be not conforming to the standard. To quote RFC 959, page 46: "The command codes and the argument fields are separated by ONE OR MORE spaces." (emphasis mine) So, the path name doesn't begin until after the second space[*]. Since there should be a <CR><LF> pair after the second space, this makes the pathname argument NULL, so the implementation should list the current directory. This is due to the following in the description of LIST(pp 32, ibid): "If the pathname specifies a directory [...] If the pathname specifies a file [...]. A null argument implies the user's current working or default directory." and in NLST (p 33 ibid): "A null argument implies the current directory" If it was me, I'd file this as an MR to TWG, none the less, since it is causing interoperability problems. Warner -- [*] I guess a case could be made here that if there are to be no arguments, then the command should be immediately followed by a <CR><LF>. However, other places call this argument a NULL argument, rather than a missing argument. -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show.
08071TCP@MSU.BITNET (Doug Nelson) (02/12/91)
>We are running WIN/TCP vs 5.1 on VMS 5.4 and are using the secure vs of >FTP as recommended by Wollongong. One problem that we have seen is that when >I am FTP'ing from VMS to another machine, the 'ls' command is actually sent >as 'ls<space><space>' (ls followed by 2 blanks). This causes unknown >directory errors on NOS/VE, IRIS (r3.3), but not on SUN, Ultrix or PC/TCP >from FTP. (The command 'ls directory' works properly). > >Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE >being too fussy? According to my reading of the spec, it's Wollongong's problem. The spec clearly states that a keyword (NLST in this case) is followed either by CR/LF if there are no parameters, or SP if there are parameters. Also, the syntax of the LIST and NLST commands is shown as having one optional parameter: LIST [<SP> <pathname>] <CRLF> "<pathname>" is defined as "<string>", which is defined as one or more occurrences of <char>, which is defined as any ASCII char from 0 to 127 excluding CR and LF, but including space. This implies that "LIST <SP> <SP> <CRLF>" is a request to list a file or directory with a single blank as its name. Now, the semantics of recognizing a pathname require the treatment of a null path as being "the current directory", but nothing prevents or requires a server to strip white space from the pathname before any further interpretation. Doug Nelson Michigan State University
jcurran@SH.CS.NET (John Curran) (02/13/91)
-------- Hmm.. RFC959 is slightly contradictory regarding the spaces between the command and argument fields: pg. 46 > LIST [<SP> <pathname>] <CRLF> > NLST [<SP> <pathname>] <CRLF> where <SP> is NVT-ASCII notation for space and hence does not allow multiple spaces. <pathname> is defined to allow a leading space. versus pg. 45 > The command codes and the argument fields are separated by one or more > spaces. The host requirement application layer rfc (1123) has this on the subject: > 4.1.4.1 Pathname Specification > > Since FTP is intended for use in a heterogeneous > environment, User-FTP implementations MUST support remote > pathnames as arbitrary character strings, so that their form > and content are not limited by the conventions of the local > operating system. > > DISCUSSION: > In particular, remote pathnames can be of arbitrary > length, and all the printing ASCII characters as well > as space (0x20) must be allowed. RFC-959 allows a > pathname to contain any 7-bit ASCII character except CR > or LF. Since the specification is inexact, I'd let each vendor (WG, CDC, and SGI) know about the interoperability issue, so that they all have the option of "fixing" their s/w. Of course, as a side issue, the next round of clarifications should be tightened to allow leading spaces in filenames (of questionable value) or multiple spaces as a delimiter. /John
imp@Solbourne.COM (Warner Losh) (02/13/91)
In article <9102120858.AA14961@ucbvax.Berkeley.EDU> Doug Nelson <NELSON%MSU.EDU@CUNYVM.CUNY.EDU> writes: >This implies that "LIST <SP> ><SP> <CRLF>" is a request to list a file or directory with a single >blank as its name. No, I must disagree with your reading of the RFC. On page 46 of RFC 959 states: "The command codes and the argument fields are separated by one or more spaces" LIST<SP><SP><CR><LF> is a list command that has a NULL pathname argument (since it starts after the last <SP> and ends before the <CR>). It is clear from reading RFC 1123 that the ftp daemon should be able to accept any string that doesn't have a <CR> or a <LF> in it. However, in light of the text I sighted above, it would appear that the path name can't start with a space. This would seem to indicate a small hole in the FTP spec. I just noticed that the SunOS 4.0.3 ftpd insists on having just one space between the command and the arguments. Checking the source makes this reason rather obvious. The reason that "LIST<SP><SP>" works on the sun (and I guess other BSD machines) is that this turns into a popen ("ls -lg ") which will list the current directory. However, like I said before, I'd file a bug with Wollongong since it is an interoperability issue. Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show.
NELSON@MSU.BITNET ("Doug.Nelson") (02/15/91)
From Merton Campbell Crockett: > The copy of RFC959 that I have indicates that a command is a "TELNET string" > and that the command verb is terminated by a space. It also states that > command arguments or parameters are separated by one or more spaces. I didn > find any explicit comments on trailing spaces. Leading spaces, on the other > hand, are addressed and permitted. > > While one might argue that Wollongong's construction of the command is shodd > the NOS/VE and IRIS command parsers err in not being "robust". I'll (gladly) stand corrected. I had looked for any reference to multiple spaces, and read right over the sentence that says it (in section 5.3) at least twice. Now that I see that, I would say that such a command should be treated as giving a null pathname, which is equivalent to the default. I was originally going to make the same statement about the NOS/VE and IRIS implementations, but without the "or more" clause there, they would have been correct. Doug