[10943] in www-talk@info.cern.ch
Re: ftp URLs and browser behaviour
daemon@ATHENA.MIT.EDU (S.N.Brodie@ecs.soton.ac.uk)
Tue Aug 19 12:13:57 1997
From: S.N.Brodie@ecs.soton.ac.uk
To: masinter@parc.xerox.com (Larry Masinter)
Date: Tue, 19 Aug 1997 17:07:09 +0100 (BST)
Cc: heaney@cambridge.scr.slb.com, www-talk@w3.org
In-Reply-To: <33F9C001.F9F60BF6@parc.xerox.com> from "Larry Masinter" at Aug 19, 97 08:47:13 am
Resent-From: www-talk@w3.org
Larry Masinter wrote:
>
> > Is there a standard solution (the URL RFC 1738 isn't clear
> > on this) or is it simply a browser implementation issue (Cyberdog
> > for example requests a username and password if anonymous fails).
It's a shame that some browser manufacturers didn't bother for follow the
specification. :-( I found that the syntax itself perfectly clear:
ftp://<user>:<password>@<host>/<url-path>
eg. ftp://username:password@hostname/path/to/object
It's just the interpreation of the <url-path> that's the problem. The
implementation in Netscape (up to and including version 3 and possibly
other browsers) diverges with the contents of RFC1738 since they tend
to pass the / that separates the host:port part from the <url-path>
part as part of the first path component. Hence all files are
referenced from the root directory visible to logged in user.
ie. ftp://username:pw@some.machine/etc/motd would attempt to read
/etc/motd rather than requiring a %2F before the 'etc'.
The result is that users cannot build URLs that reference the
given user's "home directory" on UNIX FTP servers and maybe others too.
> I think this is an area where current implementations diverge, and that
> we need to recycle the 'ftp:' scheme as a 'proposed standard' in order
> to get some convergence on it.
Surely there's no need to recycle the FTP scheme - just persuade
Netscape and others to fix their buggy products ... it's not as if
people can use non-anon FTP safely with it anyway.
--
Stewart Brodie, Electronics & Computer Science, Southampton University.
http://www.ecs.soton.ac.uk/~snb94r/
