W3C home > Mailing lists > Public > uri@w3.org > November 2004

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

From: Tony Hammond <t.hammond@nature.com>
Date: Fri, 29 Oct 2004 20:52:09 +0100
Message-Id: <04972145-29E4-11D9-A9BB-000A95B1B184@nature.com>
Cc: uri@w3.org, Paul Hoffman / IMC <phoffman@imc.org>
To: John Cowan <jcowan@reutershealth.com>

> Internet Explorer 6.0.2900.2180.xpsp_sp2_rtm.040803-2158

Now, is that version control, or is that a history book? How nuanced  
can Explorer be? No wonder it's difficult for the average consumer to  
have any real confidence. Mine's a  
'6.0.2900.2180.xpsp_sp2_rtm.040803-2158'. Pass. :)

Tony



On 29 Oct 2004, at 20:36, John Cowan wrote:

>
> 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
>




********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************
Received on Monday, 1 November 2004 09:55:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:35 GMT