IdFTP

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. 

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: 

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: 

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. 

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: 

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

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: 

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

TIdExplicitTLSClient 

IndySupport