rfcp30~p40

vivisun · 发表于 2005-10-8 23:39:48

<

><a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol the command. This second argument is optional, but when present should be separated from the first by the three Telnet characters <SP> R <SP>. This command shall be followed by a STORe or APPEnd command. The ALLO command should be treated as a NOOP (no operation) by those servers which do not require that the maximum size of the file be declared beforehand, and those servers interested in only the maximum record or page size should accept a dummy value in the first argument and ignore it. RESTART (REST) The argument field represents the server marker at which file transfer is to be restarted. This command does not cause file transfer but skips over the file to the specified data checkpoint. This command shall be immediately followed by the appropriate <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> service command which shall cause file transfer to resume. RENAME FROM (RNFR) This command specifies the old pathname of the file which is to be renamed. This command must be immediately followed by a "rename to" command specifying the new file pathname. RENAME TO (RNTO) This command specifies the new pathname of the file specified in the immediately preceding "rename from" command. Together the two commands cause a file to be renamed. ABORT (ABOR) This command tells the server to abort the previous <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> service command and any associated transfer of data. The abort command may require "special action", as discussed in the Section on <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> Commands, to force recognition by the server. No action is to be taken if the previous command has been completed (including data transfer). The control connection is not to be closed by the server, but the data connection must be closed. There are two cases for the server upon receipt of this command: (1) the <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> service command was already completed, or (2) the <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> service command is still in progress. <a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol In the first case, the server closes the data connection (if it is open) and responds with a 226 reply, indicating that the abort command was successfully processed. In the second case, the server aborts the <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> service in progress and closes the data connection, returning a 426 reply to indicate that the service request terminated abnormally. The server then sends a 226 reply, indicating that the abort command was successfully processed. DELETE (DELE) This command causes the file specified in the pathname to be deleted at the server site. If an extra level of protection is desired (such as the query, "Do you really wish to delete?"), it should be provided by the user-<a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> process. REMOVE DIRECTORY (RMD) This command causes the directory specified in the pathname to be removed as a directory (if the pathname is absolute) or as a subdirectory of the current working directory (if the pathname is relative). See Appendix II. MAKE DIRECTORY (MKD) This command causes the directory specified in the pathname to be created as a directory (if the pathname is absolute) or as a subdirectory of the current working directory (if the pathname is relative). See Appendix II.

RINT WORKING DIRECTORY (PWD) This command causes the name of the current working directory to be returned in the reply. See Appendix II.

vivisun · 发表于 2005-10-8 23:40:41

