Re: FTP urls

> 	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.
> 
Technically we cause a 2nd connection, so we do increase traffic.
However, when the client is speaking via a proxy, it doesnt do
the RETR, it simply speaks HTTP, not FTP to the proxy.
The proxy takes care of the FTP

The other factor in deciding to do this is the clients perception
of the working directory.  When the client is speaking FTP, ie no
proxy, it can adjust its perception of the working directory
when RETR fails, but with a proxy this doesnt work.
Since the proxy is doing the FTP, if it doesnt let the
client know that the cwd has changed, the client will
mis-represent relative links..
Here are some comments I had with the lynx user:

When you get a redirect, you should never modify it.
If the proxy ( or origin server ) wants you to use a slash, do it.
The server meant to do that, else it wouldnt have sent a redirect.

The proxy isnt blindly sending redirects..
the steps it follows are :
When given an FTP URL: ftp://host/dir1/dir2/name

1) It connects to the ftp server with appropriate user/pw
2) does a CWD into dir1/dir2
3) does a RETR on 'name' 
4) if name is a file, then that it returned.
-- note that according to the client, the current working directory
   is /dir1/dir2/
5) if name is a directory, the server will respond with error
   550: not a regular file
6) the proxy realizes this is a directory.
7) SEND redirect to slash terminated URL ie ftp://host/dir1/dir2/name/

if the redirect isnt sent, as you seem to recommend, then the problem
 becomes:
 (dont send the redirect, just cd into the directory)
8) CWD into name
9) do 'DIR'
the proxy has done a CWD that the client isnt aware of.
The proxy has changed into a new dir 'name'.
When the client reads the directory listings ie:

./foo
./dev/ ( another dir )
./index.html

it will assume something like:
ftp://host/dir1/dir2/index.html
when actually it should be:
ftp://host/dir1/dir2/name/index.html

This is the same thing as in HTTP ie:
http://www.foo.com/docs

How do you know if docs is a directory or a file?

the redirect says to the client:
"hey, you have to cd before you can look in here"

consider in unix:
the directory:
/home/users/josh/docs/
with the file foo.html in it.

pretend your the proxy..
The client gives the URL:
ftp://host/home/users/josh/docs
( the intent is to list the docs directory )
URL=/home/users/josh/

Hmm, looks like 
/% cd /home/users/josh
/home/users/josh/% cat docs
cat: input error on docs: Is a directory
/home/users/josh/% ls josh
blah
foo.html
blah
( this is the user clicking on or selecting a file returned from the
  first transaction )
/home/users/josh/% cat ./foo.html (($URL)/foo.html)
cat: cannot open foo.html

To summarize, with a proxy, this is all transparent, the client
doesnt know that the cwd has changed, only the proxy does.
This will break the operation of relative links.

(yes, the NS proxy is extra careful and qualifies all ftp links
it generates to avoid confusion )

> 				Fote
> 
> =========================================================================
>  Foteos Macrides            Worcester Foundation for Biomedical Research
>  MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
> =========================================================================


-----------------------------------------------------------------------------
Josh Cohen				        Netscape Communications Corp.
Netscape Fire Department	               "My opinions, not Netscape's"
Server Engineering
josh@netscape.com                       http://home.netscape.com/people/josh/
-----------------------------------------------------------------------------

Received on Tuesday, 6 May 1997 13:12:32 UTC