httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From drugg...@apache.org
Subject svn commit: r1673876 [5/11] - /httpd/httpd/branches/2.2.x/docs/manual/mod/
Date Wed, 15 Apr 2015 17:04:54 GMT
Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/mod_filter.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/mod/mod_filter.html.en?rev=1673876&r1=1673875&r2=1673876&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/docs/manual/mod/mod_filter.html.en (original)
+++ httpd/httpd/branches/2.2.x/docs/manual/mod/mod_filter.html.en Wed Apr 15 17:04:53 2015
@@ -45,15 +45,7 @@
     to <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>; no change to existing filter modules is
     required (although it may be possible to simplify them).</p>
 </div>
-<div id="quickview"><h3 class="directives">Directives</h3>
-<ul id="toc">
-<li><img alt="" src="../images/down.gif" /> <a href="#filterchain">FilterChain</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#filterdeclare">FilterDeclare</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#filterprotocol">FilterProtocol</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#filterprovider">FilterProvider</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#filtertrace">FilterTrace</a></li>
-</ul>
-<h3>Topics</h3>
+<div id="quickview"><h3>Topics</h3>
 <ul id="topics">
 <li><img alt="" src="../images/down.gif" /> <a href="#smart">Smart Filtering</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#terms">Filter Declarations, Providers and Chains</a></li>
@@ -61,7 +53,200 @@
 <li><img alt="" src="../images/down.gif" /> <a href="#errordocs">Filtering and Response Status</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#examples">Examples</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#protocol">Protocol Handling</a></li>
-</ul><ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
+</ul><h3 class="directives">Directives</h3>
+<ul id="toc">
+<li><img alt="" src="../images/down.gif" /> <a href="#filterchain">FilterChain</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#filterdeclare">FilterDeclare</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#filterprotocol">FilterProtocol</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#filterprovider">FilterProvider</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#filtertrace">FilterTrace</a></li>
+</ul>
+<ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="smart" id="smart">Smart Filtering</a></h2>
+    <p>In the traditional filtering model, filters are inserted unconditionally
+    using <code class="directive"><a href="../mod/mod_mime.html#addoutputfilter">AddOutputFilter</a></code> and family.
+    Each filter then needs to determine whether to run, and there is little
+    flexibility available for server admins to allow the chain to be
+    configured dynamically.</p>
+
+    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> by contrast gives server administrators a
+    great deal of flexibility in configuring the filter chain.  In fact,
+    filters can be inserted based on any Request Header, Response Header
+    or Environment Variable.  This generalises the limited flexibility offered
+    by <code class="directive"><a href="../mod/core.html#addoutputfilterbytype">AddOutputFilterByType</a></code>, and fixes
+    it to work correctly with dynamic content, regardless of the
+    content generator.  The ability to dispatch based on Environment
+    Variables offers the full flexibility of configuration with
+    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> to anyone who needs it.</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="terms" id="terms">Filter Declarations, Providers and Chains</a></h2>
+    <p class="figure">
+    <img src="../images/mod_filter_old.gif" width="160" height="310" alt="[This image displays the traditional filter model]" /><br />
+    <dfn>Figure 1:</dfn> The traditional filter model</p>
+
+    <p>In the traditional model, output filters are a simple chain
+    from the content generator (handler) to the client.  This works well
+    provided the filter chain can be correctly configured, but presents
+    problems when the filters need to be configured dynamically based on
+    the outcome of the handler.</p>
+
+    <p class="figure">
+    <img src="../images/mod_filter_new.gif" width="423" height="331" alt="[This image shows the mod_filter model]" /><br />
+    <dfn>Figure 2:</dfn> The <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> model</p>
+
+    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> works by introducing indirection into
+    the filter chain.  Instead of inserting filters in the chain, we insert
+    a filter harness which in turn dispatches conditionally
+    to a filter provider.  Any content filter may be used as a provider
+    to <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>; no change to existing filter modules
+    is required (although it may be possible to simplify them).  There can be
+    multiple providers for one filter, but no more than one provider will
+    run for any single request.</p>
+
+    <p>A filter chain comprises any number of instances of the filter
+    harness, each of which may have any number of providers.  A special
+    case is that of a single provider with unconditional dispatch: this
+    is equivalent to inserting the provider filter directly into the chain.</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="config" id="config">Configuring the Chain</a></h2>
+    <p>There are three stages to configuring a filter chain with
+    <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>. For details of the directives, see below.</p>
+
+    <dl>
+    <dt>Declare Filters</dt>
+    <dd>The <code class="directive"><a href="#filterdeclare">FilterDeclare</a></code> directive
+    declares a filter, assigning it a name and filter type.  Required
+    only if the filter is not the default type AP_FTYPE_RESOURCE.</dd>
+
+    <dt>Register Providers</dt>
+    <dd>The <code class="directive"><a href="#filterprovider">FilterProvider</a></code>
+    directive registers a provider with a filter. The filter may have
+    been declared with <code class="directive"><a href="#filterdeclare">FilterDeclare</a></code>; if not, FilterProvider will implicitly
+    declare it with the default type AP_FTYPE_RESOURCE. The provider
+    must have been
+    registered with <code>ap_register_output_filter</code> by some module.
+    The remaining arguments to <code class="directive"><a href="#filterprovider">FilterProvider</a></code> are a dispatch criterion and a match string.
+    The former may be an HTTP request or response header, an environment
+    variable, or the Handler used by this request.  The latter is matched
+    to it for each request, to determine whether this provider will be
+    used to implement the filter for this request.</dd>
+
+    <dt>Configure the Chain</dt>
+    <dd>The above directives build components of a smart filter chain,
+    but do not configure it to run.  The <code class="directive"><a href="#filterchain">FilterChain</a></code> directive builds a filter chain from smart
+    filters declared, offering the flexibility to insert filters at the
+    beginning or end of the chain, remove a filter, or clear the chain.</dd>
+</dl>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="errordocs" id="errordocs">Filtering and Response Status</a></h2>
+    <p>mod_filter normally only runs filters on responses with
+    HTTP status 200 (OK).  If you want to filter documents with
+    other response statuses, you can set the <var>filter-errordocs</var>
+    environment variable, and it will work on all responses
+    regardless of status.  To refine this further, you can use
+    expression conditions with <code class="directive">FilterProvider</code>.</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="examples" id="examples">Examples</a></h2>
+    <dl>
+    <dt>Server side Includes (SSI)</dt>
+    <dd>A simple case of using <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> in place of
+    <code class="directive"><a href="../mod/core.html#addoutputfilterbytype">AddOutputFilterByType</a></code>
+    <div class="example"><p><code>
+      FilterDeclare SSI<br />
+      FilterProvider SSI INCLUDES resp=Content-Type $text/html<br />
+      FilterChain SSI
+    </code></p></div>
+    </dd>
+
+    <dt>Server side Includes (SSI)</dt>
+    <dd>The same as the above but dispatching on handler (classic
+    SSI behaviour; .shtml files get processed).
+    <div class="example"><p><code>
+      FilterProvider SSI INCLUDES Handler server-parsed<br />
+      FilterChain SSI
+    </code></p></div>
+    </dd>
+
+    <dt>Emulating mod_gzip with mod_deflate</dt>
+    <dd>Insert INFLATE filter only if "gzip" is NOT in the
+    Accept-Encoding header.  This filter runs with ftype CONTENT_SET.
+    <div class="example"><p><code>
+      FilterDeclare gzip CONTENT_SET<br />
+      FilterProvider gzip inflate req=Accept-Encoding !$gzip<br />
+      FilterChain gzip
+    </code></p></div>
+    </dd>
+
+    <dt>Image Downsampling</dt>
+    <dd>Suppose we want to downsample all web images, and have filters
+    for GIF, JPEG and PNG.
+    <div class="example"><p><code>
+      FilterProvider unpack jpeg_unpack Content-Type $image/jpeg<br />
+      FilterProvider unpack gif_unpack Content-Type $image/gif<br />
+      FilterProvider unpack png_unpack Content-Type $image/png<br />
+      <br />
+      FilterProvider downsample downsample_filter Content-Type $image<br />
+      FilterProtocol downsample "change=yes"<br />
+      <br />
+      FilterProvider repack jpeg_pack Content-Type $image/jpeg<br />
+      FilterProvider repack gif_pack Content-Type $image/gif<br />
+      FilterProvider repack png_pack Content-Type $image/png<br />
+      &lt;Location /image-filter&gt;<br />
+      <span class="indent">
+        FilterChain unpack downsample repack<br />
+      </span>
+      &lt;/Location&gt;
+    </code></p></div>
+    </dd>
+    </dl>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="protocol" id="protocol">Protocol Handling</a></h2>
+    <p>Historically, each filter is responsible for ensuring that whatever
+    changes it makes are correctly represented in the HTTP response headers,
+    and that it does not run when it would make an illegal change.  This
+    imposes a burden on filter authors to re-implement some common
+    functionality in every filter:</p>
+
+    <ul>
+    <li>Many filters will change the content, invalidating existing content
+    tags, checksums, hashes, and lengths.</li>
+
+    <li>Filters that require an entire, unbroken response in input need to
+    ensure they don't get byteranges from a backend.</li>
+
+    <li>Filters that transform output in a filter need to ensure they don't
+    violate a <code>Cache-Control: no-transform</code> header from the
+    backend.</li>
+
+    <li>Filters may make responses uncacheable.</li>
+    </ul>
+
+    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> aims to offer generic handling of these
+    details of filter implementation, reducing the complexity required of
+    content filter modules. This is work-in-progress; the
+    <code class="directive"><a href="#filterprotocol">FilterProtocol</a></code> implements
+    some of this functionality for back-compatibility with Apache 2.0
+    modules.  For httpd 2.1 and later, the
+    <code>ap_register_output_filter_protocol</code> and
+    <code>ap_filter_protocol</code> API enables filter modules to
+    declare their own behaviour.</p>
+
+    <p>At the same time, <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> should not interfere
+    with a filter that wants to handle all aspects of the protocol.  By
+    default (i.e. in the absence of any <code class="directive"><a href="#filterprotocol">FilterProtocol</a></code> directives), <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>
+    will leave the headers untouched.</p>
+
+    <p>At the time of writing, this feature is largely untested,
+    as modules in common use are designed to work with 2.0.
+    Modules using it should test it carefully.</p>
+</div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="directive-section"><h2><a name="FilterChain" id="FilterChain">FilterChain</a> <a name="filterchain" id="filterchain">Directive</a></h2>
 <table class="directive">
@@ -262,191 +447,6 @@
     </dl>
 
 </div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="smart" id="smart">Smart Filtering</a></h2>
-    <p>In the traditional filtering model, filters are inserted unconditionally
-    using <code class="directive"><a href="../mod/mod_mime.html#addoutputfilter">AddOutputFilter</a></code> and family.
-    Each filter then needs to determine whether to run, and there is little
-    flexibility available for server admins to allow the chain to be
-    configured dynamically.</p>
-
-    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> by contrast gives server administrators a
-    great deal of flexibility in configuring the filter chain.  In fact,
-    filters can be inserted based on any Request Header, Response Header
-    or Environment Variable.  This generalises the limited flexibility offered
-    by <code class="directive"><a href="../mod/core.html#addoutputfilterbytype">AddOutputFilterByType</a></code>, and fixes
-    it to work correctly with dynamic content, regardless of the
-    content generator.  The ability to dispatch based on Environment
-    Variables offers the full flexibility of configuration with
-    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> to anyone who needs it.</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="terms" id="terms">Filter Declarations, Providers and Chains</a></h2>
-    <p class="figure">
-    <img src="../images/mod_filter_old.gif" width="160" height="310" alt="[This image displays the traditional filter model]" /><br />
-    <dfn>Figure 1:</dfn> The traditional filter model</p>
-
-    <p>In the traditional model, output filters are a simple chain
-    from the content generator (handler) to the client.  This works well
-    provided the filter chain can be correctly configured, but presents
-    problems when the filters need to be configured dynamically based on
-    the outcome of the handler.</p>
-
-    <p class="figure">
-    <img src="../images/mod_filter_new.gif" width="423" height="331" alt="[This image shows the mod_filter model]" /><br />
-    <dfn>Figure 2:</dfn> The <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> model</p>
-
-    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> works by introducing indirection into
-    the filter chain.  Instead of inserting filters in the chain, we insert
-    a filter harness which in turn dispatches conditionally
-    to a filter provider.  Any content filter may be used as a provider
-    to <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>; no change to existing filter modules
-    is required (although it may be possible to simplify them).  There can be
-    multiple providers for one filter, but no more than one provider will
-    run for any single request.</p>
-
-    <p>A filter chain comprises any number of instances of the filter
-    harness, each of which may have any number of providers.  A special
-    case is that of a single provider with unconditional dispatch: this
-    is equivalent to inserting the provider filter directly into the chain.</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="config" id="config">Configuring the Chain</a></h2>
-    <p>There are three stages to configuring a filter chain with
-    <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>. For details of the directives, see below.</p>
-
-    <dl>
-    <dt>Declare Filters</dt>
-    <dd>The <code class="directive"><a href="#filterdeclare">FilterDeclare</a></code> directive
-    declares a filter, assigning it a name and filter type.  Required
-    only if the filter is not the default type AP_FTYPE_RESOURCE.</dd>
-
-    <dt>Register Providers</dt>
-    <dd>The <code class="directive"><a href="#filterprovider">FilterProvider</a></code>
-    directive registers a provider with a filter. The filter may have
-    been declared with <code class="directive"><a href="#filterdeclare">FilterDeclare</a></code>; if not, FilterProvider will implicitly
-    declare it with the default type AP_FTYPE_RESOURCE. The provider
-    must have been
-    registered with <code>ap_register_output_filter</code> by some module.
-    The remaining arguments to <code class="directive"><a href="#filterprovider">FilterProvider</a></code> are a dispatch criterion and a match string.
-    The former may be an HTTP request or response header, an environment
-    variable, or the Handler used by this request.  The latter is matched
-    to it for each request, to determine whether this provider will be
-    used to implement the filter for this request.</dd>
-
-    <dt>Configure the Chain</dt>
-    <dd>The above directives build components of a smart filter chain,
-    but do not configure it to run.  The <code class="directive"><a href="#filterchain">FilterChain</a></code> directive builds a filter chain from smart
-    filters declared, offering the flexibility to insert filters at the
-    beginning or end of the chain, remove a filter, or clear the chain.</dd>
-</dl>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="errordocs" id="errordocs">Filtering and Response Status</a></h2>
-    <p>mod_filter normally only runs filters on responses with
-    HTTP status 200 (OK).  If you want to filter documents with
-    other response statuses, you can set the <var>filter-errordocs</var>
-    environment variable, and it will work on all responses
-    regardless of status.  To refine this further, you can use
-    expression conditions with <code class="directive">FilterProvider</code>.</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="examples" id="examples">Examples</a></h2>
-    <dl>
-    <dt>Server side Includes (SSI)</dt>
-    <dd>A simple case of using <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> in place of
-    <code class="directive"><a href="../mod/core.html#addoutputfilterbytype">AddOutputFilterByType</a></code>
-    <div class="example"><p><code>
-      FilterDeclare SSI<br />
-      FilterProvider SSI INCLUDES resp=Content-Type $text/html<br />
-      FilterChain SSI
-    </code></p></div>
-    </dd>
-
-    <dt>Server side Includes (SSI)</dt>
-    <dd>The same as the above but dispatching on handler (classic
-    SSI behaviour; .shtml files get processed).
-    <div class="example"><p><code>
-      FilterProvider SSI INCLUDES Handler server-parsed<br />
-      FilterChain SSI
-    </code></p></div>
-    </dd>
-
-    <dt>Emulating mod_gzip with mod_deflate</dt>
-    <dd>Insert INFLATE filter only if "gzip" is NOT in the
-    Accept-Encoding header.  This filter runs with ftype CONTENT_SET.
-    <div class="example"><p><code>
-      FilterDeclare gzip CONTENT_SET<br />
-      FilterProvider gzip inflate req=Accept-Encoding !$gzip<br />
-      FilterChain gzip
-    </code></p></div>
-    </dd>
-
-    <dt>Image Downsampling</dt>
-    <dd>Suppose we want to downsample all web images, and have filters
-    for GIF, JPEG and PNG.
-    <div class="example"><p><code>
-      FilterProvider unpack jpeg_unpack Content-Type $image/jpeg<br />
-      FilterProvider unpack gif_unpack Content-Type $image/gif<br />
-      FilterProvider unpack png_unpack Content-Type $image/png<br />
-      <br />
-      FilterProvider downsample downsample_filter Content-Type $image<br />
-      FilterProtocol downsample "change=yes"<br />
-      <br />
-      FilterProvider repack jpeg_pack Content-Type $image/jpeg<br />
-      FilterProvider repack gif_pack Content-Type $image/gif<br />
-      FilterProvider repack png_pack Content-Type $image/png<br />
-      &lt;Location /image-filter&gt;<br />
-      <span class="indent">
-        FilterChain unpack downsample repack<br />
-      </span>
-      &lt;/Location&gt;
-    </code></p></div>
-    </dd>
-    </dl>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="protocol" id="protocol">Protocol Handling</a></h2>
-    <p>Historically, each filter is responsible for ensuring that whatever
-    changes it makes are correctly represented in the HTTP response headers,
-    and that it does not run when it would make an illegal change.  This
-    imposes a burden on filter authors to re-implement some common
-    functionality in every filter:</p>
-
-    <ul>
-    <li>Many filters will change the content, invalidating existing content
-    tags, checksums, hashes, and lengths.</li>
-
-    <li>Filters that require an entire, unbroken response in input need to
-    ensure they don't get byteranges from a backend.</li>
-
-    <li>Filters that transform output in a filter need to ensure they don't
-    violate a <code>Cache-Control: no-transform</code> header from the
-    backend.</li>
-
-    <li>Filters may make responses uncacheable.</li>
-    </ul>
-
-    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> aims to offer generic handling of these
-    details of filter implementation, reducing the complexity required of
-    content filter modules. This is work-in-progress; the
-    <code class="directive"><a href="#filterprotocol">FilterProtocol</a></code> implements
-    some of this functionality for back-compatibility with Apache 2.0
-    modules.  For httpd 2.1 and later, the
-    <code>ap_register_output_filter_protocol</code> and
-    <code>ap_filter_protocol</code> API enables filter modules to
-    declare their own behaviour.</p>
-
-    <p>At the same time, <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> should not interfere
-    with a filter that wants to handle all aspects of the protocol.  By
-    default (i.e. in the absence of any <code class="directive"><a href="#filterprotocol">FilterProtocol</a></code> directives), <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>
-    will leave the headers untouched.</p>
-
-    <p>At the time of writing, this feature is largely untested,
-    as modules in common use are designed to work with 2.0.
-    Modules using it should test it carefully.</p>
-</div>
 </div>
 <div class="bottomlang">
 <p><span>Available Languages: </span><a href="../en/mod/mod_filter.html" title="English">&nbsp;en&nbsp;</a></p>

Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/mod_headers.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/mod/mod_headers.html.en?rev=1673876&r1=1673875&r2=1673876&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/docs/manual/mod/mod_headers.html.en (original)
+++ httpd/httpd/branches/2.2.x/docs/manual/mod/mod_headers.html.en Wed Apr 15 17:04:53 2015
@@ -39,17 +39,165 @@ headers</td></tr>
     request and response headers. Headers can be merged, replaced
     or removed.</p>
 </div>
