File Transfer Protocol
obsoletes
- rfc-765 — File Transfer Protocol specification
updated by
- rfc-2228 — FTP Security Extensions
- rfc-2640 — Internationalization of the File Transfer Protocol
- rfc-2773 — Encryption using KEA and SKIPJACK
- rfc-3659 — Extensions to FTP
- rfc-5797 — FTP Command and Extension Registry
- rfc-7151 — File Transfer Protocol HOST Command for Virtual Hosts
also
- std-9
Extracted elements (27)
CDUP (Change to Parent Directory) is a special case of CWD added specifically to simplify programs that transfer directory trees between operating systems with different syntax for naming the parent directory. Its reply codes are identical to CWD.
Stream transfer mode is noted as inherently unreliable because premature connection close cannot be distinguished from normal EOF. Block and Compressed modes embed sufficient in-band framing to detect EOF without closing the connection, allowing the data connection to be reused across multiple file transfers in a session.
The FTP control connection uses the Telnet protocol. The specification notes that ease of implementation and code sharing favor using an existing Telnet module, while efficiency and independence favor direct implementation. Since FTP relies on very little of Telnet, direct implementation does not necessarily involve large amounts of code.
A file must be stored and retrieved with the same TYPE, STRU, and MODE parameters to ensure the retrieved version is identical to the original. All Local type transformations must be invertible, and Image type padding schemes must be well publicized to enable processing at the storage site.
ASCII type (TYPE A) is the default representation type and MUST be accepted by all FTP implementations. Non-print format is the default format parameter and must also be accepted by all implementations. Image type is RECOMMENDED to be accepted by all FTP implementations.
Both file-structure and record-structure MUST be accepted for text files (TYPE ASCII or EBCDIC) by all FTP implementations. File-structure is the default assumed if the STRU command has not been used.
Every FTP command MUST generate at least one reply. The server-FTP process may send at most one 1yz (positive preliminary) reply per command. A user-process sending another command before receiving a completion reply violates the protocol.
Every FTP implementation MUST support use of the default data connection ports, and only the USER-PI may initiate changes to non-default ports via PORT or PASV commands.
Image type padding (required at end-of-file or end-of-record due to storage system alignment) MUST be all zero bits, may occur only at the end of the file or record, and there MUST be a way to identify padding bits so they can be stripped upon retrieval. The padding scheme must be well publicized.
The server MUST close the data connection when: (1) it has completed sending data in a mode requiring close to indicate EOF; (2) it receives ABORT; (3) the port specification is changed by user command; (4) the control connection is closed; or (5) an irrecoverable error occurs. Otherwise closing is a server option signaled by reply 250 or 226 only.
The STOU (Store Unique) command's 250 Transfer Started response MUST include the unique filename generated for the new file. The REST (Restart) command MUST be immediately followed by the appropriate FTP service command (RETR, STOR, etc.) to resume transfer.
The transfer byte size for all data transmitted over the data connection is always 8 bits, regardless of the logical byte size used for data interpretation within a host's file system.
FTP reply codes are three-digit numbers: the first digit indicates status class (1=positive preliminary, 2=positive completion, 3=positive intermediate, 4=transient negative, 5=permanent negative), the second digit indicates functional grouping, and the third provides fine-grained detail.
FTP supports third-party (server-to-server) data transfer: the user-PI establishes control connections to two server-PIs and arranges a direct data connection between them via PORT and transfer commands. Control information flows through the user but data passes directly between the two servers.
FTP uses two separate TCP connections: a control connection (following the Telnet protocol) between user-PI and server-PI for commands and replies, and a separate data connection between DTPs for file transfer. The control connection must remain open while data transfer is in progress.
Out-of-band urgent commands (ABOR, STAT, QUIT) during data transfer are delivered by the user system inserting the Telnet IP signal, then the Telnet Synch signal, then the FTP command into the control stream. After receiving IP, the server-PI scans the Telnet stream for exactly one FTP command.
The error recovery restart procedure is defined for block and compressed modes only. The sender inserts a marker block in the data stream; the receiver records the corresponding position and returns marker information via a 110 reply. On system failure, the user sends REST with the server's marker code immediately followed by the interrupted service command.
The server-PI listens on well-known port L for control connections. The server's default data port is L-1 (adjacent to the control port). The user-process default data port is the same as its control connection port U. Implementations must support these defaults.
Access controls define users' privileges to the system and its files and are necessary to prevent unauthorized or accidental use. It is the prerogative of the server-FTP process to invoke access controls; the protocol does not mandate a specific access control mechanism.
FTP passwords are transmitted as plaintext Telnet strings over the control connection. The specification notes the server has no foolproof way to mask the password, making it the responsibility of the user-FTP process to hide sensitive password information from display.
Login forms a sequential command group: USER transitions to needing password (331) or completes login (230); PASS transitions to logged in (230), needing account (332), or fails; ACCT completes login (230) or is rejected. A failure at any point requires repeating the entire sequence. REIN resets all parameters to defaults while preserving in-progress transfers, returning to the post-connection state.
Block mode data blocks are preceded by a 3-byte header: the 8 high-order bits are a descriptor byte (bit flags: 128=EOR, 64=EOF, 32=suspected errors, 16=restart marker) and the 16 low-order bits are the byte count of the following data block. Multiple descriptor bits may be set simultaneously.
Compressed mode uses three encodings: a byte string (0-bit prefix + 7-bit count n, followed by n data bytes); a replicated byte (bits 10 + 6-bit count n + data byte d); and a filler string (bits 11 + 6-bit count n, filler is SP for ASCII/EBCDIC or zero for Image/Local). An all-zero escape byte followed by a Block-mode descriptor byte signals EOR/EOF.
Multi-line replies are bracketed: the first line begins with the 3-digit reply code immediately followed by a hyphen '-'; the last line begins with the same code immediately followed by a space. Intermediate lines that begin with a 3-digit number must be padded to avoid misidentification as the final line.
Page structure page headers contain at minimum four one-logical-byte fields: Header Length (minimum 4), Page Index (logical page number, not transmission sequence), Data Length (minimum 0), and Page Type (0=last page, 1=simple, 2=descriptor, 3=access controlled requiring header length 5). Optional per-page control fields may follow.
Stream mode uses a two-byte escape sequence for record-structured files: the first byte is all ones (escape), and the second byte encodes 1 for EOR, 2 for EOF, or 3 for both. If a data byte of all ones is intended, it must be repeated as the second byte of the escape sequence.
The PORT command argument encodes a 32-bit IP address and 16-bit TCP port as six comma-separated decimal octets: PORT h1,h2,h3,h4,p1,p2, where h1 is the high-order byte of the internet host address and p1,p2 encode the port number.