Apache HTTP Server Version 2.0
This document explains how Apache uses the URL of a request to determine the filesystem location from which to serve a file.
Related Modules | Related Directives |
---|---|
In deciding what file to serve for a given request, Apache's
default behavior is to take the URL-Path for the request (the part
of the URL following the hostname and port) and add it to the end
of the DocumentRoot
specified
in your configuration files. Therefore, the files and directories
underneath the DocumentRoot
make up the basic document tree which will be visible from the
web.
Apache is also capable of Virtual
Hosting, where the server receives requests for more than one
host. In this case, a different DocumentRoot
can be specified for each
virtual host, or alternatively, the directives provided by the
module mod_vhost_alias
can
be used to dynamically determine the appropriate place from which
to serve content based on the requested IP address or
hostname.
There are frequently circumstances where it is necessary to
allow web access to parts of the filesystem that are not strictly
underneath the DocumentRoot
. Apache offers several
different ways to accomplish this. On Unix systems, symbolic links
can bring other parts of the filesystem under the DocumentRoot
. For security reasons,
Apache will follow symbolic links only if the Options
setting for the relevant
directory includes FollowSymLinks
or
SymLinksIfOwnerMatch
.
Alternatively, the Alias
directive will map any part
of the filesystem into the web space. For example, with
Alias /docs /var/web
the URL http://www.example.com/docs/dir/file.html
will be served from /var/web/dir/file.html
. The
ScriptAlias
directive
works the same way, with the additional effect that all content
located at the target path is treated as CGI scripts.
For situations where you require additional flexibility, you
can use the AliasMatch
and
ScriptAliasMatch
directives to do powerful regular-expression based matching and
substitution. For example,
ScriptAliasMatch ^/~([a-zA-Z0-9]*)/cgi-bin/(.*)
/home/$1/cgi-bin/$2
will map a request to
http://example.com/~user/cgi-bin/script.cgi
to the
path /home/user/cgi-bin/script.cgi
and will treat
the resulting file as a CGI script.
Traditionally on Unix systems, the home directory of a
particular user can be referred to as
~user/
. The module mod_userdir
extends this idea to the web by allowing files under each user's
home directory to be accessed using URLs such as the
following.
http://www.example.com/~user/file.html
For security reasons, it is inappropriate to give direct
access to a user's home directory from the web. Therefore, the
UserDir
directive
specifies a directory underneath the user's home directory
where web files are located. Using the default setting of
Userdir public_html
, the above URL maps to a file
at a directory like
/home/user/public_html/file.html
where
/home/user/
is the user's home directory as
specified in /etc/passwd
.
There are also several other forms of the
Userdir
directive which you can use on systems
where /etc/passwd
does not contain the location of
the home directory.
Some people find the "~" symbol (which is often encoded on the
web as %7e
) to be awkward and prefer to use an
alternate string to represent user directories. This functionality
is not supported by mod_userdir. However, if users' home
directories are structured in a regular way, then it is possible
to use the AliasMatch
directive to achieve the desired effect. For example, to make
http://www.example.com/upages/user/file.html
map to
/home/user/public_html/file.html
, use the following
AliasMatch
directive:
AliasMatch ^/upages/([a-zA-Z0-9]*)/?(.*)
/home/$1/public_html/$2
The configuration directives discussed in the above sections
tell Apache to get content from a specific place in the filesystem
and return it to the client. Sometimes, it is desirable instead to
inform the client that the requested content is located at a
different URL, and instruct the client to make a new request with
the new URL. This is called redirection and is
implemented by the Redirect
directive. For example, if
the contents of the directory /foo/
under the
DocumentRoot
are moved
to the new directory /bar/
, you can instruct clients
to request the content at the new location as follows:
Redirect permanent /foo/
http://www.example.com/bar/
This will redirect any URL-Path starting in
/foo/
to the same URL path on the
www.example.com
server with /bar/
substituted for /foo/
. You can redirect clients to
any server, not only the origin server.
Apache also provides a RedirectMatch
directive for more
complicated rewriting problems. For example, to redirect requests
for the site home page to a different site, but leave all other
requests alone, use the following configuration:
RedirectMatch permanent ^/$
http://www.example.com/startpage.html
Alternatively, to temporarily redirect all pages on a site to one particular page, use the following:
RedirectMatch temp .*
http://www.example.com/startpage.html
Apache also allows you to bring remote documents into the URL space of the local server. This technique is called reverse proxying because the web server acts like a proxy server by fetching the documents from a remote server and returning them to the client. It is different from normal proxying because, to the client, it appears the documents originate at the reverse proxy server.
In the following example, when clients request documents under the
/foo/
directory, the server fetches those documents from
the /bar/
directory on internal.example.com
and returns them to the client as if they were from the local
server.
ProxyPass /foo/ http://internal.example.com/bar/
ProxyPassReverse /foo/ http://internal.example.com/bar/
The ProxyPass
configures
the server to fetch the appropriate documents, while the
ProxyPassReverse
directive rewrites redirects originating at
internal.examle.com
so that they target the appropriate
directory on the local server. It is important to note, however, that
links inside the documents will not be rewritten. So any absolute
links on internal.example.com
will result in the client
breaking out of the proxy server and requesting direHTTP/1.1 200 OK
Date: Mon, 07 Jul 2025 05:33:32 GMT
Server: Apache/2.0.42 (Win32) PHP/5.2.10
Content-Location: urlmapping.html.en
Vary: negotiate,accept-language,accept-charset
TCN: choice
Accept-Ranges: bytes
Content-Length: 18472
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=ISO-8859-1
Content-Language: en
Apache HTTP Server Version 2.0
This document explains how Apache uses the URL of a request to determine the filesystem location from which to serve a file.
Related Modules | Related Directives |
---|---|