Re: MIME multipart/* vs HTTP

Josh Cohen (josh@netscape.com)
Tue, 6 May 1997 08:19:21 -0700 (PDT) 

---LA_F2155476414R-3A-862931962=:18604NCE.IlHAFeR
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

Please read the following attachment..

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


---LA_F2155476414R-3A-862931962=:18604NCE.IlHAFeR
Content-Type: TEXT/plain; name="lynx.wg"; charset=us-ascii
Content-Description: default

Greetings,

	I've recently been made aware of a situation with
Lynx interoperating with our proxy server.  The issue surrounds
ftp urls and redirections.  We've gone back and forth a bit,
and looked at the URL spec ( rfc 1738 ), but I dont think the
spec is clear in its intent, so Im asking you folks :)

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

The details.
The spec says:

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 "
My take is that this is true when the URL is a 'complete' url, 
when name is not another cwdN, but a filename.
When the url is just ftp://cwd/cwd/cwd   ( no slash )
the proxy should redirect the client to:
 ftp://cwd/cwd/cwd/

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.

My gut tells me that the client shouldnt be altering the
URL it got from the server initially ( trimming the slash )
and *definitely* shouldnt be trimming the redirect.

Thoughts?


---LA_F2155476414R-3A-862931962=:18604NCE.IlHAFeR--