18 answers about FTP protocol (really long)
- From: billiejoex <gnewsg@xxxxxxxxx>
- Date: Thu, 28 Jun 2007 13:50:48 -0700
Hi there,
I'm an Italian developer currently maintaining an FTP server library
implemented in Python.
It's been a long time I'm searching for a kind of board where I could
ask for some help about my implementation problems and I really hope
to find some answers here.
During the time I've developed such project I discovered one big
thing: RFC959 sucks! It lacks of details and it's ambiguous in many
parts.
I try to submit all my doubts below. Most of them regards FTP
commands.
Excuse me if such message is extremely long.
Feel free to contact me via mail: billiejoex [AT] gmail [DOT] com
1 - REIN: What should I do if I receive a REIN while a transfer is in
progress?
- Immediately respond with 230 and reset account information.
- Immediately reset account information and respond with 230 only when
the transfer is finished (in the meanwhile should I have to reject any
other command?).
- Immediately respond with 230 and reset account information then
respond with 230 again once the transfer is finished.
- other?
2 - USER: according to RFC959 USER command used when account is
already logged-in has the same effects of REIN (flush account
information and do not close data channel if there's a transfer in
progress). My doubts remains the same of REIN: what shall I do if I
receive USER while a transfer is in progress?
- Immediately respond with 331 and reset account information.
- Immediately reset account information and respond with 331 only when
the transfer is finished.
- Immediately respond with 331 and reset account information then
respond with 331 again once the transfer is finished.
- other?
3 - PASS: what do I have to respond in case that I receive PASS when
user has already logged-in?
4 - PASV/PORT: What should I do if PASV or PORT are received twice?
And what if they're received while there's a transfer in progress?
Actually I reset data-channel, doesn't matter if there's a transfer in
progress or not, but I'm not sure if this is the right thing to do or
not (RFC959 doesn't talk about this eventuality). I believe that
rejecting PASV/PORT with a 5xx response while a data-transfer is in
progress it would be a better choice because of the REIN / USER (x2)
commands: if user "james" starts a transfer, then he logs-in again as
"charles" by using REIN/USER he shouldn't be able to stop a transfer
that still belongs to "james" by sending PASV or PORT. Moreover, when
"james"'s data-transfer finishes "charles" will receive a "226
Transfer complete." message that's related to a transfer of another
user and this, imho, is a strange behaviour.
For these reasons, imho, if PASV/PORT are received when DTP channel is
opened, restarting data channel only if no transfer is in progress
would be a better behaviour, otherwise it would be better rejecting
request with a 5xx response.
5 - ACCT: this one appears completely obscure to me. Bernstein
( http://cr.yp.to/ftp/user.html ) gives a short explanation but still
can't understand how it should work:
Bernstein says:
The server may accept ACCT with code 230, meaning that permission
to access files under this username > has been granted; or with code
202, meaning that permission was already granted in response to USER
or PASS. The server may reject ACCT with code 503 if the previous
request was not PASS or with code 530 if the username, password, and
account name are jointly unacceptable.
What does it mean? Should I have to respond 503 if user didn't logged
in yet and 202 if he already did? Considering that I'm already living
my life quiet and happy with USER and PASS commands why should I have
need of such a thing?
6 - SMNT: What does RFC's author means by "This command allows the
user to mount a different file system data structure"? Is he talking
about some kind of "chrooting" that changes the user's home directory?
<- cwd /
-> 250 ok.
<- pwd
-> 257 "/" is the cwd. (real filesystem path is "/home/user")
<- smnt /subdir
-> 202 ok.
<- cwd /
-> 250 ok.
<- pwd
-> 257 "/" is the cwd. (real filesystem path is now "/home/user/
subdir")
7 - CWD: what should I do if CWD argument is a symbolic link? I
suppose that the right thing to do here is denying request with a 5xx
response. If this is correct why RFC959 doesn't mention such
eventuality?
8 - REST: What should I do if "REST 0" is received? Do I have to
respond with 350 and silently ignore it or do I have to return a 5xx
error?
9 - ABOR & OOB. URGENT flag required by ABOR command is a pain in the
ass not implemented into a lot of FTP client. According to this I
believe that a *good* ftp server implementation should accept also
ABOR commands with no URGENT flag set, even if this isn't RFC-
compliant. What's your opinion?
10 - ABOR: RFC959 says:
This command tells the server to abort the previous FTP"including data transfer" sounds a little bit strange to me. What does
service command and any associated transfer of data
[...]
No action is to be taken if the previous command has
been completed (including data transfer).
it mean? Maybe that if I got a QUIT "pending" (previously received
during a data-transfer) I have to "remove" it?
11 - MDTM & SIZE: almost all FTP server implementations I've seen do
implement MDTM & SIZE commands but it seems to me that it doesn't
exist any 'official' specification about them. What should I have to
do here?
12 - QUIT: if there's a transfer in progress RFC959 wants the data-
connection to remain open until the transfer is finished, then close
the command channel. While QUIT is "pending" should I have to accept
furter commands or not? If yes maybe should I have to respond with
something like "421 Service is shutting down"?
13 - RNFR/RNTO: I'd want to know if it's an RFC-compliant behaviour
let using them for MOVING files/directories instead of just RENAMING
them. What shoulda do?
14 - RNFR/RNTO: If user try to rename a file into another that already
exists what should I do? Silently rename it or reject the request with
a 5xx response warning the user the the destination file already
exists?
15 - NLST: RFC959 says:
This command causes a directory listing to be sent from serverThis is a little bit ambiguous: should I have to return only file
to user site. [...] The server will return a stream of
names of files and no other information.
names or also directory names?
16 - QUIT: RC959 tells that if a QUIT is received during a data-
transfer process the session must be closed only when the transfer is
over. My doubt is: what should I do if I receive other commands (e.g.,
PWD, STAT, and so on...) while I got a QUIT request "pending"? Should
I have to respond with 421?
17 - When I shutdown the server (e.g. SIGTERM) should I have to send
some kind of message to clients connected (e.g. "421 Service is
shutting down")?
18 - Data transferring: What should I have to do if a "transfer
command" (e.g. RETR, STOR, STOU, LIST, and so on...) is received more
than one time?
- reject it
- en queue it
- check if data transfer is already started: if yes reject it, else
delete the older transfer and start the new one.
Many thanks for your attention.
billiejoex
.
- Prev by Date: SSL/TLS ROOT Certificates
- Previous by thread: SSL/TLS ROOT Certificates
- Index(es):
Relevant Pages
|
