📄 rfc913.txt
字号:
-invalid account
Replies to PASS could be:
!Changed working dir to <new-directory>
+password ok, send account
-invalid password
KILL file-spec
This will delete the file from the remote system.
Replies are:
+<file-spec> deleted
-Not deleted because (reason)
Lottor [Page 8]
RFC 913 September 1984
Simple File Transfer Protocol
NAME old-file-spec
Renames the old-file-spec to be new-file-spec on the remote
system.
Replies:
+File exists
-Can't find <old-file-spec>
NAME command is aborted, don't send TOBE.
If you receive a '+' you then send:
TOBE new-file-spec
The server replies with:
+<old-file-spec> renamed to <new-file-spec>
-File wasn't renamed because (reason)
DONE
Tells the remote system you are done.
The remote system replies:
+(the message may be charge/accounting info)
and then both systems close the connection.
Lottor [Page 9]
RFC 913 September 1984
Simple File Transfer Protocol
RETR file-spec
Requests that the remote system send the specified file.
Receiving a '-' from the server should abort the RETR command
and the server will wait for another command.
The reply from the remote system is:
<number-of-bytes-that-will-be-sent> (as ascii digits)
-File doesn't exist
You then reply to the remote system with:
SEND (ok, waiting for file)
The file is then sent as a stream of exactly the number
of 8-bit bytes specified. When all bytes are received
control passes back to you (the remote system is waiting
for the next command). If you don't receive a byte
within a reasonable amount of time you should abort the
file transfer by closing the connection.
STOP (You don't have enough space to store file)
Replies could be:
+ok, RETR aborted
You are then ready to send another command to the remote host.
Lottor [Page 10]
RFC 913 September 1984
Simple File Transfer Protocol
STOR { NEW | OLD | APP } file-spec
Tells the remote system to receive the following file and save
it under that name.
Receiving a '-' should abort the STOR command sequence and the
server should wait for the next command.
NEW specifies it should create a new generation of the file and
not delete the existing one.
Replies could be:
+File exists, will create new generation of file
+File does not exist, will create new file
-File exists, but system doesn't support generations
OLD specifies it should write over the existing file, if any,
or else create a new file with the specified name.
Replies could be:
+Will write over old file
+Will create new file
(OLD should always return a '+')
APP specifies that what you send should be appended to the file
on the remote site. If the file doesn't exist it will be
created.
Replies could be:
+Will append to file
+Will create file
(APP should always return a '+')
Lottor [Page 11]
RFC 913 September 1984
Simple File Transfer Protocol
You then send:
SIZE <number-of-bytes-in-file> (as ASCII digits)
where number-of-bytes-in-file
is the exact number of 8-bit bytes you will be
sending.
The remote system replies:
+ok, waiting for file
You then send the file as exactly the number of bytes
specified above.
When you are done the remote system should reply:
+Saved <file-spec>
-Couldn't save because (reason)
-Not enough room, don't send it
This aborts the STOR sequence, the server is waiting for
your next command.
You are then ready to send another command to the remote host.
Lottor [Page 12]
RFC 913 September 1984
Simple File Transfer Protocol
AN EXAMPLE
An example file transfer. 'S' is the sender, the user process. 'R'
is the reply from the remote server. Remember all server replies are
terminated with <NULL>. If the reply is more than one line each line
ends with a <CRLF>.
R: (listening for connection)
S: (opens connection to R)
R: +MIT-XX SFTP Service
S: USER MKL
R: +MKL ok, send password
S: PASS foo
R: ! MKL logged in
S: LIST F PS: <MKL>
R: +PS: <MKL>
Small.File
Large.File
S: LIST V
R: +PS: <MKL>
Small.File 1 69(7) P775240 2-Aug-84 20:08 MKL
Large.File 100 255999(8) P770000 9-Dec-84 06:04 MKL
S: RETR SMALL.FILE
R: 69
S: SEND
R: This is a small file, the file is sent without
a terminating null.
S: DONE
R: +MIT-XX closing connection
Lottor [Page 13]
RFC 913 September 1984
Simple File Transfer Protocol
EDITORS NOTE
Mark Lotter receives full credit for all the good ideas in this memo.
As RFC editor, i have made an number of format changes, a few wording
changes, and one or two technical changes (mostly in the TYPEs). I
accept full responsibility for any flaws i may have introduced.
A draft form of this memo was circulated for comments. I will
attempt to list the issues raised and summarize the pros and cons,
and resolution for each.
ASCII Commands vs Binary Operation Codes
The ASCII command style is easier to debug, the extra
programming cost in minimal, the extra transmission cost is
trivial.
Binary operation codes are more efficient, and a few days of
debugging should not out weigh years of use.
Resolution: I have kept the ASCII Commands.
Additional Modes
Pro: For some machines you can't send all the bits in a word
using this protocol. There should be some additional mode to
allow it.
Con: Forget it, this is supposed to be SIMPLE file transfer.
If you need those complex modes use real FTP.
Resolution: I have added the Continuous mode.
Lottor [Page 14]
RFC 913 September 1984
Simple File Transfer Protocol
CRLF Conversion
Pro: In ASCII type, convert the local end of line indicator to
CRLF on the way out of the host and onto the network.
Con: If you require that you have to look at the bytes as you
send them, otherwise you can just send them. Most of the time
both sides will have the same end of line convention anyway.
If someone needs a conversion it can be done with a TECO macro
separately.
Resolution: I have required CRLF conversion in ASCII type. If
you have the same kind of machines and the same end of line
convention you can avoid the extra cost of conversion by using
the binary or continuous type.
TCP Urgent
Pro: Use TCP Urgent to abort a transfer, instead of aborting
the connection. Then one could retry the file, or try a
different file without having to login again.
Con: That would couple SFTP to TCP too much. SFTP is supposed
to be able to be work over any reliable 8-bit data stream.
Resolution: I have not made use of TCP Urgent.
Random Access
Pro: Wouldn't it be nice if (WIBNIF) SFTP had a way of
accessing parts of a file?
Con: Forget it, this is supposed to be SIMPLE file transfer.
If you need random access use real FTP (oops, real FTP doesn't
have random access either -- invent another protocol?).
Resolution: I have not made any provision for Random Access.
-- jon postel.
Lottor [Page 15]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -