4 ms·

FTP is still valid for larger files - mainly in the printing industry where job uploads could easily be multiple hundreds of MBs, some now use 3rd party documen

FTP is still valid for larger files - mainly in the printing industry where job uploads could easily be multiple hundreds of MBs, some now use 3rd party document transfer sites but most still rely on FTP (usually with a password access)

AndrewDucker 9y ago
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 !
awestroke 9y ago
You did not mention any advantage with using FTP over any other file transfer protocol. "Multiple hundreds of MBs" is not much by todays standards, and FTP is not especially suited to transferring large amounts of data. Literally any other file transfer protocol is better. Like sftp or https.
- robk 9y ago
  That's exactly it - the advantage is people don't want to change and it's taken them years to get used to whatever ftp client they've been given or trained on
  - smacktoward 9y ago
    Every competent FTP client I can think of can also handle SFTP and FTPS connections. With SFTP it's just a matter of telling the client that's what you're using so it can change to the different port; with FTPS you don't even have to do that. It's true that people resist change, but the change they have to swallow here is so tiny and the upside so massive that it's darn close to malpractice to continue giving them the option to use plaintext FTP.
    - victorNicollet 9y ago
      I once had trouble with a client who used his business data solution for uploading data to our server (we support FTP, FTPS and SFTP, and we recommend SFTP + keys). It was an old java-based application with no updates, no SFTP support, and all attempts at FTPS failed in the face of certificate issues (outdated list of CAs, no ability to force a certificate). The client had no understanding of the issue and the technician was an expert for this specific business application, with no ability (or willingness, maybe) to write any sort of script or workaround outside that application.
    - Touche 9y ago
      I think a lot of the problems we have with new protocols is that we simply can't add new ports. So many routers simply block anything that's not 80, 443, or 21.
mbell 9y ago
I don't see why FTP is any more valid than HTTP for this. Uploading from the browser directly to S3 isn't difficult. You can support resume and whatever auth strategy you want as your backend generates the signing key.
- victorNicollet 9y ago
  We do this (well, with Azure Blob Storage instead of S3, but it's the same). It works because we can have our customer execute[#] some code that authenticates them, queries our server for the signature, then slices up the file and uploads it, then notifies our server when it's done. [#] including JavaScript in the page. Obviously, turning that into an automated process that runs from a Windows Scheduled Task (or worse) is not as easy.
agumonkey 9y ago
~10 years ago, a huge client came to our huge company to ask for some sort of stuff to manage synchronization over FTP. I was stumped. Very sensitive data. Not even rsync ..
IgorPartola 9y ago
s/FTP/rsync/
- Piskvorrr 9y ago
  Delta transfers? Multiple freshness checking methods? Multiple transport protocols? Built in checksumming? This is not your grandfather's rsync, mind you - the protocol is at version 30, IIRC. (As opposed to FTP which has made zero progress in the last two decades) Now, I'm not pretending it's a universal tool (there are far more efficient protocols for e.g. file distribution), but at one way synchronization tasks, it excels.
creatonez 9y ago
This is unrelated but I would really love ipfs to be adopted for use cases like these.
err4nt 9y ago
I have definitely worked in this world - I feel like the right replacement for FTP for sending large assets around would be to host them in an S3 bucket, sooner than use web-based services where you add files to your account and share them out with somebody. I know Dropbox and Google Drive are commonly used for this, but isn't it more of a hassle than S3?

AndrewDucker 9y ago

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 !

awestroke 9y ago

You did not mention any advantage with using FTP over any other file transfer protocol. "Multiple hundreds of MBs" is not much by todays standards, and FTP is not especially suited to transferring large amounts of data. Literally any other file transfer protocol is better. Like sftp or https.

robk 9y ago
That's exactly it - the advantage is people don't want to change and it's taken them years to get used to whatever ftp client they've been given or trained on
- smacktoward 9y ago
  Every competent FTP client I can think of can also handle SFTP and FTPS connections. With SFTP it's just a matter of telling the client that's what you're using so it can change to the different port; with FTPS you don't even have to do that. It's true that people resist change, but the change they have to swallow here is so tiny and the upside so massive that it's darn close to malpractice to continue giving them the option to use plaintext FTP.
  - victorNicollet 9y ago
    I once had trouble with a client who used his business data solution for uploading data to our server (we support FTP, FTPS and SFTP, and we recommend SFTP + keys). It was an old java-based application with no updates, no SFTP support, and all attempts at FTPS failed in the face of certificate issues (outdated list of CAs, no ability to force a certificate). The client had no understanding of the issue and the technician was an expert for this specific business application, with no ability (or willingness, maybe) to write any sort of script or workaround outside that application.
  - Touche 9y ago
    I think a lot of the problems we have with new protocols is that we simply can't add new ports. So many routers simply block anything that's not 80, 443, or 21.

mbell 9y ago

I don't see why FTP is any more valid than HTTP for this. Uploading from the browser directly to S3 isn't difficult. You can support resume and whatever auth strategy you want as your backend generates the signing key.

victorNicollet 9y ago
We do this (well, with Azure Blob Storage instead of S3, but it's the same). It works because we can have our customer execute[#] some code that authenticates them, queries our server for the signature, then slices up the file and uploads it, then notifies our server when it's done. [#] including JavaScript in the page. Obviously, turning that into an automated process that runs from a Windows Scheduled Task (or worse) is not as easy.

agumonkey 9y ago

~10 years ago, a huge client came to our huge company to ask for some sort of stuff to manage synchronization over FTP. I was stumped. Very sensitive data. Not even rsync ..

IgorPartola 9y ago

s/FTP/rsync/

Piskvorrr 9y ago
Delta transfers? Multiple freshness checking methods? Multiple transport protocols? Built in checksumming? This is not your grandfather's rsync, mind you - the protocol is at version 30, IIRC. (As opposed to FTP which has made zero progress in the last two decades) Now, I'm not pretending it's a universal tool (there are far more efficient protocols for e.g. file distribution), but at one way synchronization tasks, it excels.

creatonez 9y ago

This is unrelated but I would really love ipfs to be adopted for use cases like these.

err4nt 9y ago

I have definitely worked in this world - I feel like the right replacement for FTP for sending large assets around would be to host them in an S3 bucket, sooner than use web-based services where you add files to your account and share them out with somebody. I know Dropbox and Google Drive are commonly used for this, but isn't it more of a hassle than S3?