mirror of
				https://github.com/apache/httpd.git
				synced 2025-11-02 06:53:27 +03:00 
			
		
		
		
	git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1820055 13f79535-47bb-0310-9956-ffa450edef68
		
			
				
	
	
		
			598 lines
		
	
	
		
			37 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
			
		
		
	
	
			598 lines
		
	
	
		
			37 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
<?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>
 | 
						||
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
 | 
						||
<!--
 | 
						||
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 | 
						||
              This file is generated from xml source: DO NOT EDIT
 | 
						||
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 | 
						||
      -->
 | 
						||
<title>Configuration Sections - Apache HTTP Server Version 2.5</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.min.js" type="text/javascript">
 | 
						||
</script>
 | 
						||
 | 
						||
<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/quickreference.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.png" /></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<61>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<72>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><h3>See also</h3><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>
 | 
						||
 | 
						||
<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_md.html#mdomainsetsection"><MDomainSet></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/mod_ssl.html#sslpolicydefinesection"><SSLPolicyDefine></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>
 | 
						||
 | 
						||
 | 
						||
<p>Regular expressions containing <strong>named groups and
 | 
						||
backreferences</strong> are added to the environment with the
 | 
						||
corresponding name in uppercase. This allows elements of filename paths
 | 
						||
and URLs to be referenced from within <a href="expr.html">expressions</a>
 | 
						||
and modules like <code class="module"><a href="./mod/mod_rewrite.html">mod_rewrite</a></code>.</p>
 | 
						||
 | 
						||
<pre class="prettyprint lang-config"><DirectoryMatch "^/var/www/combined/(?<SITENAME>[^/]+)">
 | 
						||
    require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 | 
						||
</DirectoryMatch></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. On 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 (but not inside another
 | 
						||
<code class="directive"><a href="./mod/core.html#if"><If></a></code>). 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 allow only a subset of clients to access the
 | 
						||
<code>www.example.com</code> website using the proxy server:</p>
 | 
						||
 | 
						||
<pre class="prettyprint lang-config"><Proxy http://www.example.com/*>
 | 
						||
    Require host yournetwork.example.com
 | 
						||
</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>Some important remarks:</p>
 | 
						||
    <ul>
 | 
						||
        <li>Apart from <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>, within each group the sections are
 | 
						||
        processed in the order they appear in the configuration files.
 | 
						||
        For example, a request for <em>/foo</em> will match
 | 
						||
        <code><Location "/foo/bar"></code> and 
 | 
						||
        <code><Location "/foo"></code> (group 4 in this case):
 | 
						||
        both sections will be evaluated
 | 
						||
        but in the order they appear in the configuration files.</li>
 | 
						||
        <li><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. For example,
 | 
						||
        <code><Directory "/var/web/dir"></code> will be processed before
 | 
						||
        <code><Directory "/var/web/dir/subdir"></code>.</li>
 | 
						||
        <li>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.</li>
 | 
						||
        <li>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.</li>
 | 
						||
        <li>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.</li>
 | 
						||
        <li>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.</li>
 | 
						||
    </ul>
 | 
						||
 | 
						||
    <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="relationship-module-configuration" id="relationship-module-configuration">Relationship between modules and configuration sections</a></h3>
 | 
						||
    <p>One question that often arises after reading how configuration sections are
 | 
						||
    merged is related to how and when directives of specific modules like <code class="module"><a href="./mod/mod_rewrite.html">mod_rewrite</a></code>
 | 
						||
    are processed. The answer is not trivial and needs a bit of background. 
 | 
						||
    Each httpd module manages its own configuration, and each of its directives in httpd.conf specify one piece 
 | 
						||
    of configuration in a particular context. httpd does not execute a command as it is read.</p>
 | 
						||
    <p>At runtime, the core of httpd iterates over the defined configuration sections in the order
 | 
						||
    described above to determine which ones apply to the current request. When the first section matches, 
 | 
						||
    it is considered the current configuration for this request. If a subsequent section matches too, 
 | 
						||
    then each module with a directive in either of the sections is given a chance to merge its configuration between the two sections. The result is a third configuration, and the process goes on until all the configuration sections
 | 
						||
    are evaluated.</p>
 | 
						||
    <p>After the above step, the "real" processing of the HTTP request begins: each module has a chance to run 
 | 
						||
    and perform whatever tasks they like. They can retrieve their own final merged configuration from the core
 | 
						||
    of the httpd to determine how they should act.</p>
 | 
						||
    <p>An example can help to visualize the whole process. The following configuration uses the 
 | 
						||
        <code class="directive"><a href="./mod/mod_headers.html#header">Header</a></code> directive of <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> to set
 | 
						||
        a specific HTTP header. What value will httpd set in the <code>CustomHeaderName</code> header for a request to
 | 
						||
        <code>/example/index.html</code> ?
 | 
						||
    </p>
 | 
						||
    <pre class="prettyprint lang-config"><Directory "/">
 | 
						||
    Header set CustomHeaderName one
 | 
						||
    <FilesMatch ".*">
 | 
						||
        Header set CustomHeaderName three
 | 
						||
    </FilesMatch>
 | 
						||
</Directory>
 | 
						||
 | 
						||
<Directory "/example">
 | 
						||
    Header set CustomHeaderName two
 | 
						||
</Directory></pre>
 | 
						||
    
 | 
						||
    <ul>
 | 
						||
        <li><code class="directive">Directory</code> "/" matches and an initial configuration to set the <code>CustomHeaderName</code> header with the value <code>one</code> is created.</li>
 | 
						||
        <li><code class="directive">Directory</code> "/example" matches, and since <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> specifies in its code to override in case of a merge, a new configuration is created to set the <code>CustomHeaderName</code> header with the value <code>two</code>.</li>
 | 
						||
        <li><code class="directive">FilesMatch</code> ".*" matches and another merge opportunity arises, causing the <code>CustomHeaderName</code> header to be set with the value <code>three</code>.</li>
 | 
						||
        <li>Eventually during the next steps of the HTTP request processing <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> will be called and it will receive the configuration to set the <code>CustomHeaderName</code> header with the value <code>three</code>. <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> normally uses this configuration to perfom its job, namely setting the foo header. This does not mean that a module can't perform a more complex action like discarding directives because not needed or deprecated, etc..</li>
 | 
						||
    </ul>
 | 
						||
 | 
						||
    <p>This is true for .htaccess too since they have the same priority as <code class="directive">Directory</code> in the merge order. The important concept to understand is that configuration sections like  <code class="directive">Directory</code> and <code class="directive">FilesMatch</code> are not comparable to module specific directives like <code class="directive"><a href="./mod/mod_headers.html#header">Header</a></code> or <code class="directive"><a href="./mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> because they operate on different levels.
 | 
						||
    </p>
 | 
						||
 | 
						||
 | 
						||
<h3><a name="merge-examples" id="merge-examples">Some useful 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
 | 
						||
    </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>
 | 
						||
 | 
						||
# Whoops!  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<61>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<72>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 2018 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/quickreference.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> |