-<div id="quickview"><h3 class="directives">Directives</h3>
-<ul id="toc">
-<li><img alt="" src="../images/down.gif" /> <a href="#header">Header</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#requestheader">RequestHeader</a></li>
-</ul>
-<h3>Topics</h3>
+<div id="quickview"><h3>Topics</h3>
 <ul id="topics">
 <li><img alt="" src="../images/down.gif" /> <a href="#order">Order of Processing</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#early">Early and Late Processing</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#examples">Examples</a></li>
-</ul><ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
+</ul><h3 class="directives">Directives</h3>
+<ul id="toc">
+<li><img alt="" src="../images/down.gif" /> <a href="#header">Header</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#requestheader">RequestHeader</a></li>
+</ul>
+<ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="order" id="order">Order of Processing</a></h2>
+
+    <p>The directives provided by <code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> can
+    occur almost anywhere within the server configuration, and can be
+    limited in scope by enclosing them in <a href="../sections.html">configuration sections</a>.</p>
+
+    <p>Order of processing is important and is affected both by the
+    order in the configuration file and by placement in <a href="../sections.html#mergin">configuration sections</a>. These
+    two directives have a different effect if reversed:</p>
+
+    <div class="example"><p><code>
+      RequestHeader append MirrorID "mirror 12"<br />
+      RequestHeader unset MirrorID
+    </code></p></div>
+
+    <p>This way round, the <code>MirrorID</code> header is not set. If
+    reversed, the MirrorID header is set to "mirror 12".</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="early" id="early">Early and Late Processing</a></h2>
+    <p><code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> can be applied either early or late
+    in the request.  The normal mode is late, when <em>Request</em> Headers are
+    set immediately before running the content generator and <em>Response</em>
+    Headers just as the response is sent down the wire.  Always use
+    Late mode in an operational server.</p>
+
+    <p>Early mode is designed as a test/debugging aid for developers.
+    Directives defined using the <code>early</code> keyword are set
+    right at the beginning of processing the request.  This means
+    they can be used to simulate different requests and set up test
+    cases, but it also means that headers may be changed at any time
+    by other modules before generating a Response.</p>
+
+    <p>Because early directives are processed before the request path's
+    configuration is traversed, early headers can only be set in a
+    main server or virtual host context.  Early directives cannot depend
+    on a request path, so they will fail in contexts such as
+    <code>&lt;Directory&gt;</code> or <code>&lt;Location&gt;</code>.</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="examples" id="examples">Examples</a></h2>
+
+    <ol>
+      <li>
+        Copy all request headers that begin with "TS" to the
+        response headers:
+
+        <div class="example"><p><code>
+          Header echo ^TS
+        </code></p></div>
+      </li>
+
+      <li>
+        Add a header, <code>MyHeader</code>, to the response including a
+        timestamp for when the request was received and how long it
+        took to begin serving the request. This header can be used by
+        the client to intuit load on the server or in isolating
+        bottlenecks between the client and the server.
+
+        <div class="example"><p><code>
+          Header set MyHeader "%D %t"
+        </code></p></div>
+
+        <p>results in this header being added to the response:</p>
+
+        <div class="example"><p><code>
+          MyHeader: D=3775428 t=991424704447256
+        </code></p></div>
+      </li>
+
+      <li>
+        Say hello to Joe
+
+        <div class="example"><p><code>
+          Header set MyHeader "Hello Joe. It took %D microseconds \<br />
+          for Apache to serve this request."
+        </code></p></div>
+
+        <p>results in this header being added to the response:</p>
+
+        <div class="example"><p><code>
+          MyHeader: Hello Joe. It took D=3775428 microseconds for Apache
+          to serve this request.
+        </code></p></div>
+      </li>
+
+      <li>
+        Conditionally send <code>MyHeader</code> on the response if and
+        only if header <code>MyRequestHeader</code> is present on the request.
+        This is useful for constructing headers in response to some client
+        stimulus. Note that this example requires the services of the
+        <code class="module"><a href="../mod/mod_setenvif.html">mod_setenvif</a></code> module.
+
+        <div class="example"><p><code>
+          SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader<br />
+          Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
+        </code></p></div>
+
+        <p>If the header <code>MyRequestHeader: myvalue</code> is present on
+        the HTTP request, the response will contain the following header:</p>
+
+        <div class="example"><p><code>
+          MyHeader: D=3775428 t=991424704447256 mytext
+        </code></p></div>
+      </li>
+
+      <li>
+        Enable DAV to work with Apache running HTTP through SSL hardware
+        (<a href="http://svn.haxx.se/users/archive-2006-03/0549.shtml">problem
+        description</a>) by replacing <var>https:</var> with
+        <var>http:</var> in the <var>Destination</var> header:
+
+        <div class="example"><p><code>
+          RequestHeader edit Destination ^https: http: early
+        </code></p></div>
+      </li>
+
+      <li>
+        Set the same header value under multiple nonexclusive conditions,
+        but do not duplicate the value in the final header.
+        If all of the following conditions applied to a request (i.e.,
+        if the <code>CGI</code>, <code>NO_CACHE</code> and
+        <code>NO_STORE</code> environment variables all existed for the
+        request):
+
+        <div class="example"><p><code>
+          Header merge Cache-Control no-cache env=CGI<br />
+          Header merge Cache-Control no-cache env=NO_CACHE<br />
+          Header merge Cache-Control no-store env=NO_STORE
+        </code></p></div>
+
+        <p>then the response would contain the following header:</p>
+
+        <div class="example"><p><code>
+          Cache-Control: no-cache, no-store
+        </code></p></div>
+
+        <p>If <code>append</code> was used instead of <code>merge</code>,
+        then the response would contain the following header:</p>
+
+        <div class="example"><p><code>
+          Cache-Control: no-cache, no-cache, no-store
+        </code></p></div>
+      </li>
+    </ol>
+</div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="directive-section"><h2><a name="Header" id="Header">Header</a> <a name="header" id="header">Directive</a></h2>
 <table class="directive">
