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

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

From: Alun Jones <alunj@microsoft.com>
Date: Mon, 1 Nov 2004 09:07:23 -0800
Message-ID: <0966E90CB313084DA7A9C55799FDEFD203004836@RED-MSG-50.redmond.corp.microsoft.com>
To: "John Cowan" <jcowan@reutershealth.com>
Cc: <uri@w3.org>

> -----Original Message-----
> From: John Cowan [mailto:jcowan@reutershealth.com] 
> Alun Jones scripsit:
> > Did you check the commands going over the wire,
> No.  When I say "conformant", I mean that the results are conformant,
> not necessarily the method used.

The commands are important to check, too - as well as the behaviour of
the client under failure to find the file.  There are a couple of goals
we could have in this situation:

1. Find a 'best operation' and impose it on all - that's not exactly
friendly, but may be the best approach, since it is a purpose of RFCs to
standardise behaviour.  Unfortunately, many implementors have already
either ignored or poorly implemented the existing RFC, so this approach
may be doomed to a similar failure.

2. Find an approach that allows URLs to work on the majority of clients
- this would mean taking failover operation into account.  If the
majority of clients that use operation A first, and fail over to
operation B, while the majority of clients that use operation B fail to
fail over to anything, let alone A, it would make sense to set operation
B as the standard, as it would allow future URLs to work on the majority
of clients.

Goal 1 is likely to result in a lot of argument and no consensus.  Goal
2 may be more easily achievable, but requires observation of what a
client will do in the event that it cannot find the file using its first
method of access.

> Depending on the behavior, it will actually fetch one of two different
> files, locally known as /ftptest.txt and 
> /export/home/stamber/ftptest.txt.
> I urge people to try the URI, which I repeat here, with 
> various different
> tools: http://stamber:stamber@publish.reutershealth.com/ftptest.txt .

Interesting typo :-)

I'm inserting another copy of my previous test results, as it appears
from your comments that you're missing these:

IE 6 (Windows Server 2003 RTM) - "ftp://localhost/ie6/path"

CWD /ie6/
CWD /ie6/
CWD /ie6/path/
CWD /ie6/path/

Mozilla 1.7 - "ftp://localhost/mozilla1_7/path"

SIZE /mozilla1_7/path
MDTM /mozilla1_7/path
RETR /mozilla1_7/path
CWD /mozilla1_7/path

Firefox 1.0 preview - "ftp://localhost/firefox1_0p/path"

SIZE /firefox1_0p/path
MDTM /firefox1_0p/path
RETR /firefox1_0p/path
CWD /firefox1_0p/path

Netscape 7.2 - "ftp://localhost/netscape7_2/path"

SIZE /netscape7_2/path
MDTM /netscape7_2/path
RETR /netscape7_2/path
CWD /netscape7_2/path

Opera 7.54 - "ftp://localhost/opera7_54/path"

SIZE opera7_54/path
CWD opera7_54/path
SIZE opera7_54
CWD opera7_54

The "Firefox 1.0 preview" version above bills itself as version 0.10.1.
Obviously, that's the version I downloaded when I did the original

It now seems, from your results and mine combined, that the behaviour of
FTP implementations isn't as simple as choosing one or other behaviour -
that some implementations flip between one behaviour and another, based
on some internal logic (undocumented, as far as I can tell, without
looking at source code - which would be inappropriate for me to do).

It's possible that the Mozilla crew are taking one behaviour when the
user name is not supplied, and a different behaviour when it is.

> Well, FWIW, K-Meleon 0.8.2 (which is based on Mozilla 1.5) shows
> the same behavior as Firefox: conformant.  I don't know what versions
> of Netscape and Mozilla you were looking at.

Try your browsers with the URLs I was using - see if you can reproduce
my behaviour.  I can promise you that I was not inventing output!

> > This sucks for two groups of people:
> Exactly so.

I left out another group:

3. Those of us that care enough to see FTP continue its widespread use,
but are irritated that there doesn't seem to be a standard on how to
process URLs. :-)

I am the 'F' in "IIS".
Received on Monday, 1 November 2004 17:09:44 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:46 UTC