From: pcs
+
+See also: How Directory,
+Location and Files sections work for an explanation of how these
+different sections are combined when a request is received
+
+
+
<DirectoryMatch>
Syntax: <DirectoryMatch regex> ... </DirectoryMatch>
@@ -435,7 +441,11 @@ argument a regular expression. For example:
See Also: <Directory> for a description of how -regular expressions are mixed in with normal <Directory>s.
+regular expressions are mixed in with normal <Directory>s. +/
character,
the directory being applied will be prefixed automatically.
-
+ +See also: How Directory, +Location and Files sections work for an explanation of how these +different sections are combined when a request is received + +
would match most common Internet graphics formats.
+See also: How Directory, +Location and Files sections work for an explanation of how these +different sections are combined when a request is received ++See also: How Directory, +Location and Files sections work for an explanation of how these +different sections are combined when a request is received +
would match URLs that contained the substring "/extra/data" or "/special/data".
+See also: How Directory, +Location and Files sections work for an explanation of how these +different sections are combined when a request is received +<Directory>
, <Location>
and <Files>
can contain
+directives which only apply to specified directories, URLs or files
+respectively. Also htaccess files can be used inside a directory to
+apply directives to that directory. This document explains how these
+different sections differ and how they relate to each other when
+Apache decides which directives apply for a particular directory or
+request URL.
+
+<Directory>
is also allowed in
+<Location>
(except a sub-<Files>
+section, but the code doesn't test for that, Lars has an open bug
+report on that). Semantically however some things, and the most
+notable is AllowOverrides, make no sense in
+<Location>
. The same for
+<Files>
-- syntactically everything is fine, but
+semantically some things are different.
+
+<Directory>
(except regular expressions) and
+ .htaccess done simultaneously (with .htaccess overriding
+ <Directory>
)
+
+<DirectoryMatch>
, and
+ <Directory>
with regular expressions
+
+<Files>
and <FilesMatch>
done simultaneously
+ <Location>
and <LocationMatch>
done simultaneously
+ <Directory>
, each group is processed in
+the order that they appear in the configuration
+files. <Directory>
(group 1 above) is processed in
+the order shortest directory component to longest. If multiple
+<Directory>
sections apply to the same directory
+they they are processed in the configuration file order. The
+configuration files are read in the order httpd.conf, srm.conf and
+access.conf. Configurations included via the Include
+directive will be treated as if they where inside the including file
+at the location of the Include
directive.
+
+
+
+Sections inside <VirtualHost>
sections are applied
+after the corresponding sections outside the virtual host
+definition. This allows virtual hosts to override the main server
+configuration. (Note: this only works correctly from 1.2.2 and 1.3a2
+onwards. Before those releases sections inside virtual hosts were
+applied before the main server).
+
+
+ +
<Directory>
and/or
+ <Files>
.
+<Location>
+<Directory>
. This is
+ a legacy mistake because the proxy existed prior to
+ <Location>
. A future version of the config
+ language should probably switch this to
+ <Location>
.
++ +Another note: +
+ +
<Location>
/<LocationMatch>
+ sequence performed just before the name translation phase (where
+ Aliases
and DocumentRoots
are used to
+ map URLs to filenames). The results of this sequence are
+ completely thrown away after the translation has completed.
+<Directory>
, <Location>
and <Files>
can contain
+directives which only apply to specified directories, URLs or files
+respectively. Also htaccess files can be used inside a directory to
+apply directives to that directory. This document explains how these
+different sections differ and how they relate to each other when
+Apache decides which directives apply for a particular directory or
+request URL.
+
+<Directory>
is also allowed in
+<Location>
(except a sub-<Files>
+section, but the code doesn't test for that, Lars has an open bug
+report on that). Semantically however some things, and the most
+notable is AllowOverrides, make no sense in
+<Location>
. The same for
+<Files>
-- syntactically everything is fine, but
+semantically some things are different.
+
+<Directory>
(except regular expressions) and
+ .htaccess done simultaneously (with .htaccess overriding
+ <Directory>
)
+
+<DirectoryMatch>
, and
+ <Directory>
with regular expressions
+
+<Files>
and <FilesMatch>
done simultaneously
+ <Location>
and <LocationMatch>
done simultaneously
+ <Directory>
, each group is processed in
+the order that they appear in the configuration
+files. <Directory>
(group 1 above) is processed in
+the order shortest directory component to longest. If multiple
+<Directory>
sections apply to the same directory
+they they are processed in the configuration file order. The
+configuration files are read in the order httpd.conf, srm.conf and
+access.conf. Configurations included via the Include
+directive will be treated as if they where inside the including file
+at the location of the Include
directive.
+
+
+
+Sections inside <VirtualHost>
sections are applied
+after the corresponding sections outside the virtual host
+definition. This allows virtual hosts to override the main server
+configuration. (Note: this only works correctly from 1.2.2 and 1.3a2
+onwards. Before those releases sections inside virtual hosts were
+applied before the main server).
+
+
+ +
<Directory>
and/or
+ <Files>
.
+<Location>
+<Directory>
. This is
+ a legacy mistake because the proxy existed prior to
+ <Location>
. A future version of the config
+ language should probably switch this to
+ <Location>
.
++ +Another note: +
+ +
<Location>
/<LocationMatch>
+ sequence performed just before the name translation phase (where
+ Aliases
and DocumentRoots
are used to
+ map URLs to filenames). The results of this sequence are
+ completely thrown away after the translation has completed.
+