This document explains how the Apache HTTP Server 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, httpd'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 theDocumentRoot
specified in your configuration files. Therefore, the files and directories underneath theDocumentRoot
make up the basic document tree which will be visible from the web.
For example, ifDocumentRoot
were set to/var/www/html
then a request forhttp://www.example.com/fish/guppies.html
would result in the file/var/www/html/fish/guppies.html
being served to the requesting client.
If a directory is requested (i.e. a path ending with/
), the file served from that directory is defined by theDirectoryIndex
directive. For example, ifDocumentRoot
were set as above, and you were to set:
DirectoryIndex index.html index.php
Then a request forhttp://www.example.com/fish/
will cause httpd to attempt to serve the file/var/www/html/fish/index.html
. In the event that that file does not exist, it will next attempt to serve the file/var/www/html/fish/index.php
.
If neither of these files existed, the next step is to attempt to provide a directory index, ifmod_autoindex
is loaded and configured to permit that.
httpd is also capable ofVirtual Hosting, where the server receives requests for more than one host. In this case, a differentDocumentRoot
can be specified for each virtual host, or alternatively, the directives provided by the modulemod_vhost_alias
can be used to dynamically determine the appropriate place from which to serve content based on the requested IP address or hostname.
TheDocumentRoot
directive is set in your main server configuration file (httpd.conf
) and, possibly, once per additionalVirtual Host you create.
There are frequently circumstances where it is necessary to allow web access to parts of the filesystem that are not strictly underneath theDocumentRoot
. httpd offers several different ways to accomplish this. On Unix systems, symbolic links can bring other parts of the filesystem under theDocumentRoot
. For security reasons, httpd will follow symbolic links only if theOptions
setting for the relevant directory includesFollowSymLinks
orSymLinksIfOwnerMatch
.
Alternatively, theAlias
directive will map any part of the filesystem into the web space. For example, with
Alias "/docs" "/var/web"
the URLhttp://www.example.com/docs/dir/file.html
will be served from/var/web/dir/file.html
. TheScriptAlias
directive works the same way, with the additional effect that all content located at the target path is treated asCGI scripts.
For situations where you require additional flexibility, you can use theAliasMatch
andScriptAliasMatch
directives to do powerfulregular expression based matching and substitution. For example,
ScriptAliasMatch "^/~([a-zA-Z0-9]+)/cgi-bin/(.+)" "/home/$1/cgi-bin/$2"
will map a request tohttp://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 particularuser can be referred to as~user/
. The modulemod_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, theUserDir
directive specifies a directory underneath the user's home directory where web files are located. Using the default setting ofUserdir 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 theUserdir
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 theAliasMatch
directive to achieve the desired effect. For example, to makehttp://www.example.com/upages/user/file.html
map to/home/user/public_html/file.html
, use the followingAliasMatch
directive:
AliasMatch "^/upages/([a-zA-Z0-9]+)(/(.*))?$" "/home/$1/public_html/$3"
The configuration directives discussed in the above sections tell httpd 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 calledredirection and is implemented by theRedirect
directive. For example, if the contents of the directory/foo/
under theDocumentRoot
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 thewww.example.com
server with/bar/
substituted for/foo/
. You can redirect clients to any server, not only the origin server.
httpd also provides aRedirectMatch
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 one site to a particular page on another site, use the following:
RedirectMatch temp ".*" "http://othersite.example.com/startpage.html"
httpd also allows you to bring remote documents into the URL spaceof the local server. This technique is calledreverseproxying because the web server acts like a proxy server byfetching the documents from a remote server and returning them to theclient. It is different from normal (forward) 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 fromthe/bar/
directory oninternal.example.com
and returns them to the client as if they were from the localserver.
ProxyPass "/foo/" "http://internal.example.com/bar/"ProxyPassReverse "/foo/" "http://internal.example.com/bar/"ProxyPassReverseCookieDomain internal.example.com public.example.comProxyPassReverseCookiePath "/foo/" "/bar/"
TheProxyPass
configuresthe server to fetch the appropriate documents, while theProxyPassReverse
directive rewrites redirects originating atinternal.example.com
so that they target the appropriatedirectory on the local server. Similarly, theProxyPassReverseCookieDomain
andProxyPassReverseCookiePath
rewrite cookies set by the backend server.
It is important to note, however, thatlinks inside the documents will not be rewritten. So any absolutelinks oninternal.example.com
will result in the clientbreaking out of the proxy server and requesting directly frominternal.example.com
. You can modify these links (and othercontent) in a page as it is being served to the client usingmod_substitute
.
Substitute "s/internal\.example\.com/www.example.com/i"
For more sophisticated rewriting of links in HTML and XHTML, themod_proxy_html
module is also available. It allows youto create maps of URLs that need to be rewritten, so that complexproxying scenarios can be handled.
When even more powerful substitution is required, the rewriting engine provided bymod_rewrite
can be useful. The directives provided by this module can use characteristics of the request such as browser type or source IP address in deciding from where to serve content. In addition, mod_rewrite can use external database files or programs to determine how to handle a request. The rewriting engine is capable of performing all three types of mappings discussed above: internal redirects (aliases), external redirects, and proxying. Many practical examples employing mod_rewrite are discussed in thedetailed mod_rewrite documentation.
Inevitably, URLs will be requested for which no matching file can be found in the filesystem. This can happen for several reasons. In some cases, it can be a result of moving documents from one location to another. In this case, it is best to useURL redirection to inform clients of the new location of the resource. In this way, you can assure that old bookmarks and links will continue to work, even though the resource is at a new location.
Another common cause of "File Not Found" errors is accidental mistyping of URLs, either directly in the browser, or in HTML links. httpd provides the modulemod_speling
(sic) to help with this problem. When this module is activated, it will intercept "File Not Found" errors and look for a resource with a similar filename. If one such file is found, mod_speling will send an HTTP redirect to the client informing it of the correct location. If several "close" files are found, a list of available alternatives will be presented to the client.
An especially useful feature of mod_speling, is that it will compare filenames without respect to case. This can help systems where users are unaware of the case-sensitive nature of URLs and the unix filesystem. But using mod_speling for anything more than the occasional URL correction can place additional load on the server, since each "incorrect" request is followed by a URL redirection and a new request from the client.
mod_dir
providesFallbackResource
, which can be used to map virtual URIs to a real resource, which then serves them. This is a very useful replacement formod_rewrite
when implementing a 'front controller'
If all attempts to locate the content fail, httpd returns an error page with HTTP status code 404 (file not found). The appearance of this page is controlled with theErrorDocument
directive and can be customized in a flexible manner as discussed in theCustom error responses document.
Other modules available for URL mapping include:
mod_actions
- Maps a request to a CGI script based on the request method, or resource MIME type.mod_dir
- Provides basic mapping of a trailing slash into an index file such asindex.html
.mod_imagemap
- Maps a request to a URL based on where a user clicks on an image embedded in a HTML document.mod_negotiation
- Selects an appropriate document based on client preferences such as language or content compression.Copyright 2025 The Apache Software Foundation.
Licensed under theApache License, Version 2.0.