Topic Path: Symbol Reference > Classes > TIdFTP Class
ContentsIndexHome
PreviousUpNext
TIdFTP Class

Implements a File Transfer Protocol (FTP) client.

File
TIdFTP = class(TIdExplicitTLSClient);

TIdFTP is a TIdExplicitTLSClient descendant that implements a File Transfer Protocol (FTP) client, as described in the Internet Standards documents: 

RFC 959 - File Transfer Protocol [FTP]  

RFC 2228 - FTP Security Extensions  

RFC 2389 - Feature negotiation mechanism for the File Transfer Protocol  

RFC 2428 - FTP Extensions for IPv6 and NATs  

RFC 2640 - FTP Internalization  

IETF Draft Extensions to FTP  

Deflate transmission mode for FTP  

Securing FTP with TLS  

FTP is a protocol that promotes sharing files, efficiently uploading and downloading files, as well as isolating differences in the file systems for remote host computers. 

TIdFTP provides an encapsulation of the FTP protocol interpreter that acts as the control channel or communication path for the exchange of FTP commands and their specific FTP replies. Several key properties and methods are used to establish the control channel for the FTP session, including: 

 

 

After creating the control channel connection using Connect or Login, the following properties can be used to examine the content of FTP replies and settings detected during the process: 

 

 

TIdFTP uses properties and methods to implement the FTP Access Control Commands, as described in RFC 959 and other related Internet Standards documents. 

 

FTP Command 
Method or Properties 
USER 
Username property supplied in the Login method 
PASS 
Password property supplied in the Login method 
ACCT 
Account method 
CWD 
ChangeDir method 
CDUP 
ChangeDirUp method 
SMNT 
StructureMount method 
REIN 
Reinitialize method 
QUIT 
Quit method 

 

Internally, TIdFTP handles the interactions required for establishing and maintaining the data channel over which data is transferred using the specified structure, mode and type. All file transfer functions are performed using the internal data channel. The data channel connection can use the default port number for the FTP client, or may negotiate a non-default port number using the FTP PORT command. 

Data transfer commands and arguments are implemented in TIdFTP using the following properties and methods: 

 

FTP Command 
Method or Properties 
PORT 
Uses the value in DataPort when the data channel is opened in the Get and Put methods. 
PASV 
Uses the Passive property when the data channel is opened in the Get and Put methods. 
TYPE 
Uses the TransferType property in Login or when the property value is changed. 
STRU 
FileStructure method. 
MODE 
TransferMode method. 

 

TIdFTP also implements support for compression of data using the "deflate" transmission mode, as described in the Internet Draft "Deflate transmission mode for FTP". In deflate transmission mode, data is compressed and transmitted as a stream of octets (8 bit bytes). The sender and receiver rely on a compression engine to perform compression operations (deflate/inflate) and maintain state. The compression engine generates a unique data stream using the ZLIB compressed data format specified in RFC 1950. 

The deflate extension modifies the MODE command by adding the parameter "Z". 

TIdFTP also supports the FTP FEAT and OPTS commands as specified in RFC 2389 to discover optional commands supported on the FTP server. Use the Capabilities property to examine features supported on the server. Use the SetCMDOpt method to send the FTP OPTS command that specifies the desired behavior of the FTP server process when a subsequent FTP command is issued. 

TIdFTP implements the common FTP Service Commands that define the file transfer or the file system function requested by the client. FTP service commands are issued on the control channel for the client session. Data transferred in response to an FTP service commands is always be sent over the data channel connection. TIdFTP implements the following FTP service commands using the indicated properties and methods: 

 

