4 ms·

Is it faster than HTTP?

Piskvorrr 9y ago
Nope (both are capable of saturating a line). Also, does it protect the data in transit? Nope (HTTPS does, rarely do I see plain HTTP any more). Does it have resume capabilities? Nope. Does it play well with NAT or proxies? Nope. Does it mangle data in transfer? Yes. The only thing that keeps FTP around is its ubiquity.
- eganist 9y ago
  Pedantic correction: > Does it have resume capabilities? Nope. See RFC 959, > RESTART (REST) > > The argument field represents the server marker at which > file transfer is to be restarted. This command does not > cause file transfer but skips over the file to the specified > data checkpoint. This command shall be immediately followed > by the appropriate FTP service command which shall cause > file transfer to resume. And it would seem the definition from the RFC isn't even what's commonly implemented anymore, per https://cr.yp.to/ftp/retr.html https://cr.yp.to/ftp/retr.html (ctrl/cmd+f "The REST verb" no quotes) Finally, if we're including HTTPS and comparing HTTP v FTP, why not include FTPS? https://en.wikipedia.org/wiki/FTPS https://en.wikipedia.org/wiki/FTPS (edit: probably because Chrome doesn't support it. Heh.)
  - mmahemoff 9y ago
    I remember the collective joy when ncftp [1] turned up as an alternative to the default ftp client, suddenly making it possible to resume FTP transfers. An important feature when you've initiated a large (several MB) file with a dialup modem but someone in the house needs to make a phone call. IIRC FTP clients throughout the '90s were actually more reliable than browsers at resuming downloads. 1. https://en.wikipedia.org/wiki/NcFTP https://en.wikipedia.org/wiki/NcFTP
    - fiddlerwoaroof 9y ago
      I've never had a good experience with browser resume: I generally copy the link and then use aria2/curl/wget to actually get the file
    - ryan-c 9y ago
      IIRC in the late 90's to early 2000's "download managers" that could reliably resume were fairly popular.
- ars 9y ago
  It's much harder to transfer entire directories with HTTP. You would need SFTP at least. But at least the setups that I've seen SFTP wants you to be a user on the remote server, while FTP is easier to have FTP only users (who are not actual users, they are just logins that are valid for FTP).
  - vetinari 9y ago
    It might be like shooting with cannon into sparrows, but FreeIPA can define policies, where you can say which service on which host or hostgroup is allowed to authenticate which user (or group). So you can have an user, which is defacto "on the remote server", but the only thing he can do is to login into specified sftp service. For smaller scales, it is surely possible to do something similar, without FreeIPA, only with PAM.
  - okasaki 9y ago
    How are separate FTP accounts better than UNIX accounts with the shell set to scponly?
mariuolo 9y ago
I think the only advantage is a slightly lower overhead.
- agumonkey 9y ago
  Articles mention the added complexity of FTP, having both control and data socket, randomized port, connection latency (N round trips vs 1 in HTTP IIRC).. That said HTTP has an aura of atomic resource download, while FTP comes with :drumroll: a file system access aura. I barely never upload anything in shell through HTTP. And before the era of HTML drag n drop, it wasn't in my mind to upload through a browser over HTTP either. That changed a bit though. Still my favorite thing to upload over the web is webtorrent. [1] https://whydoesitsuck.com/why-does-ftp-suck/ https://whydoesitsuck.com/why-does-ftp-suck/
- drdaeman 9y ago
  I believe it's higher. It's especially visible if transferring multiple smaller files, as each download requires a separate new connection (no data connection reuse). I'm not sure why WebDAV is less popular. It has its oddities and implementation issues but it's nowhere close to FTP weirdness. And AFAIK WebDAV support is either built-in or readily available to install in all mainstream OSes.
Pxtl 9y ago
Faster to develop, maybe. Every time I try to do bulk uploads of files over HTTP I deal with APIs that are aggressively developer-hostile at both ends - bad error messages, painful workflow, massive amounts of boilerplate, and missing features that you take for granted in an FTP client. Just because the technology is physically capable of doing it doesn't mean it's at all usable.
- victorNicollet 9y ago
  And rate-limiting !

