One of the possible forms of a URL is a file URL, which is of the form
is the fully qualified domain name of the system on
which the path is accessible,
and path is a hierarchical
directory path of the form
As a special case,
host can be the string
localhost or the empty
string; this is interpreted as 'the machine from which the URL is
This means that on the Web such a URL is interpreted as a reference
to a file on the computer in which the Web browser runs.
Some Web page creation tools produce such
file URLs, which may
then work fine for the author, who runs a Web browser on the same
system where he keep his Web documents, but it won't work at all for
anyone else! The point is that such tools fix the URLs when they upload
the page onto a server.
Examples (warning: these probably won't work for you!):
The first example is of the general form of
with host being
The second one has host omitted; such defaulting
means that the URL refers to a file in the local computer, i.e.
in the computer where the URL is used in attempt to refer to resource.
one is similar but simpler, and it might actually work for you,
if you are using a typical Unix-like system where the file
etc/motd (relative to system's root directory, i.e.
normally referred to using
contains the system's "message of the day".
Notice that the slash character
/) is used in different
meanings in a
file URL. The
// after the
file: is part of the general syntax of URLs.
(The double slash
// should always appear in a
URL according to the specification, but in practice many Web browsers
allow you to omit it, in some cases at least.)
slash between host and path is part of the syntax
file URLs. And the slashes in path separate
directory names in a hierarchical system of directories and
subdirectories. In the last usage, the slash is a general, system-independent
way of separating the parts, and in a particular host system it might
be used as such in a pathname (as in Unix systems) or internally mapped
to another character (as to backslash
\ in MS Windows systems).
Something more complicated might happen, too; for instance, if
vms.host.edu is a host running the VMS operating system, an
might actually refer to the VMS file
On MS Windows systems, the normal colon (:)
after a device letter has sometimes been
replaced by a vertical bar (|) in
file URLs. For
example, to refer to file
FOO.BAR in the top level directory
C disk, the URL
was used. This reflected the original URL syntax, which made
the colon a reserved character in a path part.
Mozilla browsers refuse to follow file: links on a page that it has fetched with the HTTP protocol, so that the page's own URL is an http: URL. When you click on such a link, nothing happens. The purpose is presumably security: to prevent a remote page from executing a program on the visitor's computer. The file: links work on Mozilla on pages that are local files on the user's disk.
The specification which defines what (absolute) URLs are,
gives the following information about
The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet.
The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited.
Thus, you can hardly expect a
file URL to work
on the Web
locally, when the host referred to
is the same on which one uses a Web browser.
The special name
localhost or omission of the host name
file:///foo) can be used to specify such a reference.
Notice that if you have,
URL in a link
on your Web page, then a person following that link will
either see an error message or the content of
file URL is hardly useful on the Web for the
reasons explained above. Possible rare exceptions:
fileURL links to
BATfiles on PC's typically cause the file to the executed, not viewed! On the other hand, depending on the browser and its (security-related) settings, references to applications, command files etc might have to go through various checks, which perhaps ask the user for permission to execute them.
fileURLs as well. More practically, it might be the case that the Web server shares files with other computers (which allow user logins), perhaps company- or campus-wide. In such cases,
fileURLs might provide a somewhat useful way of restricting access. But in general it is better to use the access control methods provided by a Web server, such as module mod_access in Apache.