5 ms·

Why do we need a separate legacy protocol for file transfers? What’s the benefit in keeping protocols for the sake of it?

im3w1l 7y ago
We need a protocol for file transfers because having a protocol makes it more standardized and interoperable than if everyone rolls their own solution. Do we need browser support for it? It still happens now and then that a link will have an ftp target. That could be handled in the browser or it could open a separate url-handling application, as e.g. email or magnet urls do.
- anyfoo 7y ago
  Yes, but as someone who's been around when FTP was a big thing, and HTTP only just came into fruition... what, really, is the benefit of FTP? In fact, FTP is actually a horrible protocol, that caused me much pain even back then: It uses separate "command" and "data" channels. The data channel is usually in the other direction, i.e. the client listens to a connection from the server when downloading a file. Passive mode, and an extra command for that, had to be implemented, and if the stars don't align right, it still ends up being a pain. FTP also used to default to 7bit. If you did not explicitly switch to 8bit mode, you got corrupted downloads. This maybe made sense in a world with fundamentally different encodings, line endings, and where connection speeds were slow enough that downloading text files was a big task, but now? Then, if I remember correctly, the file listing you got was not actually standardized, it could just be the output of the "ls" command on the server! FTP clients used to be dumb and just passed that output through to you, so it did not matter much. For smarter clients later, it did start to matter. Finally, what does FTP actually offer that, in most cases, HTTP, and, in niche cases, rsync, scp or sftp do not offer?
  - viraptor 7y ago
    > It uses separate "command" and "data" channels This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.
    - anyfoo 7y ago
      Yes. Just like the text conversion thing, or the non-standardizes file listing thing (not everything was UNIX-ish, VMS was still around), at the time it made sense. Today it's just clunky hindrances, and the protocol has lost its benefits.
    - ZWoz 7y ago
      I would argue, that separate control/data channels makes protocol more secure. You can't sneak commands on data and you don't need worry, how do terminate data transmission and switch back to control mode.
