lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev RFC959 non-compliance in Lynx hangs the client


From: David Woolley
Subject: Re: lynx-dev RFC959 non-compliance in Lynx hangs the client
Date: Sun, 12 Sep 1999 10:38:52 +0100 (BST)

> > Lynx will be doing an RETR here because it doesn't know that the
> > initial, forced, / is a directory.  The CWD is actually error
> > recovery in Lynx.
> 
> Well it should.  That is, if you're reading the RFCs.

I've now re-read RFC 1738 and the CWD is definitely error recovery.
In fact, it looks like the common convention of interpreting URLs with
a trailing / as directories is questionable - it depends on how liberally
you interpret:

3.2.3. FTP Typecode is Optional

   The entire ;type=<typecode> part of a FTP URL is optional. If it is
   omitted, the client program interpreting the URL must guess the
   appropriate mode to use. In general, the data content type of a file
   can only be guessed from the name, e.g., from the suffix of the name;
   the appropriate type code to be used for transfer of the file can
   then be deduced from the data content of the file.

Even this doesn't require a retry if the initial type code appears wrong.

As far as I can tell, the only sure way of getting a directory listing
of the root directory on Unix is:

ftp://host.domain/%2F;type=d

although you would need to use:

ftp://host.domain/%2F/;type=d

to be sure of safely using relative URLs, and you would need the trailing
/ to ensure that any type=d heuristic was triggered.

Note that using %2F is well defined for a Unix server; I may have suggested
otherwise before.

I'm not happy with my interpretation of the 2.7.2 Lynx source with respect
to persistent connections after a type=d operation on default (i.e. Unix)
servers.

reply via email to

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