Active and passive mode

I have removed this section (Mike Gleason). Sorry, but the section contained numerous errors. I also feel that these are internal protocol details that are of no concern to the reader (unless we want to write up an entire technical analysis of the protocol internals).

The errors are detailed below.

"Active mode requires both the client and the server to open a port and listen on it in order to establish an FTP session." Not true; the server does not need to listen on the port for the active data connection. It does need to be bound to port 20 for outgoing connections, but it is not listening on port 20 which would imply that someone is connecting to the server at port 20.

"Passive mode requires only the server to have a process listen on a port, and thus it bypasses firewall issues on the client computer." The reason passive mode is more firewall friendly is that for passive mode, the client connects to the server, rather than for active mode, where the server connects to the client on an arbitrary port. Firewalls are typically on the client side, and inbound connections on the client side are not desired. On the server side, there is already a port open for inbound FTP control connections, so it's not as problematic to open ports for inbound FTP data connections.

"A random unprivileged port (a port with a number above 1024...". The important thing to note here is that it doesn't have to be above 1024. By convention it is, because the early years of FTP were dominated by TCP/IP stacks from the UNIX operating system, where this restriction was imposed. The port number here can be any valid IP port number, from 1 to 65535, and it doesn't need to be "random." It would be better to say an arbitrary port number.

"...known as the command port..." It's more commonly known as the control connection port.

"The source port is now the random port number x on the client and the destination port is port 21 on the server." This section is supposed to contrast active (PORT) and passive (PASV) data connections, but you're discussing the setup of the control connection.

"The client starts listening to port (x+1) and sends a PORT command to the server..." The client can choose any port it wants for use with PORT. It does not have to be x + 1. You're probably confusing this with the fact that the data connection, by default if not specified by the client, is x - 1.

"The server opens port 21..." No, port 21 is already open and in use for the control connection. It connects outward to the client with source port 20.

"The client opens a connection to port 21 on the server via client's data port and then sends the server an acknowledgment that it has established the connection." Connections are already open. An acknowledgment is made on the control connection. There is certainly no mixing of the data connection and the control connection.

Active mode Port on the Server

In the text it is mentioned that the port on the server is 21, this is the control port. The data port should be 20.

client sends "port x"

servers opens connection from "server:port 20" to "client:port x"

Not according to the RFC: "8. CONNECTION ESTABLISHMENT: The FTP control connection is established via TCP between the user process port U and the server process port L. This protocol is assigned the service port 21 (25 octal), that is L=21." [1] - Ta bu shi da yu 11:04, 27 Oct 2004 (UTC)

No, whoever wrote the original note was correct. The server listens on port 21 for the FTP control connection, but active data connections (PORT) originate from the server from port 20 and connect out to the client. --Mike Gleason

So why FTP?

Reading this article, I had one goal in mind: to figure out what advantages FTP has over HTTP. I didn't see any. Perhaps these could be added? —Simetrical (talk) 02:17, 21 Mar 2005 (UTC)

HTTP when transferring binary content, encodes it in base 64, which basically increases the volume of the transfer by a huge amount. FTP on the other hand, uses binary transfer (no encoding is done), which means the transfer is faster.

FTP requires the the user to login (anonymous ftp is also common these days) before he can fetch content. so authentication is built into the system.

FTP uses seperate connections for control (user commands) and data transfer. The data transfer occurs on arbitrary ports, which makes it harder for FTP connection to get through strict firewalls.

HTTP is a stateless protocol. This means the client has to maintain its own state. FTP on the other hand, maintains the state for the user, e.g. his current directory.

There is no requirement to encode binary content transferred over HTTP. The standard has provisions for this, but they are fortunately hardly ever used or needed. The only required overhead comes from the textual HTTP header, which is negligible when transferring large files. Aapo Laitinen 16:22, 29 October 2005 (UTC)

Indeed HTTP can require the user to login, too. And since HTTP 1.1, it shouldn't be stateless anymore. But it's true that there's nothing in HTTP about manipulating files and directories in the remote server. HTTP is just for retrieving files (well, not in its origins -PUT, etc.- but in the practice it is).

Of course, it's completely possible (and some web hosting sites have done it) to build an FTP-equivalent system (using CGI) which uses http to transfer files to and from the client machine. Those systems have the advantage of being more familiar for non-expert users (well, few people know there exist ftp clients... apart from their browser). Another advantage is that what would be the client program is web-based, and thus designed by the server (this could be thougth as a disadvantage, but there certainly must be ways for automatically doing it if you don't want to handcraft a client).

