Re: lynx-dev Revised patch for HTFTP.c

[Klaus Weide]

On Mon, 21 Aug 2000, Henry Nelson wrote:

> > Maybe it's not so good that lynx treats files of completely unknown type
> > (no suffix mappings) as text/plain by default.
> 
> If it's "not so good" why not have Lynx transfer all files of "completely
> unknown type" in binary?

A different way of answering this (nothing new, but maybe clearer):
because the way files are transferred is coupled to the way the content
is handled once it's received.  Both are determined by MIME type which
(for FTP) in turn depends on the file suffix.

That would be a nice answer, except... it isn't actually true.  It seems
to me now that it would be more correct if it were so...  (ASCII mode
transfer for all text/* MIME types, binary mode transfer for all
or most other MIME types).  But actually, lynx uses an "encoding"
property, which is kept track of separately from the MIME type
proper; and this "encoding" can be specified in SUFFIX rules in
lynx.cfg since 1999-10-21 (2.8.3dev.13) or so; and the rule is
that if "encoding" is "binary" then FTP *transfer* is by default
in binary mode, but if "encoding" is "7bit" or "8bit" then FTP
transfer is by default in ASCII mode, and the MIME type itself
does not really enter into the decision.

So it is already possible to get the behavior that DK wants,
by appropriate configuration at run time (no compile time changes
necessary): Enter SUFFIX rules that say "binary" for all text/*
types that should be transferred in binary mode.  Don't forget
rules for "file extensions" * and *.* (meaning described in lynx.cfg).

Well that doesn't give any sort of EBCDIC exemption; can't have
everything.

The above isn't actually tested; I would appreciate confirmation.


   Klaus


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