Hacker News Reader

Comment by rwmj | Hacker News Reader

As the author of an FTP server called Net::FTPServer, I must say this article is full of crap. All modern clients request binary mode and passive connections by default. All modern servers can restrict the range of port numbers used on the server side. Clients support encrypted control and/or data connections. You can checksum files using de facto standard commands (it's better than unencrypted http in this regard).

Now some benefits of FTP:

- easy uploading of files

- standardized file listings, delete, mkdir, etc

- extensible protocol via "SITE" commands

- wide availability of clients and servers

It's better to compare FTP to WebDAV. After comparing it you may still think FTP should "die" (whatever that means in the open internet where any two people can run any service they want), but at least you'd be making a sound technical decision, which you're not doing by reading this article.

View on HN

> - standardized file listings, delete, mkdir, etc

Isn't one of the rant's point specifically that these are not standardised (in a de-jure sense)?

> It's better to compare FTP to WebDAV.

SFTP exists, has none of FTP or WebDAV's issues and (as far as I can tell) ticks all your boxes. Even extensions: http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#sect...

Those commands really are standardized. The problem is that the rant didn't bother to look at any of the more modern RFCs, nor at de facto standards supported across lots of servers and clients.

SFTP is fine too, assuming you have support, which is not available on many embedded platforms, and even on Windows requires downloading extra tools.

I'm hardly claiming that FTP is the pinnacle of human achievement. The original standards have many obvious flaws, but those have long been fixed. What we have now is maybe not elegant, but it works and the problems with it are not any of the things outlined in the article.

As the author of a FTP server called warftpd, I agree :)

Another argument in favor of FTP is that the protocol is simple to implement from scratch, well understood and - well it's an established standard. In stead of re-inventing transfer protocols, creative people can cook up new ways to use it.

The FTP protocol designers understood the need for something like ASCII mode back in 1985. Something the SFTP people had to re-discover in 2005.

Abhay Bhushan, Postel, Reynolds etc did an awesome job!

edit: wrong rfc

Out of curiosity, why did sftp need ascii mode? I'm drawing a blank trying to think of why sftp would need it.

I use it almost daily in a test/configuration environment to move text conf files to Linux machines we are setting up via scripted process. The Linux hosts have ftp disabled and ssh enabled by default.

I use sftp/scp constantly, but I'm not sure how is an ASCII mode needed/important for that.

Do you transfer text files or binary?

Text I do ascii, always have. Is there a reason, no, but that's how I roll.

I run a MUD which has alot of people from all over the world as developers. Most are not technical and do simple thing like create areas for the game etc. Explaining how to convert files from CRLF to LF only has turned out to be impossible.

When they use modern FTP clients which automatically handle ASCII mode it just works. SFTP seems to work for some users. It probably depends on the clients support for ASCII mode..

Reply on news.ycombinator.com