@@ -316,154 +464,6 @@ headers</td></tr>
     input filters to be overridden or modified.</p>
 
 </div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="order" id="order">Order of Processing</a></h2>
-
-    <p>The directives provided by <code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> can
-    occur almost anywhere within the server configuration, and can be
-    limited in scope by enclosing them in <a href="../sections.html">configuration sections</a>.</p>
-
-    <p>Order of processing is important and is affected both by the
-    order in the configuration file and by placement in <a href="../sections.html#mergin">configuration sections</a>. These
-    two directives have a different effect if reversed:</p>
-
-    <div class="example"><p><code>
-      RequestHeader append MirrorID "mirror 12"<br />
-      RequestHeader unset MirrorID
-    </code></p></div>
-
-    <p>This way round, the <code>MirrorID</code> header is not set. If
-    reversed, the MirrorID header is set to "mirror 12".</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="early" id="early">Early and Late Processing</a></h2>
-    <p><code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> can be applied either early or late
-    in the request.  The normal mode is late, when <em>Request</em> Headers are
-    set immediately before running the content generator and <em>Response</em>
-    Headers just as the response is sent down the wire.  Always use
-    Late mode in an operational server.</p>
-
-    <p>Early mode is designed as a test/debugging aid for developers.
-    Directives defined using the <code>early</code> keyword are set
-    right at the beginning of processing the request.  This means
-    they can be used to simulate different requests and set up test
-    cases, but it also means that headers may be changed at any time
-    by other modules before generating a Response.</p>
-
-    <p>Because early directives are processed before the request path's
-    configuration is traversed, early headers can only be set in a
-    main server or virtual host context.  Early directives cannot depend
-    on a request path, so they will fail in contexts such as
-    <code>&lt;Directory&gt;</code> or <code>&lt;Location&gt;</code>.</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="examples" id="examples">Examples</a></h2>
-
-    <ol>
-      <li>
-        Copy all request headers that begin with "TS" to the
-        response headers:
-
-        <div class="example"><p><code>
-          Header echo ^TS
-        </code></p></div>
-      </li>
-
-      <li>
-        Add a header, <code>MyHeader</code>, to the response including a
-        timestamp for when the request was received and how long it
-        took to begin serving the request. This header can be used by
-        the client to intuit load on the server or in isolating
-        bottlenecks between the client and the server.
-
-        <div class="example"><p><code>
-          Header set MyHeader "%D %t"
-        </code></p></div>
-
-        <p>results in this header being added to the response:</p>
-
-        <div class="example"><p><code>
-          MyHeader: D=3775428 t=991424704447256
-        </code></p></div>
-      </li>
-
-      <li>
-        Say hello to Joe
-
-        <div class="example"><p><code>
-          Header set MyHeader "Hello Joe. It took %D microseconds \<br />
-          for Apache to serve this request."
-        </code></p></div>
-
-        <p>results in this header being added to the response:</p>
-
-        <div class="example"><p><code>
-          MyHeader: Hello Joe. It took D=3775428 microseconds for Apache
-          to serve this request.
-        </code></p></div>
-      </li>
-
-      <li>
-        Conditionally send <code>MyHeader</code> on the response if and
-        only if header <code>MyRequestHeader</code> is present on the request.
-        This is useful for constructing headers in response to some client
-        stimulus. Note that this example requires the services of the
-        <code class="module"><a href="../mod/mod_setenvif.html">mod_setenvif</a></code> module.
-
-        <div class="example"><p><code>
-          SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader<br />
-          Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
-        </code></p></div>
-
-        <p>If the header <code>MyRequestHeader: myvalue</code> is present on
-        the HTTP request, the response will contain the following header:</p>
-
-        <div class="example"><p><code>
-          MyHeader: D=3775428 t=991424704447256 mytext
-        </code></p></div>
-      </li>
-
-      <li>
-        Enable DAV to work with Apache running HTTP through SSL hardware
-        (<a href="http://svn.haxx.se/users/archive-2006-03/0549.shtml">problem
-        description</a>) by replacing <var>https:</var> with
-        <var>http:</var> in the <var>Destination</var> header:
-
-        <div class="example"><p><code>
-          RequestHeader edit Destination ^https: http: early
-        </code></p></div>
-      </li>
-
-      <li>
-        Set the same header value under multiple nonexclusive conditions,
-        but do not duplicate the value in the final header.
-        If all of the following conditions applied to a request (i.e.,
-        if the <code>CGI</code>, <code>NO_CACHE</code> and
-        <code>NO_STORE</code> environment variables all existed for the
-        request):
-
-        <div class="example"><p><code>
-          Header merge Cache-Control no-cache env=CGI<br />
-          Header merge Cache-Control no-cache env=NO_CACHE<br />
-          Header merge Cache-Control no-store env=NO_STORE
-        </code></p></div>
-
-        <p>then the response would contain the following header:</p>
-
-        <div class="example"><p><code>
-          Cache-Control: no-cache, no-store
-        </code></p></div>
-
-        <p>If <code>append</code> was used instead of <code>merge</code>,
-        then the response would contain the following header:</p>
-
-        <div class="example"><p><code>
-          Cache-Control: no-cache, no-cache, no-store
-        </code></p></div>
-      </li>
-    </ol>
-</div>
 </div>
 <div class="bottomlang">
 <p><span>Available Languages: </span><a href="../en/mod/mod_headers.html" title="English">&nbsp;en&nbsp;</a> |

Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/mod_ident.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/mod/mod_ident.html.en?rev=1673876&r1=1673875&r2=1673876&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/docs/manual/mod/mod_ident.html.en (original)
+++ httpd/httpd/branches/2.2.x/docs/manual/mod/mod_ident.html.en Wed Apr 15 17:04:53 2015
@@ -47,6 +47,7 @@
 <ul class="seealso">
 <li><code class="module"><a href="../mod/mod_log_config.html">mod_log_config</a></code></li>
 </ul><ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
