Re: more FTP protocol violations

Greg Skinner (gds@sri-spam.ARPA)
Thu, 3 Apr 86 11:29:18 PST

I don't have a copy of RFC959 handy, but here's an interesting paragraph
from RFC765 on the sequencing of commands and replies.

   The table below lists alternative success and failure replies for
   each command. These must be *strictly* (emphasis mine) adhered to; a
   server may substitute text in the replies, but the meaning and action
   implied by the code numbers and by the specific command reply
   sequence cannot be altered.

And, in the sequence for DELE

      450, 550
      500, 501, 502, 421, 530

So it would seem (at least to implementors of RFC765 FTP) that the
burden of protocol correctness is on the server end. If I'm not
mistaken 4.2bsd FTP was written sometime afterwards with all the X
commands, which may account for the fact that it didn't conform to

   From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

   Several (all?) Unix server implementations send 200. This is NOT the
   correct response, and I think a user program that does look at all three
   digits is allowed to consider this a protocol violation.

Well, not all. I wrote an FTP server for a pdp11 v6 Unix once that
returned 250 for a successful delete. RFC765 seems to suggest that a
user FTP implement a FSM to interpret server replies, rather than match
on the replies themselves. Considering the fact that the requested
action is completed, independent of whether or not the response from the
DELE indicates so, it seems to be a bit nitpicky to require an exact
interpretation of the successful reply to a DELE, and also bothersome
for a user FTP to match exactly on its response. (Does anyone out there
actually examine for the grade of success?) But, of course, one should
be conservative in what one sends, etc.


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