It's about cost, too. HTTP can be cached very efficiently, but FTP not at all. If I were the operator in charge and I had the choice between next-to-free caching by nearly anything, be it a Squid proxy, apt-cache or nexus, or no caching and having to maintain expensive servers, I'd choose HTTP.
FTP is not nearly as trivial, plus it's a stupid, broken protocol that deserves to die. The whole thing is a giant bag of hurt.
I agree with you, but FTP has one very valid use case left: easy file sharing, especially for shared hosting. FTP clients are native to every popular OS, from Android to Windows (only exceptions I know are Win Mobile and iOS), and there's a lot of ecosystem built around FTP.
There is SCP and SFTP but they don't really have any kind of widespread usage in the non-professional world.
Nope. Nope. Nope. Not easy. Not secure. Not user friendly. Not anything good. Have an iPhone and need to FTP something? Don't have installation rights on your Windows workstation and need to FTP something? Unpleasant if not confusing as all hell.
Dropbox or a Dropbox-like program is significantly easier to get people on board with.
Any "ecosystem" built around FTP is rotten to the core. Blow it up and get rid of it as soon as you can.
Some vendors insist on using FTP because reasons, but those reasons are always laziness. I can't be the only one that would prefer they use ssh/scp/rsync with actual keys so I can be certain the entity uploading a file is actually them and not some random dude who sniffed the plain-text password off the wire.
Windows explorer has FTP built into the shell. As does every other desktop OS.
If you care about file integrity, you want to out of band to verify the signatures on the binary anyway.
Dropbox is blocked in most commercial networks and offers no assurance of anything.
Versus drag and drop file to this page. There you go. It's uploading.
That's why I said Dropbox or a Dropbox-like service, of which there are hundreds. Microsoft SharePoint is but one example.
Type ftp://ftp-site/path/to/file. Drag and drop to your hearts content.
Windows has first-class support (obviously); but Samba gives Linux and BSD support that, in modern Desktop Environments, is exactly as good. Mobile devices don't tend to have OS-level support for it, but there are very good libraries to enable individual apps to speak the protocols (look at VLC's mobile apps.)
Even Apple has given up on their own file-sharing protocol (AFP) in favor of macOS machines just speaking SMB to one-another.
Yes, it's not workable over the public Internet. Neither is FTP, any more. If you've got a server somewhere far away, and want all your devices to put files on it, you're presumably versed with configuring servers, so go ahead and set up a WebDAV server on that box. Everything speaks that.
Yeah, nope. Dead out of the gate. Thanks for playing.
The GP comment:
> FTP clients are native to every popular OS, from Android to Windows (only exceptions I know are Win Mobile and iOS)
To rephrase: only 1/3 of mobile OSes support FTP.
Not working on iOS is like saying "Oh, this road doesn't work with German made cars. That's not a big deal, is it?"
https://panic.com/transmit-ios/
Searching the App Store I also see some apps for SMB, but I don't know whether they have document provider extensions.
FWIW, I'm not convinced that "web-based" is a better alternative for read/write file access, assuming you mean file manager webapps. No OS can integrate those into the native file picker, so you can't avoid the inefficiency of manually uploading files after changing them. WebDAV works pretty well though, if that counts...
I wonder if GP is pulling our legs about WebDAV. Yuck.
Uh, hell no. Never ever I'd expose a SMB server to the Internet. SMB is really picky when the link has packet loss or latency issues, plus the countless SMB-based security issues.
> Even Apple has given up on their own file-sharing protocol (AFP) in favor of macOS machines just speaking SMB to one-another.
TimeMachine still depends on AFP.
No, it doesn't:
https://developer.apple.com/library/content/releasenotes/Net...
Imagine a file transfer protocol that defines the command to list files in a folder, but does not specify the format of the response other that it should be human-readable.
https://www.ietf.org/rfc/rfc959.txt LIST and NLST commands for example. No way to get a standard list of files with sizes and modification dates. yay!
Oh, and the data connection that is made from the server to the client. That works wonders with firewalls of today.
It was an ok spec when it was invented, but today it's very painful to operate.
It's ironic that you mention cost and caching but lot of services used for software distribution of one kind of another (e.g. Github releases) are following the "HTTPS everywhere" mantra and HTTPS can't be cached anywhere other than at the client.
For Debian, packages are secured by PGP in combination with checksums so it's not relevant for them. The debian repos are often HTTP only.
No. Nexus for example can certainly cache apt, as well as Squid can do if you provision it with a certificate that's trusted by the client.
Also, Cloudflare supports HTTPS caching if you supply them with the certificate, and if you pay them enough and host some special server that handles the initial crypto handshake you don't even have to hand over your cert/privkey to them (e.g. required by law for banks, healthcare stuff etc)
Gopher generally avoids most of FTP's pitfalls and it is dead easy to implement.
[1] http://shows.howstuffworks.com/techstuff/what-was-gopher.htm
IIRC WebDAV uses GET for retrieval, so the read parts can be cached by an intermediate proxy and the write part be relayed to the server.