ftp URL stuff (was MIME multipart/* vs HTTP)

[ about Netscape proxy ]
> The simple question is this:
> When a proxy gets a request like:
> GET ftp://host/dir/filename HTTP/1.0
> and the proxy determines that filename is actually a directory,
> ie the intent was a dir listing like:
> ftp://host/dir/
> should a proxy send a redirect to the slash terminated URL ?
> ie ftp://host/dir/filename/ ( filename is a dir, remember ).
> 
> Our proxy currently does this to preserve the clients'
> idea of the current directory..
[...]
> What happens with most versions of lynx is that for a url like:
> 
> ftp://host/dir/  ( lets say from an ftp directory listing )
> Lynx insists upon trimming the slash.
> When it submits its modified URL, the proxy returns
> a redirect, pointing back to the slash terminated URL.
> the result: redirect loop. 

Lynx's trimming of the final slash for ftp URLs was appropriate
for its internal gateway to the FTP protocol, but not for requests
sent to a proxy.  This has been changed (for the proxy case) in the
last version (2.7.1).

For the question whether a proxy *should* send such redirections...

> Our proxy currently does this to preserve the clients'
> idea of the current directory..

There isn't generally a notion of a "current remote directory" for
HTTP clients (as opposed to real FTP clients).  You only have to
make sure that the relative URLs in the text/html document generated
for a directory listing resolve to the correct absolute URLs when the
client sees them.  You could just create different relative URLs (with
an additional path segment, I believe that is what other ftp proxies
do) and/or insert a <BASE> (although some old clients may ignore that).
That may result in two different versions, with different URLs, being
seen by the client if it uses both kinds of URLs in a session, but
would avoid the necessity to send any redirects.

Netscape apparently has chosen to regard the slash-terminated form of
directory ftp URLs as "canonical", and this choice contradicts with
what some other implementations have regarded as canonical for some
time...

But all this probably hasn't much to do with the HTTP protocol...

  Klaus

Received on Tuesday, 6 May 1997 13:08:48 UTC