Re: ftp URLs and browser behaviour

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/

Received on Tuesday, 19 August 1997 12:09:40 UTC