Live data from Hacker News

FTP Must Die

mywiki.wooledge.org

81–90 of 119 posts

Re: FTP Must Die

#81
post #43
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…

XHR is awful for large file uploads. It doesn't support sending the file object (which presumably would be processed according to RFC1867) on Firefox, but it does support that on Chrome.

As a result, for cross-browser compatibility you have to upload via raw POST data and send your own file metadata headers. Not entirely a bad thing, but it's annoying because most HTTP servers don't support this. And because you cannot send the file object, you have to load the file into browser memory. No streaming options.

Thus, you have to make multiple request uploads that upload a chunk at a time to the server per request (spliced uploading), which is annoying and unnecessary.

To make matters worse, Chrome doesn't support XMLHttpRequest.sendAsBinary (WHY? you can easily implement this in javascript anyway), and a bunch of other random inconsistencies.

And no, PUT doesn't help.

Re: FTP Must Die

#82
FTP is dead. I haven't used the FTP protocol in years[1]… that's what we have SSH / SCP for.

[1]: Before you say that my anecdotal evidence does not a fact make, my point is that there's nothing forcing us to use FTP today. Even the lousiest web host supports SFTP, and none of my machines or VPSs run an FTP server. There's no reason to proclaim that we need to kill FTP, because FTP is a non-issue in today's world. Sure, you can still use it, the same way you can still use telnet if you'd like. But practically nothing relies on it with no alternative.

Re: FTP Must Die

#83

I think SFTP is an excellent alternative to FTP (as well as FTP over SSL/TLS). It's a whole lot safer than FTP and it solves the archaic annoyance of data ports. Sadly the OpenSSH solution is over the top awkward when it comes to setting up chrooted access, but it works. Introducing something entirely new at this point makes no sense - the situation isn't really as serious as some people want to make it out to be.

Maybe you missed the OpenSSH 4.9 release? http://www.openssh.com/txt/release-4.9

Since then, it is easy to setup a chroot'ed account which easily acts like an ftp server. Have a look at ChrootDirectory and the internal-sftp subsystem.

Re: FTP Must Die

#84
post #49
post #48

Earlier quoted context omitted.

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.

Maybe you should go with ssh if you need a secure ftp replacement: http://news.ycombinator.com/item?id=3526713

Re: FTP Must Die

#85

Earlier quoted context omitted.

[edited because I realized we're in violent agreement] To me, MDY makes as much sense as writing pi as 14.3.159265

I might be missing something, but that's not at all what I was arguing! MDY drives me nuts too.

It's more that different places use different versions that gets me. I have wrote a bunch of importers for sales an nearly all of them list the date time differently. Very few affiliate networks have used either a timestamp or the standards based datetime.

Re: FTP Must Die

#86
post #37

Earlier quoted context omitted.

How do you mean, SFTP is a hack that suffers from all the same problems? SFTP is a new protocol, it's not the same as FTP. It doesn't concern itself with data port nonsense, and while it doesn't offer authentication or secure transfers in itself, there is - at least to my knowledge - no SFTP solution available that doesn't perform SFTP via an underlying mechanism for secure auth/transfer.

I suspect the GP was referring to FTP over SSL, which is an ugly abomination with few redeeming features.

In this case that's FTPS (FTP over SSL), not SFTP (SSH File Transfer Protocol)

Re: FTP Must Die

#87
post #24

Sign me up, but where's the alternative? WebDAV is a trainwreck. SFTP could be nice but the OpenSSH impl falls terribly short as a FTPd replacement (the most useful implementation is ironically the one in ProFTPd). Sendfile never went anywhere. Network filesystems don't cut the FTP use-case either. People don't use FTP because they like it. They use it for the lack of a viable alternative.

> the OpenSSH impl falls terribly short as a FTPd replacement

any specific reason?

Re: FTP Must Die

#88
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.

The overhead of encryption is marginal and the advantage of being able to compress the stream is considerable. scp and rsync, which is a fantastic companion, allows on-the-fly compression of content to get truly impossible speeds over the wire.

It is marginal if you want to transfer a file from time to time but if you are in a business where you transfer thousands to millions of files everyday it makes a big difference. FTP is still used because its interface is simple and well-known: good old file-directory paradigm that everybody knows. It is also used because it runs on every platform. I am in favour of having a new protocol but it should: - be faster than FTP (would have to use UDP instead of TCP here). - Firewall friendly. For that, you could use one port to do everything and forget about the data connection (Is it feasible with UDP as you would need to control the flow ?) - Being FTP compliant from the interface point of view. You should be able to replace your ftp client with your fastTP protocol and everything would run. - Add optional strong security. Possibility to encrypt or not the data stream and encrypt the password negotiation.

If we have this and it is marketed well then it could replace FTP.

Re: FTP Must Die

#89
post #35

Earlier quoted context omitted.

That's actually the standard European order. Testing the Russian locale might be a scary proposition, but certainly not for this specific reason.

It's not just the standard European order, it's the standard order for nearly everywhere on the planet except: > MDY: Belize, USA, parts of Canada, Philippines, Saudi Arabia > YMD: Japan, China, Iran, small bits of Europe > DMY: Probably 3/4 of the planet's land surface That said, YMD should make the most sense (and is most consistent with the universally accepted HMS time format). I try to use YMD wherever I can.

Here's a nice stimulus bill for the US economy: mandatory switch from MDY to DMY. That should keep "a few" programmers busy for years! I'm not joking, that's how you move the economy: it's the digital equivalent of building a new bridge.

(It'd be more forward-thinking to actually switch to YMD, but I can imagine the reactions at the idea of aligning with Iran and China.)

Post reply on HN