Nope (both are capable of saturating a line). Also, does it protect the data in transit? Nope (HTTPS does, rarely do I see plain HTTP any more). Does it have resume capabilities? Nope. Does it play well with NAT or proxies? Nope. Does it mangle data in transfer? Yes. The only thing that keeps FTP around is its ubiquity.

eganist 9y ago
Pedantic correction: > Does it have resume capabilities? Nope. See RFC 959, > RESTART (REST) > > The argument field represents the server marker at which > file transfer is to be restarted. This command does not > cause file transfer but skips over the file to the specified > data checkpoint. This command shall be immediately followed > by the appropriate FTP service command which shall cause > file transfer to resume. And it would seem the definition from the RFC isn't even what's commonly implemented anymore, per https://cr.yp.to/ftp/retr.html https://cr.yp.to/ftp/retr.html (ctrl/cmd+f "The REST verb" no quotes) Finally, if we're including HTTPS and comparing HTTP v FTP, why not include FTPS? https://en.wikipedia.org/wiki/FTPS https://en.wikipedia.org/wiki/FTPS (edit: probably because Chrome doesn't support it. Heh.)
- mmahemoff 9y ago
  I remember the collective joy when ncftp [1] turned up as an alternative to the default ftp client, suddenly making it possible to resume FTP transfers. An important feature when you've initiated a large (several MB) file with a dialup modem but someone in the house needs to make a phone call. IIRC FTP clients throughout the '90s were actually more reliable than browsers at resuming downloads. 1. https://en.wikipedia.org/wiki/NcFTP https://en.wikipedia.org/wiki/NcFTP
  - fiddlerwoaroof 9y ago
    I've never had a good experience with browser resume: I generally copy the link and then use aria2/curl/wget to actually get the file
  - ryan-c 9y ago
    IIRC in the late 90's to early 2000's "download managers" that could reliably resume were fairly popular.
ars 9y ago
It's much harder to transfer entire directories with HTTP. You would need SFTP at least. But at least the setups that I've seen SFTP wants you to be a user on the remote server, while FTP is easier to have FTP only users (who are not actual users, they are just logins that are valid for FTP).
- vetinari 9y ago
  It might be like shooting with cannon into sparrows, but FreeIPA can define policies, where you can say which service on which host or hostgroup is allowed to authenticate which user (or group). So you can have an user, which is defacto "on the remote server", but the only thing he can do is to login into specified sftp service. For smaller scales, it is surely possible to do something similar, without FreeIPA, only with PAM.
- okasaki 9y ago
  How are separate FTP accounts better than UNIX accounts with the shell set to scponly?

mariuolo 9y ago

I think the only advantage is a slightly lower overhead.

agumonkey 9y ago
Articles mention the added complexity of FTP, having both control and data socket, randomized port, connection latency (N round trips vs 1 in HTTP IIRC).. That said HTTP has an aura of atomic resource download, while FTP comes with :drumroll: a file system access aura. I barely never upload anything in shell through HTTP. And before the era of HTML drag n drop, it wasn't in my mind to upload through a browser over HTTP either. That changed a bit though. Still my favorite thing to upload over the web is webtorrent. [1] https://whydoesitsuck.com/why-does-ftp-suck/ https://whydoesitsuck.com/why-does-ftp-suck/
drdaeman 9y ago
I believe it's higher. It's especially visible if transferring multiple smaller files, as each download requires a separate new connection (no data connection reuse). I'm not sure why WebDAV is less popular. It has its oddities and implementation issues but it's nowhere close to FTP weirdness. And AFAIK WebDAV support is either built-in or readily available to install in all mainstream OSes.

Pxtl 9y ago

Faster to develop, maybe. Every time I try to do bulk uploads of files over HTTP I deal with APIs that are aggressively developer-hostile at both ends - bad error messages, painful workflow, massive amounts of boilerplate, and missing features that you take for granted in an FTP client. Just because the technology is physically capable of doing it doesn't mean it's at all usable.

victorNicollet 9y ago
And rate-limiting !