An important thing to consider is that FTP predates HTTP. It's not like somebody thougth it would be better than HTTP =D. (As trivia, Tim based HTTP's response codes -as 404- on FTP's).

Perhaps the file transfer article would be a better place to discuss the advantages and disadvantages of one protocol over another. --75.37.227.177 20:09, 9 August 2007 (UTC)

Requested move

File Transfer Protocol → FTP – (1) The term file transfer protocol, when uncapitalized, is a generic term which can refer to any method of transferring files from one communications point to another. (2) I have just written a new article on file transfer protocols in general and don't want it to be confused with this one. (3) The Internet File Transfer Protocol discussed is better-known as FTP. (4) The titles of most of the other protocols in the Internet protocol suite (HTTP, etc.) use the acronym rather than the full name. —Psychonaut 14:40, 2 Apr 2005 (UTC)

Add *Support or *Oppose followed by an optional one sentence explanation and sign your vote with ~~~~

Support We talk about "FTP sites" all the time, but never "File Transfer Protocol sites". —MichaelZ.2005-04-4 08:06 Z

Oppose. Please see Talk:Post Office Protocol for a simular requested move. The outcome of that discussion was that the article should not be under the TLA (three letter acronym). It's more clear, more encyclopedic, and more consistant with other articles to spell out the name in the title. Jonathunder 08:18, 2005 Apr 4 (UTC)

Reason 4. above appears wrong, or at least misleading. Very few of the other protocols which appear in the Internet protocol suite box in fact have their articles titled with the acronym rather than the full name. I checked these out explicitly:

Only the last is as stated in reason 4. Judging by the links in the suite box, there are only 3 of the 20 articles that use the acronym. (The other two are IPv4 and IPv6, and note that their parent article is Internet Protocol, not "IP".)

It is true that one says an "FTP site" but if one is programming to the protocol one says "File Transfer Protocol" one does not say "what is error number 550 in the FT Protocol" (it makes it sound like something in the Financial Times), one says "What is error number 550 in the File Transfer Protocol?"

To talk about a "file transfer protocol" as a generic term, is using a very narrow definition of inter-computer comminications is all about. For example what about the old CPM "Periphal Interchange Program" or Kermit or rsh, or ssh, all of which can transfer finite and infinite data sets, but are not "file transfer protocols" unless one defines all data trasfered as files. -- Philip Baird Shearer 14:35, 6 Apr 2005 (UTC)

Decision

It was requested that this article be renamed but there was no consensus for it to be moved.violet/riga(t) 22:49, 6 Apr 2005 (UTC)

Protocol in more detail

I don't think it would hurt the article to add a summary which discusses the working protocol in more detail, including establishing a connection, sending data, and terminating a connection. Maybe something about a the various FTP commands that are part of the protocol (file system browsing, etc.). It wouldn't have to be especially technical, but just discuss the parts of a typical FTP conversation, and some of the things that the client can "tell" the server. Brent 14:10, 23 October 2005 (UTC)

Maybe add something about the different directory listings with unix style the most common, vms and dos.

The article would benefit from a brief explanation of the error-checking/correction methods built into it (if any), and a comparison of the pros and cons of sending files via FTP and as email attachments. EEye (talk) 10:14, 1 April 2008 (UTC)

Understanding FTP