FTP Command 
Method or Properties 
RETR 
Get method. 
STOR 
Uses the Put method and the Append argument. 
STOU 
StoreUnique method. 
APPE 
Used in the Put method and the Append argument. 
ALLO 
Allocate method. 
REST 
Sent in the Put and Append methods, or when the ResumeSupported property is updated. 
RNFR 
Used in the Rename method. 
RNTO 
Used in the Rename method. 
ABOR 
Abort method. 
DELE 
Delete method. 
RMD 
RemoveDir method. 
MKD 
MakeDir method. 
PWD 
LIST 
List method. 
NLST 
List method using the ADetails argument. 
SITE 
Site method or the Connect method when SITE ZONE is supported. 
SYST 
Used in the Connect method to update the SystemDesc property. 
STAT 
Status method. 
HELP 
Help method. 
NOOP 
Noop method. 

 

Secure FTP using TLS

 

TIdFTP also supports the mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined in RFC 2246, and the extensions to the FTP protocol defined by RFC 2228. When the FTP session control channel is established, the client requests TLS using the value in the UseTLS property. Data channel connections may be secured using the Passive and UseTLS properties. Should the FTP client wish to make the control connection revert back into plaintext (once the authentication phase is completed), set the value in UseCCC

Use of TLS for control and/or data channel connections requires the use of TIdSSLIOHandlerSocketBase, and access to the OpenSSL (or compatible) library for the operating system or platform hosting the Indy application. 

 

FTP Protocol Replies

 

Replies to File Transfer Protocol commands are devised to ensure the synchronization of requests and actions in the process of file transfer, and to guarantee that the user process always knows the state of the Server. Every command must generate at least one reply, although there may be more than one; in the latter case, the multiple replies must be easily distinguished. In addition, some commands occur in sequential groups, such as USER, PASS and ACCT, or RNFR and RNTO. The replies show the existence of an intermediate state if all preceding commands have been successful. A failure at any point in the sequence necessitates the repetition of the entire sequence from the beginning. 

FTP reply values can be accessed using the LastCmdResult property, and consists of a 3-digit numeric response number followed by some arbitrary text. The response number is intended for use by automata to determine what state to enter next; the text is intended for the human user. It is intended that the three digits contain enough encoded information that the control channel will not need to examine the text and may either discard it or pass it on to the user, as appropriate. In particular, the text may be server-dependent, so there are likely to be varying texts for each reply code. 

The three digits of the reply each have a special significance. This is intended to allow a range of very simple to very sophisticated responses by the user-process. The first digit denotes whether the response is good, bad or incomplete. The FTP client can determine its next course of action by simply examining this first digit in the numeric response. For more detailed information about a numeric response code, the FTP client may examine the second digit, reserving the third digit for the finest gradation of information (e.g., RNTO command without a preceding RNFR). 

There are five values for the first digit of the reply code: 

 

Code 
Meaning 
1xx 
Positive Preliminary reply. The requested action is being initiated, but expect another reply before proceeding with a new command. 
2xx 
Positive Completion reply. The requested action has been successfully completed. A new request may be initiated. 
3xx 
Positive Intermediate reply. The command has been accepted, but the requested action is being held in abeyance, pending receipt of further information. The user should send another command specifying this information. 
4xx 
Transient Negative Completion reply. The command was not accepted and the requested action did not take place, but the error condition is temporary and the action may be requested again. 
5xx 
Permanent Negative Completion reply. The command was not accepted and the requested action did not take place. The client is discouraged from repeating the exact request (in the same sequence). 

 

The second digit in a numeric response code encodes the following functional groupings: 

 

Code 
Meaning 
x0x 
Syntax. These replies refer to syntax errors, syntactically correct commands that don't fit any functional category, unimplemented or superfluous commands. 
x1x 
Information. These are replies to requests for information, such as status or help
x2x 
Connections. Replies referring to the control and data connections. 
x3x 
Authentication and accounting. Replies for the login process and accounting procedures. 
x4x 
Unspecified as yet. x5x File system. These replies indicate the status of the Server file system for the requested file transfer or other file system action. 

 

The third digit in the numeric response code provides the finest gradation of meaning in each of the function categories. The text associated with each reply is recommended, rather than mandatory, and may even change according to the command with which it is associated. The reply codes, on the other hand, must strictly follow the specifications in the last section; that is, Server implementations should not invent new codes for situations that are only slightly different from the ones described here, but rather should adapt codes already defined. 

