<section id="introduction">
<title>Introduction</title>
- <p>As of Apache HTTP server version 2.2 <module>mod_cache</module> and
- <module>mod_file_cache</module> are no longer marked experimental and are
- considered suitable for production use. These caching architectures provide
- a powerful means to accelerate HTTP handling, both as a webserver and as a
- proxy.</p>
+ <p>As of Apache HTTP server version 2.2 <module>mod_cache</module>
+ and <module>mod_file_cache</module> are no longer marked
+ experimental and are considered suitable for production use. These
+ caching architectures provide a powerful means to accelerate HTTP
+ handling, both as an origin webserver and as a proxy.</p>
<p><module>mod_cache</module> and its provider modules
<module>mod_mem_cache</module> and <module>mod_disk_cache</module>
the complexity of actively ensuring the cachability of URLs,
<module>mod_file_cache</module> offers file-handle and memory-mapping
tricks to keep a cache of files as they were when Apache was last
- started. As such <module>mod_file_cache</module> is aimed at improving
+ started. As such, <module>mod_file_cache</module> is aimed at improving
the access time to local static files which do not change very
often.</p>
</directivelist>
</related>
- <p>There are two main stages in <module>mod_cache</module> which can
+ <p>There are two main stages in <module>mod_cache</module> that can
occur in the lifetime of a request. First, <module>mod_cache</module>
is a URL mapping module, which means that if a URL has been cached,
and the cached version of that URL has not expired, the request will
be served directly by <module>mod_cache</module>.</p>
- <p>This means that any other stages with might ordinarily happen in the
- process of serving a request, for example being handled by
- <module>mod_proxy</module>, or <module>mod_rewrite</module> won't happen.
- But then this is the point of caching content in the first place.</p>
+ <p>This means that any other stages that might ordinarily happen
+ in the process of serving a request -- for example being handled
+ by <module>mod_proxy</module>, or <module>mod_rewrite</module> --
+ won't happen. But then this is the point of caching content in
+ the first place.</p>
<p>If the URL is not found within the cache, <module>mod_cache</module>
will add a <a href="filter.html">filter</a> to the request handling. After
links.</p>
</note>
- <p>Extended regular
- expressions can also be used, with the addition of the
+ <p><glossary ref="regex">Regular
+ expressions</glossary> can also be used, with the addition of the
<code>~</code> character. For example:</p>
<example>
of directives which will apply only to the named directory and
sub-directories of that directory, the same as <directive
module="core" type="section">Directory</directive>. However, it
- takes as an argument a regular expression. For example:</p>
+ takes as an argument a <glossary ref="regex">regular
+ expression</glossary>. For example:</p>
<example>
<DirectoryMatch "^/www/(.+/)?[0-9]{3}">
<p>The <var>filename</var> argument should include a filename, or
a wild-card string, where <code>?</code> matches any single character,
- and <code>*</code> matches any sequences of characters. Extended regular
- expressions can also be used, with the addition of the
+ and <code>*</code> matches any sequences of characters.
+ <glossary ref="regex">Regular expressions</glossary>
+ can also be used, with the addition of the
<code>~</code> character. For example:</p>
<example>
<p>The <directive type="section">FilesMatch</directive> directive
limits the scope of the enclosed directives by filename, just as the
<directive module="core" type="section">Files</directive> directive
- does. However, it accepts a regular expression. For example:</p>
+ does. However, it accepts a <glossary ref="regex">regular
+ expression</glossary>. For example:</p>
<example>
<FilesMatch "\.(gif|jpe?g|png)$">
any single character, and <code>*</code> matches any sequences of
characters.</p>
- <p>Extended regular
- expressions can also be used, with the addition of the
+ <p><glossary ref="regex">Regular expressions</glossary>
+ can also be used, with the addition of the
<code>~</code> character. For example:</p>
<example>
<p>The <directive type="section">LocationMatch</directive> directive
limits the scope of the enclosed directives by URL, in an identical manner
to <directive module="core" type="section">Location</directive>. However,
- it takes a regular expression as an argument instead of a simple
- string. For example:</p>
+ it takes a <glossary ref="regex">regular expression</glossary>
+ as an argument instead of a simple string. For example:</p>
<example>
<LocationMatch "/(extra|special)/data">
<dt><em>regex</em></dt>
- <dd>A Perl-compatible <a href="../glossary.html#regex">regular
- expression</a>. The directive definition will specify what the
+ <dd>A Perl-compatible <glossary ref="regex">regular
+ expression</glossary>. The directive definition will specify what the
<em>regex</em> is matching against.</dd>
<dt><em>extension</em></dt>
<usage>
<p>This directive is equivalent to <directive
- module="mod_alias">Alias</directive>, but makes use of standard
- regular expressions, instead of simple prefix matching. The
+ module="mod_alias">Alias</directive>, but makes use of
+ <glossary ref="regex">regular expressions</glossary>,
+ instead of simple prefix matching. The
supplied regular expression is matched against the URL-path, and
if it matches, the server will substitute any parenthesized
matches into the given string and use it as a filename. For
<usage>
<p>This directive is equivalent to <directive
- module="mod_alias">Redirect</directive>, but makes use of standard
- regular expressions, instead of simple prefix matching. The
+ module="mod_alias">Redirect</directive>, but makes use of
+ <glossary ref="regex">regular expressions</glossary>,
+ instead of simple prefix matching. The
supplied regular expression is matched against the URL-path, and
if it matches, the server will substitute any parenthesized
matches into the given string and use it as a filename. For
<usage>
<p>This directive is equivalent to <directive module="mod_alias"
- >ScriptAlias</directive>, but makes use of standard
- regular expressions, instead of simple prefix matching. The
+ >ScriptAlias</directive>, but makes use of
+ <glossary ref="regex">regular expressions</glossary>,
+ instead of simple prefix matching. The
supplied regular expression is matched against the URL-path,
and if it matches, the server will substitute any parenthesized
matches into the given string and use it as a filename. For
<p>The <var>match</var> argument specifies a match that will be applied to
the filter's <var>dispatch</var> criterion. The <var>match</var> may be
- a string match (exact match or substring), a regexp, an integer (greater,
+ a string match (exact match or substring), a <glossary>regex</glossary>,
+ an integer (greater,
lessthan or equals), or unconditional. The first characters of the
<var>match</var> argument determines this:</p>
<tr><th>Character</th><th>Description</th></tr>
<tr><td><em>(none)</em></td><td>exact match</td></tr>
<tr><td><code>$</code></td><td>substring match</td></tr>
- <tr><td><code>/</code></td><td>regexp match (delimited by a second <code>/</code>)</td></tr>
+ <tr><td><code>/</code></td><td>regex match (delimited by a second <code>/</code>)</td></tr>
<tr><td><code>=</code></td><td>integer equality</td></tr>
<tr><td><code><</code></td><td>integer less-than</td></tr>
<tr><td><code><=</code></td><td>integer less-than or equal</td></tr>
<dt><code>echo</code></dt>
<dd>Request headers with this name are echoed back in the
- response headers. <var>header</var> may be a regular expression.
+ response headers. <var>header</var> may be a
+ <glossary ref="regex">regular expression</glossary>.
<var>value</var> must be omitted.</dd>
</dl>
can include the final colon, but it is not required. Case is
ignored for <code>set</code>, <code>append</code>, <code>add</code>
and <code>unset</code>. The <var>header</var> name for <code>echo</code>
- is case sensitive and may be a regular expression.</p>
+ is case sensitive and may be a <glossary ref="regex">regular
+ expression</glossary>.</p>
<p>For <code>add</code>, <code>append</code> and <code>set</code> a
<var>value</var> is specified as the third argument. If <var>value</var>
<p>The <directive type="section">ProxyMatch</directive> directive is
identical to the <directive module="mod_proxy"
type="section">Proxy</directive> directive, except it matches URLs
- using regular expressions.</p>
+ using <glossary ref="regex">regular expressions</glossary>.</p>
</usage>
</directivesynopsis>
<usage>
<p>The <directive>ProxyRemoteMatch</directive> is identical to the
<directive module="mod_proxy">ProxyRemote</directive> directive, except the
- first argument is a regular expression match against the requested URL.</p>
+ first argument is a <glossary ref="regex">regular expression</glossary>
+ match against the requested URL.</p>
</usage>
</directivesynopsis>
because any number of rules may already have matched and made
alterations to it.</p>
- <p>Some hints about the syntax of regular expressions:</p>
+ <p>Some hints about the syntax of <glossary ref="regex">regular
+ expressions</glossary>:</p>
<note><pre>
<strong>Text:</strong>
</li>
</ol>
-<p>The second argument (<em>regex</em>) is a <a
-href="http://www.pcre.org/">Perl compatible regular expression</a>.
-This is similar to a POSIX.2 egrep-style regular expression.
-If the <em>regex</em> matches against the <em>attribute</em>,
-then the remainder of the arguments are evaluated.</p>
+<p>The second argument (<em>regex</em>) is a <glossary
+ref="regex">regular expression</glossary>. If the <em>regex</em>
+matches against the <em>attribute</em>, then the remainder of the
+arguments are evaluated.</p>
<p>The rest of the arguments give the names of variables to set, and
optionally values to which they should be set. These take the form
</IfVersion>
</example>
- <p>Besides the numerical comparison it is possible to match a regular
- expression against the httpd version. There are two ways to write it:</p>
+ <p>Besides the numerical comparison it is possible to match a
+ <glossary ref="regex">regular expression</glossary>
+ against the httpd version. There are two ways to write it:</p>
<table style="zebra" border="1">
<tr><th><var>operator</var></th><th>description</th></tr>
scalability can choose to use a threaded MPM like
<module>worker</module> or <module>event</module>, while sites requiring
stability or compatibility with older software can use a
- <module>prefork</module>. In addition,
- special features like serving different hosts under different
- userids (<module>perchild</module>) can be
- provided.</li>
+ <module>prefork</module>.</li>
</ul>
<p>At the user level, MPMs appear much like other Apache
<p>The <directive type="section" module="core">Directory</directive>
and <directive type="section" module="core">Files</directive>
-directives, along with their regex counterparts, apply directives to
+directives, along with their <glossary>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
<section id="webspace"><title>Webspace Containers</title>
<p>The <directive type="section" module="core">Location</directive>
-directive and its regex counterpart, on the other hand, change the
+directive and its <glossary>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
explicitly.</p>
<p>If even more flexible matching is required, each
-container has a regular-expression (regex) counterpart <directive
+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
-<a href="glossary.html#regex">regular expressions</a>
+<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>
will be served from <code>/var/web/dir/file.html</code>. The
<directive module="mod_alias">ScriptAlias</directive> directive
works the same way, with the additional effect that all content
- located at the target path is treated as CGI scripts.</p>
+ located at the target path is treated as <glossary>CGI</glossary> scripts.</p>
<p>For situations where you require additional flexibility, you
- can use the <directive module="mod_alias">AliasMatch</directive> and
- <directive module="mod_alias">ScriptAliasMatch</directive>
- directives to do powerful regular-expression based matching and
- substitution. For example,</p>
+ can use the <directive module="mod_alias">AliasMatch</directive>
+ and <directive module="mod_alias">ScriptAliasMatch</directive>
+ directives to do powerful <glossary ref="regex">regular
+ expression</glossary> based matching and substitution. For
+ example,</p>
<example>ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+)
/home/$1/cgi-bin/$2</example>
projects / apache / commitdiff