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: [EMAIL PROTECTED]
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
