Date:    Wed, 11 Mar 1998 15:52:39 CST
To:      ftp@tripod.com

From:    Travis H <travish@dejanews.com>
Subject: bug in your FTP server

X-PGP-keyid: C7FDD3D5
X-PGP-fingerprint: 7A 48 DD 46 E6 7F 11 E7  8F 7E 53 9A DF 33 9E FA
X-Copyright: Copyright (c) 1998 travish@dejanews.com
X-Disclaimer: This email is my personal opinion only.
X-URI:   <URL:http://www.tripod.com/~travcom>

> travish@hostname 4 bash$ echo quit | nc ftp.tripod.com ftp | od -c
> 0000000   2   2   0      \n   2   2   1       G   o   o   d   b   y   e
> 0000020   !           H   a   v   e       s   e   v   e   r   a   l    
> 0000040   n   i   c   e       d   a   y   s   .   .   .  \r  \n
> 0000056

As one can see clearly above, your FTP server is using a bare linefeed
for end-of-line.  This is incorrect and causes some clients to hang.

Quoting from <URL:http://www.cis.ohio-state.edu/htbin/rfc/rfc959.html>:

> A reply is defined to contain the 3-digit code, followed by Space
> <SP>, followed by one line of text (where some maximum line length
> has been specified), and terminated by the Telnet end-of-line
> code.

As everybody should know, the telnet end-of-line code is a
carriage-return followed by a linefeed.  Yes, it is spooky MS-DOS,
line-printer crap.  Quoting from
<URL:http://www.cis.ohio-state.edu/htbin/rfc/rfc854.html>:

> The sequence "CR LF", as defined, will cause the NVT to be
> positioned at the left margin of the next print line (as would,
> for example, the sequence "LF CR").  However, many systems and
> terminals do not treat CR and LF independently, and will have to
> go to some effort to simulate their effect.  (For example, some
> terminals do not have a CR independent of the LF, but on such
> terminals it may be possible to simulate a CR by backspacing.)
> Therefore, the sequence "CR LF" must be treated as a single "new
> line" character and used whenever their combined action is
> intended; the sequence "CR NUL" must be used where a carriage
> return alone is actually desired; and the CR character must be
> avoided in other contexts.  This rule gives assurance to systems
> which must decide whether to perform a "new line" function or a
> multiple-backspace that the TELNET stream contains a character
> following a CR that will allow a rational decision.
>
>    Note that "CR LF" or "CR NUL" is required in both directions
>    (in the default ASCII mode), to preserve the symmetry of the
>    NVT model.  Even though it may be known in some situations
>    (e.g., with remote echo and suppress go ahead options in
>    effect) that characters are not being sent to an actual
>    printer, nonetheless, for the sake of consistency, the protocol
>    requires that a NUL be inserted following a CR not followed by
>    a LF in the data stream.  The converse of this is that a NUL
>    received in the data stream after a CR (in the absence of
>    options negotiations which explicitly specify otherwise) should
>    be stripped out prior to applying the NVT to local character
>    set mapping.

I don't normally debug other people's code for them, but it was more
trouble to set up another home page.  I spent about an hour on this,
most of it trying to figure out why the client was hanging.

Unfortunately, bad implementations on the net are the rule rather
than the exception, and pointing out their faults seems to yield
hostility more often than gratitude.  Sigh.
--
Travis H, Database Administrator
More funky styles than Adobe has fonts