18 answers about FTP protocol (really long) - TCP-IP

This is a discussion on 18 answers about FTP protocol (really long) - TCP-IP ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: 18 answers about FTP protocol (really long)

  1. 18 answers about FTP protocol (really long)

    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
    > service command and any associated transfer of data
    > [...]
    > No action is to be taken if the previous command has
    > been completed (including data transfer).

    "including data transfer" sounds a little bit strange to me. What does
    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 server
    > to user site. [...] The server will return a stream of
    > names of files and no other information.

    This is a little bit ambiguous: should I have to return only file
    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


  2. Re: 18 answers about FTP protocol (really long)


    "billiejoex" wrote in message
    news:1183063950.549542.168440@q69g2000hsb.googlegr oups.com...
    > 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
    >

    :
    >
    > 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?
    >


    RFC 3659 documents the MDTM and SIZE commands.

    http://www.ietf.org/rfc/rfc3659.txt?number=3659



+ Reply to Thread