W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: FTP urls

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Tue, 06 May 1997 15:28:14 -0500 (EST)
To: josh@netscape.com
Cc: ben@algroup.co.uk, masinter@parc.xerox.com, http-wg@cuckoo.hpl.hp.com
Message-Id: <01IIJXJRFYBA0084M9@SCI.WFBR.EDU>
Josh Cohen <josh@netscape.com> wrote:
>So, 
> do most people agree with this?
>
> should a ftp url like:
> ftp://host/cwd/cwd/  be terminated with a slash?
>
> meaning that if the last component is a dir and not a 'name'
> then it isnt 'complete' and should have the slash,
> or that in absence of the slash the final componenent being
> a dir, a redirect to the slash terminated URL is prudent ?
>
>ie ftp://host/cwd/cwd/cwd
> becomes:
>   ftp://host/cwd/cwd/cwd/ vie redirect.
>
>Im restating this because I sent the original message with 
> the wrong subject.
>
>> Josh Cohen wrote:
>> > 3.2.2. FTP url-path
>> > 
>> >    The url-path of a FTP URL has the following syntax:
>> > 
>> >         <cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
>> > 
>> >    Where <cwd1> through <cwdN> and <name> are (possibly encoded) strings
>> >    and <typecode> is one of the characters "a", "i", or "d".  The part
>> >    ";type=<typecode>" may be omitted. The <cwdx> and <name> parts may be
>> >    empty. The whole url-path may be omitted, including the "/"
>> >    delimiting it from the prefix containing user, password, host, and
>> >    port.
>> > 
>> > The lynx user asserts this to mean "an ftp URL may not be terminated
>> >  by a slash "

	The Lynx user is wrong, in that the terminal slash on an ftp
path for a directory is optional, at least, historically.  Lynx, like
the great majority of deployed browsers, uses a RETR upon making a
connection and logging in to the ftp server if the URL had a path (i.e.,
was not just ftp://host or ftp://host/), and if that fails, then attempts
a listing.  It will bypass that guessing game if a ;type=[A, I or D]
parameter was present.  However, since the terminal slash is optional
(i.e., ftp://host/path is functionally identical to ftp://host/path/),
until your proxy server caused Lynx problems it would always strip the
termimal slash if a path/ was present, to avoid the possibility of ever
ending up with two stored anchor and associated structure, one with, and
one without the slash, that are functionally identical.  When your proxy
started returning redirection for ftp URLs, and to my knowledge it is
the only server in existence which does, Lynx would keep stripping the
terminal slash and end up in a redirection loop with the server until
the redirection limit was reached.  We dealt with that in current versions
by not stripping the terminal slash if a proxy is being used, and thus
living with the possibility that for proxies other than yours we might
end up with two anchor and associated structures that are functionally
for the same URL.

	The more important point, which I hope you'll take to heart, is
that by returning redirection for ftp URLs, you are causing more network
traffic and overhead than is necessary if the clients could simply play
the "try RETR, then a listing" guessing game when a terminal slash or
the type parameter is not present in the URL.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
Received on Tuesday, 6 May 1997 12:38:22 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:41 EDT