[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Revised patch for HTFTP.c

From: Klaus Weide
Subject: Re: lynx-dev Revised patch for HTFTP.c
Date: Sun, 20 Aug 2000 14:20:03 -0500 (CDT)

On Sat, 19 Aug 2000, Doug Kaufman wrote:

> On Sat, 19 Aug 2000 address@hidden wrote:
> > Me too.  Accommodating broken servers can only serve to encourage them.
> This is only true if you have some clout with those who make the
> servers. I doubt that lynx does, other than as a voice in the
> wilderness asking for adherence to standards.
> I still don't see where any servers are broken. 

I don't see how you can continue to say that, after it has been shown
that some servers send CRCRLF in ASCII mode in place of a line break.
That's so obviously broken - what more do you want?

Maybe you understand server in a different way than I.  What I mean
with "server" is the entity with which the FTP client interacts, as
it can be observed in its behavior during interaction.  It doens't matter
whether the server software daemon ("server" in some narrower sense) is
broken, or the setup is misconfigured, or both - the observable behavior
of the server is broken.

> I thought that we
> had agreed (correct me if I am in error) that the responsibility for
> deciding mode of transfer is held by the client. It seems that lynx
> is specifically requesting transfer in ascii mode of files which are
> not "text" files, if "text" is defined as being in the native text
> format of the server. 

"Text files" means "text files", textual in nature, or in MIME terms, 
anything that would be correctly labelled as a "text/*" media type (after
possibly some canonicalization).  It's a property of the content, not
of a specific representation (which may be "native" or not on a given

That's how I understand it...

> Any other files should be considered binary,
> including files with DOS EOLs residing on a unix server. The problem
> is that lynx is requesting them in ascii transfer mode, which is
> inappropriate.

All lynx has to go by for making the decision A vs. I is
(1) suffix mappings
(2) explicit ";type=[I|A]" parameter in URL
(3) some information about the FTP server that comes to light during the
    connection (i.e., does it identify itself as Unix?  DOS?  something
    else?  nothing recognizable at all?)

In the absense of an explicit directive of form (2), it makes sense to let
the transfer mode be determined by suffix (file extension) rules.  File
suffixes are not standardized, but they're the best we've got for FTP
(and other protocols that don't carry MIME information); there are *some*
reasonably reliable conventions (for example: ".txt" means "text"); and
after all, we're already basing the decision what to do with the contents
(render? download? invoke viewer?) on the suffix, so if it's reliable
enough for _that_ we ought to be able to trust it for the A vs I decision.

I believe that's basically what HTFTP.c does, as in
     format = HTFileFormat(filename, &encoding, NULL);

Now, given that the file suffix plays this role - and assuming an FTP
server that doesn't try to intentionally confuse, but is configured to
support existing conventions -
     should mean TEXT.  No additional information about the server (its
     native file format etc.) is needed.  Since this is a URL for a TEXT
     document, it should af course be downloaded in ASCII mode.
If OTOH the FTP server wants to offer files-that-are-really-TEXT but
for some reason wants to offer them as binary - then it should not
confuse clients by calling those files .txt.  They should be
instead - or some other suffix that does (by hopefully widely understood
convention) NOT imply text/plain.

Maybe it's not so good that lynx treats files of completely unknown type
(no suffix mappings) as text/plain by default.

IMO, (3) should ideally play no role at all.  It just shouldn't be
necessary.  It's all unreliable information, I don't think there is
a reliable way to determine that a server is (for example) "Mac, DOS,
or UNIX" or not.

> Note that the current implementation does this ONLY
> when the files are to be rendered on screen. "lynx -dump" of these
> same files retrieves them in binary and send the rendered version to
> standard output. 

Indeed, that is inconsistent.  For consistency, -dump should probably not
automatically imply binary mode, but should be consistent with the
normal rendering logic.

I had suggested (via the patch) to make the default
> transfer mode binary, since lynx has no need of the file conversion
> done by the server.

... in the special (although frequent) cases that you are thinking of.

> Ascii transfer could still be done by adding
> ";type=A" to the URL.

Yes, but that shouldn't be necessary in order to retrieve a ".txt" file
from any server type (even unknown) in the right mode, which is ASCII.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]