+
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="directive-section"><h2><a name="IdentityCheck" id="IdentityCheck">IdentityCheck</a> <a name="identitycheck" id="identitycheck">Directive</a></h2>
 <table class="directive">
@@ -94,7 +95,6 @@ user</td></tr>
     timeout value according to your local network speed.</p>
 
 </div>
-
 </div>
 <div class="bottomlang">
 <p><span>Available Languages: </span><a href="../en/mod/mod_ident.html" title="English">&nbsp;en&nbsp;</a> |

Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/mod_imagemap.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/mod/mod_imagemap.html.en?rev=1673876&r1=1673875&r2=1673876&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/docs/manual/mod/mod_imagemap.html.en (original)
+++ httpd/httpd/branches/2.2.x/docs/manual/mod/mod_imagemap.html.en Wed Apr 15 17:04:53 2015
@@ -53,106 +53,19 @@
     <p>However, we are trying to phase out "magic MIME types" so we
     are deprecating this method.</p>
 </div>
-<div id="quickview"><h3 class="directives">Directives</h3>
-<ul id="toc">
-<li><img alt="" src="../images/down.gif" /> <a href="#imapbase">ImapBase</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#imapdefault">ImapDefault</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#imapmenu">ImapMenu</a></li>
-</ul>
-<h3>Topics</h3>
+<div id="quickview"><h3>Topics</h3>
 <ul id="topics">
 <li><img alt="" src="../images/down.gif" /> <a href="#features">New Features</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#imapfile">Imagemap File</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#example">Example Mapfile</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#referencing">Referencing your mapfile</a></li>