big_chungus 7y ago
FTP is basically useful as a single-use protocol: file transfer only. File transfer only allows a more stripped-down, dedicated server with better security. Vsftpd and others have excellent security specifically tailored to permission-based file transfers with access control lists etc. You will rarely find a comparable http option. It's not perfect, but there are also good partes and reasons why it's still around. Secure FTP is still a good option for some cases.
- anyfoo 7y ago
  As written in another comment, you will find FTP to actually be a truly horrendous protocol, at least from today's perspective. I'm not sure there is anything that FTP offers, that the rsync or sftp, for example, offer much better (or simply HTTP if it's only in one direction), and then some. SFTP is actually not just FTP over SSH. The protocol is different precisely to get rid of a lot of the outdated nuisances.
  - takeda 7y ago
    FTP became a nightmare to use thanks to introduction of NAT, it was developed before NAT existed so it wasn't designed with it in mind. As for rsync, sftp, scp those are heavily tied to ssh, rsync to the point that you actually ssh to host and call rsync command. rsync has a server mode as well, but almost no one uses it.
  - big_chungus 7y ago
    Yes, there are lots of issues with FTP. I've worked with it, and it is in many ways a nightmare. That aside, you can use FTP for auth and ACL in of which HTTP and rsync just aren't capable. I'm not sure this is a flaw in the core protocol so much as the tooling, but there you have it. FTP config syntax may often be byzantine. But it's widely supported (especially on old, low-spec, or embedded devices). For newer stuff, yeah sftp is probably better. But it's still got its uses.
    - georgebarnett 7y ago
      Completely agree it still has its uses. So does Cobol and any number of older legacy tooling. That’s not the point we are discussing though; This is specifically regarding Chromium supporting FTP.
lazylizard 7y ago
Ftp is fast
- georgebarnett 7y ago
  Genuinely curious. Why do you think a bitstream from an FTP server is faster than from a HTTP server?
  - ZWoz 7y ago
    Whole solution and experience is different, even if some point uploading file by bytes over TCP is similar. HTTP server itself isn't solution. You need code implementing upload functionality, probably support for uploading many files at once and tracking progress. Now you client uses javascript and that client is remote, you need to "download" it from HTTP server. FTP client is small, local and don't have much overhead, HTTP with its stateless form needs headers retransmitted with every request.
    - georgebarnett 7y ago
      That’s all well and good, and has nothing to do with Chromium keeping ftp support.
      - ZWoz 7y ago
        Indeed, but your question wasn't about Chromium ftp support. Note, I am not lazylizard, so I don't really know, what he meant by "Ftp is fast", but I have my own thoughs and general dislike to webify everything on internet.
layoutIfNeeded 7y ago
How would you download a folder of files via HTTP? I don’t want to wait 10 minutes for the server to zip them, thank you.

im3w1l 7y ago

We need a protocol for file transfers because having a protocol makes it more standardized and interoperable than if everyone rolls their own solution. Do we need browser support for it? It still happens now and then that a link will have an ftp target. That could be handled in the browser or it could open a separate url-handling application, as e.g. email or magnet urls do.

anyfoo 7y ago
Yes, but as someone who's been around when FTP was a big thing, and HTTP only just came into fruition... what, really, is the benefit of FTP? In fact, FTP is actually a horrible protocol, that caused me much pain even back then: It uses separate "command" and "data" channels. The data channel is usually in the other direction, i.e. the client listens to a connection from the server when downloading a file. Passive mode, and an extra command for that, had to be implemented, and if the stars don't align right, it still ends up being a pain. FTP also used to default to 7bit. If you did not explicitly switch to 8bit mode, you got corrupted downloads. This maybe made sense in a world with fundamentally different encodings, line endings, and where connection speeds were slow enough that downloading text files was a big task, but now? Then, if I remember correctly, the file listing you got was not actually standardized, it could just be the output of the "ls" command on the server! FTP clients used to be dumb and just passed that output through to you, so it did not matter much. For smarter clients later, it did start to matter. Finally, what does FTP actually offer that, in most cases, HTTP, and, in niche cases, rsync, scp or sftp do not offer?
- viraptor 7y ago
  > It uses separate "command" and "data" channels This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.
  - anyfoo 7y ago
    Yes. Just like the text conversion thing, or the non-standardizes file listing thing (not everything was UNIX-ish, VMS was still around), at the time it made sense. Today it's just clunky hindrances, and the protocol has lost its benefits.
  - ZWoz 7y ago
    I would argue, that separate control/data channels makes protocol more secure. You can't sneak commands on data and you don't need worry, how do terminate data transmission and switch back to control mode.

big_chungus 7y ago

FTP is basically useful as a single-use protocol: file transfer only. File transfer only allows a more stripped-down, dedicated server with better security. Vsftpd and others have excellent security specifically tailored to permission-based file transfers with access control lists etc. You will rarely find a comparable http option. It's not perfect, but there are also good partes and reasons why it's still around. Secure FTP is still a good option for some cases.

anyfoo 7y ago
As written in another comment, you will find FTP to actually be a truly horrendous protocol, at least from today's perspective. I'm not sure there is anything that FTP offers, that the rsync or sftp, for example, offer much better (or simply HTTP if it's only in one direction), and then some. SFTP is actually not just FTP over SSH. The protocol is different precisely to get rid of a lot of the outdated nuisances.
- takeda 7y ago
  FTP became a nightmare to use thanks to introduction of NAT, it was developed before NAT existed so it wasn't designed with it in mind. As for rsync, sftp, scp those are heavily tied to ssh, rsync to the point that you actually ssh to host and call rsync command. rsync has a server mode as well, but almost no one uses it.
- big_chungus 7y ago
  Yes, there are lots of issues with FTP. I've worked with it, and it is in many ways a nightmare. That aside, you can use FTP for auth and ACL in of which HTTP and rsync just aren't capable. I'm not sure this is a flaw in the core protocol so much as the tooling, but there you have it. FTP config syntax may often be byzantine. But it's widely supported (especially on old, low-spec, or embedded devices). For newer stuff, yeah sftp is probably better. But it's still got its uses.
  - georgebarnett 7y ago
    Completely agree it still has its uses. So does Cobol and any number of older legacy tooling. That’s not the point we are discussing though; This is specifically regarding Chromium supporting FTP.

lazylizard 7y ago

Ftp is fast

georgebarnett 7y ago
Genuinely curious. Why do you think a bitstream from an FTP server is faster than from a HTTP server?
- ZWoz 7y ago
  Whole solution and experience is different, even if some point uploading file by bytes over TCP is similar. HTTP server itself isn't solution. You need code implementing upload functionality, probably support for uploading many files at once and tracking progress. Now you client uses javascript and that client is remote, you need to "download" it from HTTP server. FTP client is small, local and don't have much overhead, HTTP with its stateless form needs headers retransmitted with every request.
  - georgebarnett 7y ago
    That’s all well and good, and has nothing to do with Chromium keeping ftp support.
    - ZWoz 7y ago
      Indeed, but your question wasn't about Chromium ftp support. Note, I am not lazylizard, so I don't really know, what he meant by "Ftp is fast", but I have my own thoughs and general dislike to webify everything on internet.

layoutIfNeeded 7y ago

How would you download a folder of files via HTTP? I don’t want to wait 10 minutes for the server to zip them, thank you.