The following list indicates the numeric FTP reply codes and their suggested textual content for a typical FTP server implementation: 

 

Code 
Message 
110 
MARK yyyy = mmmm 
120 
Service ready in nnn minutes. 
125 
Data connection already open; transfer starting. 
150 
File status okay; about to open data connection. 
200 
Command okay. 
202 
Command not implemented, superfluous at this site
211 
System status, or system help reply. 
212 
Directory status
213 
File status
214 
Help message. 
215 
NAME system type. 
220 
Service ready for new user. 
221 
Service closing control connection. 
225 
Data connection open; no transfer in progress. 
226 
Closing data connection. 
227 
Entering Passive Mode (h1,h2,h3,h4,p1,p2). 
230 
User logged in, proceed. 
250 
Requested file action okay, completed. 
257 
"PATHNAME" created. 
331 
User name okay, need password. 
332 
Need account for login
350 
Requested file action pending further information. 
421 
Service not available, closing control connection. 
425 
Can't open data connection. 
426 
Connection closed; transfer aborted. 
450 
Requested file action not taken. 
451 
Requested action aborted: local error in processing. 
452 
Requested action not taken. 
500 
Syntax error, command unrecognized. 
501 
Syntax error in parameters or arguments. 
502 
Command not implemented. 
503 
Bad sequence of commands. 
504 
Command not implemented for that parameter. 
530 
Not logged in. 
532 
Need account for storing files. 
550 
Requested action not taken. 
551 
Requested action aborted: page type unknown. 
552 
Requested file action aborted. 
553 
Requested action not taken. 

 

Directory Listings Using TIdFTP

 

One of the key features of the FTP protocol is the ability to access a list of files found in a directory on the remote host using the FTP LIST or NLST commands. TIdFTP implements this feature, and captures the list of file names and optional file details in the ListResult property. 

The FTP protocol (by design) isolated the FTP client from the nuances of host-specific file systems. In obeyance of this design goal, it also did not specify a standard representation for the contents of a directory listing. Instead, FTP clients have historically relied on defacto representations for the content of a directory listing as used in specific server implementations. 

There are FTP extensions that have been presented to the IETF (Internet Engineering Task Force) that specifies new FTP commands to obtain listings of remote directories in a defined format. Two commands are defined, MLST which provides data about exactly the object named on its command line, and no others. MLSD on the other hand will list the contents of a directory if a directory is named. The MLST and MLSD commands are intended to standardize the file and directory information returned by the Server FTP process. These commands differ from the LIST command in that the format of the replies is strictly defined although extensible. 

The MLST format is intended for machine processing, not human viewing, and as such the format is very rigid. implementations must not vary the format by, for example, inserting extra spaces for readability, replacing spaces by tabs, including header or title lines, or inserting blank lines, or in any other way alter this format. 

In TIdFTP, the List command can use either the FTP LIST or NLST commands to request the content of a directory listing. In addition, the ExtListDir and ExtListItem methods can be used to invoke the FTP extenstion commands MLST and MLSTD for servers supporting the features. 

The Indy library recognizes these defacto standards, and makes provisions for the IETF draft standards. TIdFTP provides the capabilitiy to parse the various formats for the textual content in the ListResult property into a structured representation of the directory stored in the DirectoryListing property. At the present time, Indy offers parsers for 30 different host-specific directory listing formats. Additional parsers are offered as new directory listing formats are encountered and codified. Use the IdAllFTPListParser.pas unit to include and register the known directory listing parsers for the Indy library.

Discuss enabling LargeStream support in IOHandlers using OnDataChannelCreate

Copyright 1993-2006, Chad Z. Hower (aka Kudzu) and the Indy Pit Crew. All rights reserved.
Post feedback to the Indy Docs Newsgroup.