-</ul><ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="directive-section"><h2><a name="ImapBase" id="ImapBase">ImapBase</a> <a name="imapbase" id="imapbase">Directive</a></h2>
-<table class="directive">
-<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Default <code>base</code> for imagemap files</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>ImapBase map|referer|<var>URL</var></code></td></tr>
-<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>ImapBase http://servername/</code></td></tr>
-<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
-<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Indexes</td></tr>
-<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Base</td></tr>
-<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_imagemap</td></tr>
-</table>
-    <p>The <code class="directive">ImapBase</code> directive sets the default
-    <code>base</code> used in the imagemap files. Its value is
-    overridden by a <code>base</code> directive within the imagemap
-    file. If not present, the <code>base</code> defaults to
-    <code>http://<var>servername</var>/</code>.</p>
-
-<h3>See also</h3>
-<ul>
-<li><code class="directive"><a href="../mod/core.html#usecanonicalname">UseCanonicalName</a></code></li>
+</ul><h3 class="directives">Directives</h3>
+<ul id="toc">
+<li><img alt="" src="../images/down.gif" /> <a href="#imapbase">ImapBase</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#imapdefault">ImapDefault</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#imapmenu">ImapMenu</a></li>
 </ul>
-</div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="directive-section"><h2><a name="ImapDefault" id="ImapDefault">ImapDefault</a> <a name="imapdefault" id="imapdefault">Directive</a></h2>
-<table class="directive">
-<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Default action when an imagemap is called with coordinates
-that are not explicitly mapped</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>ImapDefault error|nocontent|map|referer|<var>URL</var></code></td></tr>
-<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>ImapDefault nocontent</code></td></tr>
-<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
-<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Indexes</td></tr>
-<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Base</td></tr>
-<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_imagemap</td></tr>
-</table>
-    <p>The <code class="directive">ImapDefault</code> directive sets the default
-    <code>default</code> used in the imagemap files. Its value is
-    overridden by a <code>default</code> directive within the
-    imagemap file. If not present, the <code>default</code> action
-    is <code>nocontent</code>, which means that a <code>204 No
-    Content</code> is sent to the client. In this case, the client
-    should continue to display the original page.</p>
-
-</div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="directive-section"><h2><a name="ImapMenu" id="ImapMenu">ImapMenu</a> <a name="imapmenu" id="imapmenu">Directive</a></h2>
-<table class="directive">
-<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Action if no coordinates are given when calling
-an imagemap</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>ImapMenu none|formatted|semiformatted|unformatted</code></td></tr>
-<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
-<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Indexes</td></tr>
-<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Base</td></tr>
-<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_imagemap</td></tr>
-</table>
-    <p>The <code class="directive">ImapMenu</code> directive determines the
-    action taken if an imagemap file is called without valid
-    coordinates.</p>
-
-    <dl>
-      <dt><code>none</code></dt>
-      <dd>If ImapMenu is <code>none</code>, no menu is generated,
-      and the <code>default</code> action is performed.</dd>
-
-      <dt><code>formatted</code></dt>
-      <dd>A <code>formatted</code> menu is the simplest menu.
-      Comments in the imagemap file are ignored. A level one header
-      is printed, then an hrule, then the links each on a separate
-      line. The menu has a consistent, plain look close to that of
-      a directory listing.</dd>
-
-      <dt><code>semiformatted</code></dt>
-      <dd>In the <code>semiformatted</code> menu, comments are
-      printed where they occur in the imagemap file. Blank lines
-      are turned into HTML breaks. No header or hrule is printed,
-      but otherwise the menu is the same as a
-      <code>formatted</code> menu.</dd>
-
-      <dt><code>unformatted</code></dt>
-      <dd>Comments are printed, blank lines are ignored. Nothing is
-      printed that does not appear in the imagemap file. All breaks
-      and headers must be included as comments in the imagemap
-      file. This gives you the most flexibility over the appearance
-      of your menus, but requires you to treat your map files as
-      HTML instead of plaintext.</dd>
-    </dl>
-
-</div>
+<ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
 <h2><a name="features" id="features">New Features</a></h2>
