summaryrefslogtreecommitdiffstats
path: root/docs/manual/urlmapping.xml
diff options
context:
space:
mode:
authorJoshua Slive <slive@apache.org>2002-08-16 05:30:24 +0200
committerJoshua Slive <slive@apache.org>2002-08-16 05:30:24 +0200
commitd80cb22682b33519d62731af816b663cc736d3ec (patch)
tree1cfb73966f4cc45191192c53318c3640bb6d5786 /docs/manual/urlmapping.xml
parentNew XML (diff)
downloadapache2-d80cb22682b33519d62731af816b663cc736d3ec.tar.xz
apache2-d80cb22682b33519d62731af816b663cc736d3ec.zip
New XML.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96397 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs/manual/urlmapping.xml')
-rw-r--r--docs/manual/urlmapping.xml280
1 files changed, 280 insertions, 0 deletions
diff --git a/docs/manual/urlmapping.xml b/docs/manual/urlmapping.xml
new file mode 100644
index 0000000000..ab8caa1dfc
--- /dev/null
+++ b/docs/manual/urlmapping.xml
@@ -0,0 +1,280 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?>
+
+<manualpage>
+ <relativepath href="."/>
+
+ <title>Mapping URLs to Filesystem Locations</title>
+
+ <summary>
+ <p>This document explains how Apache uses the URL of a request
+ to determine the filesystem location from which to serve a
+ file.</p>
+ </summary>
+
+<section id="related"><title>Related Modules and Directives</title>
+
+<related>
+<modulelist>
+<module>mod_alias</module>
+<module>mod_proxy</module>
+<module>mod_rewrite</module>
+<module>mod_userdir</module>
+<module>mod_speling</module>
+<module>mod_vhost_alias</module>
+</modulelist>
+<directivelist>
+<directive module="mod_alias">Alias</directive>
+<directive module="mod_alias">AliasMatch</directive>
+<directive module="mod_speling">CheckSpelling</directive>
+<directive module="core">DocumentRoot</directive>
+<directive module="core">ErrorDocument</directive>
+<directive module="core">Options</directive>
+<directive module="mod_proxy">ProxyPass</directive>
+<directive module="mod_proxy">ProxyPassReverse</directive>
+<directive module="mod_alias">Redirect</directive>
+<directive module="mod_alias">RedirectMatch</directive>
+<directive module="mod_rewrite">RewriteCond</directive>
+<directive module="mod_rewrite">RewriteMatch</directive>
+<directive module="mod_alias">ScriptAlias</directive>
+<directive module="mod_alias">ScriptAliasMatch</directive>
+<directive module="mod_userdir">UserDir</directive>
+</directivelist>
+</related>
+</section>
+
+<section id="documentroot"><title>DocumentRoot</title>
+
+ <p>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 <directive module="core">DocumentRoot</directive> specified
+ in your configuration files. Therefore, the files and directories
+ underneath the <directive module="core">DocumentRoot</directive>
+ make up the basic document tree which will be visible from the
+ web.</p>
+
+ <p>Apache is also capable of <a href="vhosts/">Virtual
+ Hosting</a>, where the server receives requests for more than one
+ host. In this case, a different <directive
+ module="core">DocumentRoot</directive> can be specified for each
+ virtual host, or alternatively, the directives provided by the
+ module <module>mod_vhost_alias</module> can
+ be used to dynamically determine the appropriate place from which
+ to serve content based on the requested IP address or
+ hostname.</p>
+</section>
+
+<section id="outside"><title>Files Outside the DocumentRoot</title>
+
+ <p>There are frequently circumstances where it is necessary to
+ allow web access to parts of the filesystem that are not strictly
+ underneath the <directive
+ module="core">DocumentRoot</directive>. Apache offers several
+ different ways to accomplish this. On Unix systems, symbolic links
+ can bring other parts of the filesystem under the <directive
+ module="core">DocumentRoot</directive>. For security reasons,
+ Apache will follow symbolic links only if the <directive
+ module="core">Options</directive> setting for the relevant
+ directory includes <code>FollowSymLinks</code> or
+ <code>SymLinksIfOwnerMatch</code>.</p>
+
+ <p>Alternatively, the <directive
+ module="mod_alias">Alias</directive> directive will map any part
+ of the filesystem into the web space. For example, with</p>
+
+<example>Alias /docs /var/web</example>
+
+ <p>the URL <code>http://www.example.com/docs/dir/file.html</code>
+ will be served from <code>/var/web/dir/file.html</code>. The
+ <directive module="mod_alias">ScriptAlias</directive> directive
+ works the same way, with the additional effect that all content
+ located at the target path is treated as CGI scripts.</p>
+
+ <p>For situations where you require additional flexibility, you
+ can use the <directive module="mod_alias">AliasMatch</directive> and
+ <directive module="mod_alias">ScriptAliasMatch</directive>
+ directives to do powerful regular-expression based matching and
+ substitution. For example,</p>
+
+<example>ScriptAliasMatch ^/~([a-zA-Z0-9]*)/cgi-bin/(.*)
+ /home/$1/cgi-bin/$2</example>
+
+ <p>will map a request to
+ <code>http://example.com/~user/cgi-bin/script.cgi</code> to the
+ path <code>/home/user/cgi-bin/script.cgi</code> and will treat
+ the resulting file as a CGI script.</p>
+</section>
+
+<section id="user"><title>User Directories</title>
+
+ <p>Traditionally on Unix systems, the home directory of a
+ particular <em>user</em> can be referred to as
+ <code>~user/</code>. The module <module>mod_userdir</module>
+ extends this idea to the web by allowing files under each user's
+ home directory to be accessed using URLs such as the
+ following.</p>
+
+<example>http://www.example.com/~user/file.html</example>
+
+ <p>For security reasons, it is inappropriate to give direct
+ access to a user's home directory from the web. Therefore, the
+ <directive module="mod_userdir">UserDir</directive> directive
+ specifies a directory underneath the user's home directory
+ where web files are located. Using the default setting of
+ <code>Userdir public_html</code>, the above URL maps to a file
+ at a directory like
+ <code>/home/user/public_html/file.html</code> where
+ <code>/home/user/</code> is the user's home directory as
+ specified in <code>/etc/passwd</code>.</p>
+
+ <p>There are also several other forms of the
+ <code>Userdir</code> directive which you can use on systems
+ where <code>/etc/passwd</code> does not contain the location of
+ the home directory.</p>
+
+ <p>Some people find the "~" symbol (which is often encoded on the
+ web as <code>%7e</code>) 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 <directive module="mod_alias">AliasMatch</directive>
+ directive to achieve the desired effect. For example, to make
+ <code>http://www.example.com/upages/user/file.html</code> map to
+ <code>/home/user/public_html/file.html</code>, use the following
+ <code>AliasMatch</code> directive:</p>
+
+<example>AliasMatch ^/upages/([a-zA-Z0-9]*)/?(.*)
+ /home/$1/public_html/$2</example>
+</section>
+
+<section id="redirect"><title>URL Redirection</title>
+
+ <p>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 <em>redirection</em> and is
+ implemented by the <directive
+ module="mod_alias">Redirect</directive> directive. For example, if
+ the contents of the directory <code>/foo/</code> under the
+ <directive module="mod_alias">DocumentRoot</directive> are moved
+ to the new directory <code>/bar/</code>, you can instruct clients
+ to request the content at the new location as follows:</p>
+
+<example>Redirect permanent /foo/
+ http://www.example.com/bar/</example>
+
+ <p>This will redirect any URL-Path starting in
+ <code>/foo/</code> to the same URL path on the
+ <code>www.example.com</code> server with <code>/bar/</code>
+ substituted for <code>/foo/</code>. You can redirect clients to
+ any server, not only the origin server.</p>
+
+ <p>Apache also provides a <directive
+ module="mod_alias">RedirectMatch</directive> 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:</p>
+
+<example>RedirectMatch permanent ^/$
+ http://www.example.com/startpage.html</example>
+
+ <p>Alternatively, to temporarily redirect all pages on a site
+ to one particular page, use the following:</p>
+
+<example>RedirectMatch temp .*
+ http://www.example.com/startpage.html</example>
+</section>
+
+<section id="proxy"><title>Reverse Proxy</title>
+
+<p>Apache also allows you to bring remote documents into the URL space
+of the local server. This technique is called <em>reverse
+proxying</em> 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.</p>
+
+<p>In the following example, when clients request documents under the
+<code>/foo/</code> directory, the server fetches those documents from
+the <code>/bar/</code> directory on <code>internal.example.com</code>
+and returns them to the client as if they were from the local
+server.</p>
+
+<example>
+ProxyPass /foo/ http://internal.example.com/bar/<br />
+ProxyPassReverse /foo/ http://internal.example.com/bar/
+</example>
+
+<p>The <directive module="mod_proxy">ProxyPass</directive> configures
+the server to fetch the appropriate documents, while the
+<directive module="mod_proxy">ProxyPassReverse</directive>
+directive rewrites redirects originating at
+<code>internal.examle.com</code> 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 <code>internal.example.com</code> will result in the client
+breaking out of the proxy server and requesting directly from
+<code>internal.example.com</code>.</p>
+</section>
+
+<section id="rewrite"><title>Rewriting Engine</title>
+
+ <p>When even more powerful substitution is required, the rewriting
+ engine provided by <module>mod_rewrite</module>
+ can be useful. The directives provided by this module 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 the
+ <a href="misc/rewriteguide.html">URL Rewriting Guide</a>.</p>
+</section>
+
+<section id="notfound"><title>File Not Found</title>
+
+ <p>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 use <a href="#redirect">URL redirection</a> 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.</p>
+
+ <p>Another common cause of "File Not Found" errors is
+ accidental mistyping of URLs, either directly in the browser,
+ or in HTML links. Apache provides the module
+ <module>mod_speling</module> (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.</p>
+
+ <p>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.</p>
+
+ <p>If all attempts to locate the content fail, Apache returns
+ an error page with HTTP status code 404 (file not found). The
+ appearance of this page is controlled with the
+ <directive module="core">ErrorDocument</directive> directive
+ and can be customized in a flexible manner as discussed in the
+ <a href="custom-error.html">Custom error responses</a> and <a
+ href="misc/custom_errordocs.html">International Server Error
+ Responses</a> documents.</p>
+</section>
+
+</manualpage> \ No newline at end of file