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

Yes - that portion of the RFC is not under question.

Sadly, the major browsers all borrowed from one source in implementing
their URL parsing for FTP, and that source was not a good reader of RFC
1738, and we are left with a situation where the URL is documented as
being relative to the logon directory, whereas the major browsers (and
really, there are few, if any, other places where FTP URLs are used)
treat it as absolute.

This distinction _usually_ doesn't matter, because the access is usually
through anonymous FTP, and that user is normally locked in to his home
directory anyway.  Unfortunately, we have the situation that noone obeys
the RFC, except for a few people starting to implement it, who then
quickly find out that noone else pays attention to it, either.

We could keep arguing that keeping the RFC the way it is allows for
access to numerous FTP platforms, or we could create an RFC that
documents URIs as they have been used for over a decade.  Going the
former route, you'll come up with the same situation - an RFC that is
worse than useless, because it tells people to try something that is
almost, but not quite, completely unlike the behaviour that everyone
else exhibits.  The latter route will produce an RFC that at least
documents the way that URIs can be generated and processed in a
compatible way with everyone else.

I've already tried the tack of persuading the browser authors to change
their code to perform as RFC 1738 dictates.  You can see how well that
worked.  I did get one triumphant email from Netscape telling me that
they'd come up with the (awful, IMHO) scheme where
"ftp://<userinfo@>site.example.com/./path1/.../pathN" would be treated
as a relative path.

Pick your favourite browser, and see how it interprets the FTP URI.  Now
weigh whether it's appropriate to try and change existing and
established behaviour, or an Internet-Draft document that's currently
being edited to replace an RFC that's about to become Historic.

As my signature indicates, I am not in the browser group here, but when
I found out that RFC 1738 was about to be replaced, I figured it was
important enough to reach a stage where the FTP URI is implemented as
documented - I can't change the implementation, but I can help change
the documentation.

Alun.
~~~~
P.S. Most FTP clients use the "/" as a path separator; hence, most FTP
servers accept it, regardless of their underlying file system.
-- 
I am the 'F' in "IIS".
 

> -----Original Message-----
> From: uri-request@w3.org [mailto:uri-request@w3.org] On 
> Behalf Of Walter Underwood
> Sent: Wednesday, September 29, 2004 7:49 AM
> To: uri@w3c.org
> Subject: Re: FTP URIs - time to document the way browsers 
> really behave?
> 
> 
> --On Tuesday, September 28, 2004 3:18 PM -0700 Alun Jones 
> <alunj@microsoft.com> wrote:
> >
> > 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.
> 
> The series of individual CWD commands is required for OS's 
> that do not use "/" as a path separator: VAX/VMS, Multics, 
> Mac OS Classic, Windows Classic, and so on.
> 
> wunder
> --
> Walter Underwood
> Principal Architect, Verity
> 
>

Received on Wednesday, 29 September 2004 23:40:04 UTC