A FTP URL syntax is in the form of :
ftp://user:password@host:port/path
so that some or all of the parts user:password@, :password, :port and /path may be excluded. The components obey the following rules:
user
a user name (user id) on the host
password
the password corresponding to the user name; note: if the user and password field in a URL contains character : or @ or /, the character must be encoded
host
the fully qualified domain name of a network host, or its IP address
port
the port number to connect to; it omitted, defaults to 21
path
path specification of the form
cwd1/cwd2/…/cwdN/name
(where any occurrence of / or ; within a cwdi or the name must be encoded) optionally followed by
;type=typecode
where typecode is one of the characters a, i
Effectively, ;type=a means “Ascii mode” (plain text mode) of transfer
whereas ;type=i means image (binary) mode.
If the ;type=typecode part of an FTP URL is omitted, the client program interpreting the URL must guess the appropriate mode to use. In general, the data content type of a file can only be guessed from the name, e.g., from the suffix of the name; the appropriate type code to be used for transfer of the file can then be deduced from the data content of the file.
User id and password
If an FTP URL contains user and password fields, they are used in the FTP USER and PASS commands after making the connection to the FTP server. Otherwise the conventions for “anonymous” FTP are used:
· the user name anonymous is supplied
· the Internet e-mail address of the end user is supplied as the password.
However, browsers often fail to conform to these requirements. Generally, they cannot have access to the user’s correct E-mail address. In practice, browsers may send addresses with invented user name parts like mozilla or IE30user. Such “addresses” are syntactically legal in the sense of passing some tests made by an FTP server (such as checking that there is an @ somewhere) but, being fancy nonexistent addresses, fail to serve the purpose for which FTP servers like to get E-mail addresses. (Such purposes may include statistics collection or informing users about errors detected in files which they have fetched.) In some cases, the address passed is a valid address but the address of a proxy or gateway, not the address of the user.
If the URL supplies user but no password and the FTP server requests a password, the program interpreting the FTP URL (usually, a Web browser) should request a password from the user. Typically this takes place in a dialog box in which the password will not be visible as you type it (i.e., no echoing). However, some browsers (e.g., old versions of IE) do not request password from the user; instead, the connection fails.
However, IE 7 (where processing of FTP URLs is rather peculiar in many ways), ignores the user and password parts if present. It initiates a dialogue where the user is prompted for them. Any user:password data seems to trigger this; the data is otherwise discarded but taken as a request to use non-anonymous FTP. This can be treated as added security, since passing passwords in URLs is risky, as URL specifications have always said.