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

71–80 of 119 posts

Re: FTP Must Die

#71

Post by sunchild »

reitzensteinm wrote: post #61
sjwright wrote: post #57

Earlier quoted context omitted.

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.

YMD is logical, because it puts the most significant number on the left. But both DMY and HMS are consistent in another way - the information is ordered from most to least important for every day access, from left to right. A vast majority of dates on advertising, tickets, timetables etc actually leave off the year, unless it's ambiguous. Similarly, one might say something like 'on the 4th', which implies 'the 4th of…

Absent any date-format-aware sort controller:

YMD will group results by year, then month, then day.

MDY will group results by month, then day, then year.

DMY will group results by day, then month, then year.

That's why all my filenames look like: YYYY_MM_DD_filename.suffix

Re: FTP Must Die

#72

Post by sjwright »

reitzensteinm wrote: post #61
sjwright wrote: post #57

Earlier quoted context omitted.

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.

YMD is logical, because it puts the most significant number on the left. But both DMY and HMS are consistent in another way - the information is ordered from most to least important for every day access, from left to right. A vast majority of dates on advertising, tickets, timetables etc actually leave off the year, unless it's ambiguous. Similarly, one might say something like 'on the 4th', which implies 'the 4th of…

[edited because I realized we're in violent agreement]

To me, MDY makes as much sense as writing pi as 14.3.159265

Re: FTP Must Die

#74

Post by mhansen »

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…

Uh, yeah, you needed flash. You can't read local files in javascript without the HTML5 file api. Reading the value of tags is forbidden in javascript. Try it.

Re: FTP Must Die

#75

Post by pilif »

sjwright wrote: post #54

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.

WebDAV was invented as a HTTP based way for accessing remote files. In general, support on the clientside is very good (built-in clients are in every major OS).

What hinders wide deployment is the server side: the most widely known implementation is mod_dav for apache and apache was never really made for a common use-case of FTP which is people using it with their unix account credentials for transmitting files.

If you have access to an OSX server, have a look at all the hoops they had to jump through to allow WebDAV with mod_dav and still do that in the context of the corresponding system user.

The other reason for FTP still being popular is legacy systems: over the years, I interfaced so many ERP systems for our product and usually, the only thing that customers can provide is good old FTP (or direct database access).

As this scenario doesn't involve unix accounts, I would love to use WebDAV for all the reasons outlined in te article, but body supports it on their end, despite it being around for 20 yars or so.

Re: FTP Must Die

#76

Post by reitzensteinm »

sjwright wrote: post #72
reitzensteinm wrote: post #61

Earlier quoted context omitted.

YMD is logical, because it puts the most significant number on the left. But both DMY and HMS are consistent in another way - the information is ordered from most to least important for every day access, from left to right. A vast majority of dates on advertising, tickets, timetables etc actually leave off the year, unless it's ambiguous. Similarly, one might say something like 'on the 4th', which implies 'the 4th of…

[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.

Re: FTP Must Die

#77

Post by pilif »

omh wrote: post #6

FTP is definitely outdated, and there are better uses in many circumstances. But I find some of these criticisms a bit odd. The client listening was largely solved by 'passive' mode, and just about every server and client supports this now. The firewall and NAT interaction is awkward, but most modern firewalls can deal with this automatically (as long as there's no SSL involved) And yes, the RFC is 20 years old. But…

While passive FTP solved the issue for the client, it totally breaks if the server is behind a NAT, so you are back to the firewall needing knowledge of the inner workings of the protocol.

having the two separate connections really is an anachronism which proves to be a big hassle or all parties.

And not even IPv6 will slve this one as a firewall still needs to know what port to let data through. And because the PORT command lists IP addresses, you can't even transparently run FTP over v6. It's one of te protocols where users need to have special protocol awareness beyond the length of the IP address.

Re: FTP Must Die

#79

Post by antoncohen »

hackermom wrote: post #27

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.

> Sadly the OpenSSH solution is over the top awkward when it comes to setting up chrooted access, but it works.

With OpenSSH it's pretty easy to setup users in a chroot, with no shell access. The hard part is if you want logging (to audit what they do), then you need to create a log device in their chroot, which adds complication, and you need OpenSSH 5.2+.

sshd_config:

  Subsystem       sftp    internal-sftp -l VERBOSE
  Match Group sftponly
          ChrootDirectory %h
          ForceCommand internal-sftp -f AUTH -l VERBOSE
Make user1 only be able to use SFTP:

  groupadd sftponly; usermod -a -G sftponly user1; usermod -s /sbin/nologin user1
If you actually want the "-l VERBOSE" logging to work you need to create ~user1/dev, then modify rsyslog.conf with:

  $AddUnixListenSocket /path/to/user1/home/dev/log

Re: FTP Must Die

#80

Post by Too »

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…

axiak is right, I've done this myself too. The server can read the file size during transfer and send this back to the client over XHR. It's quite messy to set up and most backend frameworks require obscure hacking (reflection in asp.net for example) to get it to work, but it certainly is possible.
Post reply on HN