×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

FTP: Better Than HTTP, Or Obsolete?

timothy posted more than 11 years ago | from the don-your-holy-vestments dept.

Software 1093

An anonymous reader asks "Looking to serve files for downloading (typically 1MB-6MB), I'm confused about whether I should provide an FTP server instead of / as well as HTTP. According to a rapid Google search, the experts say 1) HTTP is slower and less reliable than FTP and 2) HTTP is amateur and will make you look a wimp. But a) FTP is full of security holes. and b) FTP is a crumbling legacy protocol and will make you look a dinosaur. Surely some contradiction... Should I make the effort to implement FTP or take desperate steps to avoid it?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

1093 comments

Different, not better or wose (0, Redundant)

Anonymous Coward | more than 11 years ago | (#5297942)

They serve different purposes, and each was designed to meet those needs. Each one has its own positives and negatives.

WOW, THAT WAS FUCKING INSIGHTFUL (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5297964)

dumbass

Jealous? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5297994)

I know you are.

Re:Jealous? (0, Troll)

Anonymous Coward | more than 11 years ago | (#5298010)

But what am I?

Re:Jealous? (-1, Redundant)

Anonymous Coward | more than 11 years ago | (#5298026)

Jealous.

Wimp? (-1, Flamebait)

EvilJello (577315) | more than 11 years ago | (#5297949)

Because, as we all know, some internet protocols are more manly than others.

Re:Wimp? (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5297958)

IMAP is definately more manly than POP, and IMAP over SSL can kick both their asses.

Forget them both.... (3, Flamebait)

NinteyThree (256826) | more than 11 years ago | (#5297951)

...use sftp!

Re:Forget them both.... (4, Informative)

Karamchand (607798) | more than 11 years ago | (#5298059)

I guess that's not what s/he wants. It sounds like anonymous downloading of publicy available files - whatfor do we need any encryption then? There are no passwords to secure, no sensitive data to secure. You'd get only hassles from MSIE users who never heard about sftp..

Re:Forget them both.... (1)

Sunnan (466558) | more than 11 years ago | (#5298062)

Right. It's a lot more demanding on the server, though, and I don't know of a way to provide sftp-access without providing shell access - which opens up a whole can of worms.

hmm (5, Interesting)

nomadic (141991) | more than 11 years ago | (#5297955)

I haven't really noticed any reliability issues with http anymore. If it starts loading it usually finishes, and I haven't run into any corruption problems. Maybe if you were serving huge files ftp would be a good idea, but for 1-6 mb it's probably not worth it.

Re:hmm (3, Informative)

cbv (221379) | more than 11 years ago | (#5298077)

If it starts loading it usually finishes, and I haven't run into any corruption problems.

You may (just may) run into a routing or timeout problem, in which case the download will stop and you are forced to do the entire download again. Using the right client, eg. ncftp, you can continue downloading partially downloaded files. An option, HTTP doesn't offer.

With respect to the original question, I would set-up a box offering both, HTTP and FTP access.

what's the problem again? (0)

Anonymous Coward | more than 11 years ago | (#5297959)

so what's the problem with doing both? it's not hard to set up either one (or both)...ftp may be filled with security holes, but atleast it has some security. you can use ftps (ssl) or whatever also.

check out proftp

Both... (1)

Myuu (529245) | more than 11 years ago | (#5297960)

I think the best thing would be to proved both, true you still have the security risk, but everything has its risks.

Lots of companies have both, I cannot think of a reason of utmost importance to do otherwise (besides sec.)

Re:Both... (0)

Anonymous Coward | more than 11 years ago | (#5298037)

>true you still have the security risk, but everything has its risks.

That's one of the stupidest things I've read in a while.

So what you're saying is that we shouldn't base decisions on differing levels of risk?

I could shave with a safety razor or a chainsaw. They both still "have risks". I know which one I'd prefer if I was shaving your face.

Re:Both... (5, Insightful)

macrom (537566) | more than 11 years ago | (#5298038)

I cannot think of a reason of utmost importance to do otherwise

Many companies lock down their firewalls with a huge, gigantic virtual padlock -- ie, port 80 outgoing only. When I'm at work and want to download something from a site that offers FTP only, I'm screwed. Some companies will keep ports < 1024 or some other low number open, but many will not. This would be a driving reason to provide HTTP access to files.

Personally, anyone that calls you an amateur for using HTTP or a dinosaur for using FTP needs to get a life. Both protocols have their place in the modern internet; there's absolutely nothing wrong with serving files via either method other than security and the above mentioned concern. Do what you feel is easiest to maintain and simplest for your users.

Re:Both... (2, Funny)

KDan (90353) | more than 11 years ago | (#5298079)

Yeah, but come on... "files from 1-6Mb in size"... now what do you think he's serving here?

Would you download that on your work connection? Heh.

Daniel

ftp (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5297961)

FTP is a crumbling legacy protocol and will make you look a dinosaur.

What the hell are you talking about?

IANAL, CMdrTaCO (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5297962)

*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_
g_______________________________________________g_ _
o_/_____\_____________\____________/____\_______o_ _
a|_______|_____________\__________|______|______a_ _
t|_______`._____________|_________|_______:_____t_ _
s`________|_____________|________\|_______|_____s_ _
e_\_______|_/_______/__\\\___--___\\_______:____e_ _
x__\______\/____--~~__________~--__|_\_____|____x_ _
*___\______\_-~____________________~-_\____|____*_ _
g____\______\_________.--------.______\|___|____g_ _
o______\_____\______//_________(_(__>__\___|____o_ _
a_______\___.__C____)_________(_(____>__|__/____a_ _
t_______/\_|___C_____)/Insert\_(_____>__|_/_____t_ _
s______/_/\|___C_____)__Cock_|__(___>___/__\____s_ _
e_____|___(____C_____)\_Here_/__//__/_/_____\___e_ _
x_____|____\__|_____\\_________//_(__/_______|__x_ _
*____|_\____\____)___`----___--'_____________|__*_ _
g____|__\______________\_______/____________/_|_g_ _
o___|______________/____|_____|__\____________|_o_ _
a___|_____________|____/_______\__\___________|_a_ _
t___|__________/_/____|_________|__\___________|t_ _
s___|_________/_/______\__/\___/____|__________|s_ _
e__|_________/_/________|____|_______|_________|e_ _
x__|__________|_________|____|_______|_________|x_ _
*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_e_x_*_


Important Stuff: Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you want replies to your comments sent to you, consider logging in or creating an account.

Important Stuff: Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you want replies to your comments sent to you, consider logging in or creating an account.

Important Stuff: Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you want replies to your comments sent to you, consider logging in or creating an account.

I wouldn't worry about it... (2, Insightful)

$$$$$exyGal (638164) | more than 11 years ago | (#5297966)

Do whatever is more convenient for you. The differences are not that great.

--sex [slashdot.org]

Screw all of that! (4, Funny)

Anonymous Coward | more than 11 years ago | (#5297969)

Use telnet and screen capture the VT100 Term buffer!

In my opinion, (0)

Anonymous Coward | more than 11 years ago | (#5297970)

HTTP is the way to go, especially for larger files, because you can see the download rate and a better estimate of how much longer before the download is complete. The "HTTP is for wimps" mentality is for fools. You normally don't see the download rate when using FTP, unless you're using a special ftp GUI....which, could be argued, is for wimps.

do both... (4, Informative)

jeffy124 (453342) | more than 11 years ago | (#5297971)

But in my experiences, HTTP for whatever reason goes faster (not entirely sure why), and FTP doesnt work for some because of firewalls.

Try both - see which gets used more.

how about rsync? (5, Informative)

SurfTheWorld (162247) | more than 11 years ago | (#5297973)

rsync is a great protocol, fairly robust, can be wrappered in ssh (or not), supports resuming transmission, and operates over one socket.

seems like the best of both worlds to me.

the real question is - do you control the clients that are going to access you? or is it something like a browser (which doesn't support rsync).

My opinion (-1, Troll)

Slashdotess (605550) | more than 11 years ago | (#5297974)

Small files use HTTP, because they'll probably be able to get them quick, resuming, disconnection, extra protocol bandwidth wouldn't be a problem. But for large files use FTP as disconnections might occur for dial-up users, etc. The FTP servers that incorporate download-only policies (ie. just like HTTP) (I am sure they're are many) have little or no security holes compared to an feature-filled FTP server, that is used for uploading, moving, and downloading many files with many different logins.

Http/Ftp which is slower? (3, Informative)

emf (68407) | more than 11 years ago | (#5297975)

"HTTP is slower and less reliable than FTP"

I would think FTP is slower since with FTP you have to login and build the data connection before the transfer begins. With HTTP it's a simple GET request.

As far as the actual data being sent, I believe that the file is sent the same way with both protocols. (just send the data via a TCP connection). I could be wrong though.

FTP (1)

Blackbox42 (188299) | more than 11 years ago | (#5297976)

I'd implement FTP if your attempting to transfer large files. There are many excellent programs to resume FTP transfers yet I do not know of any such programs for HTTP transfers. Real Download might do it, but who in god's name would want to inflict that upon themselves.

Both (0)

Anonymous Coward | more than 11 years ago | (#5297977)

Granted I'm not an expert on the security flaws of either the HTTP or FTP protocols, but I can say that most commercial enterprises provide download services for both.

protocol (0)

Anonymous Coward | more than 11 years ago | (#5297978)

just dump passworded zips to usenet

well, what're you trying to do? (4, Insightful)

twiggy (104320) | more than 11 years ago | (#5297979)

As long as you're willing to secure your FTP server and do the simple stuff like watch out for file permissions - FTP is much better.

HTTP is restricted by browsers, many of which will not support files larger than a certain size. Furthermore, FTP allows for features such as resume, etc...

The real question, however, is what are you trying to use this for? What's your intended application?

If it's a file repository for moderately computer literate people - FTP is definitely the way to go.

If it's a place for average-joes to store pictures, maybe HTTP is your best option. Sacrificing a bit of speed and capabilities such as resume might be made up for with ease of use..

Re:well, what're you trying to do? (1)

ahknight (128958) | more than 11 years ago | (#5298042)

HTTP is restricted by browsers, many of which will not support files larger than a certain size.

What you say?! I've downloaded ISO images in IE and Chimera with no issues. Never heard of this.

Re:well, what're you trying to do? (5, Informative)

Fastolfe (1470) | more than 11 years ago | (#5298071)

Furthermore, FTP allows for features such as resume, etc...

So does HTTP. With the 'Range' header, you can retrieve only a portion of a resource.

I agree that it really depends on the application, but for most practical "view directory, download file" purposes, there's no significant difference.

If you wanted to interact with a directory structure, change ownerships, create directories, remove files, etc., it's generally easier to do this with FTP.

Use sshd (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5297982)

Its encrypted it is easy to get through firewalls, and it lets you run rsync (which lets you synchronise two machines automatically).

Ftp is a major pain for firewalls because unless you use it in passive mode it opens another port back after the initial connection.

IE (0)

Anonymous Coward | more than 11 years ago | (#5297985)

IE, especially 6, doesn't seem to handle FTP well, so if you expect Windows users, consider IE performance

Anecdotally, HTTP is more reliable (4, Insightful)

kisrael (134664) | more than 11 years ago | (#5297988)

Whenever I see a list of FTP mirrors with one HTTP version, the HTTP version is faster and more reliable 9 times out of 10.

It's generally simpler to get to from a browser, which is where 95% of people's online life is anyway. Yeah, you can rig up a FTP URL, but it seems a bit kludgey and more prone to firewall issues.

HTTP is faster (1, Interesting)

CAPSLOCK2000 (27149) | more than 11 years ago | (#5297990)

Actually, http is faster. FTP keeps open another connection to control the file transfer. This connection also uses bandwith, just a little bit, but enough to matter.

Any Delphi programmers? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5297991)

I'm having problems with converting infix notation to postfix notation.

I have tried creating a stack to store the operators in, and the operands are added to a string. However, I'm stuck with comparing the priorities of the operators among other things.

Any ideas?

Re:Any Delphi programmers? (0)

Anonymous Coward | more than 11 years ago | (#5298058)

No. Delphi is gay.

Re:Any Delphi programmers? (0)

Anonymous Coward | more than 11 years ago | (#5298072)

do your own homework, curry boy

go with http (0)

skelley (526008) | more than 11 years ago | (#5297993)

a) it is more easily secured

b) it is easier for people to use (ftp url's tend to confuse some people)

c) it seems like it is easier to overwhelm an ftp server with traffic than it is a webserver

your concern is not correct (-1)

TRoLLaXoR (181585) | more than 11 years ago | (#5297998)

while you care about how what protocol you choose will make you look to others (something sad in itself), you should be worry about what protocol will do the best job of allowing others to download 1-6MB files.

this is curely an example of slashdot's readership consisting of 13 year old fatherless geeks.

Don't let "Dinosaur" daunt you, .... (1)

dr-suess-fan (210327) | more than 11 years ago | (#5297999)

If the right tool for the job is efficient, let
them name-call all they want.

As far as I've seen, HTTP for FTP type operations
is still somewhat new. While FTP has it's firewall and security issues, It is still used a whole lot
more than HTTP IMHO.

If this is your first FTP application and you are already running HTTP alot, you might consider just
using HTTP. If you plan to do alot of FTP hosting, I would suggest cracking the FTP server books.

HTH.

Another option (0)

Anonymous Coward | more than 11 years ago | (#5298000)

what about gopher?

FTP (0)

Anonymous Coward | more than 11 years ago | (#5298002)

I'll be leaving my current DSL provider because they will be removing FTP from the standard services they provide. (SBC to SBC Yahoo!)

for what its worlth (3, Informative)

dunedan (529179) | more than 11 years ago | (#5298003)

Those of your customers who don't have fast access to the internet may appreciate even a slightly faster standard.

Idiots (0)

Anonymous Coward | more than 11 years ago | (#5298004)

HTTP is not "slower", "less reliable" or "amateur", and the people who say that are idiots. If it was "slower" or "less reliable", than why would web sites distribute graphics, or binary downloads, or banking information, or purchasing with it ???
FTP is outdated, but useful if you want the user to be able to navigate a directory structure with a simple command line client. I'm sure a lot of free software developers prefer FTP, at least ones who were on the net before HTTP was common. But it is brainless to say that HTTP is "less reliable" or any such bullshit. This web page came up for you, didn't it ???

Why isn't there SFTP support from the browser? (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5298005)

My god i wish there was! Every time i need it, i have to go look for putty, and download psftp. Maybe we should write a patch for mozilla?

FTP is the cat's pj's (2, Informative)

simetra (155655) | more than 11 years ago | (#5298006)

you can ftp files without having a GUI, Browser, etc. Though, you can use HTTP with Lynx, and I'm sure wget, snarf, etc. FTP is a good, reliable tool. It comes standard with most every operating system out there. It's fairly standard; the commands you use in one OS are pretty much the same in another OS.

FTP is the cat's pajamas. HTTP depends on too much other stuff.

ftp: going, going, but not gone (1, Informative)

cybermint (255744) | more than 11 years ago | (#5298008)

If you only providing files, with little or no uploading, then I would use http because it is generally easier for someone in a browser to just grab it off an http server. IE in particular has some problems when navigating in nested directories.

If you are providing a large number of files where people frequently download several files from the same directory, then ftp access would help as most ftp clients can queue multiple files for downloading.

If users are uploading and downloading multiple files, then ftp is still your best bet by far. No one wants to upload one file at a time via some html form.

HTTP is fine (4, Informative)

ahknight (128958) | more than 11 years ago | (#5298012)

HTTP does not have firewall issues, does not need authentication, does not (by default) allow directory listings, and is the same speed as FTP. It's a good deal for general file distrubution.

FTP is quickly becoming a special-needs protocol. If you need authentication, uploads, directory listings, accessability with interactive tools, etc. then this is for you. Mainly useful for web designers these days, IMO, since the site software packages can use the extra file metadata for synchronization. Other than that, it's a lot of connection overhead for a simple file.

FTP does have one nice advantage that HTTP lacks: it can limit concurrent connections based on access privleges (500 anonymous and 100 real, etc.). Doesn't sound like you need that.

Go with HTTP. Simple, quick, anonymous, generally foolproof.

Re:HTTP is fine (5, Informative)

Voytek (15888) | more than 11 years ago | (#5298068)

[SNIP]
does not (by default) allow directory listings
[SNIP]

That is a dangerous and very incorrect assumption which has nothing to do with http and everything to do with your http server.

Firewalls (0)

Anonymous Coward | more than 11 years ago | (#5298013)

HTTP file transfers are easier to get through corporate firewalls.

Looks??? (1)

TJ6581 (182825) | more than 11 years ago | (#5298015)

Last time I checked the best way to evaluate a technology was to see if it meets your needs in a secure fashion. Calling FTP a "Dinosaur" shows that you are only interested in being 3733t and not being really secure. If you really want to impress the script kiddies on IRC try something challenging like tunneling FTP through SSH or use something like SCP to transfer files.

Security is the only worry (2, Informative)

brokenin2 (103006) | more than 11 years ago | (#5298017)

If you're just looking to transfer files back and forth, then FTP is the way to go.. If you only want to send out files, you might want to stick with the warm fuzzy feeling by knowing you've only got apache exposed to the outside world.


We run ftp, but we have to have people send us files, and also distribute them on a regular basis.The client software available for doing the sending and receiving on a regular basis is a lot better for FTP.. it's pretty klunky, but it is very doable for http.


We just choose to stay on top of our ftp updates.

um ? (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5298018)

Why is this lame question on /. ?

Nothing on Linux in Autralia today ?

dumb questions (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5298019)

I am sick and tired of people using slashdot as a way to ask questions that a little bit of research would answer for themselves, if after that they wish to post a discussion paper then I would be glad to read their viewpoints but really asking the difference between FTP and HTTP is not slashworthy news.

Boy do I feel the pain... (5, Funny)

Anonvmous Coward (589068) | more than 11 years ago | (#5298020)

"HTTP is amateur and will make you look a wimp"

You really gotta watch out for things like this. I know one guy that got a 'click me' sign on his back because he used HTTP instead of FTP.

Why does it matter? (1)

Arctic Fox (105204) | more than 11 years ago | (#5298021)

I'm really surprised at this question. Those are small files. Serve them any way you want. If I were posting ISOs or something, it seems more "natural" to serve via FTP.
However, I'm sure you'll be serving them via a "Click to Download" link, which it doesn't matter. You click, the browser downloads. End of story.
I'm really interested in Missionary vs Doggy Style. Missionary is traditional, old-skool, and makes me feel dominant. However, doggy style gives me that porn star class that I crave in my lovemaking sessions, not to mention the hairpulling and ass-slapping possibilities. But you dont see me asking Slashdot. Even though it is "stuff that matters".

Eh, FTP (1)

rice_web (604109) | more than 11 years ago | (#5298023)

I personally loathe FTP, except the times that I need to connect to my file server--which it actually does quite well. I am running a Linux box that stores all of my music, my documents, and more, and I simply connect to that machine when I'm at work or elsewhere. So, just for this reason alone, FTP is excellent. In fact, it's actually saved me a few times, when I've noticed that I hadn't printed a document or finished a website, and I needed my files.

However, the security holes of FTP would prevent me from ever keeping FTP connections open on high-traffic websites. Yes, I maintain FTP accounts on my servers to allow updating the site, but no guest accounts are active (not that my server is magically "safe"), and the sites hardly receive an ounce of traffic.

Transparent (5, Insightful)

mao che minh (611166) | more than 11 years ago | (#5298024)

It's almost transparent - most people (99.9%) don't know the difference between http and ftp. The .1% that "gets it" don't care what you're using as long as the pr0n gets from point A to point B (point B being my computer, which I lovingly call "My Pr0ndex").

And I wouldn't care about the opinion of someone who would actually judge you over what friggin protocol you use to provide downloads. Such an utter nerd is somethig that I can not relate too. Maybe after I use Linux for a few more years, who knows.

What do you want to do? (5, Informative)

fwankypoo (58987) | more than 11 years ago | (#5298028)

The question is, "what do you want to do?" I run an FTP server (incidentally affiliated with etree.org, lossless live music!) and I need what it can give me. Namely I need multiple classes of login, each with a different

1) number of available slots
2) speed limit
3) premission set

Some people can only read files at 60KB/s, some can read and write (to the upload dir) at the same speed, come can only browse, etc. etc. For this kind of a setup, FTP is great _IF_ you keep your software up to date; subscribe to bugtraq or your distro's security bulletin or both.

On the other hand, HTTP is great when you want to give lots of people unlimited ANONYMOUS access to something. I'm sure there is a way to throttle bandwidth, but can you do it on a class by class basis? In proftpd it's a simple "RateReadBPS xxx" and I'm set.

As always, choose the tool that fits _your_ purpose, not the one that everyone says is "best"; they both have good and bad qualities. And http can be just as secure/insecure as any other protocol.

10/100BaseT specs. (0)

Anonymous Coward | more than 11 years ago | (#5298030)

If you want the real answer, it's ftp. All the way. Unless we're talking Gig-E. The specs for 10BaseT and 100BaseT will only allow protocols such as ftp to even get close the the supposed throughput.

I'm sure others can add details to this.

Who is Your Audience? (1)

dasheiff (261577) | more than 11 years ago | (#5298034)

Though I'm tempted to say for a less skilled downloading community you should use http and the reverse for ftp. But now I'm thinking that doesn't quite fit since one can always wget a http file (or ftp file for that matter) and one can use ftp though a web browser.

Eh, my vote is https, more secure, and maybe more manly since it's not port 80? Of course moving out a directory structure is more natural for me than to click on pretty little icons.

Therefore I conclude use ftp (or sftp) if you got users the like command prompts. Otherwise just go for the one whose logs are more fun for you to read.

SCP (5, Interesting)

elliotj (519297) | more than 11 years ago | (#5298035)

If you're only offering files to a group of users who you can give passwords to, you could even use SCP. (Secure copy...uses sshd on the server side)

It all depends on the application. I only use SCP to move files around if I have the choice, just because I like better security if I can have it.

But if you want to offer files to the public, I'd recommend offering both FTP and HTTP so people can use the most convenient.

HTTP/1.1 (0)

Anonymous Coward | more than 11 years ago | (#5298036)

I would consider an HTTP/1.1 server a better choice than an FTP server. HTTP works with firewalls better. It can support "resumable" downloads, by requesting byte ranges, although I'm not sure if there's a client that can do this for file transfers. I don't understand how it would be slower than FTP -- it's just a byte stream.

Of course, I can't "mget" files from a webserver using my "http" command-line client, but I can give multiple URLs to wget to accomplish the same thing.

500th's person to say it, I'm sure... (1)

morgajel (568462) | more than 11 years ago | (#5298043)

but use scp. SCP is part of the SSH suite.
as a matter of fact, I mention it in my beginners walkthrough of ssh [homelinux.net] on my website. I'd suggest checking it out if you got the time.

and yes, it's probably got incorrect information, but it's sole purpose is to teach my future father-in-law how to use ssh.

who's going to be downloading? (1)

Whitecloud (649593) | more than 11 years ago | (#5298046)

Who are your users? If you are supplying 1-6mb pdf's of recipes for housewifes you probably don't want to use ftp...it will just create confusion and complicate the user experience. If, on the other hand, you are sharing custom software then you can guess that your users will be more experienced with computers and comfortable using ftp.

ohhhhhh, new icon? (0)

Anonymous Coward | more than 11 years ago | (#5298048)

where'd that "Software" topic icon come from?

Make your life simpler: use HTTP (5, Insightful)

kazrak (31860) | more than 11 years ago | (#5298049)

I question why people think FTP is 'faster' or 'more lightweight' than HTTP. HTTP is a fairly lightweight protocol, and what overhead it does have is massively outweighed by the size of the files when you get into the multi-megabyte range. Add in that everything can be done in one transaction via HTTP (compared to logging in, changing to the right directory, activating passive mode if needed, starting the transfer, opening up a second TCP connection for the data transfer, etc. for FTP) and I really don't see a performance advantage to FTP.

Security-wise, HTTP is a big win over FTP if only because it makes your port-filtering easier - "allow to 80" is simpler and less likely to cause unintended holes than all the things you need to do to support FTP active and passive connections. Certain FTP server software has a reputation as having more security holes than IIS, but there are FTP servers out there that are as secure as Apache.

Well... (1)

fredrikj (629833) | more than 11 years ago | (#5298050)

1-6 MB? Use HTTP. It's probably more convenient for everybody, for instance there's no login procedure/delay for the end user. With files no bigger than that, people won't have the need to resume interrupted downloads either (the biggest advantage of FTP is the ability to do that when downloading a CD image :).

Of all the morons (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5298054)

There are two things to consider:
* protocol
* application

Neither ftp nor http are `full of holes'.
It very much depends which specific server you are using. Now, IIS is full of holes, and some ftp servers have been full of holes in the past, and still are... and there has been holes in apache as well.

As far as the functionality goes, ftp indeed provides some very useful functionality for file transfers: the ability to resume an interrupted transfer. Most servers and most clients support it nowadays and that is really VERY useful.

ftp is slightly more difficult to set up when firewalls are in effect, because of the two actual tcp channels used (data+control), which means the firewall needs to know about ftp (or it can get very unpleasant: active/passive protocols tricks will get you through one firewall, not through two of them).

Of course, if you are a complete moron, you will botch your server configuration and leave yourself wide open, or choose the wrong server, or forget to upgrade, and get security holes all over the place... doesn't matter which
protocol you use.

In reality, depending on what you want to serve, modern answers include sup, cvsup, rsync, and all kinds of other applications which leave ftp faaar behind (not even talking about http...). But then, they are less accessible and a little more 3l33t, which is maybe what you are looking for.

I'd say it depends on what you're serving... (4, Insightful)

PhaseBurn (44685) | more than 11 years ago | (#5298056)

From my point of view (A network administrator), I provide both ftp and http servers for the same files (stick all downloads off /download or something, and set the ftp root to that). This has several benefets...

1) I've found HTTP transfers are a little faster than FTP transfers (just personally, and I can in no way prove it - it may be user error, or just the programs I'm using)

2) I've found that FTP clients are everwhere - Windows, Linux, BSD, everything I've ever installed has included a command line FTP client, but not a web browser unless I specifically remember to install one. Further more, most of the "live CDs/boot disks" that I use don't have a web browser, but do have FTP... Thus, if you're serving files that a person with out a web browser/server might need, I'd set up both...

3) FTP security is what you/your daemon makes of it. wu-ftpd has a long history of being rooted... ProFTPd dosn't. VSFtp doesn't. HTTP security is the same way... IIS has a long history of being rooted... Apache doesn't... *(Not to say that there haven't been occasional exploits for these platforms)

There is no clear "Use this" or "Use that" procedure here, it depends entirely on your situation, what you're serving, what your network setup is, etc...

hmm (1)

Xtifr (1323) | more than 11 years ago | (#5298057)

Arguments 2 and b aren't arguments, they're polemicizing. Arguments 1 and a are both true (AFAIK). So, basically it comes down to a matter of taste. However, I'll point out that the speed of the protocol is unlikely to matter anywhere near as much as the speed of your server & pipe.

FTP alternatives (0)

Boltronics (180064) | more than 11 years ago | (#5298060)

I've set up a server where security is a main concern. As we wanted FTP, but didn't want our passwords sent in the clear, we have the following services:

1. SSH-FTP
2. SSL-FTP (which falls back to standard FTP if the FTP client doesn't support it).
There is also SSH available to those who want it.

No matter which they choose, our clients are always in their own individual chrooted environment. It is used for modifying their web sites (yes, we also have Apache 1.3x, but didn't bother with it for uploads).

Don't be an ego (1)

Symb (182813) | more than 11 years ago | (#5298064)

Remember this is about your customer base not your ego or /.'s peer pressure. You want as much convenience for as many people as is possible with in your time/quality/cost constraints. So, don't be guided by your ego. Offer both if you can and if you cater to 1337 trolls then offer SFTP, FTP-SSL, gopher, and other not-popular protocols. Just make sure that the majority of your users can access the content and your ok either way.

ftp allows 'resume' ops (1)

TheGratefulNet (143330) | more than 11 years ago | (#5298065)

its more common to be able to resume an aborted ftp session than http. but perhaps that depends on the fetching agent.

with wget, you can choose which protocol you want to fetch with. and wget can resume from where it left off when using ftp. I'm not sure it can do that with http (anyone know for sure?)

ftp has more features (2, Informative)

AnEmbodiedMind (612071) | more than 11 years ago | (#5298066)

FTP provides you with user authentication, and binary transfers (which should be faster as there is no encoding??) It can also be linked to via the web, so there's not too much hassle for the user...

On the other hand, if you don't need user authentication - and don't want to off load big file transfers from your web-server, you may as well just leave it as http.

FTP vs HTTP (2, Insightful)

The_Rippa (181699) | more than 11 years ago | (#5298070)

I run into this dilemna constantly. I've found that HTTP is more reliable for downloads for intranet applications. When I build something in VB I try to use FTP, because I have better control of what's going on. For file uploads, of course, FTP is definitely the way to go. As for speed, I think FTP is technically faster, but HTTP throught the browser has the added bonus of showing you how much time is left on the download, making it SEEM to go faster. Basically, if the file is something that doesn't need to be secure, I'd use HTTP if speed isn't an issue (ie: intranet only or broadband connections mostly), otherwise, I'd go with FTP.

Security (2, Insightful)

Devil's BSD (562630) | more than 11 years ago | (#5298073)

If you're looking for security, look into sftp, part of the openssh package. It uses the same encryption as SSH, is secure, yadayada. The only drawback is that windoze users have to get the sftp client to connect to an sftp server. Our school is considering adding sftp to the student fileserver so that we can access files from home without risk of attack.

Says who? (2, Informative)

jafo (11982) | more than 11 years ago | (#5298078)

Anyone who says that HTTP is slower and less reliable than FTP probably hasn't done any benchmarking. Based on my experience, HTTP is definitely more reliable if only because it tends to go through firewalls easier then the two-connection FTP protocol.

Both FTP and HTTP stream data across a TCP socket -- I can't see that streaming it over port 20 versus 80 is going to make any difference.

FTP was designed to be able to do all these neat things back when the internet didn't have so many security issues. Most of these features are either not used or explicitly disabled these days... The fact that the FTP server uses a different port means that firewall have to understand and properly be configured for this. HTTP sends the data back in response to the initial connection, so it tends to be easier to get through firewalls.

If you're concerned about looking like a "wimp", then you should offer both and let people pick what they prefer. Or... Stop worrying about what people these people think and figure out what YOU think is best.

The people who would call you a "wimp" probably aren't worth worrying about.

Sean

Use Both (1)

Anonymous Coward | more than 11 years ago | (#5298080)

My business is serving files to customers. I use FTP but have a few comments:

- Security is not an issue if you use the right ftp server. Check freshmeat to find the right one. Don't use WUFTPD or similar unless you have some reason to do so.

- I believe FTP is still the protocol of choice for reliably serving files.

- It's easy to implement authentication with ftp.

That said, I'm adding http support because a lot of customers can't access ftp from work because of firewalls and a lot of home users have firewalls installed (some don't even know it) and ftp causes support problems.

My recommendation is to support both protocols. I'm inclined to make ftp the default and use http as a user option because I "like to do things right" despite resulting customer problems. You might want to opt for http default.

HTTP vs FTP opinion (1)

dsb3 (129585) | more than 11 years ago | (#5298081)

Anoymous, download-only FTP is not too high of a risk. You do run into firewall problems - depending on your server firewall and your clients' firewall you may block both passive and active ftp connections. For download-only you can minimize exploits by keeping up to date on a reputable server (kernel.org uses proftpd which, although it's had some oopsies, is otherwise highly regarded).

Certainly HTTP is a lot easier for the majority of people to handle.

You might look at something like djb's publicfile which makes a given directory available over both http and ftp in a secure fashion.

FTP uploads? Avoid if at all possible. ANONYMOUS FTP downloads .... if you want to you can offer it in addition.

$0.02.

WebDAV? (2, Insightful)

Kevinv (21462) | more than 11 years ago | (#5298083)

How about implementing a webdav solution? You can get away from clear-text passwords, users can mount them like a drive on Mac, Windows and Linux (via DAVfs, http://freshmeat.net/projects/davfs/?topic_id=143% 2C90 )

Still have some of the unreliablity of HTTP transfers and slowness. But works a lot better through firewalls (and more securely since connection tracking works better with WebDAV).

I've found Passive Mode FTP to also be more unstable than standard ftp transfers.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...