Re: lynx-dev Revised patch for HTFTP.c

[pg]

In a recent note, Doug Kaufman said:

> Date: Mon, 7 Aug 2000 22:28:58 -0700 (PDT)
> > 
> > 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

RFC 959 defines the protocol between server and client.  It is
indifferent to the protocol between client and user interface, and
to the protocol between server and filesystem.  So CR CR LF is
a CR to be treated as data followed by a line break.  A UNIX
server properly follows the local convention by inserting CR
before each LF in ASCII mode.  A DOS server properly follows
its local conventions by transferring ASCII files unmodified.
But I believe neither behavior is required by RFC 959.

> 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

Alas, Netscape has been notorious for guessing wrong and munging binary
files.  But I suspect this is for scheme=http.

> 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.
> 
Unfortunately, there's no automatic way specified by RFC 959 for a
client to determine whether a file is appropriately treated as ASCII
or binary; nor even whether a name refers to a base file or a
directory.  Standards superseding RFC 959 may have improved this,
but they're largely irrelevant -- anyone who cares uses http.

> 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?
>   
The requirement is that the server acting in concert with the filesystem
behind it generate standard network protocol.

> > > 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.
> 
I've been sitting on a patch for OS/390 (aka MVS) servers for a couple
years now.  :-)  Needs some polishing.  But the Big 2 also fail on
OS/390.  RFC 1738 violations rather than RFC 959.

> 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.
> 
True, and the client has no way of knowing.  ASCII if the file is meant
for display; binary for downloads is as good as any other convention.
RFC 1738 also allows this information to be present in a URL.  If
the server admin provides an index page in each directory, the ambiguity
is resolved.  (But the client must know to render the index as
text/html rather than text/plain.)

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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