FTP is still pretty much alive in research as well (well, until now). I also used it in the past week. I understand it has flaws, but... I don't know, this seems yet another nail in the Old Web coffin.
"Has flaws" is an understatement. FTP does not play well with the current way the web is set up. Any firewalling or NAT is a pain unless you have the firewall introspect the FTP commands, which is easy for plain FTP because it's plain text and unencrypted, but once you start encrypting the transport it gets more complex, and you need to add support for that in the firewall. There's also often two connection channels, one for control and one for data.
Just be aware that any FTP upload capability offered is likely a serious pain for the admins on the other side. Even if they finally get it configured well enough to mostly forget about, they'll have to dive back in every time they upgrade any infrastructure along the path to it. It's much easier to just pass a TCP port though, which is what scp/sftp (the SSH variant, not the misnamed ftp/s variants some clients used to advertise as it) is much easier, and if you use rsync, includes easy recovery.
> FTP does not play well with the current way the web is set up. Any firewalling or NAT is a pain unless you have the firewall introspect the FTP commands,
That is true only for active mode FTP. Firefox (and many other clients) already used passive mode FTP by default, which passes through NATs and firewalls just fine without need for special help.
Active FTP is a problem if the client is firewalled or behind NAT. Passive mode is a problem if the server is firewalled or behind NAT. The client makes both connections to the server, but still using a second arranged port, so any firewalling on the server has to either be aware of the specific port requested, or a wide range of ports needs to be directly passed through. This is what I was talking about with FTP aware firewalls.
This is what the ip_conntrack_ftp and ip_nat_ftp Linux kernel modules are, a way to make iptables more FTP aware by supplementing iptables at the kernel level.
This is also what OpenBSD's ftp-proxy utility is for, a way to deal with this without resorting to privileged specialty packet processing code, and a way to bypass not being able to see into encrypted traffic.
The fact that these workarounds exist is a testament to how hard FTP has been to deal with in the modern era of the web.
> I don't think FTP is ever going to fully die. It is still a typical way to deploy your files when using a shared web hosting that does not offer SSH.
Surely those abominations are almost dead now though, in the age of the low-overhead VMs?
Some parts of the tech world seem quick to forget that smaller (and sometimes bigger) non-tech companies do exist. Sometimes non professional people create and deploy websites either as hobbyists or simply because there is no budget to hire a proper tech guy.
Wordpress is still a huge part of the Web and is running fine on shared hosting. And yes it can be an appropriate and cost effective choice for smaller sites even in 2021.
Also adding to that, the one time I did migrate a project from shared hosting to a dockerized VM solution was when the hoster was not supporting the needed PHP version anymore. Meaning hopelessly too old to ever update.
SFTP is not only just preferable but so unrelated to FTP that it frustrates me that it's often brought up in the same sentence... why did they call it that.. uhg.
We’re kind of crazy and use WebDAV. Big upsides besides upload support were built in support in Windows Explorer, running over a single port / http, and https support.
While we have a automatic deployment pipeline for our own projects, lots of our customers that host externally still use good old FTP.
I don't think FTP is ever going to fully die. It is still a typical way to deploy your files when using a shared web hosting that does not offer SSH.