Re: lynx-dev Revised patch for HTFTP.c

[Doug Kaufman]

On Mon, 7 Aug 2000, Klaus Weide wrote:

> I also saw the CR CR LF line endings when the test file was transmitted,
> using tcpdump.  Transmitting text line ends as CR CR LF in ASCII mode is a
> violation of the FTP protocol, which says that line ends are transmitted
> on the wire as CR LF.  The responsibility for this is on the server side.

I tried looking at the RFCs regarding FTP. Clearly, in ASCII mode
line endings must be CR LF. I don't see where it says that inserting
an extra CR in the text is a violation of the protocol. Indeed, if
these were interpreted literally, the document being viewed would be
unchanged, since the carriage would be returned to the left twice in
a row, but no extra linefeed generated. In lynx, I think that the
rendering problem comes from HTML_put_character, which translates 
CR LF to LF and translates an isolated CR to LF. Hence lynx translates
CR CR LF to LF LF. On a line mode printer the ASCII text transmitted
would be printed correctly.

By the way, is this only a problem with certain FTP server
implementations, or is this a general problem for all FTP servers?
Perhaps someone with access to FTP servers can check this with other
implementations.

>From a practical point of view, is there ever any time (except when
accessing a CMS server) when lynx needs to get a file for rendering on
screen in ASCII mode? If not, getting in binary mode takes care of the
problem.
                             Doug
__ 
Doug Kaufman
Internet: address@hidden


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden