| <!DOCTYPE html SYSTEM "about:legacy-compat"> | |
| <html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8"> | |
| <meta content="width=device-width, initial-scale=1" name="viewport"> | |
| <!-- | |
| 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"> | |
| </script> | |
| <link href="./images/favicon.png" 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="https://cwiki.apache.org/confluence/display/httpd/FAQ">FAQ</a> | <a href="./glossary.html">Glossary</a> | <a href="./sitemap.html">Sitemap</a> | <a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2">Report a bug</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="https://www.apache.org/">Apache</a> > <a href="https://httpd.apache.org/">HTTP Server</a> > <a href="https://httpd.apache.org/docs/">Documentation</a> > <a href="./">Version 2.5</a></div><div id="page-content"><div id="preamble"><h1>Configuration Sections</h1> | |
| <button aria-label="Toggle language list" class="lang-toggle"><svg xmlns="http://www.w3.org/2000/svg" stroke-width="2" stroke="currentColor" fill="none" viewBox="0 0 24 24" height="16" width="16"><circle r="10" cy="12" cx="12"/><line y2="12" x2="22" y1="12" x1="2"/><path d="M12 2a15.3 15.3 0 0 1 4 10 15.3 15.3 0 0 1-4 10 15.3 15.3 0 0 1-4-10 15.3 15.3 0 0 1 4-10z"/></svg></button> | |
| <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></div> | |
| <div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="types">Types of Configuration Section Containers <a title="Permanent link" href="#types" class="permalink">¶</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/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, | |
| or with a <code class="directive"><a href="./mod/core.html#define">Define</a></code> directive. 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 id="file-and-web">Filesystem, Webspace, and Boolean Expressions <a title="Permanent link" href="#file-and-web" class="permalink">¶</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 id="filesystem">Filesystem Containers</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 id="webspace">Webspace Containers</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 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 on the | |
| filesystem.</p> | |
| <pre class="prettyprint lang-config"># Map a URL to a built-in handler: | |
| <Location "/server-status"> | |
| SetHandler server-status | |
| </Location> | |
| # Map a URL path to a reverse proxy backend: | |
| <Location "/app"> | |
| ProxyPass "http://backend.example.com/" | |
| ProxyPassReverse "http://backend.example.com/" | |
| </Location> | |
| # Deny access to a URL path regardless of what serves it: | |
| <Location "/private"> | |
| Require all denied | |
| </Location></pre> | |
| <p>Because <code class="directive"><a href="./mod/core.html#location"><Location></a></code> | |
| operates on URLs rather than filesystem paths, it is the appropriate | |
| container for proxy configuration and module-provided endpoints.</p> | |
| <h3 id="overlapping-webspace">Overlapping Webspace</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 id="wildcards">Wildcards and Regular Expressions</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 id="expressions">Boolean expressions</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 id="whichwhen">What to use When</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 id="nesting">Nesting of sections</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 id="virtualhost">Virtual Hosts <a title="Permanent link" href="#virtualhost" class="permalink">¶</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 id="proxy">Proxy <a title="Permanent link" href="#proxy" class="permalink">¶</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 id="whatwhere">What Directives are Allowed? <a title="Permanent link" href="#whatwhere" class="permalink">¶</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 id="merging">How the sections are merged <a title="Permanent link" href="#merging" class="permalink">¶</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> sections, even when | |
| they are enclosed in any of the preceding contexts. | |
| </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/bar</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 (regardless of the order in which they | |
| appear in the configuration file). 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. The same applies when multiple | |
| <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>, or | |
| <code class="directive"><a href="./mod/core.html#locationmatch"><LocationMatch></a></code> | |
| sections match the same resource.</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. Note that unlike the | |
| other section types, only one | |
| <code class="directive"><a href="./mod/core.html#virtualhost"><VirtualHost></a></code> | |
| is selected per request — directives from multiple matching | |
| vhosts are never merged. See | |
| <a href="vhosts/details.html">virtual host matching</a> | |
| for details on how a vhost is selected.</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> | |
| <li> Caution should be exercised when mixing related configuration | |
| directives inside and outside of <code class="directive"><a href="./mod/core.html#if"><If></a></code> because of the effect on merging order. Explicit use | |
| of <code class="directive"><a href="./mod/core.html#else"><Else></a></code> can help. | |
| </li> | |
| <li> When <code class="directive"><a href="./mod/core.html#if"><If></a></code> is | |
| used in <code>.htaccess</code>, the enclosed directives in a parent | |
| directory will be merged <em>after</em> non-enclosed directives in a | |
| subdirectory.</li> | |
| <li><div class="warning"><h3>Caution: <Limit> inside | |
| <Location> can silently grant access</h3> | |
| <p>Using <code class="directive"><a href="./mod/core.html#limit"><Limit></a></code> | |
| inside a <code class="directive"><a href="./mod/core.html#location"><Location></a></code> | |
| section to restrict authorization to specific HTTP methods can have | |
| unexpected results. For methods not listed in the | |
| <code class="directive"><a href="./mod/core.html#limit"><Limit></a></code>, the | |
| enclosing <code class="directive"><a href="./mod/core.html#location"><Location></a></code> | |
| section is treated as having no authorization requirements — which | |
| effectively grants access and overrides any | |
| <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> | |
| restrictions that would otherwise apply. Use | |
| <code class="directive"><a href="./mod/core.html#limitexcept"><LimitExcept></a></code> | |
| instead, or apply authorization without method restrictions.</p> | |
| </div></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 id="relationship-module-configuration">Relationship between modules and configuration sections</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 perform 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 id="merge-examples">Some useful examples</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ç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 id="footer"> | |
| <p class="apache">Copyright 2026 The Apache Software Foundation.<br>Licensed under the <a href="https://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="https://cwiki.apache.org/confluence/display/httpd/FAQ">FAQ</a> | <a href="./glossary.html">Glossary</a> | <a href="./sitemap.html">Sitemap</a> | <a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2">Report a bug</a></p></div><script><!--//--><![CDATA[//><!-- | |
| if (typeof(prettyPrint) !== 'undefined') { | |
| prettyPrint(); | |
| } | |
| var langToggle = document.querySelector('.lang-toggle'); | |
| var topLang = document.querySelector('.toplang'); | |
| if (langToggle && topLang) { | |
| langToggle.addEventListener('click', function() { topLang.classList.toggle('open'); }); | |
| } | |
| var qv = document.getElementById('quickview'); | |
| if (qv) { | |
| document.body.appendChild(qv); | |
| var qvBtn = document.createElement('button'); | |
| qvBtn.className = 'qv-toggle'; | |
| qvBtn.setAttribute('aria-label', 'Toggle page navigation'); | |
| qvBtn.innerHTML = '☰'; | |
| document.body.appendChild(qvBtn); | |
| qvBtn.addEventListener('click', function() { | |
| var isOpen = qv.classList.toggle('open'); | |
| if (isOpen) { | |
| qv.style.top = window.scrollY + 10 + 'px'; | |
| } | |
| }); | |
| window.addEventListener('scroll', function() { qv.classList.remove('open'); }); | |
| } | |
| //--><!]]></script> | |
| </body></html> |