9 ms·

Is FTP really worse HTTP? If you try to enumerate directories over HTTP alarms start going off because you look like an attacker.

duskwuff 22d ago
> Is FTP really worse HTTP? I don't think I'd even call it that. FTP had one purpose: it was an early protocol for remotely managing files. It never had any intent to support dynamically generated or otherwise "virtual" content (as supported by e.g. CGI scripts and mod_rewrite in Apache), and I don't think anyone has ever made a serious attempt to implement that. There's no practical use case for it. Even as a file management protocol, though, FTP sucks. Its connection management is primitive in the extreme - one TCP connection per transfer - and that ruins performance for transfers involving many files, and is difficult to pass through firewalls and load balancers. FTPS encryption is an afterthought, and makes small-file performance even worse (as each connection requires separate TLS negotiation). There's no standard format for directory listings, just ad-hoc parsing of "ls -l" output. Support for modern filesystem features like extended attributes is largely nonexistent. Need I continue? :)
- chuckadams 22d ago
  The strange way FTP manages connections goes back to FTP being older than TCP/IP itself, and thus using older circuit-switched networks. It wouldn't have been unusual for a server to dial up the receiving machine on-demand, which didn't have to be the machine running the command session. Before SMTP came around, email was commonly implemented on top of FTP.
  - inigyou 22d ago
    FTP was written for an early version of TCP/IP (which wasn't called that). Maybe you're thinking of UUCP, which did often run over dial-up circuits and was used for email, but didn't require two connections.
    - chuckadams 22d ago
      No, I was thinking of FTP, but I was probably off the mark anyway: I'd noticed that FTP was mentioned in the RFCs and surrounding discussions long before RFC 793, and that it seemed to be behaving like a point-to-point network, but it hadn't occurred to me that it might have just been using an ancestor of TCP/IP -- some variant of the "Host protocol" perhaps? Hard to get the full context, it was before my time: my beard may be grey now, but I'm not that old.
      - inigyou 21d ago
        The original version of TCP/IP was (is currently thought to have been) called Network Control Program/Protocol or NCP. There's a reason current legacy IP is version number 4.
inigyou 22d ago
Yes, in every way except that servers and clients normally support upload while HTTP ones don't. This is the main reason to use it. But you should use SFTP instead. This is SSH's replacement for FTP. It's not the same as FTPS which is useless. We don't have to keep old protocols that offer nothing alive. Maybe a couple of clients and servers to demonstrate with, but it's a museum piece, not useful code. That's not an insult - museums are important. But we don't run Network Control Protocol (IPv1) on the internet, either.
- grumbel 22d ago
  [dead]

duskwuff 22d ago

> Is FTP really worse HTTP? I don't think I'd even call it that. FTP had one purpose: it was an early protocol for remotely managing files. It never had any intent to support dynamically generated or otherwise "virtual" content (as supported by e.g. CGI scripts and mod_rewrite in Apache), and I don't think anyone has ever made a serious attempt to implement that. There's no practical use case for it. Even as a file management protocol, though, FTP sucks. Its connection management is primitive in the extreme - one TCP connection per transfer - and that ruins performance for transfers involving many files, and is difficult to pass through firewalls and load balancers. FTPS encryption is an afterthought, and makes small-file performance even worse (as each connection requires separate TLS negotiation). There's no standard format for directory listings, just ad-hoc parsing of "ls -l" output. Support for modern filesystem features like extended attributes is largely nonexistent. Need I continue? :)

chuckadams 22d ago
The strange way FTP manages connections goes back to FTP being older than TCP/IP itself, and thus using older circuit-switched networks. It wouldn't have been unusual for a server to dial up the receiving machine on-demand, which didn't have to be the machine running the command session. Before SMTP came around, email was commonly implemented on top of FTP.
- inigyou 22d ago
  FTP was written for an early version of TCP/IP (which wasn't called that). Maybe you're thinking of UUCP, which did often run over dial-up circuits and was used for email, but didn't require two connections.
  - chuckadams 22d ago
    No, I was thinking of FTP, but I was probably off the mark anyway: I'd noticed that FTP was mentioned in the RFCs and surrounding discussions long before RFC 793, and that it seemed to be behaving like a point-to-point network, but it hadn't occurred to me that it might have just been using an ancestor of TCP/IP -- some variant of the "Host protocol" perhaps? Hard to get the full context, it was before my time: my beard may be grey now, but I'm not that old.
    - inigyou 21d ago
      The original version of TCP/IP was (is currently thought to have been) called Network Control Program/Protocol or NCP. There's a reason current legacy IP is version number 4.

inigyou 22d ago

Yes, in every way except that servers and clients normally support upload while HTTP ones don't. This is the main reason to use it. But you should use SFTP instead. This is SSH's replacement for FTP. It's not the same as FTPS which is useless. We don't have to keep old protocols that offer nothing alive. Maybe a couple of clients and servers to demonstrate with, but it's a museum piece, not useful code. That's not an insult - museums are important. But we don't run Network Control Protocol (IPv1) on the internet, either.

grumbel 22d ago
[dead]