LIST (LIST) This command causes a list to be sent from the server to the passive DTP. If the pathname specifies a directory or other group of files, the server should transfer a list of files in the specified directory. If the pathname specifies a file then the server should send current information on the file. A null argument implies the user's current working or default directory. The data transfer is over the data connection in type ASCII or type EBCDIC. (The user must <a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol ensure that the TYPE is appropriately ASCII or EBCDIC). Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user. NAME LIST (NLST) This command causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor; a null argument implies the current directory. The server will return a stream of names of files and no other information. The data will be transferred in ASCII or EBCDIC type over the data connection as valid pathname strings separated by <CRLF> or <NL>. (Again the user must ensure that the TYPE is correct.) This command is intended to return information that can be used by a program to further process the files automatically. For example, in the implementation of a "multiple get" function. SITE PARAMETERS (SITE) This command is used by the server to provide services specific to his system that are essential to file transfer but not sufficiently universal to be included as commands in the protocol. The nature of these services and the specification of their syntax can be stated in a reply to the HELP SITE command. SYSTEM (SYST) This command is used to find out the type of operating system at the server. The reply shall have as its first word one of the system names listed in the current version of the Assigned Numbers document [4]. STATUS (STAT) This command shall cause a status response to be sent over the control connection in the form of a reply. The command may be sent during a file transfer (along with the Telnet IP and Synch signals--see the Section on <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> Commands) in which case the server will respond with the status of the operation in progress, or it may be sent between file transfers. In the latter case, the command may have an argument field. If the argument is a pathname, the command is analogous to the "list" command except that data shall be <a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol transferred over the control connection. If a partial pathname is given, the server may respond with a list of file names or attributes associated with that specification. If no argument is given, the server should return general status information about the server <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> process. This should include current values of all transfer parameters and the status of connections. HELP (HELP) This command shall cause the server to send helpful information regarding its implementation status over the control connection to the user. The command may take an argument (e.g., any command name) and return more specific information as a response. The reply is type 211 or 214. It is suggested that HELP be allowed before entering a USER command. The server may use this reply to specify site-dependent parameters, e.g., in response to HELP SITE. NOOP (NOOP) This command does not affect any parameters or previously entered commands. It specifies no action other than that the server send an OK reply. The File Transfer Protocol follows the specifications of the Telnet protocol for all communications over the control connection. Since the language used for Telnet communication may be a negotiated option, all references in the next two sections will be to the "Telnet language" and the corresponding "Telnet end-of-line code". Currently, one may take these to mean NVT-ASCII and <CRLF>. No other specifications of the Telnet protocol will be cited. <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> commands are "Telnet strings" terminated by the "Telnet end of line code". The command codes themselves are alphabetic characters terminated by the character <SP> (Space) if parameters follow and Telnet-EOL otherwise. The command codes and the semantics of commands are described in this section; the detailed syntax of commands is specified in the Section on Commands, the reply sequences are discussed in the Section on Sequencing of Commands and Replies, and scenarios illustrating the use of commands are provided in the Section on Typical <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> Scenarios. <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> commands may be partitioned as those specifying access-control identifiers, data transfer parameters, or <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> service requests. Certain commands (such as ABOR, STAT, QUIT) may be sent over the control connection while a data transfer is in progress. Some <a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol servers may not be able to monitor the control and data connections simultaneously, in which case some special action will be necessary to get the server's attention. The following ordered format is tentatively recommended: 1. User system inserts the Telnet "Interrupt Process" (IP) signal in the Telnet stream. 2. User system sends the Telnet "Synch" signal. 3. User system inserts the command (e.g., ABOR) in the Telnet stream. 4. Server PI, after receiving "IP", scans the Telnet stream for EXACTLY ONE <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> command. (For other servers this may not be necessary but the actions listed above should have no unusual effect.) 4.2. <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> 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. The details of the command-reply sequence are made explicit in a set of state diagrams below. An <a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> reply consists of a three digit number (transmitted as three alphanumeric characters) followed by some text. The 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 user-process (the User-PI) 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. A reply is defined to contain the 3-digit code, followed by Space <a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol <SP>, followed by one line of text (where some maximum line length has been specified), and terminated by the Telnet end-of-line code. There will be cases however, where the text is longer than a single line. In these cases the complete text must be bracketed so the User-process knows when it may stop reading the reply (i.e. stop processing input on the control connection) and go do other things. This requires a special format on the first line to indicate that more than one line is coming, and another on the last line to designate it as the last. At least one of these must contain the appropriate reply code to indicate the state of the transaction. To satisfy all factions, it was decided that both the first and last line codes should be the same. Thus the format for multi-line replies is that the first line will begin with the exact required reply code, followed immediately by a Hyphen, "-" (also known as Minus), followed by text. The last line will begin with the same code, followed immediately by Space <SP>, optionally some text, and the Telnet end-of-line code. For example: 123-First line Second line <st1:chmetcnv w:st="on" UnitName="a" SourceValue="234" HasSpace="True" Negative="False" NumberType="1" TCSC="0">234 A</st1:chmetcnv> line beginning with numbers 123 The last line The user-process then simply needs to search for the second occurrence of the same reply code, followed by <SP> (Space), at the beginning of a line, and ignore all intermediary lines. If an intermediary line begins with a 3-digit number, the Server must pad the front to avoid confusion. This scheme allows standard system routines to be used for reply information (such as for the STAT reply), with "artificial" first and last lines tacked on. In rare cases where these routines are able to generate three digits and a Space at the beginning of any line, the beginning of each text line should be offset by some neutral text, like Space. This scheme assumes that multi-line replies may not be nested. 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. (Referring to the state diagram), an unsophisticated user-process will be able to determine its next action (proceed as planned, <a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol redo, retrench, etc.) by simply examining this first digit. A user-process that wants to know approximately what kind of error occurred (e.g. file system error, command syntax error) 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: 1yz Positive Preliminary reply The requested action is being initiated; expect another reply before proceeding with a new command. (The user-process sending another command before the completion reply would be in violation of protocol; but server-<a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> processes should queue any commands that arrive while a preceding command is in progress.) This type of reply can be used to indicate that the command was accepted and the user-process may now pay attention to the data connections, for implementations where simultaneous monitoring is difficult. The server-<a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> process may send at most, one 1yz reply per command. 2yz Positive Completion reply The requested action has been successfully completed. A new request may be initiated. 3yz 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. This reply is used in command sequence groups. 4yz 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. The user should return to the beginning of the command sequence, if any. It is difficult to assign a meaning to "transient", particularly when two distinct sites (Server- and User-processes) have to agree on the interpretation. Each reply in the 4yz category might have a slightly different time value, but the intent is that the <a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol

vivisun · 发表于 2005-10-8 23:41:17

user-process is encouraged to try again. A rule of thumb in determining if a reply fits into the 4yz or the 5yz (Permanent Negative) category is that replies are 4yz if the commands can be repeated without any change in command form or in properties of the User or Server (e.g., the command is spelled the same with the same arguments used; the user does not change his file access or user name; the server does not put up a new implementation.) 5yz Permanent Negative Completion reply The command was not accepted and the requested action did not take place. The User-process is discouraged from repeating the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct his User-process to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered his directory status.) The following function groupings are encoded in the second digit: x0z Syntax - These replies refer to syntax errors, syntactically correct commands that don't fit any functional category, unimplemented or superfluous commands. x1z Information - These are replies to requests for information, such as status or help. x2z Connections - Replies referring to the control and data connections. x3z Authentication and accounting - Replies for the login process and accounting procedures. x4z Unspecified as yet. x5z File system - These replies indicate the status of the Server file system vis-a-vis the requested transfer or other file system action. The third digit gives a finer gradation of meaning in each of the function categories, specified by the second digit. The list of replies below will illustrate this. Note that the text <a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol 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. A command such as TYPE or ALLO whose successful execution does not offer the user-process any new information will cause a 200 reply to be returned. If the command is not implemented by a particular Server-<a href="http://www.cnpaf.net/class/ftp/" target="_blank" >FTP</A> process because it has no relevance to that computer system, for example ALLO at a TOPS20 site, a Positive Completion reply is still desired so that the simple User-process knows it can proceed with its course of action. A 202 reply is used in this case with, for example, the reply text: "No storage allocation necessary." If, on the other hand, the command requests a non-site-specific action and is unimplemented, the response is 502. A refinement of that is the 504 reply for a command that is implemented, but that requests an unimplemented parameter. <st1:chsdate w:st="on" Year="1899" Month="12" Day="30" IsLunarDate="False" IsROCDate="False">4.2.1</st1:chsdate> Reply Codes by Function Groups 200 Command okay. 500 Syntax error, command unrecognized. This may include errors such as command line too long. 501 Syntax error in parameters or arguments. 202 Command not implemented, superfluous at this site. 502 Command not implemented. 503 Bad sequence of commands. 504 Command not implemented for that parameter. <a href="http://www.cnpaf.net/class/RfcAll/" target="_blank" >RFC</A>959 October 1985 File Transfer Protocol 110 Restart marker reply. In this case, the text is exact and not left to the particular implementation; it must read: MARK yyyy = mmmm Where yyyy is User-process data stream marker, and mmmm server's equivalent marker (note the spaces between markers and "="). 211 System status, or system help reply. 212 Directory status. 213 File status. 214 Help message. On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user. 215 NAME system type. Where NAME is an official system name from the list in the Assigned Numbers document. 120 Service ready in nnn minutes. 220 Service ready for new user. 221 Service closing control connection. Logged out if appropriate. 421 Service not available, closing control connection. This may be a reply to any command if the service knows it must shut down. 125 Data connection already open; transfer starting. 225 Data connection open; no transfer in progress. 425 Can't open data connection. 226 Closing data connection. Requested file action successful (for example, file transfer or file abort). 426 Connection closed; transfer aborted. 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). 230 User logged in, proceed. 530 Not logged in. 331 User name okay, need password. 332 Need account for login. 532 Need account for storing files.

		自动登录	找回密码
密码			注-册-帐-号