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

51–60 of 119 posts

Re: FTP Must Die

#51

Post by thristian »

eli wrote: post #16
thristian wrote: post #9

It's been a long time since I've been involved with transferring files to and from clients, but even five years or so ago I recall enabling IIS's WebDAV mode in preference to handling customer-support calls about getting FTP working. Of course, WebDAV is still a ball of horror, even if it's not as bad as FTP, so please let's all stick to SFTP from now on?

So you had XP boxes connecting via WebDAV? I think I'd take FTP over having to support that.

Indeed. It worked pretty well, actually - in the standard Windows Explorer 'mount network drive' dialog, you could type an HTTP URL and get an ordinary-looking Explorer window and drag files to and fro.

Re: FTP Must Die

#52

Post by toyg »

soult wrote: post #45
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…

SSH is a pain to secure properly, and the potential for mischief is huge. There is no sudo in FTP.

Re: FTP Must Die

#53

Post by vacri »

ecaron wrote: post #15
wollw wrote: post #10

Earlier quoted context omitted.

Have you tried using SCP? I don't know if Windows comes with a client but a quick search turned up a few options. It is my goto method for transferring files these days but I admittedly don't use Windows.

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.

scp is very slow, but not sure how slow in comparison to the other two. Copying lots of data between servers on your own network, it's much faster to tar/netcat between the two than scp.

It's slow enough that someone has made 'high performance ssh/scp': http://www.psc.edu/networking/projects/hpn-ssh/

Re: FTP Must Die

#54

Post by sjwright »

Surely the best answer is for the HTTP 2.0 working group to require the updated protocol to include useful hooks for file-serving scenarios.

Critically, there's only a few missing things in my estimation, and they revolve around resumable uploading and structured directory listings for GUI clients.

Re: FTP Must Die

#55

Post by sjwright »

pygorex wrote: post #8

FTP is like religion: poorly designed at inception, implemented a thousand different ways and accepted as normal only because it's ubiquitous.

Except unlike religion, FTP began with a legitimate use-case scenario.

Re: FTP Must Die

#56

Post by Hemospectrum »

toyg wrote: post #52
soult wrote: post #45

Earlier quoted context omitted.

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…

SSH is a pain to secure properly, and the potential for mischief is huge. There is no sudo in FTP.

It's straightforward to permit SSH access but not shell logins.... if you can administer user and group settings. I guess stuff like scponly (http://freecode.com/projects/scponly) is useless if you're running Windows server-side.

Re: FTP Must Die

#57

Post by sjwright »

toyg wrote: post #35
evmar wrote: post #4

You might be amused to browse Chrome's implementation of FTP, which has separate modules for each of the different types of FTP servers you might encounter, as each emits the "ls -l" output in a different way and that is (I guess) the only way to get file sizes. http://git.chromium.org/gitweb/?p=chromium.git;a=tree;f=net/... see all the "directory listing" files. The unit tests are full of scary cases like // Tests f…

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.

Re: FTP Must Die

#58

Post by jff »

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…

9P does a lot of these. It's just not very fast over high-latency links. On the other hand, it's extremely simple, can be easily encrypted, and does only filesystem operations. Oh, and there are clients and servers for all the major platforms and libraries for a lot of popular languages.

Re: FTP Must Die

#59

Post by jff »

lubutu wrote: post #38
jbarham wrote: post #31

Plan 9's 9P is a nice file protocol: http://plan9.bell-labs.com/sys/man/5/INDEX.html . A client implementation has been available for Linux since version 2.6 ( http://cm.bell-labs.com/wiki/plan9/v9fs/index.html ).

Unfortunately 9P2000 tends to perform badly over high latency connections. There was talk of writing a new version that would allow clients to group certain messages, but nothing ever came of it. Edit: I just found a very recent paper on Improving the performance of Styx based services over high latency links (Styx being the Inferno name for 9P): http://gsyc.es/tr-docs/RoSaC-2011-2.pdf

Ah, yes, that would be the work on Op, which IIRC can act as a sort of proxy, meaning you shouldn't have to re-write any clients or servers. There is also an experimental implementation of 9P "streams", which actually resemble a passive FTP transfer--a separate TCP connection is negotiated via the 9P connection and then used solely to transfer file data.

Re: FTP Must Die

#60

Post by dchest »

toyg wrote: post #35
evmar wrote: post #4

You might be amused to browse Chrome's implementation of FTP, which has separate modules for each of the different types of FTP servers you might encounter, as each emits the "ls -l" output in a different way and that is (I guess) the only way to get file sizes. http://git.chromium.org/gitweb/?p=chromium.git;a=tree;f=net/... see all the "directory listing" files. The unit tests are full of scary cases like // Tests f…

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

The comment says "Russian" because they really test the month name in Russian: "23 май 2011".

  -rwxrwxr-x 1 ftp ftp 123 23 \xd0\xbc\xd0\xb0\xd0\xb9 2011 test
The note about day, month order is useful because all other tests have "%b %e" format and rows are full of other numbers:

  drwxr-xr-x1732 266      111        90112 Jun 21  2001 .rda_2
http://git.chromium.org/gitweb/?p=chromium.git;a=blob;f=net/...
Post reply on HN