| <?xml version="1.0" encoding="UTF-8" ?> |
| <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd"> |
| <?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?> |
| <!-- $LastChangedRevision$ --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <manualpage metafile="sections.xml.meta"> |
| |
| <title>Configuration Sections</title> |
| |
| <summary> <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> |
| </summary> |
| |
| <section id="types"><title>Types of Configuration Section Containers</title> |
| |
| <related> |
| <modulelist> |
| <module>core</module> |
| <module>mod_version</module> |
| <module>mod_proxy</module> |
| </modulelist> |
| <directivelist> |
| <directive type="section" module="core">Directory</directive> |
| <directive type="section" module="core">DirectoryMatch</directive> |
| <directive type="section" module="core">Files</directive> |
| <directive type="section" module="core">FilesMatch</directive> |
| <directive type="section" module="core">If</directive> |
| <directive type="section" module="core">IfDefine</directive> |
| <directive type="section" module="core">IfModule</directive> |
| <directive type="section" module="mod_version">IfVersion</directive> |
| <directive type="section" module="core">Location</directive> |
| <directive type="section" module="core">LocationMatch</directive> |
| <directive type="section" idtype="section" module="mod_md">MDomainSet</directive> |
| <directive type="section" module="mod_proxy">Proxy</directive> |
| <directive type="section" module="mod_proxy">ProxyMatch</directive> |
| <directive type="section" module="core">VirtualHost</directive> |
| </directivelist> |
| </related> |
| |
| <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 <directive |
| type="section" module="core">IfDefine</directive>, <directive |
| type="section" module="core">IfModule</directive>, and |
| <directive type="section" module="mod_version">IfVersion</directive> |
| 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 <directive type="section" module="core">IfDefine</directive> directive |
| encloses directives that will only be applied if an appropriate |
| parameter is defined on the <program>httpd</program> 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> |
| |
| <highlight language="config"> |
| <IfDefine ClosedForNow> |
| Redirect "/" "http://otherserver.example.com/" |
| </IfDefine> |
| </highlight> |
| |
| <p>The <directive type="section" module="core">IfModule</directive> |
| 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 <directive |
| module="mod_so">LoadModule</directive> 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 <directive |
| module="mod_mime_magic">MimeMagicFile</directive> directive will be |
| applied only if <module>mod_mime_magic</module> is available.</p> |
| |
| <highlight language="config"> |
| <IfModule mod_mime_magic.c> |
| MimeMagicFile "conf/magic" |
| </IfModule> |
| </highlight> |
| |
| <p>The <directive type="section" module="mod_version">IfVersion</directive> |
| directive is very similar to <directive type="section" |
| module="core">IfDefine</directive> and <directive type="section" |
| module="core">IfModule</directive>, 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> |
| |
| <highlight language="config"> |
| <IfVersion >= 2.4> |
| # this happens only in versions greater or |
| # equal 2.4.0. |
| </IfVersion> |
| </highlight> |
| |
| <p><directive type="section" module="core">IfDefine</directive>, |
| <directive type="section" module="core">IfModule</directive>, and the |
| <directive type="section" module="mod_version">IfVersion</directive> |
| can apply negative conditions by preceding their test with "!". |
| Also, these sections can be nested to achieve more complex |
| restrictions.</p> |
| </section> |
| |
| <section id="file-and-web"><title>Filesystem, Webspace, and Boolean Expressions</title> |
| |
| <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> |
| |
| <section id="filesystem"><title>Filesystem Containers</title> |
| |
| <p>The <directive type="section" module="core">Directory</directive> |
| and <directive type="section" module="core">Files</directive> |
| directives, along with their <glossary ref="regex">regex</glossary> |
| counterparts, apply directives to |
| parts of the filesystem. Directives enclosed in a <directive |
| type="section" module="core">Directory</directive> 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> |
| |
| <highlight language="config"> |
| <Directory "/var/web/dir1"> |
| Options +Indexes |
| </Directory> |
| </highlight> |
| |
| <p>Directives enclosed in a <directive type="section" |
| module="core">Files</directive> 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> |
| |
| <highlight language="config"> |
| <Files "private.html"> |
| Require all denied |
| </Files> |
| </highlight> |
| |
| <p>To address files found in a particular part of the filesystem, the |
| <directive type="section" module="core">Files</directive> and |
| <directive type="section" module="core">Directory</directive> 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> |
| |
| <highlight language="config"> |
| <Directory "/var/web/dir1"> |
| <Files "private.html"> |
| Require all denied |
| </Files> |
| </Directory> |
| </highlight> |
| </section> |
| |
| <section id="webspace"><title>Webspace Containers</title> |
| |
| <p>The <directive type="section" module="core">Location</directive> |
| directive and its <glossary ref="regex">regex</glossary> 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> |
| |
| <highlight language="config"> |
| <LocationMatch "^/private"> |
| Require all denied |
| </LocationMatch> |
| </highlight> |
| |
| <p>The <directive type="section" module="core">Location</directive> |
| 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 <module>mod_status</module>. |
| No file called <code>server-status</code> needs to exist in the |
| filesystem.</p> |
| |
| <highlight language="config"> |
| <Location "/server-status"> |
| SetHandler server-status |
| </Location> |
| </highlight> |
| </section> |
| |
| <section id="overlapping-webspace"><title>Overlapping Webspace</title> |
| <p>In order to have two overlapping URLs one has to consider the order in which |
| certain sections or directives are evaluated. For |
| <directive type="section" module="core">Location</directive> this would be:</p> |
| <highlight language="config"> |
| <Location "/foo"> |
| </Location> |
| <Location "/foo/bar"> |
| </Location> |
| </highlight> |
| <p><directive type="section" module="mod_alias">Alias</directive>es on the other hand, |
| are mapped vice-versa:</p> |
| <highlight language="config"> |
| Alias "/foo/bar" "/srv/www/uncommon/bar" |
| Alias "/foo" "/srv/www/common/foo" |
| </highlight> |
| <p>The same is true for the <directive module="mod_proxy">ProxyPass</directive> |
| directives:</p> |
| <highlight language="config"> |
| ProxyPass "/special-area" "http://special.example.com" smax=5 max=10 |
| ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On |
| </highlight> |
| </section> |
| |
| <section id="wildcards"><title>Wildcards and Regular Expressions</title> |
| |
| <p>The <directive type="section" module="core">Directory</directive>, |
| <directive type="section" module="core">Files</directive>, and |
| <directive type="section" module="core">Location</directive> |
| 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 <directive |
| type="section" module="core">DirectoryMatch</directive>, <directive |
| type="section" module="core">FilesMatch</directive>, and <directive |
| type="section" module="core">LocationMatch</directive> that allow |
| perl-compatible |
| <glossary ref="regex">regular expressions</glossary> |
| 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> |
| |
| <highlight language="config"> |
| <Directory "/home/*/public_html"> |
| Options Indexes |
| </Directory> |
| </highlight> |
| |
| <p>Using regex sections, we can deny access to many types of image files |
| at once:</p> |
| <highlight language="config"> |
| <FilesMatch "\.(?i:gif|jpe?g|png)$"> |
| Require all denied |
| </FilesMatch> |
| </highlight> |
| |
| <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 <module>mod_rewrite</module>.</p> |
| |
| <highlight language="config"> |
| <DirectoryMatch "^/var/www/combined/(?<SITENAME>[^/]+)"> |
| Require ldap-group "cn=%{env:MATCH_SITENAME},ou=combined,o=Example" |
| </DirectoryMatch> |
| </highlight> |
| |
| </section> |
| |
| <section id="expressions"><title>Boolean expressions</title> |
| <p>The <directive type="section" module="core">If</directive> |
| 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> |
| <highlight language="config"> |
| <If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')"> |
| Require all denied |
| </If> |
| </highlight> |
| |
| </section> |
| |
| <section id="whichwhen"><title>What to use When</title> |
| |
| <p>Choosing between filesystem containers and webspace containers is |
| actually quite easy. When applying directives to objects that reside |
| in the filesystem always use <directive type="section" |
| module="core">Directory</directive> or <directive type="section" |
| module="core">Files</directive>. When applying directives to objects |
| that do not reside in the filesystem (such as a webpage generated from |
| a database), use <directive type="section" |
| module="core">Location</directive>.</p> |
| |
| <p>It is important to never use <directive type="section" |
| module="core">Location</directive> 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> |
| |
| <highlight language="config"> |
| <Location "/dir/"> |
| Require all denied |
| </Location> |
| </highlight> |
| |
| <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 <directive |
| type="section" module="core">Directory</directive> 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 <directive type="section" |
| module="core">Directory</directive> 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 |
| <directive module="core">Options</directive> 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> |
| </section> |
| |
| <section id="nesting"><title>Nesting of sections</title> |
| |
| <p>Some section types can be nested inside other section types. On the one |
| hand, <directive type="section" module="core">Files</directive> can be used |
| inside <directive type="section" module="core">Directory</directive>. On |
| the other hand, <directive type="section" module="core">If</directive> can |
| be used inside <directive type="section" module="core">Directory</directive>, |
| <directive type="section" module="core">Location</directive>, and <directive |
| type="section" module="core">Files</directive> sections (but not inside another |
| <directive type="section" module="core">If</directive>). The regex |
| counterparts of the named section behave identically.</p> |
| |
| <p>Nested sections are merged after non-nested sections of the same type.</p> |
| |
| </section> |
| |
| </section> |
| |
| <section id="virtualhost"><title>Virtual Hosts</title> |
| |
| <p>The <directive type="section" module="core">VirtualHost</directive> |
| 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> |
| </section> |
| |
| <section id="proxy"><title>Proxy</title> |
| |
| <p>The <directive type="section" module="mod_proxy">Proxy</directive> |
| and <directive type="section" module="mod_proxy">ProxyMatch</directive> |
| containers apply enclosed configuration directives only |
| to sites accessed through <module>mod_proxy</module>'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> |
| |
| <highlight language="config"> |
| <Proxy "http://www.example.com/*"> |
| Require host yournetwork.example.com |
| </Proxy> |
| </highlight> |
| </section> |
| |
| <section id="whatwhere"><title>What Directives are Allowed?</title> |
| |
| <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 |
| <directive type="section" module="core">Directory</directive> |
| sections is also syntactically allowed in |
| <directive type="section" module="core">DirectoryMatch</directive>, |
| <directive type="section" module="core">Files</directive>, |
| <directive type="section" module="core">FilesMatch</directive>, |
| <directive type="section" module="core">Location</directive>, |
| <directive type="section" module="core">LocationMatch</directive>, |
| <directive type="section" module="mod_proxy">Proxy</directive>, |
| and <directive type="section" module="mod_proxy">ProxyMatch</directive> |
| sections. There are some exceptions, however:</p> |
| |
| <ul> |
| <li>The <directive module="core">AllowOverride</directive> directive |
| works only in <directive type="section" module="core">Directory</directive> |
| sections.</li> |
| |
| <li>The <code>FollowSymLinks</code> and |
| <code>SymLinksIfOwnerMatch</code> <directive |
| module="core">Options</directive> work only in <directive |
| type="section" module="core">Directory</directive> sections or |
| <code>.htaccess</code> files.</li> |
| |
| <li>The <directive module="core">Options</directive> directive cannot |
| be used in <directive type="section" module="core">Files</directive> |
| and <directive type="section" module="core">FilesMatch</directive> |
| sections.</li> |
| </ul> |
| </section> |
| |
| <section id="merging"><title>How the sections are merged</title> |
| |
| <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> <directive type="section" |
| module="core">Directory</directive> (except regular expressions) |
| and <code>.htaccess</code> done simultaneously (with |
| <code>.htaccess</code>, if allowed, overriding |
| <directive type="section" module="core">Directory</directive>)</li> |
| |
| <li><directive type="section" module="core">DirectoryMatch</directive> |
| (and <code><Directory "~"></code>)</li> |
| |
| <li><directive type="section" |
| module="core">Files</directive> and <directive |
| type="section" module="core">FilesMatch</directive> done |
| simultaneously</li> |
| |
| <li><directive type="section" module="core">Location</directive> |
| and <directive type="section" |
| module="core">LocationMatch</directive> done simultaneously</li> |
| |
| <li><directive type="section" module="core">If</directive> |
| </li> |
| |
| </ol> |
| |
| <p>Some important remarks:</p> |
| <ul> |
| <li>Apart from <directive type="section" |
| module="core">Directory</directive>, 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><directive type="section" module="core">Directory</directive> |
| (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 <directive |
| type="section" module="core">Directory</directive> sections apply |
| to the same directory they are processed in the configuration file |
| order.</li> |
| <li>Configurations included via the <directive |
| module="core">Include</directive> directive will be treated as if |
| they were inside the including file at the location of the |
| <directive module="core">Include</directive> directive.</li> |
| <li>Sections inside <directive type="section" |
| module="core">VirtualHost</directive> 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 <module>mod_proxy</module>, the |
| <directive module="mod_proxy" type="section">Proxy</directive> |
| container takes the place of the <directive module="core" |
| type="section">Directory</directive> container in the processing |
| order.</li> |
| </ul> |
| |
| <note><title>Technical Note</title> |
| 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. |
| </note> |
| |
| <section id="relationship-module-configuration"><title>Relationship between modules and configuration sections</title> |
| <p>One question that often arises after reading how configuration sections are |
| merged is related to how and when directives of specific modules like <module>mod_rewrite</module> |
| 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 |
| <directive module="mod_headers">Header</directive> directive of <module>mod_headers</module> 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> |
| <highlight language="config"> |
| |
| <Directory "/"> |
| Header set CustomHeaderName one |
| <FilesMatch ".*"> |
| Header set CustomHeaderName three |
| </FilesMatch> |
| </Directory> |
| |
| <Directory "/example"> |
| Header set CustomHeaderName two |
| </Directory> |
| |
| </highlight> |
| <ul> |
| <li><directive>Directory</directive> "/" matches and an initial configuration to set the <code>CustomHeaderName</code> header with the value <code>one</code> is created.</li> |
| <li><directive>Directory</directive> "/example" matches, and since <module>mod_headers</module> 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><directive>FilesMatch</directive> ".*" 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 <module>mod_headers</module> will be called and it will receive the configuration to set the <code>CustomHeaderName</code> header with the value <code>three</code>. <module>mod_headers</module> 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 <directive>Directory</directive> in the merge order. The important concept to understand is that configuration sections like <directive>Directory</directive> and <directive>FilesMatch</directive> are not comparable to module specific directives like <directive module="mod_headers">Header</directive> or <directive module="mod_rewrite">RewriteRule</directive> because they operate on different levels. |
| </p> |
| </section> |
| |
| <section id="merge-examples"><title>Some useful examples</title> |
| |
| <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> |
| |
| <highlight language="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> |
| |
| </highlight> |
| |
| |
| <p>For a more concrete example, consider the following. Regardless of |
| any access restrictions placed in <directive module="core" |
| type="section">Directory</directive> sections, the <directive |
| module="core" type="section">Location</directive> 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> |
| |
| <highlight language="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> |
| </highlight> |
| |
| </section> |
| |
| </section> |
| </manualpage> |