<-
Apache > HTTP Server > Documentation > Version 2.0

Mapping URLs to Filesystem Locations

This document explains how Apache uses the URL of a request to determine the filesystem location from which to serve a file.

top

Related Modules and Directives

top

DocumentRoot

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.

top

Files Outside the DocumentRoot

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.

top

User Directories

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

top

URL Redirection

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

top

Reverse Proxy

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 Mapping URLs to Filesystem Locations - Apache HTTP Server

<-

Mapping URLs to Filesystem Locations

This document explains how Apache uses the URL of a request to determine the filesystem location from which to serve a file.

top