gft_robert@gsbacd.uchicago.edu (10/30/90)
----- The story so far: when I do an "ls" when anonymously ftping into ftp.apple.com I get directory listings which have LF's, but no CR's. That is, the text keeps on wrapping to the right of the screen instead of being in a nice vertical column. I asked about this and got a couple of responses which said that it looked OK from other sites, so the problem must be at my site. Indeed, I tried it from a friends unix machine and it looked OK. So I contacted my system manager. He tried ftping from our site into numerous other machines. All worked fine. But ftp.apple.com still had the same problem. His theory is that ftp.apple.com is not issuing CRLF pairs, but merely LF's. This would probably work fine on a unix machine, but since gsbacd runs under VMS, it needs a CRLF pair to look correctly. Can anyone who is managing ftp.apple.com comment on this? I'd be glad to continue this thru email, but I don't know who's managing the site. Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
Jim.Matthews@dartmouth.edu (Jim Matthews) (10/30/90)
>His theory is that ftp.apple.com is not issuing CRLF pairs, but merely LF's. >This would probably work fine on a unix machine, but since gsbacd runs under >VMS, it needs a CRLF pair to look correctly. This problem springs from an ambiguity in RFC-959, the document that specifies the FTP protocol. The description of the NLST command makes it seem as if the output of that command can be LF-terminated (instead of CRLF-terminated, which all other output is). Jon Postel (the author of the RFC) has assured me that he did not intend that interpretation, but the latest ftp server for Berkeley Unix follows it so we're stuck. There are a couple avenues of action. Apple could fix the server on ftp.apple.com -- the line in question is in send_file_list(), where fprintf(dout, "%s\n", dirname); should be changed to fprintf(dout, "%s\r\n", dirname); Alternatively, you can use an FTP client that handles LF-terminated lines (Unix FTP clients, HyperFTP, and NRC's MacFTP included). Other FTP clients may provide an alternative file list command (on Unix it's called "dir"). These commands will typically use a different underlying FTP command, and thereby evade the bug. Jim Matthews Dartmouth Software Development Disclaimer: I wrote MacFTP (but I didn't choose its name!).--