granicus.if.org Git - apache/blob - docs/manual/sections.html.en

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
   2 <HTML><HEAD>
   3 <TITLE>How Directory, Location and Files sections work</TITLE>
   4 </HEAD>
   5
   6 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
   7 <BODY
   8  BGCOLOR="#FFFFFF"
   9  TEXT="#000000"
  10  LINK="#0000FF"
  11  VLINK="#000080"
  12  ALINK="#FF0000"
  13 >
  14 <!--#include virtual="header.html" -->
  15 <H1 ALIGN="CENTER">How Directory, Location and Files sections work</H1>
  16
  17 The sections <A
  18 HREF="mod/core.html#directory"><CODE>&lt;Directory&gt;</CODE></A>, <A
  19 HREF="mod/core.html#location"><CODE>&lt;Location&gt;</CODE></A> and <A
  20 HREF="mod/core.html#files"><CODE>&lt;Files&gt;</CODE></A> can contain
  21 directives which only apply to specified directories, URLs or files
  22 respectively. Also htaccess files can be used inside a directory to
  23 apply directives to that directory. This document explains how these
  24 different sections differ and how they relate to each other when
  25 Apache decides which directives apply for a particular directory or
  26 request URL.
  27
  28 <H2>Directives allowed in the sections</H2>
  29
  30 Everything that is syntactically allowed in
  31 <CODE>&lt;Directory&gt;</CODE> is also allowed in
  32 <CODE>&lt;Location&gt;</CODE> (except a sub-<CODE>&lt;Files&gt;</CODE>
  33 section, but the code doesn't test for that, Lars has an open bug
  34 report on that).  Semantically however some things, and the most
  35 notable is AllowOverride, make no sense in
  36 <CODE>&lt;Location&gt;</CODE>.  The same for
  37 <CODE>&lt;Files&gt;</CODE> -- syntactically everything is fine, but
  38 semantically some things are different.
  39
  40 <H2>How the sections are merged</H2>
  41
  42 The order of merging is:
  43
  44 <OL>
  45
  46 <LI>
  47
  48  <CODE>&lt;Directory&gt;</CODE> (except regular expressions) and
  49  .htaccess done simultaneously (with .htaccess overriding
  50  <CODE>&lt;Directory&gt;</CODE>)
  51
  52 </LI>
  53
  54 <LI>
  55  <CODE>&lt;DirectoryMatch&gt;</CODE>, and
  56  <CODE>&lt;Directory&gt;</CODE> with regular expressions
  57
  58 </LI>
  59
  60  <LI><CODE>&lt;Files&gt;</CODE> and <CODE>&lt;FilesMatch&gt;</CODE> done simultaneously
  61  </LI>
  62
  63  <LI><CODE>&lt;Location&gt;</CODE> and <CODE>&lt;LocationMatch&gt;</CODE> done simultaneously
  64  </LI>
  65
  66 </OL>
  67
  68 Apart from <CODE>&lt;Directory&gt;</CODE>, each group is processed in
  69 the order that they appear in the configuration
  70 files. <CODE>&lt;Directory&gt;</CODE> (group 1 above) is processed in
  71 the order shortest directory component to longest. If multiple
  72 <CODE>&lt;Directory&gt;</CODE> sections apply to the same directory
  73 they they are processed in the configuration file order.  The
  74 configuration files are read in the order httpd.conf, srm.conf and
  75 access.conf. Configurations included via the <CODE>Include</CODE>
  76 directive will be treated as if they where inside the including file
  77 at the location of the <CODE>Include</CODE> directive.
  78
  79 <P>
  80
  81 Sections inside <CODE>&lt;VirtualHost&gt;</CODE> sections are applied
  82 <EM>after</EM> the corresponding sections outside the virtual host
  83 definition. This allows virtual hosts to override the main server
  84 configuration. (Note: this only works correctly from 1.2.2 and 1.3a2
  85 onwards. Before those releases sections inside virtual hosts were
  86 applied <EM>before</EM> the main server).
  87
  88 <H2>Notes about using sections</H2>
  89
  90 The general guidelines are:
  91
  92 <P>
  93
  94 <UL>
  95 <LI>
  96     If you are attempting to match objects at the filesystem level
  97     then you must use <CODE>&lt;Directory&gt;</CODE> and/or
  98     <CODE>&lt;Files&gt;</CODE>.
  99 </LI>
 100
 101 <LI>
 102     If you are attempting to match objects at the URL level then you
 103     must use <CODE>&lt;Location&gt;</CODE>
 104 </LI>
 105 </UL>
 106
 107 But a notable exception is:
 108
 109 <UL>
 110 <LI>
 111     proxy control is done via <CODE>&lt;Directory&gt;</CODE>.  This is
 112     a legacy mistake because the proxy existed prior to
 113     <CODE>&lt;Location&gt;</CODE>.  A future version of the config
 114     language should probably switch this to
 115     <CODE>&lt;Location&gt;</CODE>.
 116 </LI>
 117 </UL>
 118
 119 Note also that modifying .htaccess parsing during Location doesn't do
 120 anything because .htaccess parsing has already occurred.
 121
 122 <P>
 123
 124 Another note:
 125 <P>
 126
 127 <UL>
 128 <LI>
 129     There is actually a
 130     <CODE>&lt;Location&gt;</CODE>/<CODE>&lt;LocationMatch&gt;</CODE>
 131     sequence performed just before the name translation phase (where
 132     <CODE>Aliases</CODE> and <CODE>DocumentRoots</CODE> are used to
 133     map URLs to filenames).  The results of this sequence are
 134     completely thrown away after the translation has completed.
 135 </LI>
 136 </UL>
 137
 138 <!--#include virtual="footer.html" -->
 139 </BODY></HTML>