Hacker News Reader

To be fair to FTP, it was written for NCP in the 70s. Network protocol design was a very different problem back then and NCP required incoming data on a different port to outgoing (usually with adjacent, odd/even, ports though).

However I do completely and emphatically agree that FTP needs to die. There is no need for it in the modern era. We’ve had a whole plethora of better suited protocols since (I don’t agree HTTP is a good fit replacement but there isn’t a shortage of options out there) and in many cases FTP - even once you’ve applied the mountain of kludges and workarounds just to get it working with SSL behind two NAT’ed firewalls - still falls short of what a great many alternatives can already do.

FTP not only needs to die; it should have already died 10 or 20 years ago.

You have strong opinions about this, which makes me think maybe you can tell me details I didn't know about FTP.

> It's an archaic protocol built around the limitations of early-1980s systems.

What were the limitations, and how did they shape the protocol?

> protocol "feature" of having server responses be human-readable (and not machine-parseable)

The responses are successfully parsed by quite a few clients, no? The fact that I as a person can easily read the output would seem in and of itself to be a positive quality.

> control and data connections ... caused something like 2 decades of security problems, also makes it a nightmare to provision in modern networks

I know little about configuring network security, can you tell me more here? The idea is that in passive mode the server has to pick and listen on a bunch of random ports and so the firewall can't unconditionally block them?

Also you mention "modern networks" -- did it used to be easier to provision networks in the past and something has changed recently?

Someone else on HN probably has firsthand experience with the systems that birthed FTP, and I will be speculating a bit. But here's an example, and it's an interesting one because it infects TCP to this day: presumably because systems at the time didn't have workable socket multiplexing, FTP (and TCP) supports an "URGent pointer" that allows one TCP to flag another that important command-and-control data needs to be read during a file transfer --- this despite the fact that FTP is already (pointlessly) allocating an additional socket connection for each data transfer. The URG wart lives on in TCP to this day, unused by any modern protocol.

FTP LIST responses are "successfully parsed" by predicting that servers will return a circa-1991 ftpd "ls" listing. Which means that to be parsed by those clients, you need to be bug-compatible with those servers. That was the point DJB was making with his (parsable) publicfile output.

For a good starting point on FTP's security design, read up on [FTP bounce attacks]. But the key thing to remember is: this design is pointless. There is no reason for a file transfer protocol to be allocating new connections like this.

> There is nothing FTP does that HTTP can't already do.

In my experience, HTTP regularly chokes on multi-GB file transfers. I am not endorsing FTP, and when we have 100GB+ transfers we have in the past resorted to snearkernet.