Re: lynx-dev Revised patch for HTFTP.c

[Doug Kaufman]

On Mon, 7 Aug 2000 address@hidden wrote:

> 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.
> ...

Point taken. I am still not sure that a server is broken when it
ensures CR LF eol by inserting a CR before each LF. How can it be
sure that this is not a unix file containing embedded text with CR
as meaningful characters? Under the FTP protocol the client must
specify whether to get in ASCII or image mode. Servers default to
ASCII mode on connection. Users are supposed to know when they are
obtaining a binary file and instruct the server to switch modes. It
was because of lack of user attention to mode that there were so
many bad downloads of binary files (transferred incorrectly in ascii
mode) before downloading via web browsers became common. If lynx
specifically requests a file and leaves the browser in ascii mode when
this is inappropriate, I would think that this is an error by lynx.

I am also not willing to accept the assertion that text files on a
server should necessarily be in the default eol mode for that server.
I don't know that this has ever been the case. I am thinking about all
the unix and DOS files that had been served from VAX machines when
BITNET was quite popular, and the DOS files from Simtel when it was
on a TOPS-20 machine at White Sands Missle Range (ftp in tenex mode).
When did this need to match server with files come about?
  
> > 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 think that lynx handles Macintosh files for display. If I read the
code correctly, it converts "CR LF" to "LF" and converts isolated "CR"
to "LF" when rendering. Lynx downloads from all these servers (except
CMS servers) have been binary. It is only when viewing the file online
that the ascii transfer occurs. Do downloads of files from OS/390
servers fail now? Unless they are interpreted as CMS servers by lynx,
downloads should now be in binary mode. If they are interpreted as CMS
servers, then my patch should not affect them.

It seems that one of the basic questions here is "Who is responsible
for determining the mode of transfer under ftp, the server or the
client?". My understanding is that it has always been the client.

Corrections to any of this cheerfully taken.
                                 Doug

__ 
Doug Kaufman
Internet: address@hidden


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