1<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 3<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 4 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 5 6<html xmlns="http://www.w3.org/1999/xhtml"> 7 <head> 8 <meta name="generator" content="HTML Tidy, see www.w3.org" /> 9 10 <title>How Directory, Location and Files sections work</title> 11 </head> 12 <!-- Background white, links blue (unvisited), navy (visited), red (active) --> 13 14 <body bgcolor="#FFFFFF" text="#000000" link="#0000FF" 15 vlink="#000080" alink="#FF0000"> 16 <div align="CENTER"> 17 <img src="images/sub.gif" alt="[APACHE DOCUMENTATION]" /> 18 19 <h3>Apache HTTP Server</h3> 20 </div> 21 22 23 24 <h1 align="CENTER">How Directory, Location and Files sections 25 work</h1> 26 27 <p>The sections <a 28 href="mod/core.html#directory"><code><Directory></code></a>, 29 <a 30 href="mod/core.html#location"><code><Location></code></a> 31 and <a 32 href="mod/core.html#files"><code><Files></code></a> can 33 contain directives which only apply to specified directories, 34 URLs or files respectively. Also htaccess files can be used 35 inside a directory to apply directives to that directory. This 36 document explains how these different sections differ and how 37 they relate to each other when Apache decides which directives 38 apply for a particular directory or request URL.</p> 39 40 <h2>Directives allowed in the sections</h2> 41 42 <p>Everything that is syntactically allowed in 43 <code><Directory></code> is also allowed in 44 <code><Location></code> (except a 45 sub-<code><Files></code> section). Semantically, however 46 some things, most notably <code>AllowOverride</code> and the 47 two options <code>FollowSymLinks</code> and 48 <code>SymLinksIfOwnerMatch</code>, make no sense in 49 <code><Location></code>, 50 <code><LocationMatch></code> or 51 <code><DirectoryMatch></code>. The same for 52 <code><Files></code> -- syntactically everything is fine, 53 but semantically some things are different.</p> 54 55 <h2>How the sections are merged</h2> 56 57 <p>The order of merging is:</p> 58 59 <ol> 60 <li><code><Directory></code> (except regular 61 expressions) and .htaccess done simultaneously (with 62 .htaccess, if allowed, overriding 63 <code><Directory></code>)</li> 64 65 <li><code><DirectoryMatch></code>, and 66 <code><Directory></code> with regular expressions</li> 67 68 <li><code><Files></code> and 69 <code><FilesMatch></code> done simultaneously</li> 70 71 <li><code><Location></code> and 72 <code><LocationMatch></code> done simultaneously</li> 73 </ol> 74 75 <p>Apart from <code><Directory></code>, each group is 76 processed in the order that they appear in the configuration 77 files. <code><Directory></code> (group 1 above) is 78 processed in the order shortest directory component to longest. 79 If multiple <code><Directory></code> sections apply to 80 the same directory they are processed in the configuration 81 file order. The configuration files are read in the order 82 httpd.conf, srm.conf and access.conf. Configurations included 83 via the <code>Include</code> directive will be treated as if 84 they were inside the including file at the location of the 85 <code>Include</code> directive.</p> 86 87 <p>Sections inside <code><VirtualHost></code> sections 88 are applied <em>after</em> the corresponding sections outside 89 the virtual host definition. This allows virtual hosts to 90 override the main server configuration. (Note: this only works 91 correctly from 1.2.2 and 1.3a2 onwards. Before those releases 92 sections inside virtual hosts were applied <em>before</em> the 93 main server).</p> 94 95 <p>Later sections override earlier ones.</p> 96 97 <h2>Notes about using sections</h2> 98 99 <p>The general guidelines are:</p> 100 101 <ul> 102 <li>If you are attempting to match objects at the filesystem 103 level then you must use <code><Directory></code> and/or 104 <code><Files></code>.</li> 105 106 <li>If you are attempting to match objects at the URL level 107 then you must use <code><Location></code></li> 108 </ul> 109 110 <p>But a notable exception is:</p> 111 112 <ul> 113 <li>proxy control is done via <code><Directory></code>. 114 This is a legacy mistake because the proxy existed prior to 115 <code><Location></code>. A future version of the config 116 language should probably switch this to 117 <code><Location></code>.</li> 118 </ul> 119 120 <p>Note about .htaccess parsing:</p> 121 122 <ul> 123 <li>Modifying .htaccess parsing during Location doesn't do 124 anything because .htaccess parsing has already occurred.</li> 125 </ul> 126 127 <p><code><Location></code> and symbolic links:</p> 128 129 <ul> 130 <li>It is not possible to use "<code>Options 131 FollowSymLinks</code>" or "<code>Options 132 SymLinksIfOwnerMatch</code>" inside a 133 <code><Location></code>, 134 <code><LocationMatch></code> or 135 <code><DirectoryMatch></code> section (the options are 136 simply ignored). Using the options in question is only 137 possible inside a <code><Directory></code> section (or 138 a <code>.htaccess</code> file).</li> 139 </ul> 140 141 <p><code><Files></code> and <code>Options</code>:</p> 142 143 <ul> 144 <li>Apache won't check for it, but using an 145 <code>Options</code> directive inside a 146 <code><Files></code> section has no effect.</li> 147 </ul> 148 149 <p>Another note:</p> 150 151 <ul> 152 <li>There is actually a 153 <code><Location></code>/<code><LocationMatch></code> 154 sequence performed just before the name translation phase 155 (where <code>Aliases</code> and <code>DocumentRoots</code> 156 are used to map URLs to filenames). The results of this 157 sequence are completely thrown away after the translation has 158 completed.</li> 159 </ul> 160 <hr /> 161 162 <h3 align="CENTER">Apache HTTP Server</h3> 163 <a href="./"><img src="images/index.gif" alt="Index" /></a> 164 165 </body> 166</html> 167 168 169 170
