Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FTP Must Die

mywiki.wooledge.org

Post reply on HN
Print view View original

41–50 of 119 posts

Re: FTP Must Die

#41

Post by tptacek »

alecco wrote: post #39
tptacek wrote: post #13

Earlier quoted context omitted.

Browsers are terrible at file upload. The weakness here isn't really in the protocol.

That's why I said browsers. But only recently with HTML5 XHR file uploads we could have progress and status reported in-page (instead of poorly in the status bar, if any). And it's still not good enough and definitely not widely available.

But the choice isn't between "browsers doing FTP" and "browsers doing HTTP"; it's between special-purpose FTP software and (somewhat hypothetical, if you exclude Transmit) special-purpose HTTP software.

Re: FTP Must Die

#42

Post by tptacek »

justincormack wrote: post #32
tptacek wrote: post #12

Earlier quoted context omitted.

PASV mode came with its own security drama, and doesn't address the core issue with the (absolutely pointless) multiple-connection model of FTP. And so, yes, firewalls and NATs "interact" with FTP --- because they all had to be hacked specifically to deal with the FTP protocol, which moots your rebuttal --- but in doing so they create additional security issues, like the NAT pinning stuff Samy Kamkar posted last year…

Have used tftp for net booting, those legacy bioses cant do anything else, as it really is trivial...

Has there been a piece of equipment shipped in the last 10 years that legitimately couldn't get a TCP running to bootstrap itself? That's why TFTP exists: to avoid the need for TCP.

Re: FTP Must Die

#43

Post by axiak »

alecco wrote: post #39
tptacek wrote: post #13

Earlier quoted context omitted.

Browsers are terrible at file upload. The weakness here isn't really in the protocol.

That's why I said browsers. But only recently with HTML5 XHR file uploads we could have progress and status reported in-page (instead of poorly in the status bar, if any). And it's still not good enough and definitely not widely available.

Huh? As long as you have XHR and JS, you can do file upload progress bars. Gmail has been doing it for years, and I've certainly had implementations going back to 2007.

Now, if the upload is failed for whatever reason (i.e. the file is rejected in-progress), then the upload failure mode is terrible unless you resort to the usual iframe hackery (Connection Reset screen).

HTML5 XHR file upload is certainly a cleaner solution and something everybody has wanted, but it's certainly not needed for progress and status reported in-page without flash.

Re: FTP Must Die

#44

Post by hackermom »

wollw wrote: post #25
ecaron wrote: post #15

Earlier quoted context omitted.

I'd love to know the transfer speed differences between SCP, SFTP and FTP - because when I can view both ends of the wire then security is less of a concern than transfer time.

I just tested ftp and scp between my laptop and server over wireless and got about 2.5MB/s on both.

I can happily report to you that your 11g wifi link's data throughput is fully saturated. Achievement unlocked!

Re: FTP Must Die

#45

Post by soult »

toyg wrote: post #40

So, what would it be a modern drop-in replacement for FTP? Requirements: * It should only deal with filesystem operations (i.e. SSH is way too problematic). * It should be firewall-, NAT-, proxy- and browser-friendly. * It should have cross-platform servers and clients, fully operational via CLI as well as GUI. * it should be secure (i.e. no http, thanks; https, maybe.) I'd say it's potential startup territory, excep…

I don't see why you disqualify SSH here. If you want a system that only deals with filesystem operations, I suggest NFS. It is neither firewall-, NAT-, proxy- or browser-friendly, is not cross-platform (Windows support only if you pay extra) and is neither encrypted nor authenticated. But hey, it deals with filesystem operations only.

If, on the other hand, you want a system that meets your last 3 requirements, just use SSH/SFTP.

Re: FTP Must Die

#46

Post by kenrik »

This should not be "FTP must die" but rather "someone needs to make a really nice GUI for rsync"

I use rbsync to backup to S3 and it really works great but was a pain to setup as it's command line only.

Re: FTP Must Die

#47

Post by alecco »

axiak wrote: post #43
alecco wrote: post #39

Earlier quoted context omitted.

That's why I said browsers. But only recently with HTML5 XHR file uploads we could have progress and status reported in-page (instead of poorly in the status bar, if any). And it's still not good enough and definitely not widely available.

Huh? As long as you have XHR and JS, you can do file upload progress bars. Gmail has been doing it for years, and I've certainly had implementations going back to 2007. Now, if the upload is failed for whatever reason (i.e. the file is rejected in-progress), then the upload failure mode is terrible unless you resort to the usual iframe hackery (Connection Reset screen). HTML5 XHR file upload is certainly a cleaner so…

OK.

Small nitpick, Gmail used a Flash uploader for many years, at least until 2009:

http://ajaxian.com/archives/multi-file-upload-in-the-flickr-...

Re: FTP Must Die

#48

Post by _ea1k »

moe wrote: post #30
peter_l_downs wrote: post #26

Earlier quoted context omitted.

cleaver and sehugg have both mentioned rsync, which I also think is a viable alternative. If possible, I try to use scp - is there any reason neither of these are viable alternatives? The only reason I ever use ftp is because I'm forced to with my godaddy hosting.

For many use-cases rsync and scp are not adequate. For example neither can provide a file-listing or interactively walk a tree, which is essential for a wide range of push-based or fileserver-style applications.

rsync can provide file-listings:

jsight@jsight-ubuntudesktop:~$ rsync localhost:/home/jsight/hackernews/ drwxrwxr-x 4096 2012/01/29 20:02:48 . -rw-rw-r-- 0 2012/01/29 20:02:36 tmp1 -rw-rw-r-- 0 2012/01/29 20:02:38 tmp2 -rw-rw-r-- 0 2012/01/29 20:02:39 tmp3 -rw-rw-r-- 11 2012/01/29 20:02:45 tmp4 -rw-rw-r-- 11 2012/01/29 20:02:46 tmp5 -rw-rw-r-- 11 2012/01/29 20:02:48 tmp6

Re: FTP Must Die

#49

Post by moe »

_ea1k wrote: post #48
moe wrote: post #30

Earlier quoted context omitted.

For many use-cases rsync and scp are not adequate. For example neither can provide a file-listing or interactively walk a tree, which is essential for a wide range of push-based or fileserver-style applications.

rsync can provide file-listings: jsight@jsight-ubuntudesktop:~$ rsync localhost:/home/jsight/hackernews/ drwxrwxr-x 4096 2012/01/29 20:02:48 . -rw-rw-r-- 0 2012/01/29 20:02:36 tmp1 -rw-rw-r-- 0 2012/01/29 20:02:38 tmp2 -rw-rw-r-- 0 2012/01/29 20:02:39 tmp3 -rw-rw-r-- 11 2012/01/29 20:02:45 tmp4 -rw-rw-r-- 11 2012/01/29 20:02:46 tmp5 -rw-rw-r-- 11 2012/01/29 20:02:48 tmp6

Thanks! That was new to me.

Still, can it also serve as an interactive shell with mkdir, rename etc.? An rsync-based ftp-clone would indeed be my favorite for a replacement.

Re: FTP Must Die

#50

Post by thristian »

MatthewPhillips wrote: post #34
astrodust wrote: post #20

Earlier quoted context omitted.

FTP is as obsolete as telnet and has no place being alive today. SSH and SCP provide a much more secure alternative. SFTP is a hack that suffers from all the same problems.

FTP is platform agnostic. As uncool as it may be it's the only realistic choice for companies to share sensitive data.

I work for a company that processes sensitive data, and almost all our interactions with clients and suppliers are over SFTP, which is more than platform-agnostic enough.
Post reply on HN