Re:Shutting down public FTP services
by acdha on Tuesday April 25, 2017 @08:24PM
(#14199500)
FTP was older and had more widespread client support in the 90s, so you were more likely to have at least a basic client preinstalled. That's obviously moot by now since just about everything ships with a web browser and/or something like curl.
FTP has a standard way to list directories. Using HTTP that way would require you to either have a well-known index file or parse HTML looking for links which don't return text/html responses.
The downside is that FTP still has issues with firewalls – I had to troubleshoot that earlier this month, actually – and is another service to maintain if you are already running an HTTP server.
In the case of either single-file downloads or something like a Linux package manager, the URLs are well known so directory listings are irrelevant. HTTP has a number of good options for CDNs and caching, so if you care about performance or reliability that's a turn-key service.
In the cases where directory listings were more valuable, people usually wanted a richer UI than just a file listing, too, and there are tons of options for that in the web world.
FTP has a standard way to list directories. Using HTTP that way would require you to either have a well-known index file or parse HTML looking for links which don't return text/html responses.
The downside is that FTP still has issues with firewalls – I had to troubleshoot that earlier this month, actually – and is another service to maintain if you are already running an HTTP server.
In the case of either single-file downloads or something like a Linux package manager, the URLs are well known so directory listings are irrelevant. HTTP has a number of good options for CDNs and caching, so if you care about performance or reliability that's a turn-key service.
In the cases where directory listings were more valuable, people usually wanted a richer UI than just a file listing, too, and there are tons of options for that in the web world.