The RETR command -- Retrieve a file
A RETR request asks the server to send the contents of a file over the data connection already established by the client. The RETR parameter is an encoded pathname of the file. The file is either a binary file or a text file, depending on the most recent TYPE request.
Normally the server responds with a mark using code 150. It then stops accepting new connections, attempts to send the contents of the file over the data connection, and closes the data connection. Finally it
The server may reject the RETR request without first responding with a mark. In this case the server does not touch the data connection.
The client needs to be prepared for many different ways that RETR can fail:
Some clients do not close the data connection until they receive the 226 response from the server.
The REST command -- Restart download
The server keeps track of a start position for the client. The start position is a nonnegative integer. At the beginning of the FTP connection, the start position is 0.
The start position changes the meaning of RETR for binary files as follows: if the start position is n, the server will omit the first n bytes of the data that it sends through the data connection.
Some servers also allow start positions for text files, with the same semantics: omit the first n bytes of data transferred through the data connection. However, clients cannot rely on this. Most existing servers skip a different number of bytes for text files.
A REST request sets the start position. REST has a parameter giving a number as ASCII digits. If the server accepts the REST request (required code 350), it has set the start position to that number. If the server rejects the REST request, it has left the start position alone.
The server will set the start position to 0 after a successful RETR, but might not set the start position to 0 after an unsuccessful RETR, so the client must be careful to send a new REST request before the next RETR. The server might set the start position to 0 after responding to any request other than REST, so the client must send REST immediately before RETR.
Servers are not required to implement REST. However, many clients can take advantage of REST to save time if a previous transfer was interrupted in the middle.
Clients beware: the file may have changed since the time of the previous transfer.