Mike,
I have been able to use the URL
ftp://ftp.mozilla.org/%2fpub%2fmozilla/nightly
using a recent nightly build of Mozilla.
Is this the URL that would not work for you with Netscape 4.x?
Perhaps this is an instance were throwing out the ftp code that Jamie
Zawinski mentioned in THE LETTER was a good thing. ; )
Adam
adam in the domain devtty.net
Mike Ruskai wrote:
> What follows is a bug report I submitted to IBM via e-mail. Since the
> problem is with Netscape, which is only tangentially an IBM product (being
> a non-OS/2-specific problem, they'll probably ignore it), I thought I'd
> post it publicly as well. I've verified its existence in NS 2.02 for
> OS/2, NS 4.61 for OS/2, and NS 4.73 for Linux. I wouldn't be surprised if
> it exists in the Mozilla project releases as well.
>
> -----
> PROBLEM DESCRIPTION:
>
> Netscape Navigator fails to properly parse FTP URL's which are of
> the format:
>
> ftp://server/%2fpath1%2fpath2/somefile.txt
>
> RFC1738 stipulates that the above URL should result in the following
> granular path component (valid for a CWD command):
>
> /path1/path2
>
> Netscape instead attempts to retrieve the following:
>
> //path1/path2/somefile.txt
>
> The key error in Netscape's behavior is that it's treating the third
> slash in the line as part of the url-path component. RFC1738
> explicitly excludes this delimiting slash from the url-path
> component.
>
> The strictly proper way to parse an FTP URL would entail the
> following behavior after login:
>
> CWD /path1/path2
> [...]
> RETR somefile.txt
>
> Here are some variations of the above URL, followed by the
> commands that would follow correct parsing:
>
> ftp://server/path1/path2/somefile.txt
>
> CWD path1
> CWD path2
> [...]
> RETR somefile.txt
>
> ftp://server/%2fpath1/path2/somefile.txt
>
> CWD /path1
> CWD path2
> [...]
> RETR somefile.txt
>
> ftp://server//path1/path2/somefile.txt
>
> CWD
> CWD path1
> CWD path2
> [...]
> RETR somefile.txt
>
> If a given server grants access to 'path2' for whatever user
> (anonymous or real) is logged in, but not 'path1', then Netscape's
> behavior prevents an administrator from providing a correct FTP URL
> to the desired file that would be compatible with Netscape.
> Providing a URL that allows Netscape to successfully download the
> file will prevent RFC-compliant clients from correctly determining
> the file's location.
> -----
> --
> - Mike
>
> Remove 'spambegone.net' and reverse to send e-mail.
>
>
>