I know wikipedia isn't a how-to-do but I normally find there is enough info in a wikipedia article of this type to be able to start to figure out how to be able to do something. When I came to this article a few weeks it was much less helpful than similar articles have been (and with the notice already in place). What I didn't grasp at the time was that you need an FTP client in order to be able to download and upload files (I already had access to a server but didn't know how to access it and clearly couldn't do anything with the relevant interent page, and I still feel that this how it works could be explained more clearly in the opening, what we have now explains it much better than before but maybe not as well as could be done. Good to know there are some free FTP clients out there, SqueakBox 17:04, 9 December 2005 (UTC)

I added a how-to section. Try it out. I've been using FTP for a while so if I went to fast in my explanation please revise it so its easy for a beginner to follow. JesseHogan 17:52, 10 December 2005 (UTC)

Wikipedia is not a tutorials site, but at the same time this article jumps into protocol specifications without providing an unfamiliar used with the principle ideas of FTP. I added a part for FTP fundamentals, but shied away from any direct tutorials. —Preceding unsigned comment added by 76.10.167.131 (talk) 06:43, 5 November 2008 (UTC)

Expert Tag

Do we still need the banner saying this article needs an expert. I'd like to remove it.JesseHogan 01:16, 14 December 2005 (UTC)

I think that the content currently in the FTP over SSH article would be better served by being included in this File Transfer Protocol article, as part of a general discussion of "securing" FTP, including other approaches such as FTP over SSL/TLS. -- JTN 14:41, 28 December 2005 (UTC)

Agree - good idea, FTP Over SSH is just another way of securing the protocol so it should be listed here. Martin Hinks 17:29, 29 January 2006 (UTC)

I do not agreee. This belongs in a 'things you can do with SSH' page and not a 'good ways of doing FTP page'. If people want to do FTP over SSH, then they should define an AUTH mechanism to extend RFC2228 and not just stick the control connection in a secure tunnel. Paulfh 16:56, 30 January 2006 (UTC)

Surely this is not a discussion on whether you think FTP over SSH is a "good way of doing FTP" but merely whether it should be merged into this article as it relates to FTP. Martin Hinks 21:15, 30 January 2006 (UTC)

As long as it is merged alongside a disclaimer stating that it is a bad thing to do - I have no problem. But putting a list of good things and bad things on the same pseudo-authoritative source without editorial comment leaves readers with little understanding as to why the information is present Paulfh 11:17, 2 February 2006 (UTC)

We cannot put a disclaimer saying what are bad things to do as it would violate Neutral Point of View policies, but we can state the advantages and disadvantages of the approach and let the reader make up their own mind. As long as each method specified gives both the positives and negatives I think the reader will be able to make an informed decision. Martin Hinks 11:29, 2 February 2006 (UTC)

Merge. The FTP over SSH article already states the problems of the method. Kwi | Talk 18:00, 2 February 2006 (UTC)

No Merge: It is rather an explanation what you can do with SSH not an extension or feature to FTP. As the article name states: Over SSH you can also do FTP. Dequid 01:26, 10 February 2006 (UTC)

No Merge: Just as FTP uses the TCP/IP layer, SSH can use the FTP layer. This merge would be as legitimate as merging FTP with TCP/IP.

Comment. An anon went ahead and copy-pasted the text into this article anyway last week. I don't see consensus here that is clear in either direction. FYI. — Saxifrage✎ 18:56, 2 March 2006 (UTC)

And while you're at it... How about the article for FTPS? That should be merged into this one as well.12.110.196.19 18:42, 3 April 2006 (UTC)

Guys, don't bother. SSH has been circumvented. Use SSL instead.

/me waits for someone to post something about SSL not being compatible with the FTP protocol. CMON GUYS! BRING IT ON!

--Insanitor.

Don't disturb Wikipedia to make a point. If you have something to contribute, feel free. Mocking the process will just get you on the wrong end of some of our processes. Incidentally, you can sign your comments by typing four tildes (~~~~) where you want your signature to appear.

I haven't mocked you. You're taking this entirely too personally. If the process doesn't go the way you want, that would be because you want something that isn't suitable for Wikipedia. Accept that and move on, or switch to wanting to do something that is acceptable by Wikipedia's standards. Wikipedia isn't made the way it is just to mock you.

If you're feeling too sick to edit like a mature adult, your best course of action would be to not edit until you can. — Saxifrage✎ 01:43, 9 July 2006 (UTC)

I thought that wikipedia was an encyclopedia that could be edited by anyone.

Then I find out that you remove the link to my tutorial on purpose and now you say that I need to edit like an adult?

You invent this process to hinder my efforts and now I am not supposed to take this personally?

What planet do you come from?

On Earth we have consideration for other people's feelings.

Why did you put my ip address on the last message?

Do you want to hack into my computer?

--Insanitor.

If you check the edit history, you'll see that you put your IP address on your last post because you weren't logged in.

I didn't invent any of this process, I'm only trying (in vain it seems) to educate you about it. Anyone can edit Wikipedia, but that doesn't mean what people decide to put on it is sacred and must never be deleted. There's a lot that's of no use to Wikipedia. And yes, editors are expected to behave themselves. That's why we have lots of policies about being civil and not behaving badly, as well as banning policies for people who refuse to follow them. — Saxifrage✎ 03:16, 9 July 2006 (UTC)

Sir I call into question your honesty and integrity concerning this.

I was logged in just fine.

My IP address did not show up until you suggested that I put "four tildes" to sign my name with.

And then all of a sudden my IP address shows up.

If you think you are trying in vain to educate me about the process then the failure is yours and not mine.

According to what you have told me in the past editors are supposed to have a consensus on whether or not the link is included and the final decision is supposed to be based on consensus.

If you read this discussion carefully the consensus so far was that there is no reason why my link should not be included yet I expect your edit if I dare to put the link back into this article.

Every editor including yourself have initially admitted that the link cannot hurt.

The fact that you and another editor have changed your minds, does not negate the fact that initial consensus nevertheless is still consensus.

It would seem to me that this process as you call it is not a process at all but actually a non standardized form of arbitrary exclusion by so called "editors" who do whatever they want and interpret the process according to which way the wind blows.

All editors including yourself initially indicated that the link being there cannot hurt the article.

You sir are not what you claim to be.

I might not have my link included in this article but I retain my dignity and perseverance in pointing out the facts in this discussion and arguing my points using factual evidence and anyone reading this using common sense and taking into account factual evidence will undoubtedly agree with my conclusions.

I sincerely hope that one day someone reading this discussion will look at my tutorial and get an ftp site running and thank me for my efforts because it seems that in here appreciation for effort is in extremely short supply.

I sincerely hope that anyone reading this will avoid the waste of time and energy I did and will see this editing process for what it really is.

--Insanitor.

I hereby retract my initial request to include my link in this article.

I am tired of being unfairly treated and if at any point wikipedia decides to include the link to my tutorial in the FTP article as I initially requested (not the link to it in this talk page) then the owners of wikipedia will hear from my lawyers.

A copy of this discussion and all related documents will be sent to the owners of this website.

--Insanitor.

There's no such thing as "initial consensus". Consensus is what comes out of the end of discussion. I would not remove a link if that's what others thought was appropriate.

You weren't logged in when you made that edit. See, here is the record of your edit. The four tildes signs your username, and if you're not logged in, your username is your IP address. IP addresses are publicly visible on the internet, and Wikipedia hides them as a courtesy for editors who log in. That's part of the purpose of having an account. I am signing this with four tildes, and it shows my username because I know well enough to be logged in when I do.

I never said that the link couldn't hurt, only that you should not be the one to decide since you have a vested interest. What others decide I'd abide by, and I haven't really contributed to the discussion until recently.

I never claimed to be anything.

Don't make legal threats. There isn't a court in the world that would support a civil suit for linking to a site against the owner's wish. Not that your sour grapes will be relevant, since I doubt the decision will be to offer a link anyway.

Since you seem to have no interest in actually helping the encyclopedia beyond getting your page linked, your disillusionment is no loss to the project. Cheers, and goodbye! — Saxifrage✎ 09:17, 9 July 2006 (UTC)

I read the rules.

There was consensus.

You simply failed to include the link.

You claimed that you would allow the link if there was consensus and there was.

You're quite right that I ignored it. As I promised you, I would allow the regular editors of this article to debate its merits and include or disinclude it. They debated the merits and decided it couldn't hurt, but obviously didn't care enough to actually add it. My "allowing" was to stand out of the way. — Saxifrage✎ 05:46, 10 July 2006 (UTC)

This is getting quite far away from the subject of FTP. If you want to talk to me specifically, you are welcome to come to my Talk page. Otherwise, I will refrain from responding any more here to discussion that is unrelated to improving the article. — Saxifrage✎ 05:49, 10 July 2006 (UTC)

Image of an FTP session?

Why is Image:AnonFTPSession.jpg necessary for this article? More specifically: why is a 108 KiB file of pure text required when it's transcription is easily sufficient? Cburnett 21:42, 23 February 2006 (UTC)

Nevermind, I guess. I already substituted the image for equitable text and put the image up for IFD. Cburnett 21:52, 23 February 2006 (UTC)

Now the text doesn't match the example given. ncftp is used instead for the DOS ftp client. The output doesn't even have the response codes now. The section was intended to give inexperienced users basic information on how to connect to an FTP server. Normally I would never print a picture when text would be adequate but most users have never used a command line interface and I wanted to make it perfectly clear how their session should look. I prefere we restore the picture but we should at least make the output match the example. JesseHogan 23:53, 23 February 2006 (UTC)

Wikipedia is not an instruction manual nor a tutorial. This is clearly your intention. Cburnett 02:38, 24 February 2006 (UTC)

To make you happy, though, I did transcribe the image. I still will absolutely insist that a 108 KiB image is completely and totally 100% irrelevant. Cburnett 02:50, 24 February 2006 (UTC)

Not a tutorial

I propose removal and or rewriting of the "How to connect to FTP" section. Wikipedia is not a tutorial. Besides, the example given is platform specific and practically obsolete. Tutorials like this should be moved to the relevant FTP Client page if included at all, and not on this page, the purpose of which is to document the Protocol, not specific programs that utilise it. Comments? Martin Hinks 10:15, 26 February 2006 (UTC)

Agreed. Perhaps it should be moved to Wikibooks instead? That's where "howto" material from Wikipedia is often moved. — Saxifrage✎ 18:38, 3 March 2006 (UTC)