Re: lynx-dev Revised patch for HTFTP.c

[pg]

In a recent note, Doug Kaufman said:

> Date: Mon, 7 Aug 2000 19:07:39 -0700 (PDT)
> 
> 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

Nor does it explicitly prohibit adding five CRs to the end of each
line.  Nor appending 100 HT characters to the end of each line.
Nor inserting a NUL between each pair of characters.  Yet I believe
the presumption is that except for representing each line break
as the canonical CR LF, the characters in the text should be
transferred otherwise unmodified.  Otherwise you subscribe to the
Judge Roy Beane thought mode ("I red the law from cover to cover,
and I cain't find no law agin killin no [ethnic pejorative].
Case dismissed.")

> 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.
> 
An attempt to accommodate such broken UNIX sites by ignoring the
extra CR would frustrate the error recovery which presumably
works for broken Macintosh servers which may transmit a line break
as merely CR.

> 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.
> 
Some FTP servers might correct for files which violate the host
conventions.  Clearly my proxy (Netscape, I believe) adopts a
different error recovery, and masked the problem on your test cases.

> 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.
> 
What would this do to Macintosh files, which represent line breaks as
simply CR?  And OS/390, which supports both a Legacy file system which
looks to Lynx much like CMS (In binary, the line breaks are out-of-band
and lost) and a POSIX filesystem.  Both are EBCDIC rather than ASCII;
and only the server can make an informed decision which it's dealing
with.

I'm pretty chilly to introducing complexity into clients to accommodate
(and thereby encourage) broken hosts.  Follow the RFC and complain to
the administrators of broken sites.  They're broken for old-fashioned
command-line FTP, anyway.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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