In a recent note, David Woolley said:
> Date: Tue, 20 Nov 2001 22:22:46 +0000 (GMT)
>
> > RFC 1738 specifies URL handling by the client that avoids such
> > mapping. Unfortunately, the Big Two flout RFC 1738 here, and
>
> I consider the awkward, step by step, directory changing to be such
> a mapping. FTP makes no pretence that it understands the structure
> at all.
>
RFC 1738 handles this. If you wish to change the directory in a
single step, simply encode the slashes as %2F.
I am very biased to the RFC here. I deal regularly with some
FTP servers for which either '/' is utterly prohibited in a path,
or for which at least some paths are accessible only via paths
with no '/'. The RFC allows me to access any file on those
servers. The Big Two won't because they disobey it; in essence
the client is pretending to understand the server's structure.
> > Lynx goes with the flow unless the server identifies itself as VAX.
>
> The flow includes some clients that seem to try and back up the
> current directory on a persistent connection, which doesn't work
> when there are symbolic links or the initial directory isn't
> the effective root (depending on whether they try ../ or / prefixes).
> I hope lynx doesn't do this.
>
RFC 1738 specifies that paths should begin at the default home
directory for USER@HOST, as supported by FTP. I.e. the URL
ftp://USER@HOST/file
should retrieve the same file as:
ftp HOST
user USER
get file
unfortunately, the Big two implement the equivalent of:
ftp HOST
user USER
cd / # Illegal on some systems!
get file
or, in RFC1738 parlance:
ftp://USER@HOST/%2F/file
-- gil
--
StorageTek
INFORMATION made POWERFUL
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
