RE: Are we done with draft-hoffman-ftp-uri-02.txt?

Did you check the commands going over the wire, or just the effect of
whether it could, or could not, fetch the file?

I posted some results earlier about what I found when testing, and at
that time, Firefox, Mozilla and Netscape all behaved just like Internet
Explorer.  Netscape and Mozilla have behaved that way for, oh, about the
last decade, having copied the behaviour over from NCSA Mosaic.

Thanks for noting that there are other FTP clients out there that handle
FTP URIs - I had only seen the browsers' behaviour to date, and it's
interesting to note that there are other FTP clients out there that may
be behaving differently.

Sadly we've now got a situation where a sensible RFC is up against
several implementations that over the last ten years have diverged into
two separate camps - helped largely by the way in which most FTP URIs
have been specified - as anonymous access to paths whose roots happen to
be the same as their initial logon directories.

This sucks for two groups of people:
A) implementors of FTP clients, who now have to choose between the
documented standard, or a popular and contradictory implementation.
B) people who wish to send FTP URL references out, as they now either
have to send out two conflicting versions of their URLs, or ensure that
every URL is to a user whose login path is his root directory.

[Server authors, such as myself, aren't going to care much either way;
all we see is a CWD or a RETR that we can approve or not, depending on
how we interpret the path.]

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

> -----Original Message-----
> From: uri-request@w3.org [mailto:uri-request@w3.org] On 
> Behalf Of John Cowan
> Sent: Friday, October 29, 2004 12:37 PM
> To: Paul Hoffman / IMC
> Cc: uri@w3.org
> Subject: Re: Are we done with draft-hoffman-ftp-uri-02.txt?
> 
> 
> Paul Hoffman / IMC scripsit:
> 
> > >"Developers of new FTP client implementations that consume FTP URIs
> > >should attempt access to the file using the slash-prefixed
> > >('/<cwd1>...') path first, and only use the format 
> specified in RFC 1738
> > >('<cwd1>...') if that operation fails."
> > 
> > This works for me; how do others feel?
> 
> I strongly disagree.  In particular, the following URI 
> produces different
> results when tested with Mozilla Firefox 1.0rc1 and Internet Explorer
> 6.0.2900.2180.xpsp_sp2_rtm.040803-2158, my two current browsers:
> 
> 	ftp://stamber:stamber@publish.reutershealth.com/ftptest.txt
> 
> Mozilla conforms to the RFC, whereas IE does not.  Neither 
> one returns an
> error of any kind.  (Note that the user 
> stamber@publish.reutershealth.com
> is *not* automatically confined to a subtree.  I will remove 
> this account
> in a few days.)
> 
> I also tested some command-line Linux (Fedora Core 2) programs that
> understand FTP URIs.  Lynx 2.8.5dev.16 does not conform to the RFC,
> but NcFTPGet 3.1.7, curl 7.11.1, and wget 1.9 do conform.  Given this
> diversity of behavior, I don't think it's appropriate to recommend
> the non-conformant interpretation, but simply to note that there are a
> considerable number of non-conformant clients of the specified type.
> 
> I note that all the clients correctly interpret the URIs
> ftp://stamber:stamber@publish.reutershealth.com/%2Fftptest.txt and
> ftp://stamber:stamber@publish.reutershealth.com/%2Fexport/home
> /stamber/ftptest.txt
> since %2F is an uninterpreted slash and /export/home/stamber 
> is stamber's
> home directory.  These results of course depend on the fact that the
> server, which is the native Solaris 8 in.ftpd server, interprets a
> leading / as reaching the root directory of publish.reutershealth.com.
> 
> In any case, "server implementers" are not the people who 
> need to be aware
> of this; rather it is FTP client implementers who understand 
> RFCs who should
> care, and users of FTP URIs who are likely to be hosed by the 
> diverse behavior.
> 
> -- 
> The man that wanders far                        
> jcowan@reutershealth.com
> from the walking tree                           
> http://www.reutershealth.com
>         --first line of a non-existent poem by:         John Cowan
> 
>

Received on Sunday, 31 October 2004 23:24:12 UTC