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.
