more FTP protocol violations


Benson I. Margulies (Margulies@SCRC-YUKON.ARPA)
Thu, 3 Apr 86 07:48 EST


    Date: Wed, 2 Apr 86 17:37:01 est
    From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

       Date: Wed, 2 Apr 86 17:06 EST
       From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

           Date: Wed, 2 Apr 86 14:15:37 est
           From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

              Date: Wed, 2 Apr 86 09:36 EST
              From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>

              .....

           .....

       Wait a minute. A spec is a spec. What's the point of the two digits if
       (a) some hosts send the wrong ones, and (b) some hosts don't bother to
       look at them. If the spec said you could be lazy, then it would be OK.
       If the spec doesn't, an implementation is INCORRECT if it sends the
       wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
       more than what the spec says.

    I probably should've just done this the first time, but I had to go
    reread the spec to be sure. From RFC 959, last paragraph of page 36:

         "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,
          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)."

    And Section 6 presents some simple state machines for commands, using
    only the first digit of the code to drive them. So we can be lazy if
    we want to.

    It makes sense to me to have an error indication (first digit) and
    then a more specific error code (second digit), but it doesn't seem to
    me that we should really have to worry about "what kind of success"
    happened when there was no error, which is what the original question
    was about (4.2 returning a strange success code). So I think most user
    implementations can probably ignore the second and third digits in the
    case of success.

    Of course, if there is a "standard" response (250) to send in the case of
    success, a server should probably send that instead of something else
    that's similar but not quite the same (200). Appendix II of RFC959
    says that the correct success response to a DELE is 250.
                                            - john

I wish that someone at the NIC would mark old RFC files old. I was
reading 765 ...



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:05 GMT