Re: lynx-dev FTP access bugs

[David Woolley]

Jacob wrote:
 
> ftp://ftp.numega.com/Anonymous/updates

>      * text/plain       4PM       <DIR>          BoundsChecker301

>      Server: weaver Microsoft FTP Service (Version 4.0).

> ftp://ftp.numega.com/Anonymous/updates/9PM%20%20%20%20%20%20%20
>           %3CDIR%3E%20%20%20%20%20%20%20%20%20%20SoftICE322sp
 
> 11-25-97  12:04PM       <DIR>          BoundsChecker301
> 
> I haven't check if Netscape still give me the same problem yet, but I
> think it is highly unlikely.  Anyway, it should be fixed.

This is rather more a case of the FTP site being fixed; it is unreasonable
to expect Lynx to cope with every possible variation in directory listing
style and every possible option.

The only FTP listing format that is intended for machine processing is
the nlst format, which consists only of filenames.  I don't know whether
Netscape uses this and forgoes the other information, or whether it has
additional rules to cope with this particular server product.

However, generally, changing Lynx should not be necessary in a properly
configured installation, as you should be using a proxy server, which
will take responsibility for parsing the directory listing.  (Conversely,
if you already use a proxy for ftp, that is where the problem lies.)

Having said this, it looks as though Lynx has parsed this line
in Unix format.  This is often the default for NT Servers, because of
exactly this problem of automated directory parsing.  The only code
in 2-7-2 for NT is for a third party server, can't cope with spaces in
file names and is not compiled into the code.

Looking a bit further (at HTFTP.c) it looks like the strategy used is
it issue a SYST command.  Otherwise to apply some heuristics to
the result of a PWD command.  If all else fails, it uses NLST, so that
it doesn't have a problem, assuming that the server does NLST properly.

All this is traced if you turn on tracing, so you should run Lynx with 
trace to see exactly what sort of server it thinks it is talking to.

The solution in this case might be to use SITE DIRSTYLE, to force Unix format,
or to write yet another NT directory listing parser.  Better still would be
to point out to the site that Unix ls format is about the only universally
understood directory listing format and ask them to set it as default.