-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>How Directory, Location and Files sections work</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">How Directory, Location and Files sections work</H1>
-
-The sections <A
-HREF="mod/core.html#directory"><CODE><Directory></CODE></A>, <A
-HREF="mod/core.html#location"><CODE><Location></CODE></A> and <A
-HREF="mod/core.html#files"><CODE><Files></CODE></A> can contain
-directives which only apply to specified directories, URLs or files
-respectively. Also htaccess files can be used inside a directory to
-apply directives to that directory. This document explains how these
-different sections differ and how they relate to each other when
-Apache decides which directives apply for a particular directory or
-request URL.
-
-<h2>Directives allowed in the sections</h2>
-
-Everything that is syntactically allowed in
-<CODE><Directory></CODE> is also allowed in
-<CODE><Location></CODE> (except a sub-<CODE><Files></CODE>
-section, but the code doesn't test for that, Lars has an open bug
-report on that). Semantically however some things, and the most
-notable is AllowOverrides, make no sense in
-<CODE><Location></CODE>. The same for
-<CODE><Files></CODE> -- syntactically everything is fine, but
-semantically some things are different.
-
-<h2>How the sections are merged</h2>
-
-The order of merging is:
-
-<OL>
-
-<LI>
-
- <CODE><Directory></CODE> (except regular expressions) and
- .htaccess done simultaneously (with .htaccess overriding
- <CODE><Directory></CODE>)
-
-</LI>
-
-<LI>
- <CODE><DirectoryMatch></CODE>, and
- <CODE><Directory></CODE> with regular expressions
-
-</LI>
-
- <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done simultaneously
- </LI>
-
- <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done simultaneously
- </LI>
-
-</OL>
-
-Apart from <CODE><Directory></CODE>, each group is processed in
-the order that they appear in the configuration
-files. <CODE><Directory></CODE> (group 1 above) is processed in
-the order shortest directory component to longest. If multiple
-<CODE><Directory></CODE> sections apply to the same directory
-they they are processed in the configuration file order. The
-configuration files are read in the order httpd.conf, srm.conf and
-access.conf. Configurations included via the <CODE>Include</CODE>
-directive will be treated as if they where inside the including file
-at the location of the <CODE>Include</CODE> directive.
-
-<P>
-
-Sections inside <CODE><VirtualHost></CODE> sections are applied
-<EM>after</EM> the corresponding sections outside the virtual host
-definition. This allows virtual hosts to override the main server
-configuration. (Note: this only works correctly from 1.2.2 and 1.3a2
-onwards. Before those releases sections inside virtual hosts were
-applied <EM>before</EM> the main server).
-
-<h2>Notes about using sections</h2>
-
-The general guidelines are:
-
-<P>
-
-<UL>
-<LI>
- If you are attempting to match objects at the filesystem level
- then you must use <CODE><Directory></CODE> and/or
- <CODE><Files></CODE>.
-</LI>
-
-<LI>
- If you are attempting to match objects at the URL level then you
- must use <CODE><Location></CODE>
-</LI>
-</UL>
-
-But a notable exception is:
-
-<UL>
-<LI>
- proxy control is done via <CODE><Directory></CODE>. This is
- a legacy mistake because the proxy existed prior to
- <CODE><Location></CODE>. A future version of the config
- language should probably switch this to
- <CODE><Location></CODE>.
-</LI>
-</UL>
-
-Note also that modifying .htaccess parsing during Location doesn't do
-anything because .htaccess parsing has already occurred.
-
-<P>
-
-Another note:
-<P>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ -->
+<title>Configuration Sections - Apache HTTP Server</title>
+<link href="./style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+<link href="./style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
+<link href="./style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="./style/css/prettify.css" />
+<script src="./style/scripts/prettify.js" type="text/javascript">
+</script>
-<UL>
-<LI>
- There is actually a
- <CODE><Location></CODE>/<CODE><LocationMatch></CODE>
- sequence performed just before the name translation phase (where
- <CODE>Aliases</CODE> and <CODE>DocumentRoots</CODE> are used to
- map URLs to filenames). The results of this sequence are
- completely thrown away after the translation has completed.
-</LI>
-</UL>
+<link href="./images/favicon.ico" rel="shortcut icon" /></head>
+<body id="manual-page"><div id="page-header">
+<p class="menu"><a href="./mod/">Modules</a> | <a href="./mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="./glossary.html">Glossary</a> | <a href="./sitemap.html">Sitemap</a></p>
+<p class="apache">Apache HTTP Server Version 2.5</p>
+<img alt="" src="./images/feather.gif" /></div>
+<div class="up"><a href="./"><img title="<-" alt="<-" src="./images/left.gif" /></a></div>
+<div id="path">
+<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="./">Version 2.5</a></div><div id="page-content"><div id="preamble"><h1>Configuration Sections</h1>
+<div class="toplang">
+<p><span>Available Languages: </span><a href="./en/sections.html" title="English"> en </a> |
+<a href="./fr/sections.html" hreflang="fr" rel="alternate" title="Français"> fr </a> |
+<a href="./ja/sections.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
+<a href="./ko/sections.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
+<a href="./tr/sections.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
+</div>
+ <p>Directives in the <a href="configuring.html">configuration files</a> may apply to the
+entire server, or they may be restricted to apply only to particular
+directories, files, hosts, or URLs. This document describes how to
+use configuration section containers or <code>.htaccess</code> files
+to change the scope of other configuration directives.</p>
+</div>
+<div id="quickview"><ul id="toc"><li><img alt="" src="./images/down.gif" /> <a href="#types">Types of Configuration Section Containers</a></li>
+<li><img alt="" src="./images/down.gif" /> <a href="#file-and-web">Filesystem, Webspace, and Boolean Expressions</a></li>
+<li><img alt="" src="./images/down.gif" /> <a href="#virtualhost">Virtual Hosts</a></li>
+<li><img alt="" src="./images/down.gif" /> <a href="#proxy">Proxy</a></li>
+<li><img alt="" src="./images/down.gif" /> <a href="#whatwhere">What Directives are Allowed?</a></li>
+<li><img alt="" src="./images/down.gif" /> <a href="#merging">How the sections are merged</a></li>
+</ul><ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="types" id="types">Types of Configuration Section Containers</a></h2>
-<!--#include virtual="footer.html" -->
-</BODY></HTML>
+<table class="related"><tr><th>Related Modules</th><th>Related Directives</th></tr><tr><td><ul><li><code class="module"><a href="./mod/core.html">core</a></code></li><li><code class="module"><a href="./mod/mod_version.html">mod_version</a></code></li><li><code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code></li></ul></td><td><ul><li><code class="directive"><a href="./mod/core.html#directory"><Directory></a></code></li><li><code class="directive"><a href="./mod/core.html#directorymatch"><DirectoryMatch></a></code></li><li><code class="directive"><a href="./mod/core.html#files"><Files></a></code></li><li><code class="directive"><a href="./mod/core.html#filesmatch"><FilesMatch></a></code></li><li><code class="directive"><a href="./mod/core.html#if"><If></a></code></li><li><code class="directive"><a href="./mod/core.html#ifdefine"><IfDefine></a></code></li><li><code class="directive"><a href="./mod/core.html#ifmodule"><IfModule></a></code></li><li><code class="directive"><a href="./mod/mod_version.html#ifversion"><IfVersion></a></code></li><li><code class="directive"><a href="./mod/core.html#location"><Location></a></code></li><li><code class="directive"><a href="./mod/core.html#locationmatch"><LocationMatch></a></code></li><li><code class="directive"><a href="./mod/mod_proxy.html#proxy"><Proxy></a></code></li><li><code class="directive"><a href="./mod/mod_proxy.html#proxymatch"><ProxyMatch></a></code></li><li><code class="directive"><a href="./mod/core.html#virtualhost"><VirtualHost></a></code></li></ul></td></tr></table>
+
+<p>There are two basic types of containers. Most containers are
+evaluated for each request. The enclosed directives are applied only
+for those requests that match the containers. The <code class="directive"><a href="./mod/core.html#ifdefine"><IfDefine></a></code>, <code class="directive"><a href="./mod/core.html#ifmodule"><IfModule></a></code>, and
+<code class="directive"><a href="./mod/mod_version.html#ifversion"><IfVersion></a></code>
+containers, on the other hand, are evaluated only at server startup
+and restart. If their conditions are true at startup, then the
+enclosed directives will apply to all requests. If the conditions are
+not true, the enclosed directives will be ignored.</p>
+
+<p>The <code class="directive"><a href="./mod/core.html#ifdefine"><IfDefine></a></code> directive
+encloses directives that will only be applied if an appropriate
+parameter is defined on the <code class="program"><a href="./programs/httpd.html">httpd</a></code> command line. For example,
+with the following configuration, all requests will be redirected
+to another site only if the server is started using
+<code>httpd -DClosedForNow</code>:</p>
+
+<pre class="prettyprint lang-config">
+<IfDefine ClosedForNow>
+ Redirect / http://otherserver.example.com/
+</IfDefine>
+</pre>
+
+
+<p>The <code class="directive"><a href="./mod/core.html#ifmodule"><IfModule></a></code>
+directive is very similar, except it encloses directives that will
+only be applied if a particular module is available in the server.
+The module must either be statically compiled in the server, or it
+must be dynamically compiled and its <code class="directive"><a href="./mod/mod_so.html#loadmodule">LoadModule</a></code> line must be earlier in the
+configuration file. This directive should only be used if you need
+your configuration file to work whether or not certain modules are
+installed. It should not be used to enclose directives that you want
+to work all the time, because it can suppress useful error messages
+about missing modules.</p>
+
+<p>In the following example, the <code class="directive"><a href="./mod/mod_mime_magic.html#mimemagicfile">MimeMagicFile</a></code> directive will be
+applied only if <code class="module"><a href="./mod/mod_mime_magic.html">mod_mime_magic</a></code> is available.</p>
+
+<pre class="prettyprint lang-config">
+<IfModule mod_mime_magic.c>
+ MimeMagicFile conf/magic
+</IfModule>
+</pre>
+
+
+<p>The <code class="directive"><a href="./mod/mod_version.html#ifversion"><IfVersion></a></code>
+directive is very similar to <code class="directive"><a href="./mod/core.html#ifdefine"><IfDefine></a></code> and <code class="directive"><a href="./mod/core.html#ifmodule"><IfModule></a></code>, except it encloses directives that will
+only be applied if a particular version of the server is executing. This
+module is designed for the use in test suites and large networks which have to
+deal with different httpd versions and different configurations.</p>
+
+<pre class="prettyprint lang-config">
+<IfVersion >= 2.4>
+ # this happens only in versions greater or
+ # equal 2.4.0.
+</IfVersion>
+</pre>
+
+
+<p><code class="directive"><a href="./mod/core.html#ifdefine"><IfDefine></a></code>,
+<code class="directive"><a href="./mod/core.html#ifmodule"><IfModule></a></code>, and the
+<code class="directive"><a href="./mod/mod_version.html#ifversion"><IfVersion></a></code>
+can apply negative conditions by preceding their test with "!".
+Also, these sections can be nested to achieve more complex
+restrictions.</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="file-and-web" id="file-and-web">Filesystem, Webspace, and Boolean Expressions</a></h2>
+
+<p>The most commonly used configuration section containers are the
+ones that change the configuration of particular places in the
+filesystem or webspace. First, it is important to understand the
+difference between the two. The filesystem is the view of your disks
+as seen by your operating system. For example, in a default install,
+Apache httpd resides at <code>/usr/local/apache2</code> in the Unix
+filesystem or <code>"c:/Program Files/Apache Group/Apache2"</code> in
+the Windows filesystem. (Note that forward slashes should always be
+used as the path separator in Apache httpd configuration files, even for Windows.) In contrast,
+the webspace is the view of your site as delivered by the web server
+and seen by the client. So the path <code>/dir/</code> in the
+webspace corresponds to the path
+<code>/usr/local/apache2/htdocs/dir/</code> in the filesystem of a
+default Apache httpd install on Unix. The webspace need not map directly to
+the filesystem, since webpages may be generated dynamically
+from databases or other locations.</p>
+
+<h3><a name="filesystem" id="filesystem">Filesystem Containers</a></h3>
+
+<p>The <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>
+and <code class="directive"><a href="./mod/core.html#files"><Files></a></code>
+directives, along with their <a class="glossarylink" href="./glossary.html#regex" title="see glossary">regex</a>
+counterparts, apply directives to
+parts of the filesystem. Directives enclosed in a <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> section apply to
+the named filesystem directory and all subdirectories of that
+directory (as well as the files in those directories).
+The same effect can be obtained using <a href="howto/htaccess.html">.htaccess files</a>. For example, in the
+following configuration, directory indexes will be enabled for the
+<code>/var/web/dir1</code> directory and all subdirectories.</p>
+
+<pre class="prettyprint lang-config">
+<Directory /var/web/dir1>
+ Options +Indexes
+</Directory>
+</pre>
+
+
+<p>Directives enclosed in a <code class="directive"><a href="./mod/core.html#files"><Files></a></code> section apply to any file with
+the specified name, regardless of what directory it lies in.
+So for example, the following configuration directives will,
+when placed in the main section of the configuration file,
+deny access to any file named <code>private.html</code> regardless
+of where it is found.</p>
+
+<pre class="prettyprint lang-config">
+<Files private.html>
+ Require all denied
+</Files>
+</pre>
+
+
+<p>To address files found in a particular part of the filesystem, the
+<code class="directive"><a href="./mod/core.html#files"><Files></a></code> and
+<code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> sections
+can be combined. For example, the following configuration will deny
+access to <code>/var/web/dir1/private.html</code>,
+<code>/var/web/dir1/subdir2/private.html</code>,
+<code>/var/web/dir1/subdir3/private.html</code>, and any other instance
+of <code>private.html</code> found under the <code>/var/web/dir1/</code>
+directory.</p>
+
+<pre class="prettyprint lang-config">
+<Directory /var/web/dir1>
+ <Files private.html>
+ Require all denied
+ </Files>
+</Directory>
+</pre>
+
+
+
+<h3><a name="webspace" id="webspace">Webspace Containers</a></h3>
+
+<p>The <code class="directive"><a href="./mod/core.html#location"><Location></a></code>
+directive and its <a class="glossarylink" href="./glossary.html#regex" title="see glossary">regex</a> counterpart, on
+the other hand, change the
+configuration for content in the webspace. For example, the following
+configuration prevents access to any URL-path that begins in /private.
+In particular, it will apply to requests for
+<code>http://yoursite.example.com/private</code>,
+<code>http://yoursite.example.com/private123</code>, and
+<code>http://yoursite.example.com/private/dir/file.html</code> as well
+as any other requests starting with the <code>/private</code> string.</p>
+
+<pre class="prettyprint lang-config">
+<LocationMatch ^/private>
+ Require all denied
+</LocationMatch>
+</pre>
+
+
+<p>The <code class="directive"><a href="./mod/core.html#location"><Location></a></code>
+directive need not have anything to do with the filesystem.
+For example, the following example shows how to map a particular
+URL to an internal Apache HTTP Server handler provided by <code class="module"><a href="./mod/mod_status.html">mod_status</a></code>.
+No file called <code>server-status</code> needs to exist in the
+filesystem.</p>
+
+<pre class="prettyprint lang-config">
+<Location /server-status>
+ SetHandler server-status
+</Location>
+</pre>
+
+
+
+<h3><a name="overlapping-webspace" id="overlapping-webspace">Overlapping Webspace</a></h3>
+<p>In order to have two overlapping URLs one has to consider the order in which
+certain sections or directives are evaluated. For
+<code class="directive"><a href="./mod/core.html#location"><Location></a></code> this would be:</p>
+<pre class="prettyprint lang-config">
+<Location /foo>
+</Location>
+<Location /foo/bar>
+</Location>
+</pre>
+
+<p><code class="directive"><a href="./mod/mod_alias.html#alias"><Alias></a></code>es on the other hand,
+are mapped vice-versa:</p>
+<pre class="prettyprint lang-config">
+Alias /foo/bar /srv/www/uncommon/bar
+Alias /foo /srv/www/common/foo
+</pre>
+
+<p>The same is true for the <code class="directive"><a href="./mod/mod_proxy.html#proxypass">ProxyPass</a></code>
+directives:</p>
+<pre class="prettyprint lang-config">
+ProxyPass /special-area http://special.example.com smax=5 max=10
+ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid nofailover=On
+</pre>
+
+
+
+<h3><a name="wildcards" id="wildcards">Wildcards and Regular Expressions</a></h3>
+
+<p>The <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>,
+<code class="directive"><a href="./mod/core.html#files"><Files></a></code>, and
+<code class="directive"><a href="./mod/core.html#location"><Location></a></code>
+directives can each use shell-style wildcard characters as in
+<code>fnmatch</code> from the C standard library. The character "*"
+matches any sequence of characters, "?" matches any single character,
+and "[<em>seq</em>]" matches any character in <em>seq</em>. The "/"
+character will not be matched by any wildcard; it must be specified
+explicitly.</p>
+
+<p>If even more flexible matching is required, each
+container has a regular expression (regex) counterpart <code class="directive"><a href="./mod/core.html#directorymatch"><DirectoryMatch></a></code>, <code class="directive"><a href="./mod/core.html#filesmatch"><FilesMatch></a></code>, and <code class="directive"><a href="./mod/core.html#locationmatch"><LocationMatch></a></code> that allow
+perl-compatible
+<a class="glossarylink" href="./glossary.html#regex" title="see glossary">regular expressions</a>
+to be used in choosing the matches. But see the section below on
+configuration merging to find out how using regex sections will change
+how directives are applied.</p>
+
+<p>A non-regex wildcard section that changes the configuration of
+all user directories could look as follows:</p>
+
+<pre class="prettyprint lang-config">
+<Directory /home/*/public_html>
+ Options Indexes
+</Directory>
+</pre>
+
+
+<p>Using regex sections, we can deny access to many types of image files
+at once:</p>
+<pre class="prettyprint lang-config">
+<FilesMatch \.(?i:gif|jpe?g|png)$>
+ Require all denied
+</FilesMatch>
+</pre>
+
+
+
+
+<h3><a name="expressions" id="expressions">Boolean expressions</a></h3>
+<p>The <code class="directive"><a href="./mod/core.html#if"><If></a></code>
+directive change the configuration depending on a condition which can be
+expressed by a boolean expression. For example, the following configuration
+denies access if the HTTP Referer header does not start with
+"http://www.example.com/".</p>
+<pre class="prettyprint lang-config">
+<If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
+ Require all denied
+</If>
+</pre>
+
+
+
+
+<h3><a name="whichwhen" id="whichwhen">What to use When</a></h3>
+
+<p>Choosing between filesystem containers and webspace containers is
+actually quite easy. When applying directives to objects that reside
+in the filesystem always use <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> or <code class="directive"><a href="./mod/core.html#files"><Files></a></code>. When applying directives to objects
+that do not reside in the filesystem (such as a webpage generated from
+a database), use <code class="directive"><a href="./mod/core.html#location"><Location></a></code>.</p>
+
+<p>It is important to never use <code class="directive"><a href="./mod/core.html#location"><Location></a></code> when trying to restrict
+access to objects in the filesystem. This is because many
+different webspace locations (URLs) could map to the same filesystem
+location, allowing your restrictions to be circumvented.
+For example, consider the following configuration:</p>
+
+<pre class="prettyprint lang-config">
+<Location /dir/>
+ Require all denied
+</Location>
+</pre>
+
+
+<p>This works fine if the request is for
+<code>http://yoursite.example.com/dir/</code>. But what if you are on
+a case-insensitive filesystem? Then your restriction could be easily
+circumvented by requesting
+<code>http://yoursite.example.com/DIR/</code>. The <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> directive, in
+contrast, will apply to any content served from that location,
+regardless of how it is called. (An exception is filesystem links.
+The same directory can be placed in more than one part of the
+filesystem using symbolic links. The <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> directive will follow the symbolic
+link without resetting the pathname. Therefore, for the highest level
+of security, symbolic links should be disabled with the appropriate
+<code class="directive"><a href="./mod/core.html#options">Options</a></code> directive.)</p>
+
+<p>If you are, perhaps, thinking that none of this applies to you
+because you use a case-sensitive filesystem, remember that there are
+many other ways to map multiple webspace locations to the same
+filesystem location. Therefore you should always use the filesystem
+containers when you can. There is, however, one exception to this
+rule. Putting configuration restrictions in a <code><Location
+/></code> section is perfectly safe because this section will apply
+to all requests regardless of the specific URL.</p>
+
+
+<h3><a name="nesting" id="nesting">Nesting of sections</a></h3>
+
+<p>Some section types can be nested inside other section types. One the one
+hand, <code class="directive"><a href="./mod/core.html#files"><Files></a></code> can be used
+inside <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>. On
+the other hand, <code class="directive"><a href="./mod/core.html#if"><If></a></code> can
+be used inside <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>,
+<code class="directive"><a href="./mod/core.html#location"><Location></a></code>, and <code class="directive"><a href="./mod/core.html#files"><Files></a></code> sections. The regex
+counterparts of the named section behave identically.</p>
+
+<p>Nested sections are merged after non-nested sections of the same type.</p>
+
+
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="virtualhost" id="virtualhost">Virtual Hosts</a></h2>
+
+<p>The <code class="directive"><a href="./mod/core.html#virtualhost"><VirtualHost></a></code>
+container encloses directives that apply to specific hosts.
+This is useful when serving multiple hosts from the same machine
+with a different configuration for each. For more information,
+see the <a href="vhosts/">Virtual Host Documentation</a>.</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="proxy" id="proxy">Proxy</a></h2>
+
+<p>The <code class="directive"><a href="./mod/mod_proxy.html#proxy"><Proxy></a></code>
+and <code class="directive"><a href="./mod/mod_proxy.html#proxymatch"><ProxyMatch></a></code>
+containers apply enclosed configuration directives only
+to sites accessed through <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code>'s proxy server
+that match the specified URL. For example, the following configuration
+will prevent the proxy server from being used to access the
+<code>www.example.com</code> website.</p>
+
+<pre class="prettyprint lang-config">
+<Proxy http://www.example.com/*>
+ Require all granted
+</Proxy>
+</pre>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="whatwhere" id="whatwhere">What Directives are Allowed?</a></h2>
+
+<p>To find out what directives are allowed in what types of
+configuration sections, check the <a href="mod/directive-dict.html#Context">Context</a> of the directive.
+Everything that is allowed in
+<code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>
+sections is also syntactically allowed in
+<code class="directive"><a href="./mod/core.html#directorymatch"><DirectoryMatch></a></code>,
+<code class="directive"><a href="./mod/core.html#files"><Files></a></code>,
+<code class="directive"><a href="./mod/core.html#filesmatch"><FilesMatch></a></code>,
+<code class="directive"><a href="./mod/core.html#location"><Location></a></code>,
+<code class="directive"><a href="./mod/core.html#locationmatch"><LocationMatch></a></code>,
+<code class="directive"><a href="./mod/mod_proxy.html#proxy"><Proxy></a></code>,
+and <code class="directive"><a href="./mod/mod_proxy.html#proxymatch"><ProxyMatch></a></code>
+sections. There are some exceptions, however:</p>
+
+<ul>
+<li>The <code class="directive"><a href="./mod/core.html#allowoverride">AllowOverride</a></code> directive
+works only in <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>
+sections.</li>
+
+<li>The <code>FollowSymLinks</code> and
+<code>SymLinksIfOwnerMatch</code> <code class="directive"><a href="./mod/core.html#options">Options</a></code> work only in <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> sections or
+<code>.htaccess</code> files.</li>
+
+<li>The <code class="directive"><a href="./mod/core.html#options">Options</a></code> directive cannot
+be used in <code class="directive"><a href="./mod/core.html#files"><Files></a></code>
+and <code class="directive"><a href="./mod/core.html#filesmatch"><FilesMatch></a></code>
+sections.</li>
+</ul>
+</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="merging" id="merging">How the sections are merged</a></h2>
+
+<p>The configuration sections are applied in a very particular order.
+Since this can have important effects on how configuration directives
+are interpreted, it is important to understand how this works.</p>
+
+ <p>The order of merging is:</p>
+
+ <ol>
+ <li> <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> (except regular expressions)
+ and <code>.htaccess</code> done simultaneously (with
+ <code>.htaccess</code>, if allowed, overriding
+ <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>)</li>
+
+ <li><code class="directive"><a href="./mod/core.html#directorymatch"><DirectoryMatch></a></code>
+ (and <code><Directory ~></code>)</li>
+
+ <li><code class="directive"><a href="./mod/core.html#files"><Files></a></code> and <code class="directive"><a href="./mod/core.html#filesmatch"><FilesMatch></a></code> done
+ simultaneously</li>
+
+ <li><code class="directive"><a href="./mod/core.html#location"><Location></a></code>
+ and <code class="directive"><a href="./mod/core.html#locationmatch"><LocationMatch></a></code> done simultaneously</li>
+
+ <li><code class="directive"><a href="./mod/core.html#if"><If></a></code>
+ </li>
+
+ </ol>
+
+ <p>Apart from <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>, each group is processed in
+ the order that they appear in the configuration files. <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> (group 1 above)
+ is processed in the order shortest directory component to longest.
+ So for example, <code><Directory /var/web/dir></code> will
+ be processed before <code><Directory
+ /var/web/dir/subdir></code>. If multiple <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> sections apply
+ to the same directory they are processed in the configuration file
+ order. Configurations included via the <code class="directive"><a href="./mod/core.html#include">Include</a></code> directive will be treated as if
+ they were inside the including file at the location of the
+ <code class="directive"><a href="./mod/core.html#include">Include</a></code> directive.</p>
+
+ <p>Sections inside <code class="directive"><a href="./mod/core.html#virtualhost"><VirtualHost></a></code> sections
+ are applied <em>after</em> the corresponding sections outside
+ the virtual host definition. This allows virtual hosts to
+ override the main server configuration.</p>
+
+ <p>When the request is served by <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code>, the
+ <code class="directive"><a href="./mod/mod_proxy.html#proxy"><Proxy></a></code>
+ container takes the place of the <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> container in the processing
+ order.</p>
+
+ <p>Later sections override earlier ones, however each module is responsible
+ for interpreting what form this override takes. A later configuration section
+ with directives from a given module might cause a conceptual "merge" of some
+ directives, all directives, or a complete replacement of the modules
+ configuration with the module defaults and directives explicitly listed in
+ the later context.</p>
+
+<div class="note"><h3>Technical Note</h3>
+ There is actually a
+ <code><Location></code>/<code><LocationMatch></code>
+ sequence performed just before the name translation phase
+ (where <code>Aliases</code> and <code>DocumentRoots</code>
+ are used to map URLs to filenames). The results of this
+ sequence are completely thrown away after the translation has
+ completed.
+</div>
+
+<h3><a name="merge-examples" id="merge-examples">Some Examples</a></h3>
+
+<p>Below is an artificial example to show the order of
+merging. Assuming they all apply to the request, the directives in
+this example will be applied in the order A > B > C > D >
+E.</p>
+
+<pre class="prettyprint lang-config">
+<Location />
+ E
+</Location>
+
+<Files f.html>
+ D
+</Files>
+
+<VirtualHost *>
+<Directory /a/b>
+ B
+</Directory>
+</VirtualHost>
+
+<DirectoryMatch "^.*b$">
+ C
+</DirectoryMatch>
+
+<Directory /a/b>
+ A
+</Directory>
+
+</pre>
+
+
+<p>For a more concrete example, consider the following. Regardless of
+any access restrictions placed in <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> sections, the <code class="directive"><a href="./mod/core.html#location"><Location></a></code> section will be
+evaluated last and will allow unrestricted access to the server. In
+other words, order of merging is important, so be careful!</p>
+
+<pre class="prettyprint lang-config">
+<Location />
+ Require all granted
+</Location>
+
+# Woops! This <Directory> section will have no effect
+<Directory />
+ <RequireAll>
+ Require all granted
+ Require not host badguy.example.com
+ </RequireAll>
+</Directory>
+</pre>
+
+
+
+
+</div></div>
+<div class="bottomlang">
+<p><span>Available Languages: </span><a href="./en/sections.html" title="English"> en </a> |
+<a href="./fr/sections.html" hreflang="fr" rel="alternate" title="Français"> fr </a> |
+<a href="./ja/sections.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
+<a href="./ko/sections.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
+<a href="./tr/sections.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
+</div><div class="top"><a href="#page-header"><img src="./images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Comments</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
+<script type="text/javascript"><!--//--><![CDATA[//><!--
+var comments_shortname = 'httpd';
+var comments_identifier = 'http://httpd.apache.org/docs/trunk/sections.html';
+(function(w, d) {
+ if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
+ d.write('<div id="comments_thread"><\/div>');
+ var s = d.createElement('script');
+ s.type = 'text/javascript';
+ s.async = true;
+ s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
+ (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
+ }
+ else {
+ d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
+ }
+})(window, document);
+//--><!]]></script></div><div id="footer">
+<p class="apache">Copyright 2012 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
+<p class="menu"><a href="./mod/">Modules</a> | <a href="./mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="./glossary.html">Glossary</a> | <a href="./sitemap.html">Sitemap</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!--
+if (typeof(prettyPrint) !== 'undefined') {
+ prettyPrint();
+}
+//--><!]]></script>
+</body></html>
\ No newline at end of file