FTP URIs - time to document the way browsers really behave?

Now that RFC 1738 is being "Historicalised", and the individual
protocols split out into their separate documents, is it appropriate to
start documenting the way in which FTP URIs are _actually_ applied in
the real world?

As I remember it (this is going back some way, and I'm not associated
with browser development, so it's very much an "outsider's view"),
Mosaic used a "liburl" that misunderstood the FTP URI spec from RFC
1738, and everyone copied Mosaic's behaviour (either directly, or by
observing).  As a result we have the following situation:

ftp://<userinfo>:<host>/path1/.../pathN is read as "log on to <host>
with credentials from <userinfo>, and either CWD to /path1/.../pathN, or
RETR /path1/.../pathN".

Now, the RFC 1738 rule says you should log on to <host> as <userinfo>,
and enter separate CWD commands for each pathM element from 1 to N, with
the possibility of issuing a RETR on pathN if the CWD fails - but notice
that this usually has the same result as CWD path1/.../pathN, or RETR
path1/.../pathN.

Yes, that's slightly different - the paths in the first case are all
absolute, those in the second case are all relative.

For most real-world uses, this is the same thing, because FTP URLs
default to anonymous access, and the anonymous user is generally locked
into what many of you know as a "chroot jail".  In such a situation,
relative and absolute are the same.  This situation went largely
unnoticed, presumably until it was too late to make a change to the
browsers' behaviour to conform to RFC 1738.

So now we have the situation that URLs don't work the way they're
documented to - and coincidentally, a chance to change the documentation
to represent a reality that has proved remarkably resistant to efforts
to bring it back in line with the documentation.

Is it possible to address this in the FTP URI document?

Alun.
~~~~
-- 
I am the 'F' in "IIS".

Received on Tuesday, 28 September 2004 22:20:46 UTC