@@ -376,6 +289,93 @@ an imagemap</td></tr>
     </code></p></div>
 
 </div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="directive-section"><h2><a name="ImapBase" id="ImapBase">ImapBase</a> <a name="imapbase" id="imapbase">Directive</a></h2>
+<table class="directive">
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Default <code>base</code> for imagemap files</td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>ImapBase map|referer|<var>URL</var></code></td></tr>
+<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>ImapBase http://servername/</code></td></tr>
+<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
+<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Indexes</td></tr>
+<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Base</td></tr>
+<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_imagemap</td></tr>
+</table>
+    <p>The <code class="directive">ImapBase</code> directive sets the default
+    <code>base</code> used in the imagemap files. Its value is
+    overridden by a <code>base</code> directive within the imagemap
+    file. If not present, the <code>base</code> defaults to
+    <code>http://<var>servername</var>/</code>.</p>
+
+<h3>See also</h3>
+<ul>
+<li><code class="directive"><a href="../mod/core.html#usecanonicalname">UseCanonicalName</a></code></li>
+</ul>
+</div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="directive-section"><h2><a name="ImapDefault" id="ImapDefault">ImapDefault</a> <a name="imapdefault" id="imapdefault">Directive</a></h2>
+<table class="directive">
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Default action when an imagemap is called with coordinates
+that are not explicitly mapped</td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>ImapDefault error|nocontent|map|referer|<var>URL</var></code></td></tr>
+<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>ImapDefault nocontent</code></td></tr>
+<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
+<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Indexes</td></tr>
+<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Base</td></tr>
+<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_imagemap</td></tr>
+</table>
+    <p>The <code class="directive">ImapDefault</code> directive sets the default
+    <code>default</code> used in the imagemap files. Its value is
+    overridden by a <code>default</code> directive within the
+    imagemap file. If not present, the <code>default</code> action
+    is <code>nocontent</code>, which means that a <code>204 No
+    Content</code> is sent to the client. In this case, the client
+    should continue to display the original page.</p>
+
+</div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="directive-section"><h2><a name="ImapMenu" id="ImapMenu">ImapMenu</a> <a name="imapmenu" id="imapmenu">Directive</a></h2>
+<table class="directive">
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Action if no coordinates are given when calling
+an imagemap</td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>ImapMenu none|formatted|semiformatted|unformatted</code></td></tr>
+<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
+<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Indexes</td></tr>
+<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Base</td></tr>
+<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_imagemap</td></tr>
+</table>
+    <p>The <code class="directive">ImapMenu</code> directive determines the
+    action taken if an imagemap file is called without valid
+    coordinates.</p>
+
+    <dl>
+      <dt><code>none</code></dt>
+      <dd>If ImapMenu is <code>none</code>, no menu is generated,
+      and the <code>default</code> action is performed.</dd>
+
+      <dt><code>formatted</code></dt>
+      <dd>A <code>formatted</code> menu is the simplest menu.
+      Comments in the imagemap file are ignored. A level one header
+      is printed, then an hrule, then the links each on a separate
+      line. The menu has a consistent, plain look close to that of
+      a directory listing.</dd>
+
+      <dt><code>semiformatted</code></dt>
+      <dd>In the <code>semiformatted</code> menu, comments are
+      printed where they occur in the imagemap file. Blank lines
+      are turned into HTML breaks. No header or hrule is printed,
+      but otherwise the menu is the same as a
+      <code>formatted</code> menu.</dd>
+
+      <dt><code>unformatted</code></dt>
+      <dd>Comments are printed, blank lines are ignored. Nothing is
+      printed that does not appear in the imagemap file. All breaks
+      and headers must be included as comments in the imagemap
+      file. This gives you the most flexibility over the appearance
+      of your menus, but requires you to treat your map files as
+      HTML instead of plaintext.</dd>
+    </dl>
+
+</div>
 </div>
 <div class="bottomlang">
 <p><span>Available Languages: </span><a href="../en/mod/mod_imagemap.html" title="English">&nbsp;en&nbsp;</a> |



Mime
View raw message