(48)Address already in use: make_sock: could not bind to address [::]:80
</example>
- <p>See <a
+ <p>See <a
href="http://wiki.apache.org/httpd/CouldNotBindToAddress">the
discussion in the wiki</a> for further troubleshooting tips.</p>
server is not listening to, it cannot be accessed.</p>
</section>
</manualpage>
-
<div class="section">
<h2><a name="introduction" id="introduction">Introduction</a></h2>
-
+
<p>The Apache HTTP server offers a range of caching features that
are designed to improve the performance of the server in various
ways.</p>
<table class="related"><tr><th>Related Modules</th><th>Related Directives</th></tr><tr><td><ul><li><code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code></li><li><code class="module"><a href="./mod/mod_cache_disk.html">mod_cache_disk</a></code></li></ul></td><td><ul><li><code class="directive"><a href="./mod/mod_cache.html#cacheenable">CacheEnable</a></code></li><li><code class="directive"><a href="./mod/mod_cache.html#cachedisable">CacheDisable</a></code></li><li><code class="directive"><a href="./mod/core.html#usecanonicalname">UseCanonicalName</a></code></li><li><code class="directive"><a href="./mod/mod_negotiation.html#cachenegotiateddocs">CacheNegotiatedDocs</a></code></li></ul></td></tr></table>
<p>The HTTP protocol contains built in support for an in-line caching
- mechanism
+ mechanism
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html">
described by section 13 of RFC2616</a>, and the
<code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> module can be used to take advantage of
<p>In this scenario, the cache behaves as if it has been "bolted
on" to the front of the server.</p>
-
+
<p>This mode offers the best performance, as the majority of
server processing is bypassed. This mode however also bypasses the
authentication and authorization phases of server processing, so
this mode should be chosen with care when this is important.</p>
-
+
<p> Requests with an "Authorization" header (for example, HTTP Basic
- Authentication) are neither cacheable nor served from the cache
+ Authentication) are neither cacheable nor served from the cache
when <code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> is running in this phase.</p>
</dd>
<dt>Normal handler phase</dt>
explicit freshness lifetime with the <code>Cache-Control</code>
header's <code>max-age</code> or <code>s-maxage</code> fields, or
by including an <code>Expires</code> header.</p>
-
+
<p>At the same time, the origin server defined freshness lifetime can
be overridden by a client when the client presents their own
<code>Cache-Control</code> header within the request. In this case,
see if the file has changed in size or modification time. As such, even
local content may still be served faster from the cache if it has not
changed.</p>
-
+
<p>Origin servers should make every effort to support conditional
requests as is practical, however if conditional requests are not
supported, the origin will respond as if the request was not
particulars of the request that are not covered by HTTP negotiation,
should not be cached. This content should declare itself uncacheable
using the <code>Cache-Control</code> header.</p>
-
+
<p>If content changes often, expressed by a freshness lifetime of minutes
or seconds, the content can still be cached, however it is highly
desirable that the origin server supports
based on the value of headers in the request, for example to serve
multiple languages at the same URL, HTTP's caching mechanism makes it
possible to cache multiple variants of the same page at the same URL.</p>
-
+
<p>This is done by the origin server adding a <code>Vary</code> header
to indicate which headers must be taken into account by a cache when
determining whether two variants are different from one another.</p>
<p><code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> will only serve the cached content to
requesters with accept-language and accept-charset headers
matching those of the original request.</p>
-
+
<p>Multiple variants of the content can be cached side by side,
<code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> uses the <code>Vary</code> header and the
corresponding values of the request headers listed by <code>Vary</code>
or more to process very large (tens of gigabytes) caches and if you are
running it from cron it is recommended that you determine how long a typical
run takes, to avoid running more than one instance at a time.</p>
-
+
<p>It is also recommended that an appropriate "nice" level is chosen for
htcacheclean so that the tool does not cause excessive disk io while the
server is running.</p>
<table class="related"><tr><th>Related Modules</th><th>Related Directives</th></tr><tr><td><ul><li><code class="module"><a href="./mod/mod_authn_socache.html">mod_authn_socache</a></code></li><li><code class="module"><a href="./mod/mod_socache_dbm.html">mod_socache_dbm</a></code></li><li><code class="module"><a href="./mod/mod_socache_dc.html">mod_socache_dc</a></code></li><li><code class="module"><a href="./mod/mod_socache_memcache.html">mod_socache_memcache</a></code></li><li><code class="module"><a href="./mod/mod_socache_shmcb.html">mod_socache_shmcb</a></code></li><li><code class="module"><a href="./mod/mod_ssl.html">mod_ssl</a></code></li></ul></td><td><ul><li><code class="directive"><a href="./mod/mod_authn_socache.html#authncachesocache">AuthnCacheSOCache</a></code></li><li><code class="directive"><a href="./mod/mod_ssl.html#sslsessioncache">SSLSessionCache</a></code></li><li><code class="directive"><a href="./mod/mod_ssl.html#sslstaplingcache">SSLStaplingCache</a></code></li></ul></td></tr></table>
-
+
<p>The Apache HTTP server offers a low level shared object cache for
caching information such as SSL sessions, or authentication credentials,
within the <a href="socache.html">socache</a> interface.</p>
on the popularity of the particular web site thousands or millions of
duplicate cache entries could be created for the same URL, crowding
out other entries in the cache.</p>
-
+
<p>In other cases, there may be a need to change the URL of a particular
resource on every request, usually by adding a "cachebuster" string to
the URL. If this content is declared cacheable by a server for a
<section id="introduction">
<title>Introduction</title>
-
+
<p>The Apache HTTP server offers a range of caching features that
are designed to improve the performance of the server in various
ways.</p>
</related>
<p>The HTTP protocol contains built in support for an in-line caching
- mechanism
+ mechanism
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html">
described by section 13 of RFC2616</a>, and the
<module>mod_cache</module> module can be used to take advantage of
<p>In this scenario, the cache behaves as if it has been "bolted
on" to the front of the server.</p>
-
+
<p>This mode offers the best performance, as the majority of
server processing is bypassed. This mode however also bypasses the
authentication and authorization phases of server processing, so
this mode should be chosen with care when this is important.</p>
-
+
<p> Requests with an "Authorization" header (for example, HTTP Basic
- Authentication) are neither cacheable nor served from the cache
+ Authentication) are neither cacheable nor served from the cache
when <module>mod_cache</module> is running in this phase.</p>
</dd>
<dt>Normal handler phase</dt>
explicit freshness lifetime with the <code>Cache-Control</code>
header's <code>max-age</code> or <code>s-maxage</code> fields, or
by including an <code>Expires</code> header.</p>
-
+
<p>At the same time, the origin server defined freshness lifetime can
be overridden by a client when the client presents their own
<code>Cache-Control</code> header within the request. In this case,
see if the file has changed in size or modification time. As such, even
local content may still be served faster from the cache if it has not
changed.</p>
-
+
<p>Origin servers should make every effort to support conditional
requests as is practical, however if conditional requests are not
supported, the origin will respond as if the request was not
particulars of the request that are not covered by HTTP negotiation,
should not be cached. This content should declare itself uncacheable
using the <code>Cache-Control</code> header.</p>
-
+
<p>If content changes often, expressed by a freshness lifetime of minutes
or seconds, the content can still be cached, however it is highly
desirable that the origin server supports
based on the value of headers in the request, for example to serve
multiple languages at the same URL, HTTP's caching mechanism makes it
possible to cache multiple variants of the same page at the same URL.</p>
-
+
<p>This is done by the origin server adding a <code>Vary</code> header
to indicate which headers must be taken into account by a cache when
determining whether two variants are different from one another.</p>
<p><module>mod_cache</module> will only serve the cached content to
requesters with accept-language and accept-charset headers
matching those of the original request.</p>
-
+
<p>Multiple variants of the content can be cached side by side,
<module>mod_cache</module> uses the <code>Vary</code> header and the
corresponding values of the request headers listed by <code>Vary</code>
or more to process very large (tens of gigabytes) caches and if you are
running it from cron it is recommended that you determine how long a typical
run takes, to avoid running more than one instance at a time.</p>
-
+
<p>It is also recommended that an appropriate "nice" level is chosen for
htcacheclean so that the tool does not cause excessive disk io while the
server is running.</p>
<directive module="mod_ssl">SSLStaplingCache</directive>
</directivelist>
</related>
-
+
<p>The Apache HTTP server offers a low level shared object cache for
caching information such as SSL sessions, or authentication credentials,
within the <a href="socache.html">socache</a> interface.</p>
on the popularity of the particular web site thousands or millions of
duplicate cache entries could be created for the same URL, crowding
out other entries in the cache.</p>
-
+
<p>In other cases, there may be a need to change the URL of a particular
resource on every request, usually by adding a "cachebuster" string to
the URL. If this content is declared cacheable by a server for a
<p>This policy will be rejected if the server response does not contain
an explicit <code>Content-Length</code> header.</p>
-
+
<p>There are a number of ways of determining the length of a response
body, described in full in
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4">
RFC2616 section 4.4 Message Length</a>.</p>
-
+
<p>When the <code>Content-Length</code> header is present, the size of
the body is declared at the start of the response. If this information
is missing, an HTTP cache might choose to ignore the response, as it
header, and the format of the header is described in full in
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7">
RFC2616 section 3.7 Media Types</a>.</p>
-
+
<p>A syntactically valid content type might look as follows:</p>
-
+
<div class="example"><p><code>
Content-Type: text/html; charset=iso-8859-1
</code></p></div>
# invalid<br />
Content-Type: foo<br />
# blank<br />
- Content-Type:
+ Content-Type:
</code></p></div>
<p>The server administrator has the option to restrict the policy to one
<p>This policy will be rejected if the server response does not contain
an explicit <code>Content-Length</code> header, or a
<code>Transfer-Encoding</code> of chunked.</p>
-
+
<p>There are a number of ways of determining the length of a response
body, described in full in
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4">
RFC2616 section 4.4 Message Length</a>.</p>
-
+
<p>When the <code>Content-Length</code> header is present, the size of
the body is declared at the start of the response. HTTP/1.1 defines the
<code>Transfer-Encoding</code> header as an alternative to
</p>
<p>Most specifically, we follow these rules:</p>
-
+
<dl>
<dt>IF</dt>
<dd>we have not marked this connection as errored;</dd>
-
+
<dt>and</dt>
<dd>the client isn't expecting 100-continue</dd>
-
+
<dt>and</dt>
<dd>the response status does not require a close;</dd>
-
+
<dt>and</dt>
<dd>the response body has a defined length due to the status code
being 304 or 204, the request method being HEAD, already having defined
Content-Length or Transfer-Encoding: chunked, or the request version
being HTTP/1.1 and thus capable of being set as chunked</dd>
-
+
<dt>THEN</dt>
<dd>we support keepalive.</dd>
</dl>
-
+
<div class="warning">The server may choose to turn off keepalive for
various reasons, such as an imminent shutdown, or a Connection: close from
the client, or an HTTP/1.0 client request with a response with no
<code>Content-Length</code>, but for our purposes we only care that
keepalive was possible from the application, not that keepalive actually
- took place.</div>
+ took place.</div>
<p>It should also be noted that the Apache httpd server includes a filter
that adds chunked encoding to responses without an explicit content
<p>This policy is implemented by the <strong>POLICY_KEEPALIVE</strong>
filter.</p>
-
+
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="policymaxage" id="policymaxage">Freshness Lifetime / Maxage Policy</a></h2>
<h2><a name="policyvary" id="policyvary">Vary Header Policy</a></h2>
<table class="related"><tr><th>Related Modules</th><th>Related Directives</th></tr><tr><td><ul><li><code class="module"><a href="./mod/mod_policy.html">mod_policy</a></code></li></ul></td><td><ul><li><code class="directive"><a href="./mod/mod_policy.html#policyvary">PolicyVary</a></code></li></ul></td></tr></table>
-
+
<p>This policy will be rejected if the server response contains a
<code>Vary</code> header, and that header in turn contains a header
blacklisted by the administrator.</p>
<p>The <code>Vary</code> header is described in full in
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44">
RFC2616 section 14.44 Vary</a>.</p>
-
+
<p>Some client provided headers, such as <code>User-Agent</code>,
can contain thousands or millions of combinations of values over a period
of time, and if the response is declared cacheable, a cache might attempt
<p>This policy will be rejected if the server response does not contain
an explicit <code>Content-Length</code> header.</p>
-
+
<p>There are a number of ways of determining the length of a response
body, described in full in
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4">
RFC2616 section 4.4 Message Length</a>.</p>
-
+
<p>When the <code>Content-Length</code> header is present, the size of
the body is declared at the start of the response. If this information
is missing, an HTTP cache might choose to ignore the response, as it
header, and the format of the header is described in full in
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7">
RFC2616 section 3.7 Media Types</a>.</p>
-
+
<p>A syntactically valid content type might look as follows:</p>
-
+
<example>
Content-Type: text/html; charset=iso-8859-1
</example>
# invalid<br />
Content-Type: foo<br />
# blank<br />
- Content-Type:
+ Content-Type:
</example>
<p>The server administrator has the option to restrict the policy to one
<p>This policy will be rejected if the server response does not contain
an explicit <code>Content-Length</code> header, or a
<code>Transfer-Encoding</code> of chunked.</p>
-
+
<p>There are a number of ways of determining the length of a response
body, described in full in
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4">
RFC2616 section 4.4 Message Length</a>.</p>
-
+
<p>When the <code>Content-Length</code> header is present, the size of
the body is declared at the start of the response. HTTP/1.1 defines the
<code>Transfer-Encoding</code> header as an alternative to
</p>
<p>Most specifically, we follow these rules:</p>
-
+
<dl>
<dt>IF</dt>
<dd>we have not marked this connection as errored;</dd>
-
+
<dt>and</dt>
<dd>the client isn't expecting 100-continue</dd>
-
+
<dt>and</dt>
<dd>the response status does not require a close;</dd>
-
+
<dt>and</dt>
<dd>the response body has a defined length due to the status code
being 304 or 204, the request method being HEAD, already having defined
Content-Length or Transfer-Encoding: chunked, or the request version
being HTTP/1.1 and thus capable of being set as chunked</dd>
-
+
<dt>THEN</dt>
<dd>we support keepalive.</dd>
</dl>
-
+
<note type="warning">The server may choose to turn off keepalive for
various reasons, such as an imminent shutdown, or a Connection: close from
the client, or an HTTP/1.0 client request with a response with no
<code>Content-Length</code>, but for our purposes we only care that
keepalive was possible from the application, not that keepalive actually
- took place.</note>
+ took place.</note>
<p>It should also be noted that the Apache httpd server includes a filter
that adds chunked encoding to responses without an explicit content
<p>This policy is implemented by the <strong>POLICY_KEEPALIVE</strong>
filter.</p>
-
+
</section>
<section id="policymaxage">
filter.</p>
</section>
-
+
<section id="policynocache">
<title>No Cache Policy</title>
<related>
filter.</p>
</section>
-
+
<section id="policyvalidation">
<title>Validation Policy</title>
<related>
filter.</p>
</section>
-
+
<section id="policyvary">
<title>Vary Header Policy</title>
<related>
<directive module="mod_policy">PolicyVary</directive>
</directivelist>
</related>
-
+
<p>This policy will be rejected if the server response contains a
<code>Vary</code> header, and that header in turn contains a header
blacklisted by the administrator.</p>
<p>The <code>Vary</code> header is described in full in
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44">
RFC2616 section 14.44 Vary</a>.</p>
-
+
<p>Some client provided headers, such as <code>User-Agent</code>,
can contain thousands or millions of combinations of values over a period
of time, and if the response is declared cacheable, a cache might attempt
filter.</p>
</section>
-
+
<section id="policyversion">
<title>Protocol Version Policy</title>
<related>
There must be no other characters or white space between the
backslash and the end of the line.</p>
- <p>Arguments to directives are separated by whitespace. If an
+ <p>Arguments to directives are separated by whitespace. If an
argument contains spaces, you must enclose that argument in quotes.</p>
<p>Directives in the configuration files are case-insensitive,
but arguments to directives are often case sensitive. Lines
that begin with the hash character "#" are considered
comments, and are ignored. Comments may <strong>not</strong> be
- included on the same line as a configuration directive.
+ included on the same line as a configuration directive.
White space occurring before a directive is ignored, so
you may indent directives for clarity. Blank lines are also ignored.</p>
There must be no other characters or white space between the
backslash and the end of the line.</p>
- <p>Arguments to directives are separated by whitespace. If an
+ <p>Arguments to directives are separated by whitespace. If an
argument contains spaces, you must enclose that argument in quotes.</p>
<p>Directives in the configuration files are case-insensitive,
but arguments to directives are often case sensitive. Lines
that begin with the hash character "#" are considered
comments, and are ignored. Comments may <strong>not</strong> be
- included on the same line as a configuration directive.
+ included on the same line as a configuration directive.
White space occurring before a directive is ignored, so
you may indent directives for clarity. Blank lines are also ignored.</p>
date.</p>
</div>
- <p>In general, a hook function is one that the Apache HTTP Server
- will call at some point during the processing of a request.
- Modules can provide functions that are called, and specify when
+ <p>In general, a hook function is one that the Apache HTTP Server
+ will call at some point during the processing of a request.
+ Modules can provide functions that are called, and specify when
they get called in comparison to other modules.</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#create">Creating a hook function</a></li>
<p>The first hook that does <em>not</em> return <code>DECLINED</code>
stops the loop and its return value is returned from the hook
- caller. Note that <code>DECLINED</code> is the traditional
+ caller. Note that <code>DECLINED</code> is the traditional
hook return value meaning "I didn't do anything", but it can be
whatever suits you.</p>
order relative to each other, but, of course, all modules using
<code>APR_HOOK_FIRST</code> will be run before <code>APR_HOOK_MIDDLE</code>
which are before <code>APR_HOOK_LAST</code>. Modules that don't care
- when they are run should use <code>APR_HOOK_MIDDLE</code>. <em>These
+ when they are run should use <code>APR_HOOK_MIDDLE</code>. <em>These
values are spaced out, so that positions like <code>APR_HOOK_FIRST-2</code>
are possible to hook slightly earlier than other functions.</em></p>
date.</p>
</note>
- <p>In general, a hook function is one that the Apache HTTP Server
- will call at some point during the processing of a request.
- Modules can provide functions that are called, and specify when
+ <p>In general, a hook function is one that the Apache HTTP Server
+ will call at some point during the processing of a request.
+ Modules can provide functions that are called, and specify when
they get called in comparison to other modules.</p>
</summary>
<p>The first hook that does <em>not</em> return <code>DECLINED</code>
stops the loop and its return value is returned from the hook
- caller. Note that <code>DECLINED</code> is the traditional
+ caller. Note that <code>DECLINED</code> is the traditional
hook return value meaning "I didn't do anything", but it can be
whatever suits you.</p>
order relative to each other, but, of course, all modules using
<code>APR_HOOK_FIRST</code> will be run before <code>APR_HOOK_MIDDLE</code>
which are before <code>APR_HOOK_LAST</code>. Modules that don't care
- when they are run should use <code>APR_HOOK_MIDDLE</code>. <em>These
+ when they are run should use <code>APR_HOOK_MIDDLE</code>. <em>These
values are spaced out, so that positions like <code>APR_HOOK_FIRST-2</code>
are possible to hook slightly earlier than other functions.</em></p>
</section>
</section>
</manualpage>
-
<p><span>Available Languages: </span><a href="../en/developer/modguide.html" title="English"> en </a></p>
</div>
-<p>This document explains how you can develop modules for the Apache HTTP
+<p>This document explains how you can develop modules for the Apache HTTP
Server 2.4</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#introduction">Introduction</a></li>
<h2><a name="introduction" id="introduction">Introduction</a></h2>
<h3><a name="what" id="what">What we will be discussing in this document</a></h3>
<p>
-This document will discuss how you can create modules for the Apache
-HTTP Server 2.4, by exploring an example module called
-<code>mod_example</code>. In the first part of this document, the purpose
-of this module will be to calculate and print out various digest values for
+This document will discuss how you can create modules for the Apache
+HTTP Server 2.4, by exploring an example module called
+<code>mod_example</code>. In the first part of this document, the purpose
+of this module will be to calculate and print out various digest values for
existing files on your web server, whenever we access the URL <code>
-http://hostname/filename.sum</code>. For instance, if we want to know the
+http://hostname/filename.sum</code>. For instance, if we want to know the
MD5 digest value of the file located at <code>
http://www.example.com/index.html</code>, we would visit <code>
-http://www.example.com/index.html.sum</code>.
+http://www.example.com/index.html.sum</code>.
</p>
<p>
-In the second part of this document, which deals with configuration
-directive and context awareness, we will be looking at a module that simply
+In the second part of this document, which deals with configuration
+directive and context awareness, we will be looking at a module that simply
writes out its own configuration to the client.
</p>
<h3><a name="prerequisites" id="prerequisites">Prerequisites</a></h3>
<p>
-First and foremost, you are expected to have a basic knowledge of how the C
-programming language works. In most cases, we will try to be as pedagogical
-as possible and link to documents describing the functions used in the
-examples, but there are also many cases where it is necessary to either
-just assume that "it works" or do some digging yourself into what the hows
-and whys of various function calls.
+First and foremost, you are expected to have a basic knowledge of how the C
+programming language works. In most cases, we will try to be as pedagogical
+as possible and link to documents describing the functions used in the
+examples, but there are also many cases where it is necessary to either
+just assume that "it works" or do some digging yourself into what the hows
+and whys of various function calls.
</p>
<p>
-Lastly, you will need to have a basic understanding of how modules are
-loaded and configured in the Apache HTTP Server, as well as how to get the headers for
-Apache if you do not have them already, as these are needed for compiling
+Lastly, you will need to have a basic understanding of how modules are
+loaded and configured in the Apache HTTP Server, as well as how to get the headers for
+Apache if you do not have them already, as these are needed for compiling
new modules.
</p>
<h3><a name="compiling" id="compiling">Compiling your module</a></h3>
<p>
-To compile the source code we are building in this document, we will be
-using <a href="../programs/apxs.html">APXS</a>. Assuming your source file
-is called mod_example.c, compiling, installing and activating the module is
-as simple as:
+To compile the source code we are building in this document, we will be
+using <a href="../programs/apxs.html">APXS</a>. Assuming your source file
+is called mod_example.c, compiling, installing and activating the module is
+as simple as:
</p>
<div class="example"><pre>apxs -i -a -c mod_example.c</pre></div>
<h2><a name="basics" id="basics">Defining a module</a></h2>
<p>
<img src="../images/build_a_mod_3.png" alt="Module name tags" /><br />
-Every module starts with the same declaration, or name tag if you will,
+Every module starts with the same declaration, or name tag if you will,
that defines a module as <em>a separate entity within Apache</em>:</p>
<pre class="prettyprint lang-c">module AP_MODULE_DECLARE_DATA example_module =
-{
+{
STANDARD20_MODULE_STUFF,
create_dir_conf, /* Per-directory configuration handler */
merge_dir_conf, /* Merge handler for per-directory configurations */
<p>
-This bit of code lets the server know that we have now registered a new module
-in the system, and that its name is <code>example_module</code>. The name
+This bit of code lets the server know that we have now registered a new module
+in the system, and that its name is <code>example_module</code>. The name
of the module is used primarily for two things:<br />
</p>
<ul>
<li>Setting up a namespace for the module to use in configurations</li>
</ul>
<p>
-For now, we're only concerned with the first purpose of the module name,
+For now, we're only concerned with the first purpose of the module name,
which comes into play when we need to load the module:
</p>
<pre class="prettyprint lang-config">LoadModule example_module "modules/mod_example.so"</pre>
<p>
-In essence, this tells the server to open up <code>mod_example.so</code> and look for a module
+In essence, this tells the server to open up <code>mod_example.so</code> and look for a module
called <code>example_module</code>.
</p>
<p>
-Within this name tag of ours is also a bunch of references to how we would
-like to handle things: Which directives do we respond to in a configuration
-file or .htaccess, how do we operate within specific contexts, and what
-handlers are we interested in registering with the Apache HTTP service. We'll
+Within this name tag of ours is also a bunch of references to how we would
+like to handle things: Which directives do we respond to in a configuration
+file or .htaccess, how do we operate within specific contexts, and what
+handlers are we interested in registering with the Apache HTTP service. We'll
return to all these elements later in this document.
</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<h2><a name="hooking" id="hooking">Getting started: Hooking into the server</a></h2>
<h3><a name="hook_intro" id="hook_intro">An introduction to hooks</a></h3>
<p>
-When handling requests in Apache HTTP Server 2.4, the first thing you will need to do is
-create a hook into the request handling process. A hook is essentially a
-message telling the server that you are willing to either serve or at least
-take a glance at certain requests given by clients. All handlers, whether
-it's mod_rewrite, mod_authn_*, mod_proxy and so on, are hooked into
-specific parts of the request process. As you are probably aware, modules
-serve different purposes; Some are authentication/authorization handlers,
-others are file or script handlers while some third modules rewrite URIs or
-proxies content. Furthermore, in the end, it is up to the user of the server
-how and when each module will come into place. Thus, the server itself does not
-presume to know which module is responsible for handling a specific
-request, and will ask each module whether they have an interest in a given
-request or not. It is then up to each module to either gently decline
-serving a request, accept serving it or flat out deny the request from
+When handling requests in Apache HTTP Server 2.4, the first thing you will need to do is
+create a hook into the request handling process. A hook is essentially a
+message telling the server that you are willing to either serve or at least
+take a glance at certain requests given by clients. All handlers, whether
+it's mod_rewrite, mod_authn_*, mod_proxy and so on, are hooked into
+specific parts of the request process. As you are probably aware, modules
+serve different purposes; Some are authentication/authorization handlers,
+others are file or script handlers while some third modules rewrite URIs or
+proxies content. Furthermore, in the end, it is up to the user of the server
+how and when each module will come into place. Thus, the server itself does not
+presume to know which module is responsible for handling a specific
+request, and will ask each module whether they have an interest in a given
+request or not. It is then up to each module to either gently decline
+serving a request, accept serving it or flat out deny the request from
being served, as authentication/authorization modules do: <br />
<img src="../images/build_a_mod_2.png" alt="Hook handling in httpd" /><br />
-To make it a bit easier for handlers such as our mod_example to know
-whether the client is requesting content we should handle or not, the server
-has directives for hinting to modules whether their assistance is needed or
-not. Two of these are <code class="directive"><a href="../mod/mod_mime.html#addhandler">AddHandler</a></code>
-and <code class="directive"><a href="../mod/core.html#sethandler">SetHandler</a></code>. Let's take a look at
-an example using <code class="directive"><a href="../mod/mod_mime.html#addhandler">AddHandler</a></code>. In
-our example case, we want every request ending with .sum to be served by
-<code>mod_example</code>, so we'll add a configuration directive that tells
+To make it a bit easier for handlers such as our mod_example to know
+whether the client is requesting content we should handle or not, the server
+has directives for hinting to modules whether their assistance is needed or
+not. Two of these are <code class="directive"><a href="../mod/mod_mime.html#addhandler">AddHandler</a></code>
+and <code class="directive"><a href="../mod/core.html#sethandler">SetHandler</a></code>. Let's take a look at
+an example using <code class="directive"><a href="../mod/mod_mime.html#addhandler">AddHandler</a></code>. In
+our example case, we want every request ending with .sum to be served by
+<code>mod_example</code>, so we'll add a configuration directive that tells
the server to do just that:
</p>
<pre class="prettyprint lang-config">AddHandler example-handler ".sum"</pre>
<p>
-What this tells the server is the following: <em>Whenever we receive a request
-for a URI ending in .sum, we are to let all modules know that we are
-looking for whoever goes by the name of "example-handler" </em>.
-Thus, when a request is being served that ends in .sum, the server will let all
+What this tells the server is the following: <em>Whenever we receive a request
+for a URI ending in .sum, we are to let all modules know that we are
+looking for whoever goes by the name of "example-handler" </em>.
+Thus, when a request is being served that ends in .sum, the server will let all
modules know, that this request should be served by "example-handler".
-As you will see later, when we start building mod_example, we will
-check for this handler tag relayed by <code>AddHandler</code> and reply to
+As you will see later, when we start building mod_example, we will
+check for this handler tag relayed by <code>AddHandler</code> and reply to
the server based on the value of this tag.
</p>
<h3><a name="hook_declaration" id="hook_declaration">Hooking into httpd</a></h3>
<p>
-To begin with, we only want to create a simple handler, that replies to the
-client browser when a specific URL is requested, so we won't bother setting
-up configuration handlers and directives just yet. Our initial module
+To begin with, we only want to create a simple handler, that replies to the
+client browser when a specific URL is requested, so we won't bother setting
+up configuration handlers and directives just yet. Our initial module
definition will look like this:</p>
-<p>This lets the server know that we are not interested in anything fancy, we
-just want to hook onto the requests and possibly handle some of them. </p>
+<p>This lets the server know that we are not interested in anything fancy, we
+just want to hook onto the requests and possibly handle some of them. </p>
-<p> The reference in our example declaration, <code>register_hooks</code>
-is the name of a function we will create to manage how we hook onto the
-request process. In this example module, the function has just one purpose;
-To create a simple hook that gets called after all the rewrites, access
-control etc has been handled. Thus, we will let the server know, that we want
-to hook into its process as one of the last modules:
+<p> The reference in our example declaration, <code>register_hooks</code>
+is the name of a function we will create to manage how we hook onto the
+request process. In this example module, the function has just one purpose;
+To create a simple hook that gets called after all the rewrites, access
+control etc has been handled. Thus, we will let the server know, that we want
+to hook into its process as one of the last modules:
</p>
<p>
-The <code>example_handler</code> reference is the function that will handle
+The <code>example_handler</code> reference is the function that will handle
the request. We will discuss how to create a handler in the next chapter.
</p>
<h3><a name="hook_others" id="hook_others">Other useful hooks</a></h3>
<p>
-Hooking into the request handling phase is but one of many hooks that you
+Hooking into the request handling phase is but one of many hooks that you
can create. Some other ways of hooking are:
</p>
<ul>
<div class="section">
<h2><a name="handling" id="handling">Building a handler</a></h2>
<p>
-A handler is essentially a function that receives a callback when a request
-to the server is made. It is passed a record of the current request (how it was
-made, which headers and requests were passed along, who's giving the
-request and so on), and is put in charge of either telling the server that it's
+A handler is essentially a function that receives a callback when a request
+to the server is made. It is passed a record of the current request (how it was
+made, which headers and requests were passed along, who's giving the
+request and so on), and is put in charge of either telling the server that it's
not interested in the request or handle the request with the tools provided.
</p>
-<h3><a name="simple_handler" id="simple_handler">A simple "Hello, world!"
-handler</a></h3>
-<p>Let's start off by making a very simple request handler
+<h3><a name="simple_handler" id="simple_handler">A simple "Hello, world!"
+handler</a></h3>
+<p>Let's start off by making a very simple request handler
that does the following:
</p>
<ol>
* and the server will try somewhere else.
*/
if (!r->handler || strcmp(r->handler, "example-handler")) return (DECLINED);
-
+
/* Now that we are handling this request, we'll write out "Hello, world!" to the client.
* To do so, we must first set the appropriate content type, followed by our output.
*/
ap_set_content_type(r, "text/html");
ap_rprintf(r, "Hello, world!");
-
+
/* Lastly, we must tell the server that we took care of this request and everything went fine.
* We do so by simply returning the value OK to the server.
*/
<p>
-Now, we put all we have learned together and end up with a program that
-looks like
+Now, we put all we have learned together and end up with a program that
+looks like
<a href="http://people.apache.org/~humbedooh/mods/examples/mod_example_1.c">mod_example_1.c</a>
-. The functions used in this example will be explained later in the section
-<a href="#functions">"Some useful functions you should know"</a>.
+. The functions used in this example will be explained later in the section
+<a href="#functions">"Some useful functions you should know"</a>.
</p>
-
-<h3><a name="request_rec" id="request_rec">The request_rec structure</a></h3>
+
+<h3><a name="request_rec" id="request_rec">The request_rec structure</a></h3>
<p>The most essential part of any request is the <em>request record
</em>. In a call to a handler function, this is represented by the <code>
-request_rec* </code> structure passed along with every call that is made.
-This struct, typically just referred to as <code>r</code> in modules,
-contains all the information you need for your module to fully process any
+request_rec* </code> structure passed along with every call that is made.
+This struct, typically just referred to as <code>r</code> in modules,
+contains all the information you need for your module to fully process any
HTTP request and respond accordingly.</p> <p>Some key elements of the <code>
request_rec </code> structure are:
</p>
<li><code>r->connection (conn_rec*):</code> A record containing information about the current connection</li>
<li><code>r->user (char*):</code> If the URI requires authentication, this is set to the username provided</li>
<li><code>r->useragent_ip (char*):</code> The IP address of the client connecting to us</li>
-<li><code>r->pool (apr_pool_t*)</code>: The memory pool of this request. We'll discuss this in the
+<li><code>r->pool (apr_pool_t*)</code>: The memory pool of this request. We'll discuss this in the
"<a href="#memory">Memory management</a>" chapter.</li>
</ul>
<p>
-A complete list of all the values contained within the <code>request_rec</code> structure can be found in
-the <a href="http://svn.apache.org/repos/asf/httpd/httpd/trunk/include/httpd.h"><code>httpd.h</code></a> header
+A complete list of all the values contained within the <code>request_rec</code> structure can be found in
+the <a href="http://svn.apache.org/repos/asf/httpd/httpd/trunk/include/httpd.h"><code>httpd.h</code></a> header
file or at <a href="http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html">http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html</a>.
</p>
/* Print out the IP address of the client connecting to us: */
ap_rprintf(r, "<h2>Hello, %s!</h2>", r->useragent_ip);
-
+
/* If we were reached through a GET or a POST request, be happy, else sad. */
if ( !strcmp(r->method, "POST") || !strcmp(r->method, "GET") ) {
ap_rputs("You used a GET or a POST method, that makes us happy!<br/>", r);
<h3><a name="return_value" id="return_value">Return values</a></h3>
<p>
-Apache relies on return values from handlers to signify whether a request
-was handled or not, and if so, whether the request went well or not. If a
-module is not interested in handling a specific request, it should always
-return the value <code>DECLINED</code>. If it is handling a request, it
-should either return the generic value <code>OK</code>, or a specific HTTP
+Apache relies on return values from handlers to signify whether a request
+was handled or not, and if so, whether the request went well or not. If a
+module is not interested in handling a specific request, it should always
+return the value <code>DECLINED</code>. If it is handling a request, it
+should either return the generic value <code>OK</code>, or a specific HTTP
status code, for example:
</p>
<p>
-Returning <code>OK</code> or a HTTP status code does not necessarily mean
-that the request will end. The server may still have other handlers that are
-interested in this request, for instance the logging modules which, upon a
-successful request, will write down a summary of what was requested and how
-it went. To do a full stop and prevent any further processing after your
-module is done, you can return the value <code>DONE</code> to let the server
-know that it should cease all activity on this request and carry on with
+Returning <code>OK</code> or a HTTP status code does not necessarily mean
+that the request will end. The server may still have other handlers that are
+interested in this request, for instance the logging modules which, upon a
+successful request, will write down a summary of what was requested and how
+it went. To do a full stop and prevent any further processing after your
+module is done, you can return the value <code>DONE</code> to let the server
+know that it should cease all activity on this request and carry on with
the next, without informing other handlers.
<br />
<strong>General response codes:</strong>
<code>ap_rputs(const char *string, request_rec *r)</code>: <br />
Sends a string of text to the client. This is a shorthand version of <a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__PROTO.html#gac827cd0537d2b6213a7c06d7c26cc36e">
ap_rwrite</a>.
-
+
<pre class="prettyprint lang-c">ap_rputs("Hello, world!", r);</pre>
<li>
<code>
<a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__PROTO.html#ga5e91eb6ca777c9a427b2e82bf1eeb81d">ap_rprintf</a></code>: <br />
- This function works just like <code>printf</code>, except it sends the result to the client.
-
+ This function works just like <code>printf</code>, except it sends the result to the client.
+
<pre class="prettyprint lang-c">ap_rprintf(r, "Hello, %s!", r->useragent_ip);</pre>
<code>
<a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__PROTO.html#gaa2f8412c400197338ec509f4a45e4579">ap_set_content_type</a>(request_rec *r, const char *type)</code>: <br />
Sets the content type of the output you are sending.
-
+
<pre class="prettyprint lang-c">ap_set_content_type(r, "text/plain"); /* force a raw text output */</pre>
<h3><a name="memory" id="memory">Memory management</a></h3>
<p>
-Managing your resources in Apache HTTP Server 2.4 is quite easy, thanks to the memory pool
-system. In essence, each server, connection and request have their own
-memory pool that gets cleaned up when its scope ends, e.g. when a request
-is done or when a server process shuts down. All your module needs to do is
-latch onto this memory pool, and you won't have to worry about having to
+Managing your resources in Apache HTTP Server 2.4 is quite easy, thanks to the memory pool
+system. In essence, each server, connection and request have their own
+memory pool that gets cleaned up when its scope ends, e.g. when a request
+is done or when a server process shuts down. All your module needs to do is
+latch onto this memory pool, and you won't have to worry about having to
clean up after yourself - pretty neat, huh?
</p>
<p>
-In our module, we will primarily be allocating memory for each request, so
-it's appropriate to use the <code>r->pool</code>
-reference when creating new objects. A few of the functions for allocating
+In our module, we will primarily be allocating memory for each request, so
+it's appropriate to use the <code>r->pool</code>
+reference when creating new objects. A few of the functions for allocating
memory within a pool are:
</p>
<ul>
const char *original = "You can't edit this!";
char *copy;
int *integers;
-
+
/* Allocate space for 10 integer values and set them all to zero. */
- integers = apr_pcalloc(r->pool, sizeof(int)*10);
-
+ integers = apr_pcalloc(r->pool, sizeof(int)*10);
+
/* Create a copy of the 'original' variable that we can edit. */
copy = apr_pstrdup(r->pool, original);
return OK;
<p>
-This is all well and good for our module, which won't need any
-pre-initialized variables or structures. However, if we wanted to
-initialize something early on, before the requests come rolling in, we
-could simply add a call to a function in our <code>register_hooks</code>
+This is all well and good for our module, which won't need any
+pre-initialized variables or structures. However, if we wanted to
+initialize something early on, before the requests come rolling in, we
+could simply add a call to a function in our <code>register_hooks</code>
function to sort it out:
</p>
<p>
-In this pre-request initialization function we would not be using the
-same pool as we did when allocating resources for request-based functions.
-Instead, we would use the pool given to us by the server for allocating memory
+In this pre-request initialization function we would not be using the
+same pool as we did when allocating resources for request-based functions.
+Instead, we would use the pool given to us by the server for allocating memory
on a per-process based level.
</p>
<h3><a name="parsing" id="parsing">Parsing request data</a></h3>
<p>
-In our example module, we would like to add a feature, that checks which
-type of digest, MD5 or SHA1 the client would like to see. This could be
-solved by adding a query string to the request. A query string is typically
-comprised of several keys and values put together in a string, for instance
-<code>valueA=yes&valueB=no&valueC=maybe</code>. It is up to the
-module itself to parse these and get the data it requires. In our example,
+In our example module, we would like to add a feature, that checks which
+type of digest, MD5 or SHA1 the client would like to see. This could be
+solved by adding a query string to the request. A query string is typically
+comprised of several keys and values put together in a string, for instance
+<code>valueA=yes&valueB=no&valueC=maybe</code>. It is up to the
+module itself to parse these and get the data it requires. In our example,
we'll be looking for a key called <code>digest</code>, and if set to <code>
-md5</code>, we'll produce an MD5 digest, otherwise we'll produce a SHA1
+md5</code>, we'll produce an MD5 digest, otherwise we'll produce a SHA1
digest.
</p>
<p>
-Since the introduction of Apache HTTP Server 2.4, parsing request data from GET and
-POST requests have never been easier. All we require to parse both GET and
+Since the introduction of Apache HTTP Server 2.4, parsing request data from GET and
+POST requests have never been easier. All we require to parse both GET and
POST data is four simple lines:
-</p>
+</p>
<pre class="prettyprint lang-c">
<a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__apr__tables.html#gad7ea82d6608a4a633fc3775694ab71e4">apr_table_t</a> *GET; <em>
-</em><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/structapr__array__header__t.html">apr_array_header_t</a>*POST;
+</em><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/structapr__array__header__t.html">apr_array_header_t</a>*POST;
<em>
</em>
<a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__SCRIPT.html#gaed25877b529623a4d8f99f819ba1b7bd">
<p>
-In our specific example module, we're looking for the <code>digest</code>
+In our specific example module, we're looking for the <code>digest</code>
value from the query string, which now resides inside a table called <code>
GET</code>. To extract this value, we need only perform a simple operation:
</p>
<p>
-The structures used for the POST and GET data are not exactly the same, so
-if we were to fetch a value from POST data instead of the query string, we
+The structures used for the POST and GET data are not exactly the same, so
+if we were to fetch a value from POST data instead of the query string, we
would have to resort to a few more lines, as outlined in <a href="#get_post">this example</a> in the last chapter of this document.
</p>
<h3><a name="advanced_handler" id="advanced_handler">Making an advanced handler</a></h3>
<p>
-Now that we have learned how to parse form data and manage our resources,
-we can move on to creating an advanced version of our module, that spits
+Now that we have learned how to parse form data and manage our resources,
+we can move on to creating an advanced version of our module, that spits
out the MD5 or SHA1 digest of files:
</p>
apr_table_t *GET;
apr_array_header_t *POST;
const char *digestType;
-
-
+
+
/* Check that the "example-handler" handler is being called. */
if (!r->handler || strcmp(r->handler, "example-handler")) return (DECLINED);
-
+
/* Figure out which file is being requested by removing the .sum from it */
filename = apr_pstrdup(r->pool, r->filename);
filename[strlen(filename)-4] = 0; /* Cut off the last 4 characters. */
-
+
/* Figure out if the file we request a sum on exists and isn't a directory */
rc = apr_stat(&finfo, filename, APR_FINFO_MIN, r->pool);
if (rc == APR_SUCCESS) {
}
/* If apr_stat failed, we're probably not allowed to check this file. */
else return HTTP_FORBIDDEN;
-
+
/* Parse the GET and, optionally, the POST data sent to us */
-
+
ap_args_to_table(r, &GET);
ap_parse_form_data(r, NULL, &POST, -1, 8192);
-
+
/* Set the appropriate content type */
ap_set_content_type(r, "text/html");
-
+
/* Print a title and some general information */
ap_rprintf(r, "<h2>Information on %s:</h2>", filename);
ap_rprintf(r, "<b>Size:</b> %u bytes<br/>", finfo.size);
-
+
/* Get the digest type the client wants to see */
digestType = apr_table_get(GET, "digest");
if (!digestType) digestType = "MD5";
-
-
+
+
rc = apr_file_open(&file, filename, APR_READ, APR_OS_DEFAULT, r->pool);
if (rc == APR_SUCCESS) {
-
+
/* Are we trying to calculate the MD5 or the SHA1 digest? */
if (!strcasecmp(digestType, "md5")) {
/* Calculate the MD5 sum of the file */
apr_md5_update(&md5, buffer, readBytes);
}
apr_md5_final(digest.chr, &md5);
-
+
/* Print out the MD5 digest */
ap_rputs("<b>MD5: </b><code>", r);
for (n = 0; n < APR_MD5_DIGESTSIZE/4; n++) {
apr_sha1_update(&sha1, buffer, readBytes);
}
apr_sha1_final(digest.chr, &sha1);
-
+
/* Print out the SHA1 digest */
ap_rputs("<b>SHA1: </b><code>", r);
for (n = 0; n < APR_SHA1_DIGESTSIZE/4; n++) {
ap_rprintf(r, "%08x", digest.num[n]);
}
ap_rputs("</code>", r);
-
+
/* Print a link to the MD5 version */
ap_rputs("<br/><a href='?digest=md5'>View the MD5 hash instead</a>", r);
}
apr_file_close(file);
-
- }
+
+ }
/* Let the server know that we responded to this request. */
return OK;
}</pre>
<p>
-This version in its entirety can be found here:
+This version in its entirety can be found here:
<a href="http://people.apache.org/~humbedooh/mods/examples/mod_example_2.c">mod_example_2.c</a>.
</p>
<div class="section">
<h2><a name="configuration" id="configuration">Adding configuration options</a></h2>
<p>
-In this next segment of this document, we will turn our eyes away from the
-digest module and create a new example module, whose only function is to
-write out its own configuration. The purpose of this is to examine how
-the server works with configuration, and what happens when you start writing
-advanced configurations
+In this next segment of this document, we will turn our eyes away from the
+digest module and create a new example module, whose only function is to
+write out its own configuration. The purpose of this is to examine how
+the server works with configuration, and what happens when you start writing
+advanced configurations
for your modules.
</p>
-<h3><a name="config_intro" id="config_intro">An introduction to configuration
+<h3><a name="config_intro" id="config_intro">An introduction to configuration
directives</a></h3>
<p>
-If you are reading this, then you probably already know
-what a configuration directive is. Simply put, a directive is a way of
-telling an individual module (or a set of modules) how to behave, such as
+If you are reading this, then you probably already know
+what a configuration directive is. Simply put, a directive is a way of
+telling an individual module (or a set of modules) how to behave, such as
these directives control how <code>mod_rewrite</code> works:
</p>
<pre class="prettyprint lang-config">RewriteEngine On
RewriteRule "^/foo/bar/(.*)$" "/foobar?page=$1"</pre>
<p>
-Each of these configuration directives are handled by a separate function,
+Each of these configuration directives are handled by a separate function,
that parses the parameters given and sets up a configuration accordingly.
</p>
<p>
-Now, let's put this into perspective by creating a very small module that
-just prints out a hard-coded configuration. You'll notice that we use the
-<code>register_hooks</code> function for initializing the configuration
+Now, let's put this into perspective by creating a very small module that
+just prints out a hard-coded configuration. You'll notice that we use the
+<code>register_hooks</code> function for initializing the configuration
values to their defaults:
</p>
return OK;
}
-static void register_hooks(apr_pool_t *pool)
+static void register_hooks(apr_pool_t *pool)
{
config.enabled = 1;
config.path = "/foo/bar";
<p>
-So far so good. To access our new handler, we could add the following to
+So far so good. To access our new handler, we could add the following to
our configuration:
</p>
<pre class="prettyprint lang-config"><Location "/example">
</Location></pre>
<p>
-When we visit, we'll see our current configuration being spit out by our
-module.
+When we visit, we'll see our current configuration being spit out by our
+module.
</p>
<h3><a name="register_directive" id="register_directive">Registering directives with the server</a></h3>
<p>
-What if we want to change our configuration, not by hard-coding new values
-into the module, but by using either the httpd.conf file or possibly a
-.htaccess file? It's time to let the server know that we want this to be
-possible. To do so, we must first change our <em>name tag</em> to include a
+What if we want to change our configuration, not by hard-coding new values
+into the module, but by using either the httpd.conf file or possibly a
+.htaccess file? It's time to let the server know that we want this to be
+possible. To do so, we must first change our <em>name tag</em> to include a
reference to the configuration directives we want to register with the server:
</p>
<p>
-This will tell the server that we are now accepting directives from the
+This will tell the server that we are now accepting directives from the
configuration files, and that the structure called <code>example_directives
-</code> holds information on what our directives are and how they work.
-Since we have three different variables in our module configuration, we
+</code> holds information on what our directives are and how they work.
+Since we have three different variables in our module configuration, we
will add a structure with three directives and a NULL at the end:
</p>
As you can see, each directive needs at least 5 parameters set:
</p>
<ol>
-<li><code><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__CONFIG.html#ga07c7d22ae17805e61204463326cf9c34">AP_INIT_TAKE1</a></code>: This is a macro that tells the server that this directive takes one and only one argument.
-If we required two arguments, we could use the macro <code><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__CONFIG.html#gafaec43534fcf200f37d9fecbf9247c21">AP_INIT_TAKE2</a></code> and so on (refer to httpd_conf.h
+<li><code><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__CONFIG.html#ga07c7d22ae17805e61204463326cf9c34">AP_INIT_TAKE1</a></code>: This is a macro that tells the server that this directive takes one and only one argument.
+If we required two arguments, we could use the macro <code><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__CONFIG.html#gafaec43534fcf200f37d9fecbf9247c21">AP_INIT_TAKE2</a></code> and so on (refer to httpd_conf.h
for more macros).</li>
-<li><code>exampleEnabled</code>: This is the name of our directive. More precisely, it is what the user must put in his/her
+<li><code>exampleEnabled</code>: This is the name of our directive. More precisely, it is what the user must put in his/her
configuration in order to invoke a configuration change in our module.</li>
-<li><code>example_set_enabled</code>: This is a reference to a C function that parses the directive and sets the configuration
+<li><code>example_set_enabled</code>: This is a reference to a C function that parses the directive and sets the configuration
accordingly. We will discuss how to make this in the following paragraph.</li>
-<li><code>RSRC_CONF</code>: This tells the server where the directive is permitted. We'll go into details on this value in the
+<li><code>RSRC_CONF</code>: This tells the server where the directive is permitted. We'll go into details on this value in the
later chapters, but for now, <code>RSRC_CONF</code> means that the server will only accept these directives in a server context.</li>
<li><code>"Enable or disable...."</code>: This is simply a brief description of what the directive does.</li>
</ol>
<p>
-(<em>The "missing" parameter in our definition, which is usually set to
-<code>NULL</code>, is an optional function that can be run after the
-initial function to parse the arguments have been run. This is usually
-omitted, as the function for verifying arguments might as well be used to
+(<em>The "missing" parameter in our definition, which is usually set to
+<code>NULL</code>, is an optional function that can be run after the
+initial function to parse the arguments have been run. This is usually
+omitted, as the function for verifying arguments might as well be used to
set them.</em>)
</p>
<h3><a name="directive_handler" id="directive_handler">The directive handler function</a></h3>
<p>
-Now that we have told the server to expect some directives for our module, it's
-time to make a few functions for handling these. What the server reads in the
-configuration file(s) is text, and so naturally, what it passes along to
-our directive handler is one or more strings, that we ourselves need to
+Now that we have told the server to expect some directives for our module, it's
+time to make a few functions for handling these. What the server reads in the
+configuration file(s) is text, and so naturally, what it passes along to
+our directive handler is one or more strings, that we ourselves need to
recognize and act upon. You'll notice, that since we set our <code>
-exampleAction</code> directive to accept two arguments, its C function also
-has an additional parameter defined:</p>
+exampleAction</code> directive to accept two arguments, its C function also
+has an additional parameter defined:</p>
<pre class="prettyprint lang-c">/* Handler for the "exampleEnabled" directive */
{
if(!strcasecmp(arg1, "file")) config.typeOfAction = 0x01;
else config.typeOfAction = 0x02;
-
+
if(!strcasecmp(arg2, "deny")) config.typeOfAction += 0x10;
else config.typeOfAction += 0x20;
return NULL;
<h3><a name="directive_complete" id="directive_complete">Putting it all together</a></h3>
<p>
-Now that we have our directives set up, and handlers configured for them,
+Now that we have our directives set up, and handlers configured for them,
we can assemble our module into one big file:
</p>
{
if(!strcasecmp(arg1, "file")) config.typeOfAction = 0x01;
else config.typeOfAction = 0x02;
-
+
if(!strcasecmp(arg2, "deny")) config.typeOfAction += 0x10;
else config.typeOfAction += 0x20;
return NULL;
The hook registration function (also initializes the default config values):
==============================================================================
*/
-static void register_hooks(apr_pool_t *pool)
+static void register_hooks(apr_pool_t *pool)
{
config.enabled = 1;
config.path = "/foo/bar";
<p>
-In our httpd.conf file, we can now change the hard-coded configuration by
+In our httpd.conf file, we can now change the hard-coded configuration by
adding a few lines:
</p>
<pre class="prettyprint lang-config">ExampleEnabled On
ExampleAction file allow</pre>
<p>
-And thus we apply the configuration, visit <code>/example</code> on our
-web site, and we see the configuration has adapted to what we wrote in our
+And thus we apply the configuration, visit <code>/example</code> on our
+web site, and we see the configuration has adapted to what we wrote in our
configuration file.
</p>
<h2><a name="context" id="context">Context aware configurations</a></h2>
<h3><a name="context_intro" id="context_intro">Introduction to context aware configurations</a></h3>
<p>
-In Apache HTTP Server 2.4, different URLs, virtual hosts, directories etc can have very
-different meanings to the user of the server, and thus different contexts
-within which modules must operate. For example, let's assume you have this
+In Apache HTTP Server 2.4, different URLs, virtual hosts, directories etc can have very
+different meanings to the user of the server, and thus different contexts
+within which modules must operate. For example, let's assume you have this
configuration set up for mod_rewrite:
</p>
<pre class="prettyprint lang-config"><Directory "/var/www">
</Directory></pre>
<p>
-In this example, you will have set up two different contexts for
+In this example, you will have set up two different contexts for
mod_rewrite:</p>
<ol>
<li>Inside <code>/var/www</code>, all requests for <code>http://example.com</code> must go to <code>http://www.example.com</code></li>
<li>Inside <code>/var/www/sub</code>, all requests for <code>foobar</code> must go to <code>index.php?foobar=true</code></li>
</ol>
<p>
-If mod_rewrite (or the entire server for that matter) wasn't context aware, then
-these rewrite rules would just apply to every and any request made,
-regardless of where and how they were made, but since the module can pull
-the context specific configuration straight from the server, it does not need
-to know itself, which of the directives are valid in this context, since
+If mod_rewrite (or the entire server for that matter) wasn't context aware, then
+these rewrite rules would just apply to every and any request made,
+regardless of where and how they were made, but since the module can pull
+the context specific configuration straight from the server, it does not need
+to know itself, which of the directives are valid in this context, since
the server takes care of this.</p>
<p>
-So how does a module get the specific configuration for the server,
+So how does a module get the specific configuration for the server,
directory or location in question? It does so by making one simple call:
</p>
<p>
-That's it! Of course, a whole lot goes on behind the scenes, which we will
-discuss in this chapter, starting with how the server came to know what our
-configuration looks like, and how it came to be set up as it is in the
+That's it! Of course, a whole lot goes on behind the scenes, which we will
+discuss in this chapter, starting with how the server came to know what our
+configuration looks like, and how it came to be set up as it is in the
specific context.
</p>
<h3><a name="context_base" id="context_base">Our basic configuration setup</a></h3>
-<p>In this chapter, we will be working with a slightly modified version of
-our previous context structure. We will set a <code>context</code>
-variable that we can use to track which context configuration is being
+<p>In this chapter, we will be working with a slightly modified version of
+our previous context structure. We will set a <code>context</code>
+variable that we can use to track which context configuration is being
used by the server in various places:
</p>
<h3><a name="context_which" id="context_which">Choosing a context</a></h3>
<p>
-Before we can start making our module context aware, we must first define,
-which contexts we will accept. As we saw in the previous chapter, defining
+Before we can start making our module context aware, we must first define,
+which contexts we will accept. As we saw in the previous chapter, defining
a directive required five elements be set:</p>
-<p>The <code>RSRC_CONF</code> definition told the server that we would only allow
-this directive in a global server context, but since we are now trying out
-a context aware version of our module, we should set this to something
-more lenient, namely the value <code>ACCESS_CONF</code>, which lets us use
-the directive inside <Directory> and <Location> blocks. For more
-control over the placement of your directives, you can combine the following
+<p>The <code>RSRC_CONF</code> definition told the server that we would only allow
+this directive in a global server context, but since we are now trying out
+a context aware version of our module, we should set this to something
+more lenient, namely the value <code>ACCESS_CONF</code>, which lets us use
+the directive inside <Directory> and <Location> blocks. For more
+control over the placement of your directives, you can combine the following
restrictions together to form a specific rule:
</p>
<ul>
<h3><a name="context_pool" id="context_pool">Using the server to allocate configuration slots</a></h3>
-<p> A much smarter way to manage your configurations is by letting the server
-help you create them. To do so, we must first start off by changing our
-<em>name tag</em> to let the server know, that it should assist us in creating
-and managing our configurations. Since we have chosen the per-directory
-(or per-location) context for our module configurations, we'll add a
+<p> A much smarter way to manage your configurations is by letting the server
+help you create them. To do so, we must first start off by changing our
+<em>name tag</em> to let the server know, that it should assist us in creating
+and managing our configurations. Since we have chosen the per-directory
+(or per-location) context for our module configurations, we'll add a
per-directory creator and merger function reference in our tag:</p>
<h3><a name="context_new" id="context_new">Creating new context configurations</a></h3>
<p>
-Now that we have told the server to help us create and manage configurations,
-our first step is to make a function for creating new, blank
-configurations. We do so by creating the function we just referenced in
+Now that we have told the server to help us create and manage configurations,
+our first step is to make a function for creating new, blank
+configurations. We do so by creating the function we just referenced in
our name tag as the Per-directory configuration handler:</p>
<pre class="prettyprint lang-c">void *create_dir_conf(apr_pool_t *pool, char *context) {
<h3><a name="context_merge" id="context_merge">Merging configurations</a></h3>
<p>
-Our next step in creating a context aware configuration is merging
-configurations. This part of the process particularly applies to scenarios
-where you have a parent configuration and a child, such as the following:
+Our next step in creating a context aware configuration is merging
+configurations. This part of the process particularly applies to scenarios
+where you have a parent configuration and a child, such as the following:
</p>
<pre class="prettyprint lang-config"><Directory "/var/www">
ExampleEnabled On
<p>
In this example, it is natural to assume that the directory <code>
/var/www/subdir</code> should inherit the values set for the <code>/var/www
-</code> directory, as we did not specify an <code>ExampleEnabled</code> nor
-an <code>ExamplePath</code> for this directory. The server does not presume to
+</code> directory, as we did not specify an <code>ExampleEnabled</code> nor
+an <code>ExamplePath</code> for this directory. The server does not presume to
know if this is true, but cleverly does the following:
</p>
<ol>
<li><strong>Proposes a merge</strong> of the two configurations into a new configuration for <code>/var/www/subdir</code></li>
</ol>
<p>
-This proposal is handled by the <code>merge_dir_conf</code> function we
-referenced in our name tag. The purpose of this function is to assess the
+This proposal is handled by the <code>merge_dir_conf</code> function we
+referenced in our name tag. The purpose of this function is to assess the
two configurations and decide how they are to be merged:</p>
example_config *base = (example_config *) BASE ; /* This is what was set in the parent context */
example_config *add = (example_config *) ADD ; /* This is what is set in the new context */
example_config *conf = (example_config *) create_dir_conf(pool, "Merged configuration"); /* This will be the merged configuration */
-
+
/* Merge configurations */
conf->enabled = ( add->enabled == 0 ) ? base->enabled : add->enabled ;
conf->typeOfAction = add->typeOfAction ? add->typeOfAction : base->typeOfAction;
strcpy(conf->path, strlen(add->path) ? add->path : base->path);
-
+
return conf ;
}</pre>
<h3><a name="context_example" id="context_example">Trying out our new context aware configurations</a></h3>
<p>
-Now, let's try putting it all together to create a new module that is
-context aware. First off, we'll create a configuration that lets us test
+Now, let's try putting it all together to create a new module that is
+context aware. First off, we'll create a configuration that lets us test
how the module works:
</p>
<pre class="prettyprint lang-config"><Location "/a">
</Location></pre>
<p>
-Then we'll assemble our module code. Note, that since we are now using our
-name tag as reference when fetching configurations in our handler, I have
+Then we'll assemble our module code. Note, that since we are now using our
+name tag as reference when fetching configurations in our handler, I have
added some prototypes to keep the compiler happy:
</p>
<div class="section">
<h2><a name="summary" id="summary">Summing up</a></h2>
<p>
-We have now looked at how to create simple modules for Apache HTTP Server 2.4 and
-configuring them. What you do next is entirely up to you, but it is my
-hope that something valuable has come out of reading this documentation.
-If you have questions on how to further develop modules, you are welcome
-to join our <a href="http://httpd.apache.org/lists.html">mailing lists</a>
+We have now looked at how to create simple modules for Apache HTTP Server 2.4 and
+configuring them. What you do next is entirely up to you, but it is my
+hope that something valuable has come out of reading this documentation.
+If you have questions on how to further develop modules, you are welcome
+to join our <a href="http://httpd.apache.org/lists.html">mailing lists</a>
or check out the rest of our documentation for further tips.
</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
return(rc);
}
-static int example_handler(request_rec *r)
+static int example_handler(request_rec *r)
{
/*~~~~~~~~~~~~~~~~*/
apr_off_t size;
<title>Developing modules for the Apache HTTP Server 2.4</title>
<summary>
-<p>This document explains how you can develop modules for the Apache HTTP
+<p>This document explains how you can develop modules for the Apache HTTP
Server 2.4</p>
</summary>
<section id="introduction"><title>Introduction</title>
<section id="what"><title>What we will be discussing in this document</title>
<p>
-This document will discuss how you can create modules for the Apache
-HTTP Server 2.4, by exploring an example module called
-<code>mod_example</code>. In the first part of this document, the purpose
-of this module will be to calculate and print out various digest values for
+This document will discuss how you can create modules for the Apache
+HTTP Server 2.4, by exploring an example module called
+<code>mod_example</code>. In the first part of this document, the purpose
+of this module will be to calculate and print out various digest values for
existing files on your web server, whenever we access the URL <code>
-http://hostname/filename.sum</code>. For instance, if we want to know the
+http://hostname/filename.sum</code>. For instance, if we want to know the
MD5 digest value of the file located at <code>
http://www.example.com/index.html</code>, we would visit <code>
-http://www.example.com/index.html.sum</code>.
+http://www.example.com/index.html.sum</code>.
</p>
<p>
-In the second part of this document, which deals with configuration
-directive and context awareness, we will be looking at a module that simply
+In the second part of this document, which deals with configuration
+directive and context awareness, we will be looking at a module that simply
writes out its own configuration to the client.
</p>
</section>
<section id="prerequisites"><title>Prerequisites</title>
<p>
-First and foremost, you are expected to have a basic knowledge of how the C
-programming language works. In most cases, we will try to be as pedagogical
-as possible and link to documents describing the functions used in the
-examples, but there are also many cases where it is necessary to either
-just assume that "it works" or do some digging yourself into what the hows
-and whys of various function calls.
+First and foremost, you are expected to have a basic knowledge of how the C
+programming language works. In most cases, we will try to be as pedagogical
+as possible and link to documents describing the functions used in the
+examples, but there are also many cases where it is necessary to either
+just assume that "it works" or do some digging yourself into what the hows
+and whys of various function calls.
</p>
<p>
-Lastly, you will need to have a basic understanding of how modules are
-loaded and configured in the Apache HTTP Server, as well as how to get the headers for
-Apache if you do not have them already, as these are needed for compiling
+Lastly, you will need to have a basic understanding of how modules are
+loaded and configured in the Apache HTTP Server, as well as how to get the headers for
+Apache if you do not have them already, as these are needed for compiling
new modules.
</p>
</section>
<section id="compiling"><title>Compiling your module</title>
<p>
-To compile the source code we are building in this document, we will be
-using <a href="../programs/apxs.html">APXS</a>. Assuming your source file
-is called mod_example.c, compiling, installing and activating the module is
-as simple as:
+To compile the source code we are building in this document, we will be
+using <a href="../programs/apxs.html">APXS</a>. Assuming your source file
+is called mod_example.c, compiling, installing and activating the module is
+as simple as:
</p>
<example><pre>
apxs -i -a -c mod_example.c
<section id="basics"><title>Defining a module</title>
<p>
<img src="../images/build_a_mod_3.png" alt="Module name tags"/><br/>
-Every module starts with the same declaration, or name tag if you will,
+Every module starts with the same declaration, or name tag if you will,
that defines a module as <em>a separate entity within Apache</em>:</p>
<!-- BEGIN EXAMPLE CODE -->
<highlight language="c">
module AP_MODULE_DECLARE_DATA example_module =
-{
+{
STANDARD20_MODULE_STUFF,
create_dir_conf, /* Per-directory configuration handler */
merge_dir_conf, /* Merge handler for per-directory configurations */
<!-- END EXAMPLE CODE -->
<p>
-This bit of code lets the server know that we have now registered a new module
-in the system, and that its name is <code>example_module</code>. The name
+This bit of code lets the server know that we have now registered a new module
+in the system, and that its name is <code>example_module</code>. The name
of the module is used primarily for two things:<br/>
</p>
<ul>
<li>Setting up a namespace for the module to use in configurations</li>
</ul>
<p>
-For now, we're only concerned with the first purpose of the module name,
+For now, we're only concerned with the first purpose of the module name,
which comes into play when we need to load the module:
</p>
<highlight language="config">
LoadModule example_module "modules/mod_example.so"
</highlight>
<p>
-In essence, this tells the server to open up <code>mod_example.so</code> and look for a module
+In essence, this tells the server to open up <code>mod_example.so</code> and look for a module
called <code>example_module</code>.
</p>
<p>
-Within this name tag of ours is also a bunch of references to how we would
-like to handle things: Which directives do we respond to in a configuration
-file or .htaccess, how do we operate within specific contexts, and what
-handlers are we interested in registering with the Apache HTTP service. We'll
+Within this name tag of ours is also a bunch of references to how we would
+like to handle things: Which directives do we respond to in a configuration
+file or .htaccess, how do we operate within specific contexts, and what
+handlers are we interested in registering with the Apache HTTP service. We'll
return to all these elements later in this document.
</p>
</section>
<section id="hooking"><title>Getting started: Hooking into the server</title>
<section id="hook_intro"><title>An introduction to hooks</title>
<p>
-When handling requests in Apache HTTP Server 2.4, the first thing you will need to do is
-create a hook into the request handling process. A hook is essentially a
-message telling the server that you are willing to either serve or at least
-take a glance at certain requests given by clients. All handlers, whether
-it's mod_rewrite, mod_authn_*, mod_proxy and so on, are hooked into
-specific parts of the request process. As you are probably aware, modules
-serve different purposes; Some are authentication/authorization handlers,
-others are file or script handlers while some third modules rewrite URIs or
-proxies content. Furthermore, in the end, it is up to the user of the server
-how and when each module will come into place. Thus, the server itself does not
-presume to know which module is responsible for handling a specific
-request, and will ask each module whether they have an interest in a given
-request or not. It is then up to each module to either gently decline
-serving a request, accept serving it or flat out deny the request from
+When handling requests in Apache HTTP Server 2.4, the first thing you will need to do is
+create a hook into the request handling process. A hook is essentially a
+message telling the server that you are willing to either serve or at least
+take a glance at certain requests given by clients. All handlers, whether
+it's mod_rewrite, mod_authn_*, mod_proxy and so on, are hooked into
+specific parts of the request process. As you are probably aware, modules
+serve different purposes; Some are authentication/authorization handlers,
+others are file or script handlers while some third modules rewrite URIs or
+proxies content. Furthermore, in the end, it is up to the user of the server
+how and when each module will come into place. Thus, the server itself does not
+presume to know which module is responsible for handling a specific
+request, and will ask each module whether they have an interest in a given
+request or not. It is then up to each module to either gently decline
+serving a request, accept serving it or flat out deny the request from
being served, as authentication/authorization modules do: <br/>
<img src="../images/build_a_mod_2.png" alt="Hook handling in httpd"/><br/>
-To make it a bit easier for handlers such as our mod_example to know
-whether the client is requesting content we should handle or not, the server
-has directives for hinting to modules whether their assistance is needed or
-not. Two of these are <directive module="mod_mime">AddHandler</directive>
-and <directive module="core">SetHandler</directive>. Let's take a look at
-an example using <directive module="mod_mime">AddHandler</directive>. In
-our example case, we want every request ending with .sum to be served by
-<code>mod_example</code>, so we'll add a configuration directive that tells
+To make it a bit easier for handlers such as our mod_example to know
+whether the client is requesting content we should handle or not, the server
+has directives for hinting to modules whether their assistance is needed or
+not. Two of these are <directive module="mod_mime">AddHandler</directive>
+and <directive module="core">SetHandler</directive>. Let's take a look at
+an example using <directive module="mod_mime">AddHandler</directive>. In
+our example case, we want every request ending with .sum to be served by
+<code>mod_example</code>, so we'll add a configuration directive that tells
the server to do just that:
</p>
<highlight language="config">
AddHandler example-handler ".sum"
</highlight>
<p>
-What this tells the server is the following: <em>Whenever we receive a request
-for a URI ending in .sum, we are to let all modules know that we are
-looking for whoever goes by the name of "example-handler" </em>.
-Thus, when a request is being served that ends in .sum, the server will let all
+What this tells the server is the following: <em>Whenever we receive a request
+for a URI ending in .sum, we are to let all modules know that we are
+looking for whoever goes by the name of "example-handler" </em>.
+Thus, when a request is being served that ends in .sum, the server will let all
modules know, that this request should be served by "example-handler".
-As you will see later, when we start building mod_example, we will
-check for this handler tag relayed by <code>AddHandler</code> and reply to
+As you will see later, when we start building mod_example, we will
+check for this handler tag relayed by <code>AddHandler</code> and reply to
the server based on the value of this tag.
</p>
</section>
<section id="hook_declaration"><title>Hooking into httpd</title>
<p>
-To begin with, we only want to create a simple handler, that replies to the
-client browser when a specific URL is requested, so we won't bother setting
-up configuration handlers and directives just yet. Our initial module
+To begin with, we only want to create a simple handler, that replies to the
+client browser when a specific URL is requested, so we won't bother setting
+up configuration handlers and directives just yet. Our initial module
definition will look like this:</p>
<!-- END EXAMPLE CODE -->
-<p>This lets the server know that we are not interested in anything fancy, we
-just want to hook onto the requests and possibly handle some of them. </p>
+<p>This lets the server know that we are not interested in anything fancy, we
+just want to hook onto the requests and possibly handle some of them. </p>
-<p> The reference in our example declaration, <code>register_hooks</code>
-is the name of a function we will create to manage how we hook onto the
-request process. In this example module, the function has just one purpose;
-To create a simple hook that gets called after all the rewrites, access
-control etc has been handled. Thus, we will let the server know, that we want
-to hook into its process as one of the last modules:
+<p> The reference in our example declaration, <code>register_hooks</code>
+is the name of a function we will create to manage how we hook onto the
+request process. In this example module, the function has just one purpose;
+To create a simple hook that gets called after all the rewrites, access
+control etc has been handled. Thus, we will let the server know, that we want
+to hook into its process as one of the last modules:
</p>
<!-- BEGIN EXAMPLE CODE -->
<!-- END EXAMPLE CODE -->
<p>
-The <code>example_handler</code> reference is the function that will handle
+The <code>example_handler</code> reference is the function that will handle
the request. We will discuss how to create a handler in the next chapter.
</p>
</section>
<section id="hook_others"><title>Other useful hooks</title>
<p>
-Hooking into the request handling phase is but one of many hooks that you
+Hooking into the request handling phase is but one of many hooks that you
can create. Some other ways of hooking are:
</p>
<ul>
<section id="handling"><title>Building a handler</title>
<p>
-A handler is essentially a function that receives a callback when a request
-to the server is made. It is passed a record of the current request (how it was
-made, which headers and requests were passed along, who's giving the
-request and so on), and is put in charge of either telling the server that it's
+A handler is essentially a function that receives a callback when a request
+to the server is made. It is passed a record of the current request (how it was
+made, which headers and requests were passed along, who's giving the
+request and so on), and is put in charge of either telling the server that it's
not interested in the request or handle the request with the tools provided.
</p>
-<section id="simple_handler"><title>A simple "Hello, world!"
-handler</title>
-<p>Let's start off by making a very simple request handler
+<section id="simple_handler"><title>A simple "Hello, world!"
+handler</title>
+<p>Let's start off by making a very simple request handler
that does the following:
</p>
<ol>
* and the server will try somewhere else.
*/
if (!r->handler || strcmp(r->handler, "example-handler")) return (DECLINED);
-
+
/* Now that we are handling this request, we'll write out "Hello, world!" to the client.
* To do so, we must first set the appropriate content type, followed by our output.
*/
ap_set_content_type(r, "text/html");
ap_rprintf(r, "Hello, world!");
-
+
/* Lastly, we must tell the server that we took care of this request and everything went fine.
* We do so by simply returning the value OK to the server.
*/
<!-- END EXAMPLE CODE -->
<p>
-Now, we put all we have learned together and end up with a program that
-looks like
+Now, we put all we have learned together and end up with a program that
+looks like
<a href="http://people.apache.org/~humbedooh/mods/examples/mod_example_1.c">mod_example_1.c</a>
-. The functions used in this example will be explained later in the section
-<a href= "#functions">"Some useful functions you should know"</a>.
+. The functions used in this example will be explained later in the section
+<a href= "#functions">"Some useful functions you should know"</a>.
</p>
-</section>
-<section id="request_rec"><title>The request_rec structure</title>
+</section>
+<section id="request_rec"><title>The request_rec structure</title>
<p>The most essential part of any request is the <em>request record
</em>. In a call to a handler function, this is represented by the <code>
-request_rec* </code> structure passed along with every call that is made.
-This struct, typically just referred to as <code>r</code> in modules,
-contains all the information you need for your module to fully process any
+request_rec* </code> structure passed along with every call that is made.
+This struct, typically just referred to as <code>r</code> in modules,
+contains all the information you need for your module to fully process any
HTTP request and respond accordingly.</p> <p>Some key elements of the <code>
request_rec </code> structure are:
</p>
<li><code>r->connection (conn_rec*):</code> A record containing information about the current connection</li>
<li><code>r->user (char*):</code> If the URI requires authentication, this is set to the username provided</li>
<li><code>r->useragent_ip (char*):</code> The IP address of the client connecting to us</li>
-<li><code>r->pool (apr_pool_t*)</code>: The memory pool of this request. We'll discuss this in the
+<li><code>r->pool (apr_pool_t*)</code>: The memory pool of this request. We'll discuss this in the
"<a href="#memory">Memory management</a>" chapter.</li>
</ul>
<p>
-A complete list of all the values contained within the <code>request_rec</code> structure can be found in
-the <a href="http://svn.apache.org/repos/asf/httpd/httpd/trunk/include/httpd.h"><code>httpd.h</code></a> header
+A complete list of all the values contained within the <code>request_rec</code> structure can be found in
+the <a href="http://svn.apache.org/repos/asf/httpd/httpd/trunk/include/httpd.h"><code>httpd.h</code></a> header
file or at <a href="http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html">http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html</a>.
</p>
/* Print out the IP address of the client connecting to us: */
ap_rprintf(r, "<h2>Hello, %s!</h2>", r->useragent_ip);
-
+
/* If we were reached through a GET or a POST request, be happy, else sad. */
if ( !strcmp(r->method, "POST") || !strcmp(r->method, "GET") ) {
ap_rputs("You used a GET or a POST method, that makes us happy!<br/>", r);
<section id="return_value"><title>Return values</title>
<p>
-Apache relies on return values from handlers to signify whether a request
-was handled or not, and if so, whether the request went well or not. If a
-module is not interested in handling a specific request, it should always
-return the value <code>DECLINED</code>. If it is handling a request, it
-should either return the generic value <code>OK</code>, or a specific HTTP
+Apache relies on return values from handlers to signify whether a request
+was handled or not, and if so, whether the request went well or not. If a
+module is not interested in handling a specific request, it should always
+return the value <code>DECLINED</code>. If it is handling a request, it
+should either return the generic value <code>OK</code>, or a specific HTTP
status code, for example:
</p>
<!-- END EXAMPLE CODE -->
<p>
-Returning <code>OK</code> or a HTTP status code does not necessarily mean
-that the request will end. The server may still have other handlers that are
-interested in this request, for instance the logging modules which, upon a
-successful request, will write down a summary of what was requested and how
-it went. To do a full stop and prevent any further processing after your
-module is done, you can return the value <code>DONE</code> to let the server
-know that it should cease all activity on this request and carry on with
+Returning <code>OK</code> or a HTTP status code does not necessarily mean
+that the request will end. The server may still have other handlers that are
+interested in this request, for instance the logging modules which, upon a
+successful request, will write down a summary of what was requested and how
+it went. To do a full stop and prevent any further processing after your
+module is done, you can return the value <code>DONE</code> to let the server
+know that it should cease all activity on this request and carry on with
the next, without informing other handlers.
<br/>
<strong>General response codes:</strong>
<ul>
<li>
<code>ap_rputs(const char *string, request_rec *r)</code>: <br/>
- Sends a string of text to the client. This is a shorthand version of <a
+ Sends a string of text to the client. This is a shorthand version of <a
href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__PROTO.html#gac827cd0537d2b6213a7c06d7c26cc36e">
ap_rwrite</a>.
-
+
<!-- BEGIN EXAMPLE CODE -->
<highlight language="c">ap_rputs("Hello, world!", r);</highlight>
<li>
<code>
<a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__PROTO.html#ga5e91eb6ca777c9a427b2e82bf1eeb81d">ap_rprintf</a></code>: <br/>
- This function works just like <code>printf</code>, except it sends the result to the client.
-
+ This function works just like <code>printf</code>, except it sends the result to the client.
+
<!-- BEGIN EXAMPLE CODE -->
<highlight language="c">ap_rprintf(r, "Hello, %s!", r->useragent_ip);</highlight>
<code>
<a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__PROTO.html#gaa2f8412c400197338ec509f4a45e4579">ap_set_content_type</a>(request_rec *r, const char *type)</code>: <br/>
Sets the content type of the output you are sending.
-
+
<!-- BEGIN EXAMPLE CODE -->
<highlight language="c">ap_set_content_type(r, "text/plain"); /* force a raw text output */</highlight>
<section id="memory"><title>Memory management</title>
<p>
-Managing your resources in Apache HTTP Server 2.4 is quite easy, thanks to the memory pool
-system. In essence, each server, connection and request have their own
-memory pool that gets cleaned up when its scope ends, e.g. when a request
-is done or when a server process shuts down. All your module needs to do is
-latch onto this memory pool, and you won't have to worry about having to
+Managing your resources in Apache HTTP Server 2.4 is quite easy, thanks to the memory pool
+system. In essence, each server, connection and request have their own
+memory pool that gets cleaned up when its scope ends, e.g. when a request
+is done or when a server process shuts down. All your module needs to do is
+latch onto this memory pool, and you won't have to worry about having to
clean up after yourself - pretty neat, huh?
</p>
<p>
-In our module, we will primarily be allocating memory for each request, so
-it's appropriate to use the <code>r->pool</code>
-reference when creating new objects. A few of the functions for allocating
+In our module, we will primarily be allocating memory for each request, so
+it's appropriate to use the <code>r->pool</code>
+reference when creating new objects. A few of the functions for allocating
memory within a pool are:
</p>
<ul>
const char *original = "You can't edit this!";
char *copy;
int *integers;
-
+
/* Allocate space for 10 integer values and set them all to zero. */
- integers = apr_pcalloc(r->pool, sizeof(int)*10);
-
+ integers = apr_pcalloc(r->pool, sizeof(int)*10);
+
/* Create a copy of the 'original' variable that we can edit. */
copy = apr_pstrdup(r->pool, original);
return OK;
<!-- END EXAMPLE CODE -->
<p>
-This is all well and good for our module, which won't need any
-pre-initialized variables or structures. However, if we wanted to
-initialize something early on, before the requests come rolling in, we
-could simply add a call to a function in our <code>register_hooks</code>
+This is all well and good for our module, which won't need any
+pre-initialized variables or structures. However, if we wanted to
+initialize something early on, before the requests come rolling in, we
+could simply add a call to a function in our <code>register_hooks</code>
function to sort it out:
</p>
<!-- END EXAMPLE CODE -->
<p>
-In this pre-request initialization function we would not be using the
-same pool as we did when allocating resources for request-based functions.
-Instead, we would use the pool given to us by the server for allocating memory
+In this pre-request initialization function we would not be using the
+same pool as we did when allocating resources for request-based functions.
+Instead, we would use the pool given to us by the server for allocating memory
on a per-process based level.
</p>
</section>
<section id="parsing"><title>Parsing request data</title>
<p>
-In our example module, we would like to add a feature, that checks which
-type of digest, MD5 or SHA1 the client would like to see. This could be
-solved by adding a query string to the request. A query string is typically
-comprised of several keys and values put together in a string, for instance
-<code>valueA=yes&valueB=no&valueC=maybe</code>. It is up to the
-module itself to parse these and get the data it requires. In our example,
+In our example module, we would like to add a feature, that checks which
+type of digest, MD5 or SHA1 the client would like to see. This could be
+solved by adding a query string to the request. A query string is typically
+comprised of several keys and values put together in a string, for instance
+<code>valueA=yes&valueB=no&valueC=maybe</code>. It is up to the
+module itself to parse these and get the data it requires. In our example,
we'll be looking for a key called <code>digest</code>, and if set to <code>
-md5</code>, we'll produce an MD5 digest, otherwise we'll produce a SHA1
+md5</code>, we'll produce an MD5 digest, otherwise we'll produce a SHA1
digest.
</p>
<p>
-Since the introduction of Apache HTTP Server 2.4, parsing request data from GET and
-POST requests have never been easier. All we require to parse both GET and
+Since the introduction of Apache HTTP Server 2.4, parsing request data from GET and
+POST requests have never been easier. All we require to parse both GET and
POST data is four simple lines:
-</p>
+</p>
<!-- BEGIN EXAMPLE CODE -->
<highlight language="c">
<a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__apr__tables.html#gad7ea82d6608a4a633fc3775694ab71e4">apr_table_t</a> *GET; <em>
-</em><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/structapr__array__header__t.html">apr_array_header_t</a>*POST;
+</em><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/structapr__array__header__t.html">apr_array_header_t</a>*POST;
<em>
</em>
<a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__SCRIPT.html#gaed25877b529623a4d8f99f819ba1b7bd">
ap_args_to_table</a>(r, &GET); <em>
</em><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__DAEMON.html#ga9d426b6382b49754d4f87c55f65af202">
-ap_parse_form_data</a>(r, NULL, &POST, -1, 8192);
+ap_parse_form_data</a>(r, NULL, &POST, -1, 8192);
</highlight>
<!-- END EXAMPLE CODE -->
<p>
-In our specific example module, we're looking for the <code>digest</code>
+In our specific example module, we're looking for the <code>digest</code>
value from the query string, which now resides inside a table called <code>
GET</code>. To extract this value, we need only perform a simple operation:
</p>
<!-- END EXAMPLE CODE -->
<p>
-The structures used for the POST and GET data are not exactly the same, so
-if we were to fetch a value from POST data instead of the query string, we
+The structures used for the POST and GET data are not exactly the same, so
+if we were to fetch a value from POST data instead of the query string, we
would have to resort to a few more lines, as outlined in <a href="#get_post"
>this example</a> in the last chapter of this document.
</p>
<section id="advanced_handler"><title>Making an advanced handler</title>
<p>
-Now that we have learned how to parse form data and manage our resources,
-we can move on to creating an advanced version of our module, that spits
+Now that we have learned how to parse form data and manage our resources,
+we can move on to creating an advanced version of our module, that spits
out the MD5 or SHA1 digest of files:
</p>
apr_table_t *GET;
apr_array_header_t *POST;
const char *digestType;
-
-
+
+
/* Check that the "example-handler" handler is being called. */
if (!r->handler || strcmp(r->handler, "example-handler")) return (DECLINED);
-
+
/* Figure out which file is being requested by removing the .sum from it */
filename = apr_pstrdup(r->pool, r->filename);
filename[strlen(filename)-4] = 0; /* Cut off the last 4 characters. */
-
+
/* Figure out if the file we request a sum on exists and isn't a directory */
rc = apr_stat(&finfo, filename, APR_FINFO_MIN, r->pool);
if (rc == APR_SUCCESS) {
}
/* If apr_stat failed, we're probably not allowed to check this file. */
else return HTTP_FORBIDDEN;
-
+
/* Parse the GET and, optionally, the POST data sent to us */
-
+
ap_args_to_table(r, &GET);
ap_parse_form_data(r, NULL, &POST, -1, 8192);
-
+
/* Set the appropriate content type */
ap_set_content_type(r, "text/html");
-
+
/* Print a title and some general information */
ap_rprintf(r, "<h2>Information on %s:</h2>", filename);
ap_rprintf(r, "<b>Size:</b> %u bytes<br/>", finfo.size);
-
+
/* Get the digest type the client wants to see */
digestType = apr_table_get(GET, "digest");
if (!digestType) digestType = "MD5";
-
-
+
+
rc = apr_file_open(&file, filename, APR_READ, APR_OS_DEFAULT, r->pool);
if (rc == APR_SUCCESS) {
-
+
/* Are we trying to calculate the MD5 or the SHA1 digest? */
if (!strcasecmp(digestType, "md5")) {
/* Calculate the MD5 sum of the file */
apr_md5_update(&md5, buffer, readBytes);
}
apr_md5_final(digest.chr, &md5);
-
+
/* Print out the MD5 digest */
ap_rputs("<b>MD5: </b><code>", r);
for (n = 0; n < APR_MD5_DIGESTSIZE/4; n++) {
apr_sha1_update(&sha1, buffer, readBytes);
}
apr_sha1_final(digest.chr, &sha1);
-
+
/* Print out the SHA1 digest */
ap_rputs("<b>SHA1: </b><code>", r);
for (n = 0; n < APR_SHA1_DIGESTSIZE/4; n++) {
ap_rprintf(r, "%08x", digest.num[n]);
}
ap_rputs("</code>", r);
-
+
/* Print a link to the MD5 version */
ap_rputs("<br/><a href='?digest=md5'>View the MD5 hash instead</a>", r);
}
apr_file_close(file);
-
- }
+
+ }
/* Let the server know that we responded to this request. */
return OK;
}
<!-- END EXAMPLE CODE -->
<p>
-This version in its entirety can be found here:
+This version in its entirety can be found here:
<a href="http://people.apache.org/~humbedooh/mods/examples/mod_example_2.c">mod_example_2.c</a>.
</p>
</section>
<section id="configuration"><title>Adding configuration options</title>
<p>
-In this next segment of this document, we will turn our eyes away from the
-digest module and create a new example module, whose only function is to
-write out its own configuration. The purpose of this is to examine how
-the server works with configuration, and what happens when you start writing
-advanced configurations
+In this next segment of this document, we will turn our eyes away from the
+digest module and create a new example module, whose only function is to
+write out its own configuration. The purpose of this is to examine how
+the server works with configuration, and what happens when you start writing
+advanced configurations
for your modules.
</p>
-<section id="config_intro"><title>An introduction to configuration
+<section id="config_intro"><title>An introduction to configuration
directives</title>
<p>
-If you are reading this, then you probably already know
-what a configuration directive is. Simply put, a directive is a way of
-telling an individual module (or a set of modules) how to behave, such as
+If you are reading this, then you probably already know
+what a configuration directive is. Simply put, a directive is a way of
+telling an individual module (or a set of modules) how to behave, such as
these directives control how <code>mod_rewrite</code> works:
</p>
<highlight language="config">
RewriteRule "^/foo/bar/(.*)$" "/foobar?page=$1"
</highlight>
<p>
-Each of these configuration directives are handled by a separate function,
+Each of these configuration directives are handled by a separate function,
that parses the parameters given and sets up a configuration accordingly.
</p>
</section>
<!-- END EXAMPLE CODE -->
<p>
-Now, let's put this into perspective by creating a very small module that
-just prints out a hard-coded configuration. You'll notice that we use the
-<code>register_hooks</code> function for initializing the configuration
+Now, let's put this into perspective by creating a very small module that
+just prints out a hard-coded configuration. You'll notice that we use the
+<code>register_hooks</code> function for initializing the configuration
values to their defaults:
</p>
return OK;
}
-static void register_hooks(apr_pool_t *pool)
+static void register_hooks(apr_pool_t *pool)
{
config.enabled = 1;
config.path = "/foo/bar";
<!-- END EXAMPLE CODE -->
<p>
-So far so good. To access our new handler, we could add the following to
+So far so good. To access our new handler, we could add the following to
our configuration:
</p>
<highlight language="config">
</Location>
</highlight>
<p>
-When we visit, we'll see our current configuration being spit out by our
-module.
+When we visit, we'll see our current configuration being spit out by our
+module.
</p>
</section>
<section id="register_directive"><title>Registering directives with the server</title>
<p>
-What if we want to change our configuration, not by hard-coding new values
-into the module, but by using either the httpd.conf file or possibly a
-.htaccess file? It's time to let the server know that we want this to be
-possible. To do so, we must first change our <em>name tag</em> to include a
+What if we want to change our configuration, not by hard-coding new values
+into the module, but by using either the httpd.conf file or possibly a
+.htaccess file? It's time to let the server know that we want this to be
+possible. To do so, we must first change our <em>name tag</em> to include a
reference to the configuration directives we want to register with the server:
</p>
<!-- END EXAMPLE CODE -->
<p>
-This will tell the server that we are now accepting directives from the
+This will tell the server that we are now accepting directives from the
configuration files, and that the structure called <code>example_directives
-</code> holds information on what our directives are and how they work.
-Since we have three different variables in our module configuration, we
+</code> holds information on what our directives are and how they work.
+Since we have three different variables in our module configuration, we
will add a structure with three directives and a NULL at the end:
</p>
As you can see, each directive needs at least 5 parameters set:
</p>
<ol>
-<li><code><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__CONFIG.html#ga07c7d22ae17805e61204463326cf9c34">AP_INIT_TAKE1</a></code>: This is a macro that tells the server that this directive takes one and only one argument.
-If we required two arguments, we could use the macro <code><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__CONFIG.html#gafaec43534fcf200f37d9fecbf9247c21">AP_INIT_TAKE2</a></code> and so on (refer to httpd_conf.h
+<li><code><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__CONFIG.html#ga07c7d22ae17805e61204463326cf9c34">AP_INIT_TAKE1</a></code>: This is a macro that tells the server that this directive takes one and only one argument.
+If we required two arguments, we could use the macro <code><a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__CONFIG.html#gafaec43534fcf200f37d9fecbf9247c21">AP_INIT_TAKE2</a></code> and so on (refer to httpd_conf.h
for more macros).</li>
-<li><code>exampleEnabled</code>: This is the name of our directive. More precisely, it is what the user must put in his/her
+<li><code>exampleEnabled</code>: This is the name of our directive. More precisely, it is what the user must put in his/her
configuration in order to invoke a configuration change in our module.</li>
-<li><code>example_set_enabled</code>: This is a reference to a C function that parses the directive and sets the configuration
+<li><code>example_set_enabled</code>: This is a reference to a C function that parses the directive and sets the configuration
accordingly. We will discuss how to make this in the following paragraph.</li>
-<li><code>RSRC_CONF</code>: This tells the server where the directive is permitted. We'll go into details on this value in the
+<li><code>RSRC_CONF</code>: This tells the server where the directive is permitted. We'll go into details on this value in the
later chapters, but for now, <code>RSRC_CONF</code> means that the server will only accept these directives in a server context.</li>
<li><code>"Enable or disable...."</code>: This is simply a brief description of what the directive does.</li>
</ol>
<p>
-(<em>The "missing" parameter in our definition, which is usually set to
-<code>NULL</code>, is an optional function that can be run after the
-initial function to parse the arguments have been run. This is usually
-omitted, as the function for verifying arguments might as well be used to
+(<em>The "missing" parameter in our definition, which is usually set to
+<code>NULL</code>, is an optional function that can be run after the
+initial function to parse the arguments have been run. This is usually
+omitted, as the function for verifying arguments might as well be used to
set them.</em>)
</p>
</section>
<section id="directive_handler"><title>The directive handler function</title>
<p>
-Now that we have told the server to expect some directives for our module, it's
-time to make a few functions for handling these. What the server reads in the
-configuration file(s) is text, and so naturally, what it passes along to
-our directive handler is one or more strings, that we ourselves need to
+Now that we have told the server to expect some directives for our module, it's
+time to make a few functions for handling these. What the server reads in the
+configuration file(s) is text, and so naturally, what it passes along to
+our directive handler is one or more strings, that we ourselves need to
recognize and act upon. You'll notice, that since we set our <code>
-exampleAction</code> directive to accept two arguments, its C function also
-has an additional parameter defined:</p>
+exampleAction</code> directive to accept two arguments, its C function also
+has an additional parameter defined:</p>
<!-- BEGIN EXAMPLE CODE -->
<highlight language="c">
{
if(!strcasecmp(arg1, "file")) config.typeOfAction = 0x01;
else config.typeOfAction = 0x02;
-
+
if(!strcasecmp(arg2, "deny")) config.typeOfAction += 0x10;
else config.typeOfAction += 0x20;
return NULL;
</section>
<section id="directive_complete"><title>Putting it all together</title>
<p>
-Now that we have our directives set up, and handlers configured for them,
+Now that we have our directives set up, and handlers configured for them,
we can assemble our module into one big file:
</p>
{
if(!strcasecmp(arg1, "file")) config.typeOfAction = 0x01;
else config.typeOfAction = 0x02;
-
+
if(!strcasecmp(arg2, "deny")) config.typeOfAction += 0x10;
else config.typeOfAction += 0x20;
return NULL;
The hook registration function (also initializes the default config values):
==============================================================================
*/
-static void register_hooks(apr_pool_t *pool)
+static void register_hooks(apr_pool_t *pool)
{
config.enabled = 1;
config.path = "/foo/bar";
<p>
-In our httpd.conf file, we can now change the hard-coded configuration by
+In our httpd.conf file, we can now change the hard-coded configuration by
adding a few lines:
</p>
<highlight language="config">
ExampleAction file allow
</highlight>
<p>
-And thus we apply the configuration, visit <code>/example</code> on our
-web site, and we see the configuration has adapted to what we wrote in our
+And thus we apply the configuration, visit <code>/example</code> on our
+web site, and we see the configuration has adapted to what we wrote in our
configuration file.
</p>
</section>
<section id="context"><title>Context aware configurations</title>
<section id="context_intro"><title>Introduction to context aware configurations</title>
<p>
-In Apache HTTP Server 2.4, different URLs, virtual hosts, directories etc can have very
-different meanings to the user of the server, and thus different contexts
-within which modules must operate. For example, let's assume you have this
+In Apache HTTP Server 2.4, different URLs, virtual hosts, directories etc can have very
+different meanings to the user of the server, and thus different contexts
+within which modules must operate. For example, let's assume you have this
configuration set up for mod_rewrite:
</p>
<highlight language="config">
</Directory>
</highlight>
<p>
-In this example, you will have set up two different contexts for
+In this example, you will have set up two different contexts for
mod_rewrite:</p>
<ol>
<li>Inside <code>/var/www</code>, all requests for <code>http://example.com</code> must go to <code>http://www.example.com</code></li>
<li>Inside <code>/var/www/sub</code>, all requests for <code>foobar</code> must go to <code>index.php?foobar=true</code></li>
</ol>
<p>
-If mod_rewrite (or the entire server for that matter) wasn't context aware, then
-these rewrite rules would just apply to every and any request made,
-regardless of where and how they were made, but since the module can pull
-the context specific configuration straight from the server, it does not need
-to know itself, which of the directives are valid in this context, since
+If mod_rewrite (or the entire server for that matter) wasn't context aware, then
+these rewrite rules would just apply to every and any request made,
+regardless of where and how they were made, but since the module can pull
+the context specific configuration straight from the server, it does not need
+to know itself, which of the directives are valid in this context, since
the server takes care of this.</p>
<p>
-So how does a module get the specific configuration for the server,
+So how does a module get the specific configuration for the server,
directory or location in question? It does so by making one simple call:
</p>
<!-- END EXAMPLE CODE -->
<p>
-That's it! Of course, a whole lot goes on behind the scenes, which we will
-discuss in this chapter, starting with how the server came to know what our
-configuration looks like, and how it came to be set up as it is in the
+That's it! Of course, a whole lot goes on behind the scenes, which we will
+discuss in this chapter, starting with how the server came to know what our
+configuration looks like, and how it came to be set up as it is in the
specific context.
</p>
</section>
<section id="context_base"><title>Our basic configuration setup</title>
-<p>In this chapter, we will be working with a slightly modified version of
-our previous context structure. We will set a <code>context</code>
-variable that we can use to track which context configuration is being
+<p>In this chapter, we will be working with a slightly modified version of
+our previous context structure. We will set a <code>context</code>
+variable that we can use to track which context configuration is being
used by the server in various places:
</p>
<!-- BEGIN EXAMPLE CODE -->
<section id="context_which"><title>Choosing a context</title>
<p>
-Before we can start making our module context aware, we must first define,
-which contexts we will accept. As we saw in the previous chapter, defining
+Before we can start making our module context aware, we must first define,
+which contexts we will accept. As we saw in the previous chapter, defining
a directive required five elements be set:</p>
<!-- END EXAMPLE CODE -->
-<p>The <code>RSRC_CONF</code> definition told the server that we would only allow
-this directive in a global server context, but since we are now trying out
-a context aware version of our module, we should set this to something
-more lenient, namely the value <code>ACCESS_CONF</code>, which lets us use
-the directive inside <Directory> and <Location> blocks. For more
-control over the placement of your directives, you can combine the following
+<p>The <code>RSRC_CONF</code> definition told the server that we would only allow
+this directive in a global server context, but since we are now trying out
+a context aware version of our module, we should set this to something
+more lenient, namely the value <code>ACCESS_CONF</code>, which lets us use
+the directive inside <Directory> and <Location> blocks. For more
+control over the placement of your directives, you can combine the following
restrictions together to form a specific rule:
</p>
<ul>
</section>
<section id="context_pool"><title>Using the server to allocate configuration slots</title>
-<p> A much smarter way to manage your configurations is by letting the server
-help you create them. To do so, we must first start off by changing our
-<em>name tag</em> to let the server know, that it should assist us in creating
-and managing our configurations. Since we have chosen the per-directory
-(or per-location) context for our module configurations, we'll add a
+<p> A much smarter way to manage your configurations is by letting the server
+help you create them. To do so, we must first start off by changing our
+<em>name tag</em> to let the server know, that it should assist us in creating
+and managing our configurations. Since we have chosen the per-directory
+(or per-location) context for our module configurations, we'll add a
per-directory creator and merger function reference in our tag:</p>
<!-- BEGIN EXAMPLE CODE -->
<section id="context_new"><title>Creating new context configurations</title>
<p>
-Now that we have told the server to help us create and manage configurations,
-our first step is to make a function for creating new, blank
-configurations. We do so by creating the function we just referenced in
+Now that we have told the server to help us create and manage configurations,
+our first step is to make a function for creating new, blank
+configurations. We do so by creating the function we just referenced in
our name tag as the Per-directory configuration handler:</p>
<!-- BEGIN EXAMPLE CODE -->
<highlight language="c">
<section id="context_merge"><title>Merging configurations</title>
<p>
-Our next step in creating a context aware configuration is merging
-configurations. This part of the process particularly applies to scenarios
-where you have a parent configuration and a child, such as the following:
+Our next step in creating a context aware configuration is merging
+configurations. This part of the process particularly applies to scenarios
+where you have a parent configuration and a child, such as the following:
</p>
<highlight language="config">
<Directory "/var/www">
<p>
In this example, it is natural to assume that the directory <code>
/var/www/subdir</code> should inherit the values set for the <code>/var/www
-</code> directory, as we did not specify an <code>ExampleEnabled</code> nor
-an <code>ExamplePath</code> for this directory. The server does not presume to
+</code> directory, as we did not specify an <code>ExampleEnabled</code> nor
+an <code>ExamplePath</code> for this directory. The server does not presume to
know if this is true, but cleverly does the following:
</p>
<ol>
<li><strong>Proposes a merge</strong> of the two configurations into a new configuration for <code>/var/www/subdir</code></li>
</ol>
<p>
-This proposal is handled by the <code>merge_dir_conf</code> function we
-referenced in our name tag. The purpose of this function is to assess the
+This proposal is handled by the <code>merge_dir_conf</code> function we
+referenced in our name tag. The purpose of this function is to assess the
two configurations and decide how they are to be merged:</p>
example_config *base = (example_config *) BASE ; /* This is what was set in the parent context */
example_config *add = (example_config *) ADD ; /* This is what is set in the new context */
example_config *conf = (example_config *) create_dir_conf(pool, "Merged configuration"); /* This will be the merged configuration */
-
+
/* Merge configurations */
conf->enabled = ( add->enabled == 0 ) ? base->enabled : add->enabled ;
conf->typeOfAction = add->typeOfAction ? add->typeOfAction : base->typeOfAction;
strcpy(conf->path, strlen(add->path) ? add->path : base->path);
-
+
return conf ;
}
</highlight>
<section id="context_example"><title>Trying out our new context aware configurations</title>
<p>
-Now, let's try putting it all together to create a new module that is
-context aware. First off, we'll create a configuration that lets us test
+Now, let's try putting it all together to create a new module that is
+context aware. First off, we'll create a configuration that lets us test
how the module works:
</p>
<highlight language="config">
</Location>
</highlight>
<p>
-Then we'll assemble our module code. Note, that since we are now using our
-name tag as reference when fetching configurations in our handler, I have
+Then we'll assemble our module code. Note, that since we are now using our
+name tag as reference when fetching configurations in our handler, I have
added some prototypes to keep the compiler happy:
</p>
<section id="summary"><title>Summing up</title>
<p>
-We have now looked at how to create simple modules for Apache HTTP Server 2.4 and
-configuring them. What you do next is entirely up to you, but it is my
-hope that something valuable has come out of reading this documentation.
-If you have questions on how to further develop modules, you are welcome
-to join our <a href="http://httpd.apache.org/lists.html">mailing lists</a>
+We have now looked at how to create simple modules for Apache HTTP Server 2.4 and
+configuring them. What you do next is entirely up to you, but it is my
+hope that something valuable has come out of reading this documentation.
+If you have questions on how to further develop modules, you are welcome
+to join our <a href="http://httpd.apache.org/lists.html">mailing lists</a>
or check out the rest of our documentation for further tips.
</p>
</section>
return(rc);
}
-static int example_handler(request_rec *r)
+static int example_handler(request_rec *r)
{
/*~~~~~~~~~~~~~~~~*/
apr_off_t size;
version 2.2 to 2.4, that may be of interest to module/application
developers and core hacks. As of the first GA release of the
2.4 branch API compatibility is preserved for the life of the
- 2.4 branch. (The
+ 2.4 branch. (The
<a href="http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/VERSIONING">VERSIONING</a>
description for the 2.4 release provides more information about API
compatibility.)</p>
<li>New API to retain data across module unload/load</li>
<li>New <code>check_config</code> hook</li>
<li>New <code>ap_process_fnmatch_configs()</code> function to process wildcards</li>
- <li>Change <code>ap_configfile_t</code>, <code>ap_cfg_getline()</code>,
- <code>ap_cfg_getc()</code> to return error codes, and add
- <code>ap_pcfg_strerror()</code> for retrieving an error description.</li>
+ <li>Change <code>ap_configfile_t</code>, <code>ap_cfg_getline()</code>,
+ <code>ap_cfg_getc()</code> to return error codes, and add
+ <code>ap_pcfg_strerror()</code> for retrieving an error description.</li>
<li>Any config directive permitted in ACCESS_CONF context must now
correctly handle being called from an .htaccess file via the new
<code class="directive"><a href="../mod/core.html#allowoverridelist">AllowOverrideList</a></code> directive.
<h3><a name="http_core" id="http_core">http_core (changed)</a></h3>
<ul>
- <li>REMOVED <code>ap_default_type</code>, <code>ap_requires</code>, all
+ <li>REMOVED <code>ap_default_type</code>, <code>ap_requires</code>, all
2.2 authnz API</li>
<li>Introduces Optional Functions for logio and authnz</li>
<li>New function <code>ap_get_server_name_for_url</code> to support IPv6
<li>Support for mod_request kept_body</li>
<li>Support buffering filter data for async requests</li>
<li>New <code>CONN_STATE</code> values</li>
- <li>Function changes: <code>ap_escape_html</code> updated;
+ <li>Function changes: <code>ap_escape_html</code> updated;
<code>ap_unescape_all</code>, <code>ap_escape_path_segment_buffer</code></li>
<li>Modules that load other modules later than the <code>EXEC_ON_READ</code> config
reading stage need to call <code>ap_reserve_module_slots()</code> or
- <code>ap_reserve_module_slots_directive()</code> in their
+ <code>ap_reserve_module_slots_directive()</code> in their
<code>pre_config hook</code>.</li>
<li>The useragent IP address per request can now be tracked
independently of the client IP address of the connection, for
<li>New auth_internal API and auth_provider API</li>
<li>New <code>EOR</code> bucket type</li>
<li>New function <code>ap_process_async_request</code></li>
- <li>New flags <code>AP_AUTH_INTERNAL_PER_CONF</code> and
+ <li>New flags <code>AP_AUTH_INTERNAL_PER_CONF</code> and
<code>AP_AUTH_INTERNAL_PER_URI</code></li>
- <li>New <code>access_checker_ex</code> hook to apply additional access control
+ <li>New <code>access_checker_ex</code> hook to apply additional access control
and/or bypass authentication.</li>
- <li>New functions <code>ap_hook_check_access_ex</code>,
- <code>ap_hook_check_access</code>, <code>ap_hook_check_authn</code>,
- <code>ap_hook_check_authz</code> which accept
+ <li>New functions <code>ap_hook_check_access_ex</code>,
+ <code>ap_hook_check_access</code>, <code>ap_hook_check_authn</code>,
+ <code>ap_hook_check_authz</code> which accept
<code>AP_AUTH_INTERNAL_PER_*</code> flags</li>
- <li>DEPRECATED direct use of <code>ap_hook_access_checker</code>,
- <code>access_checker_ex</code>, <code>ap_hook_check_user_id</code>,
+ <li>DEPRECATED direct use of <code>ap_hook_access_checker</code>,
+ <code>access_checker_ex</code>, <code>ap_hook_check_user_id</code>,
<code>ap_hook_auth_checker</code></li>
</ul>
<p>When possible, registering all access control hooks (including
<p>If your module requires the old behavior and must perform access
control checks on every sub-request with a different URI from the
initial request, even if that URI matches the same set of access
- control configuration directives, then use
+ control configuration directives, then use
<code>AP_AUTH_INTERNAL_PER_URI</code>.</p>
<h3><a name="mod_cache" id="mod_cache">mod_cache (changed)</a></h3>
- <p>Introduces a <code>commit_entity()</code> function to the cache provider
+ <p>Introduces a <code>commit_entity()</code> function to the cache provider
interface, allowing atomic writes to cache. Add a <code>cache_status()</code>
hook to report the cache decision. All private structures and functions were
removed.</p>
<code>set_scoreboard</code> (locking uses the new ap_mutex API)</li>
<li>NEW API to drop privileges (delegates this platform-dependent
function to modules)</li>
- <li>NEW Hooks: <code>mpm_query</code>, <code>timed_callback</code>, and
+ <li>NEW Hooks: <code>mpm_query</code>, <code>timed_callback</code>, and
<code>get_name</code></li>
<li>CHANGED interfaces: <code>monitor</code> hook,
- <code>ap_reclaim_child_processes</code>,
+ <code>ap_reclaim_child_processes</code>,
<code>ap_relieve_child_processes</code></li>
</ul>
<dt><code>unixd_config</code></dt>
<dd>This has been renamed to ap_unixd_config.</dd>
- <dt><code>conn_rec->remote_ip</code> and
+ <dt><code>conn_rec->remote_ip</code> and
<code>conn_rec->remote_addr</code></dt>
- <dd>These fields have been renamed in order to distinguish between
+ <dd>These fields have been renamed in order to distinguish between
the client IP address of the connection and the useragent IP address
of the request (potentially overridden by a load balancer or proxy).
References to either of these fields must be updated with one of the
<li>When you require the IP address of the client that is
connected directly to the server, which might be the useragent or
might be the load balancer or proxy itself, use
- <code>conn_rec->client_ip</code> and
+ <code>conn_rec->client_ip</code> and
<code>conn_rec->client_addr</code>.</li>
</ul>
</dd>
version 2.2 to 2.4, that may be of interest to module/application
developers and core hacks. As of the first GA release of the
2.4 branch API compatibility is preserved for the life of the
- 2.4 branch. (The
+ 2.4 branch. (The
<a href="http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/VERSIONING">VERSIONING</a>
description for the 2.4 release provides more information about API
compatibility.)</p>
<li>New API to retain data across module unload/load</li>
<li>New <code>check_config</code> hook</li>
<li>New <code>ap_process_fnmatch_configs()</code> function to process wildcards</li>
- <li>Change <code>ap_configfile_t</code>, <code>ap_cfg_getline()</code>,
- <code>ap_cfg_getc()</code> to return error codes, and add
- <code>ap_pcfg_strerror()</code> for retrieving an error description.</li>
+ <li>Change <code>ap_configfile_t</code>, <code>ap_cfg_getline()</code>,
+ <code>ap_cfg_getc()</code> to return error codes, and add
+ <code>ap_pcfg_strerror()</code> for retrieving an error description.</li>
<li>Any config directive permitted in ACCESS_CONF context must now
correctly handle being called from an .htaccess file via the new
<directive module="core">AllowOverrideList</directive> directive.
<section id="http_core">
<title>http_core (changed)</title>
<ul>
- <li>REMOVED <code>ap_default_type</code>, <code>ap_requires</code>, all
+ <li>REMOVED <code>ap_default_type</code>, <code>ap_requires</code>, all
2.2 authnz API</li>
<li>Introduces Optional Functions for logio and authnz</li>
<li>New function <code>ap_get_server_name_for_url</code> to support IPv6
<li>Support for mod_request kept_body</li>
<li>Support buffering filter data for async requests</li>
<li>New <code>CONN_STATE</code> values</li>
- <li>Function changes: <code>ap_escape_html</code> updated;
+ <li>Function changes: <code>ap_escape_html</code> updated;
<code>ap_unescape_all</code>, <code>ap_escape_path_segment_buffer</code></li>
<li>Modules that load other modules later than the <code>EXEC_ON_READ</code> config
reading stage need to call <code>ap_reserve_module_slots()</code> or
- <code>ap_reserve_module_slots_directive()</code> in their
+ <code>ap_reserve_module_slots_directive()</code> in their
<code>pre_config hook</code>.</li>
<li>The useragent IP address per request can now be tracked
independently of the client IP address of the connection, for
<li>New auth_internal API and auth_provider API</li>
<li>New <code>EOR</code> bucket type</li>
<li>New function <code>ap_process_async_request</code></li>
- <li>New flags <code>AP_AUTH_INTERNAL_PER_CONF</code> and
+ <li>New flags <code>AP_AUTH_INTERNAL_PER_CONF</code> and
<code>AP_AUTH_INTERNAL_PER_URI</code></li>
- <li>New <code>access_checker_ex</code> hook to apply additional access control
+ <li>New <code>access_checker_ex</code> hook to apply additional access control
and/or bypass authentication.</li>
- <li>New functions <code>ap_hook_check_access_ex</code>,
- <code>ap_hook_check_access</code>, <code>ap_hook_check_authn</code>,
- <code>ap_hook_check_authz</code> which accept
+ <li>New functions <code>ap_hook_check_access_ex</code>,
+ <code>ap_hook_check_access</code>, <code>ap_hook_check_authn</code>,
+ <code>ap_hook_check_authz</code> which accept
<code>AP_AUTH_INTERNAL_PER_*</code> flags</li>
- <li>DEPRECATED direct use of <code>ap_hook_access_checker</code>,
- <code>access_checker_ex</code>, <code>ap_hook_check_user_id</code>,
+ <li>DEPRECATED direct use of <code>ap_hook_access_checker</code>,
+ <code>access_checker_ex</code>, <code>ap_hook_check_user_id</code>,
<code>ap_hook_auth_checker</code></li>
</ul>
<p>When possible, registering all access control hooks (including
<p>If your module requires the old behavior and must perform access
control checks on every sub-request with a different URI from the
initial request, even if that URI matches the same set of access
- control configuration directives, then use
+ control configuration directives, then use
<code>AP_AUTH_INTERNAL_PER_URI</code>.</p>
</section>
<section id="mod_cache">
<title>mod_cache (changed)</title>
- <p>Introduces a <code>commit_entity()</code> function to the cache provider
+ <p>Introduces a <code>commit_entity()</code> function to the cache provider
interface, allowing atomic writes to cache. Add a <code>cache_status()</code>
hook to report the cache decision. All private structures and functions were
removed.</p>
<code>set_scoreboard</code> (locking uses the new ap_mutex API)</li>
<li>NEW API to drop privileges (delegates this platform-dependent
function to modules)</li>
- <li>NEW Hooks: <code>mpm_query</code>, <code>timed_callback</code>, and
+ <li>NEW Hooks: <code>mpm_query</code>, <code>timed_callback</code>, and
<code>get_name</code></li>
<li>CHANGED interfaces: <code>monitor</code> hook,
- <code>ap_reclaim_child_processes</code>,
+ <code>ap_reclaim_child_processes</code>,
<code>ap_relieve_child_processes</code></li>
</ul>
</section>
<dt><code>unixd_config</code></dt>
<dd>This has been renamed to ap_unixd_config.</dd>
- <dt><code>conn_rec->remote_ip</code> and
+ <dt><code>conn_rec->remote_ip</code> and
<code>conn_rec->remote_addr</code></dt>
- <dd>These fields have been renamed in order to distinguish between
+ <dd>These fields have been renamed in order to distinguish between
the client IP address of the connection and the useragent IP address
of the request (potentially overridden by a load balancer or proxy).
References to either of these fields must be updated with one of the
<li>When you require the IP address of the client that is
connected directly to the server, which might be the useragent or
might be the load balancer or proxy itself, use
- <code>conn_rec->client_ip</code> and
+ <code>conn_rec->client_ip</code> and
<code>conn_rec->client_addr</code>.</li>
</ul>
</dd>
{
struct dummy_state *state;
-
+
state = f->ctx;
if (state == NULL) {
-
+
/* First invocation for this response: initialise state structure.
*/
f->ctx = state = apr_palloc(f->r->pool, sizeof *state);
{
struct dummy_state *state;
-
+
state = f->ctx;
if (state == NULL) {
-
+
/* First invocation for this response: initialise state structure.
*/
f->ctx = state = apr_palloc(f->r->pool, sizeof *state);
<p>The first major change is to the subrequest and redirect
mechanisms. There were a number of different code paths in
- the Apache HTTP Server 1.3 to attempt to optimize subrequest
+ the Apache HTTP Server 1.3 to attempt to optimize subrequest
or redirect behavior. As patches were introduced to 2.0, these
optimizations (and the server behavior) were quickly broken due
to this duplication of code. All duplicate code has been folded
<p>The first major change is to the subrequest and redirect
mechanisms. There were a number of different code paths in
- the Apache HTTP Server 1.3 to attempt to optimize subrequest
+ the Apache HTTP Server 1.3 to attempt to optimize subrequest
or redirect behavior. As patches were introduced to 2.0, these
optimizations (and the server behavior) were quickly broken due
to this duplication of code. All duplicate code has been folded
</section>
</section>
</manualpage>
-
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
-<!-- English Revision: 659902:1673892 (outdated) -->
+<!-- English Revision: 659902:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
-<!-- English Revision: 105989:1673892 (outdated) -->
+<!-- English Revision: 105989:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>
-<!-- English Revision: 1300910:1673892 (outdated) -->
+<!-- English Revision: 1300910:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
-<!-- English Revision: 1663123:1673908 (outdated) -->
+<!-- English Revision: 1663123:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<dt><a name="subrequest" id="subrequest">Subrequest</a></dt>
<dd>Apache provides a subrequest API to modules that allows other
filesystem or URL paths to be partially or fully evaluated by
- the server. Example consumers of this API are
- <code class="directive"><a href="./mod/mod_dir.html#directoryindex">DirectoryIndex</a></code>,
+ the server. Example consumers of this API are
+ <code class="directive"><a href="./mod/mod_dir.html#directoryindex">DirectoryIndex</a></code>,
<code class="module"><a href="./mod/mod_autoindex.html">mod_autoindex</a></code>, and <code class="module"><a href="./mod/mod_include.html">mod_include</a></code>.
</dd>
<dt><a name="subrequest" id="subrequest">Subrequest</a></dt>
<dd>Apache provides a subrequest API to modules that allows other
filesystem or URL paths to be partially or fully evaluated by
- the server. Example consumers of this API are
- <directive module="mod_dir">DirectoryIndex</directive>,
+ the server. Example consumers of this API are
+ <directive module="mod_dir">DirectoryIndex</directive>,
<module>mod_autoindex</module>, and <module>mod_include</module>.
</dd>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.es.xsl"?>
-<!-- English Revision: 151408:1673892 (outdated) -->
+<!-- English Revision: 151408:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1330883:1673892 (outdated) -->
+<!-- English Revision: 1330883:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
-<!-- English Revision: 1330883:1673892 (outdated) -->
+<!-- English Revision: 1330883:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
-<!-- English Revision: 151408:1673892 (outdated) -->
+<!-- English Revision: 151408:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>
-<!-- English Revision: 1174747:1673892 (outdated) -->
+<!-- English Revision: 1174747:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.zh-cn.xsl"?>
-<!-- English Revision: 420990:1673892 (outdated) -->
+<!-- English Revision: 420990:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
-<!-- English Revision: 1666025:1673932 (outdated) -->
+<!-- English Revision: 1666025:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1336196:1673917 (outdated) -->
+<!-- English Revision: 1336196:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 545841:1673917 (outdated) -->
+<!-- English Revision: 545841:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version='1.0' encoding='EUC-KR' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 105989:1673917 (outdated) -->
+<!-- English Revision: 105989:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
it is nonempty.) For a full list of the comparison operators
available to you, see the <code class="module"><a href="../mod/mod_include.html">mod_include</a></code>
documentation.</p>
-
+
<p>For example, if you wish to customize the text on your web page
based on the time of day, you could use the following recipe, placed
in the HTML page:</p>
it is nonempty.) For a full list of the comparison operators
available to you, see the <module>mod_include</module>
documentation.</p>
-
+
<p>For example, if you wish to customize the text on your web page
based on the time of day, you could use the following recipe, placed
in the HTML page:</p>
(be sure the directory names do not have version numbers; for example,
the APR distribution must be under ./srclib/apr/) and use
<code>./configure</code>'s <code>--with-included-apr</code>
- option. On some platforms, you may have to install the
- corresponding <code>-dev</code> packages to allow httpd to build
+ option. On some platforms, you may have to install the
+ corresponding <code>-dev</code> packages to allow httpd to build
against your installed copy of APR and APR-Util.</dd>
<dt>Perl-Compatible Regular Expressions Library (PCRE)</dt>
- <dd>This library is required but not longer bundled with httpd.
- Download the source code from <a href="http://www.pcre.org/">http://www.pcre.org</a>,
+ <dd>This library is required but not longer bundled with httpd.
+ Download the source code from <a href="http://www.pcre.org/">http://www.pcre.org</a>,
or install a Port or Package. If your build system can't find
the pcre-config script installed by the PCRE build, point to it
- using the <code>--with-pcre</code> parameter. On some platforms,
- you may have to install the corresponding <code>-dev</code>
- package to allow httpd to build against your installed copy
+ using the <code>--with-pcre</code> parameter. On some platforms,
+ you may have to install the corresponding <code>-dev</code>
+ package to allow httpd to build against your installed copy
of PCRE.</dd>
-
+
<dt>Disk Space</dt>
<dd>Make sure you have at least 50 MB of temporary free disk
space available. After installation the server occupies
on Unix and Unix-like systems only. For compiling and
installation on Windows, see <a
href="platform/windows.html">Using Apache HTTP Server with Microsoft
- Windows</a> and <a
+ Windows</a> and <a
href="platform/win_compiling.html">Compiling Apache for Microsoft Windows</a>.
For other platforms, see the <a
href="platform/">platform</a> documentation.</p>
(be sure the directory names do not have version numbers; for example,
the APR distribution must be under ./srclib/apr/) and use
<code>./configure</code>'s <code>--with-included-apr</code>
- option. On some platforms, you may have to install the
- corresponding <code>-dev</code> packages to allow httpd to build
+ option. On some platforms, you may have to install the
+ corresponding <code>-dev</code> packages to allow httpd to build
against your installed copy of APR and APR-Util.</dd>
<dt>Perl-Compatible Regular Expressions Library (PCRE)</dt>
- <dd>This library is required but not longer bundled with httpd.
- Download the source code from <a href="http://www.pcre.org/">http://www.pcre.org</a>,
+ <dd>This library is required but not longer bundled with httpd.
+ Download the source code from <a href="http://www.pcre.org/">http://www.pcre.org</a>,
or install a Port or Package. If your build system can't find
the pcre-config script installed by the PCRE build, point to it
- using the <code>--with-pcre</code> parameter. On some platforms,
- you may have to install the corresponding <code>-dev</code>
- package to allow httpd to build against your installed copy
+ using the <code>--with-pcre</code> parameter. On some platforms,
+ you may have to install the corresponding <code>-dev</code>
+ package to allow httpd to build against your installed copy
of PCRE.</dd>
-
+
<dt>Disk Space</dt>
<dd>Make sure you have at least 50 MB of temporary free disk
space available. After installation the server occupies
<dt><a href="mod_version.html" id="V" name="V">mod_version</a></dt><dd>Version dependent configuration</dd>
<dt><a href="mod_vhost_alias.html">mod_vhost_alias</a></dt><dd>Provides for dynamically configured mass virtual
hosting</dd>
-<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
+<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
tasks</dd>
<dt><a href="mod_xml2enc.html" id="X" name="X">mod_xml2enc</a></dt><dd>Enhanced charset/internationalisation support for libxml2-based
filter modules</dd>
<dt><a href="mod_version.html" id="V" name="V">mod_version</a></dt><dd>Version dependent configuration</dd>
<dt><a href="mod_vhost_alias.html">mod_vhost_alias</a></dt><dd>Provides for dynamically configured mass virtual
hosting</dd>
-<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
+<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
tasks</dd>
<dt><a href="mod_xml2enc.html" id="X" name="X">mod_xml2enc</a></dt><dd>Enhanced charset/internationalisation support for libxml2-based
filter modules</dd>
<dt><a href="mod_version.html" id="V" name="V">mod_version</a></dt><dd>Version dependent configuration</dd>
<dt><a href="mod_vhost_alias.html">mod_vhost_alias</a></dt><dd>Provides for dynamically configured mass virtual
hosting</dd>
-<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
+<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
tasks</dd>
<dt><a href="mod_xml2enc.html" id="X" name="X">mod_xml2enc</a></dt><dd>Enhanced charset/internationalisation support for libxml2-based
filter modules</dd>
<dt><a href="mod_version.html" id="V" name="V">mod_version</a></dt><dd>Version dependent configuration</dd>
<dt><a href="mod_vhost_alias.html">mod_vhost_alias</a></dt><dd>Provides for dynamically configured mass virtual
hosting</dd>
-<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
+<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
tasks</dd>
<dt><a href="mod_xml2enc.html" id="X" name="X">mod_xml2enc</a></dt><dd>Enhanced charset/internationalisation support for libxml2-based
filter modules</dd>
<dt><a href="mod_version.html" id="V" name="V">mod_version</a></dt><dd>バージョン依存の設定</dd>
<dt><a href="mod_vhost_alias.html">mod_vhost_alias</a></dt><dd>Provides for dynamically configured mass virtual
hosting</dd>
-<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
+<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
tasks</dd>
<dt><a href="mod_xml2enc.html" id="X" name="X">mod_xml2enc</a></dt><dd>Enhanced charset/internationalisation support for libxml2-based
filter modules</dd>
<dt><a href="mod_version.html" id="V" name="V">mod_version</a></dt><dd>¹öÀüº° ¼³Á¤</dd>
<dt><a href="mod_vhost_alias.html">mod_vhost_alias</a></dt><dd>Provides for dynamically configured mass virtual
hosting</dd>
-<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
+<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
tasks</dd>
<dt><a href="mod_xml2enc.html" id="X" name="X">mod_xml2enc</a></dt><dd>Enhanced charset/internationalisation support for libxml2-based
filter modules</dd>
</dd>
<dt><a href="mod_version.html" id="V" name="V">mod_version</a></dt><dd>Version dependent configuration</dd>
<dt><a href="mod_vhost_alias.html">mod_vhost_alias</a></dt><dd>Kitlesel sanal konakların devingen olarak yapılandırılmasını sağlar</dd>
-<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
+<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
tasks</dd>
<dt><a href="mod_xml2enc.html" id="X" name="X">mod_xml2enc</a></dt><dd>Enhanced charset/internationalisation support for libxml2-based
filter modules</dd>
<dt><a href="mod_version.html" id="V" name="V">mod_version</a></dt><dd>Version dependent configuration</dd>
<dt><a href="mod_vhost_alias.html">mod_vhost_alias</a></dt><dd>Provides for dynamically configured mass virtual
hosting</dd>
-<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
+<dt><a href="mod_watchdog.html" id="W" name="W">mod_watchdog</a></dt><dd>provides infrastructure for other modules to periodically run
tasks</dd>
<dt><a href="mod_xml2enc.html" id="X" name="X">mod_xml2enc</a></dt><dd>Enhanced charset/internationalisation support for libxml2-based
filter modules</dd>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1421821:1673892 (outdated) -->
+<!-- English Revision: 1421821:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 675568:1673892 (outdated) -->
+<!-- English Revision: 675568:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1653941:1673908 (outdated) -->
+<!-- English Revision: 1653941:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 151408:1673908 (outdated) -->
+<!-- English Revision: 151408:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 151408:1673908 (outdated) -->
+<!-- English Revision: 151408:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1174747:1673908 (outdated) -->
+<!-- English Revision: 1174747:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1330911:1673892 (outdated) -->
+<!-- English Revision: 1330911:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
AuthType Digest
AuthName "private area"
AuthDigestDomain "/private/" "http://mirror.my.dom/private2/"
-
+
AuthDigestProvider file
AuthUserFile "/web/auth/.digest_pw"
Require valid-user
AuthType Digest
AuthName "private area"
AuthDigestDomain "/private/" "http://mirror.my.dom/private2/"
-
+
AuthDigestProvider file
AuthUserFile "/web/auth/.digest_pw"
Require valid-user
AuthType Basic
AuthBasicProvider file anon
AuthUserFile "/path/to/your/.htpasswd"
-
+
Anonymous_NoUserID off
Anonymous_MustGiveEmail on
Anonymous_VerifyEmail on
Anonymous_LogEmail on
Anonymous anonymous guest www test welcome
-
+
Require valid-user
</Directory></pre>
</div>
AuthType Basic
AuthBasicProvider file anon
AuthUserFile "/path/to/your/.htpasswd"
-
+
Anonymous_NoUserID off
Anonymous_MustGiveEmail on
Anonymous_VerifyEmail on
Anonymous_LogEmail on
Anonymous anonymous guest www test welcome
-
+
Require valid-user
</Directory>
</highlight>
</AuthnProviderAlias>
# Then check here
-<AuthnProviderAlias file file2>
+<AuthnProviderAlias file file2>
AuthUserFile "/www/conf/passwords2"
</AuthnProviderAlias>
<Directory "/var/web/pages/secure">
AuthBasicProvider file1 file2
-
+
AuthType Basic
AuthName "Protected Area"
Require valid-user
<Directory "/webpages/secure">
Order deny,allow
Allow from all
-
+
AuthBasicProvider ldap-other-alias ldap-alias1
-
+
AuthType Basic
AuthName "LDAP Protected Place"
Require valid-user
- # Note that Require ldap-* would not work here, since the
+ # Note that Require ldap-* would not work here, since the
# AuthnProviderAlias does not provide the config to authorization providers
# that are implemented in the same module as the authentication provider.
</Directory></pre>
</AuthnProviderAlias>
# Then check here
-<AuthnProviderAlias file file2>
+<AuthnProviderAlias file file2>
AuthUserFile "/www/conf/passwords2"
</AuthnProviderAlias>
<Directory "/var/web/pages/secure">
AuthBasicProvider file1 file2
-
+
AuthType Basic
AuthName "Protected Area"
Require valid-user
<Directory "/webpages/secure">
Order deny,allow
Allow from all
-
+
AuthBasicProvider ldap-other-alias ldap-alias1
-
+
AuthType Basic
AuthName "LDAP Protected Place"
Require valid-user
- # Note that Require ldap-* would not work here, since the
+ # Note that Require ldap-* would not work here, since the
# AuthnProviderAlias does not provide the config to authorization providers
# that are implemented in the same module as the authentication provider.
</Directory>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1659902:1673892 (outdated) -->
+<!-- English Revision: 1659902:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
with <code>KnockKnock/2.0</code> will be allowed access, and all
others will be denied.</p>
- <p>When the server looks up a path via an internal
- <a class="glossarylink" href="../glossary.html#subrequest" title="see glossary">subrequest</a> such as looking
- for a <code class="directive"><a href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a></code>
+ <p>When the server looks up a path via an internal
+ <a class="glossarylink" href="../glossary.html#subrequest" title="see glossary">subrequest</a> such as looking
+ for a <code class="directive"><a href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a></code>
or generating a directory listing with <code class="module"><a href="../mod/mod_autoindex.html">mod_autoindex</a></code>,
- per-request environment variables are <em>not</em> inherited in the
- subrequest. Additionally,
+ per-request environment variables are <em>not</em> inherited in the
+ subrequest. Additionally,
<code class="directive"><a href="../mod/mod_setenvif.html#setenvif">SetEnvIf</a></code> directives
are not separately evaluated in the subrequest due to the API phases
<code class="module"><a href="../mod/mod_setenvif.html">mod_setenvif</a></code> takes action in.</p>
<pre class="prettyprint lang-config"><RequireAll>
Require expr "!(%{QUERY_STRING} =~ /secret/)"
- Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
+ Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
</RequireAll></pre>
with <code>KnockKnock/2.0</code> will be allowed access, and all
others will be denied.</p>
- <p>When the server looks up a path via an internal
- <glossary ref="subrequest">subrequest</glossary> such as looking
- for a <directive module="mod_dir" >DirectoryIndex</directive>
+ <p>When the server looks up a path via an internal
+ <glossary ref="subrequest">subrequest</glossary> such as looking
+ for a <directive module="mod_dir" >DirectoryIndex</directive>
or generating a directory listing with <module>mod_autoindex</module>,
- per-request environment variables are <em>not</em> inherited in the
- subrequest. Additionally,
+ per-request environment variables are <em>not</em> inherited in the
+ subrequest. Additionally,
<directive module="mod_setenvif">SetEnvIf</directive> directives
are not separately evaluated in the subrequest due to the API phases
<module>mod_setenvif</module> takes action in.</p>
<highlight language="config">
<RequireAll>
Require expr "!(%{QUERY_STRING} =~ /secret/)"
- Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
+ Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
</RequireAll>
</highlight>
<highlight language="config">
- Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
+ Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
</highlight>
<p>The syntax is described in the <a href="../expr.html">ap_expr</a>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1598137:1673892 (outdated) -->
+<!-- English Revision: 1598137:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 689261:1673892 (outdated) -->
+<!-- English Revision: 689261:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 103423:1673892 (outdated) -->
+<!-- English Revision: 103423:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1303788:1673892 (outdated) -->
+<!-- English Revision: 1303788:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1590566:1673892 (outdated) -->
+<!-- English Revision: 1590566:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 504183:1673892 (outdated) -->
+<!-- English Revision: 504183:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 105569:1673892 (outdated) -->
+<!-- English Revision: 105569:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>The length of time to wait for more output from the
CGI program</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>CGIDScriptTimeout <var>time</var>[s|ms]</code></td></tr>
-<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>value of <code class="directive"><a href="../mod/core.html#timeout">Timeout</a></code> directive when
+<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>value of <code class="directive"><a href="../mod/core.html#timeout">Timeout</a></code> directive when
unset</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#Status">Status:</a></th><td>Base</td></tr>
</td></tr>
</table>
<p>This directive limits the length of time to wait for more output from
- the CGI program. If the time is exceeded, the request and CGI are
+ the CGI program. If the time is exceeded, the request and CGI are
terminated.</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">CGIDScriptTimeout 20</pre>
write in the directory where the socket is located.</p>
<p>If <var>file-path</var> is not an absolute path, the location specified
- will be relative to the value of
+ will be relative to the value of
<code class="directive"><a href="../mod/core.html#defaultruntimedir">DefaultRuntimeDir</a></code>.</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">ScriptSock /var/run/cgid.sock</pre>
<tr><th><a href="directive-dict.html#Description">説明:</a></th><td>The length of time to wait for more output from the
CGI program</td></tr>
<tr><th><a href="directive-dict.html#Syntax">構文:</a></th><td><code>CGIDScriptTimeout <var>time</var>[s|ms]</code></td></tr>
-<tr><th><a href="directive-dict.html#Default">デフォルト:</a></th><td><code>value of <code class="directive"><a href="../mod/core.html#timeout">Timeout</a></code> directive when
+<tr><th><a href="directive-dict.html#Default">デフォルト:</a></th><td><code>value of <code class="directive"><a href="../mod/core.html#timeout">Timeout</a></code> directive when
unset</code></td></tr>
<tr><th><a href="directive-dict.html#Context">コンテキスト:</a></th><td>サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess</td></tr>
<tr><th><a href="directive-dict.html#Status">ステータス:</a></th><td>Base</td></tr>
<tr><th><a href="directive-dict.html#Description">¼³¸í:</a></th><td>The length of time to wait for more output from the
CGI program</td></tr>
<tr><th><a href="directive-dict.html#Syntax">¹®¹ý:</a></th><td><code>CGIDScriptTimeout <var>time</var>[s|ms]</code></td></tr>
-<tr><th><a href="directive-dict.html#Default">±âº»°ª:</a></th><td><code>value of <code class="directive"><a href="../mod/core.html#timeout">Timeout</a></code> directive when
+<tr><th><a href="directive-dict.html#Default">±âº»°ª:</a></th><td><code>value of <code class="directive"><a href="../mod/core.html#timeout">Timeout</a></code> directive when
unset</code></td></tr>
<tr><th><a href="directive-dict.html#Context">»ç¿ëÀå¼Ò:</a></th><td>ÁÖ¼¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess</td></tr>
<tr><th><a href="directive-dict.html#Status">»óÅÂ:</a></th><td>Base</td></tr>
write in the directory where the socket is located.</p>
<p>If <var>file-path</var> is not an absolute path, the location specified
- will be relative to the value of
+ will be relative to the value of
<directive module="core">DefaultRuntimeDir</directive>.</p>
<example><title>Example</title>
<description>The length of time to wait for more output from the
CGI program</description>
<syntax>CGIDScriptTimeout <var>time</var>[s|ms]</syntax>
-<default>value of <directive module="core">Timeout</directive> directive when
+<default>value of <directive module="core">Timeout</directive> directive when
unset</default>
<contextlist><context>server config</context>
<context>virtual host</context><context>directory</context>
<usage>
<p>This directive limits the length of time to wait for more output from
- the CGI program. If the time is exceeded, the request and CGI are
+ the CGI program. If the time is exceeded, the request and CGI are
terminated.</p>
<example><title>Example</title>
</directivesynopsis>
</modulesynopsis>
-
<p>It is up to dbd user modules to use the prepared statements
and document what statements can be specified in httpd.conf,
or to provide their own directives and use <code>ap_dbd_prepare</code>.</p>
-
+
<div class="warning"><h3>Caveat</h3>
When using prepared statements with a MySQL database, it is preferred to set
<code>reconnect</code> to 0 in the connection string as to avoid errors that
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_dbd</td></tr>
</table>
- <p>Modules, that wish it, can have one or more SQL statements
- executed when a connection to a database is created. Example
- usage could be initializing certain values or adding a log
+ <p>Modules, that wish it, can have one or more SQL statements
+ executed when a connection to a database is created. Example
+ usage could be initializing certain values or adding a log
entry when a new connection is made to the database.</p>
</div>
<p>It is up to dbd user modules to use the prepared statements
and document what statements can be specified in httpd.conf,
or to provide their own directives and use <code>ap_dbd_prepare</code>.</p>
-
+
<note type="warning"><title>Caveat</title>
When using prepared statements with a MySQL database, it is preferred to set
<code>reconnect</code> to 0 in the connection string as to avoid errors that
</contextlist>
<usage>
- <p>Modules, that wish it, can have one or more SQL statements
- executed when a connection to a database is created. Example
- usage could be initializing certain values or adding a log
+ <p>Modules, that wish it, can have one or more SQL statements
+ executed when a connection to a database is created. Example
+ usage could be initializing certain values or adding a log
entry when a new connection is made to the database.</p>
</usage>
</directivesynopsis>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1655917:1673930 (outdated) -->
+<!-- English Revision: 1655917:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 420990:1673930 (outdated) -->
+<!-- English Revision: 420990:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 151408:1673930 (outdated) -->
+<!-- English Revision: 151408:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1330980:1673892 (outdated) -->
+<!-- English Revision: 1330980:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1586471:1673892 (outdated) -->
+<!-- English Revision: 1586471:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 420990:1673892 (outdated) -->
+<!-- English Revision: 420990:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 151408:1673892 (outdated) -->
+<!-- English Revision: 151408:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1307726:1673892 (outdated) -->
+<!-- English Revision: 1307726:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SetEnv SPECIAL_PATH /foo/bin</pre>
</div>
-
+
<p> If you omit the <var>value</var> argument, the variable is set to
an empty string.</p>
SetEnv SPECIAL_PATH /foo/bin
</highlight>
</example>
-
+
<p> If you omit the <var>value</var> argument, the variable is set to
an empty string.</p>
</directivesynopsis>
</modulesynopsis>
-
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1669200:1673892 (outdated) -->
+<!-- English Revision: 1669200:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 420990:1673892 (outdated) -->
+<!-- English Revision: 420990:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 105989:1673892 (outdated) -->
+<!-- English Revision: 105989:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<p>To enable the module, it should be compiled and loaded
in to your running Apache configuration, and the directives below
used to record the data you are interested in.</p>
-
+
<p>It is possible to record both incoming and outgoing data to
the same filename if desired, as the direction of flow is recorded
within each fragment.</p>
<p>The server typically serves multiple connections simultaneously,
and as a result requests and responses need to be multiplexed before
being written to the firehose.</p>
-
+
<p>The fragment format is designed as clear text, so that a firehose
can be opened with and inspected by a normal text editor.
Alternatively, the <code class="program"><a href="../programs/firehose.html">firehose</a></code> tool can be used to
<p>To enable the module, it should be compiled and loaded
in to your running Apache configuration, and the directives below
used to record the data you are interested in.</p>
-
+
<p>It is possible to record both incoming and outgoing data to
the same filename if desired, as the direction of flow is recorded
within each fragment.</p>
<p>The server typically serves multiple connections simultaneously,
and as a result requests and responses need to be multiplexed before
being written to the firehose.</p>
-
+
<p>The fragment format is designed as clear text, so that a firehose
can be opened with and inspected by a normal text editor.
Alternatively, the <program>firehose</program> tool can be used to
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>FileInfo</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_headers</td></tr>
-<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>SetIfEmpty available in 2.4.7 and later, expr=value
+<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>SetIfEmpty available in 2.4.7 and later, expr=value
available in 2.4.10 and later</td></tr>
</table>
<p>This directive can replace, merge or remove HTTP response
<p> The optional <var>condition</var> argument determines which internal
table of responses headers this directive will operate against. Despite the
- name, the default value of <code>onsuccess</code> does <em>not</em> limit
+ name, the default value of <code>onsuccess</code> does <em>not</em> limit
an <var>action</var> to responses with a 2xx status code. Headers set under
this condition are still used when, for example, a request is <em>successfully</em>
proxied or generated by CGI, even when they have generated a failing status code.</p>
<p>When your action is a function of an existing header, you may need to specify
a condition of <code>always</code>, depending on which internal table the
original header was set in. The table that corresponds to <code>always</code> is
- used for locally generated error responses as well as successful responses.
+ used for locally generated error responses as well as successful responses.
Note also that repeating this directive with both conditions makes sense in
some scenarios because <code>always</code> is not a superset of
<code>onsuccess</code> with respect to existing headers:</p>
<code>onsuccess</code> condition.</li>
</ul>
- <p>Separately from the <var>condition</var> parameter described above, you
- can limit an action based on HTTP status codes for e.g. proxied or CGI
+ <p>Separately from the <var>condition</var> parameter described above, you
+ can limit an action based on HTTP status codes for e.g. proxied or CGI
requests. See the example that uses %{REQUEST_STATUS} in the section above.</p>
<p>The action it performs is determined by the first
<code>add</code> a <var>value</var> is specified as the next argument.
If <var>value</var>
contains spaces, it should be surrounded by double quotes.
- <var>value</var> may be a character string, a string containing
- <code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> specific format specifiers (and character
+ <var>value</var> may be a character string, a string containing
+ <code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> specific format specifiers (and character
literals), or an <a href="../expr.html">ap_expr</a> expression prefixed
with <em>expr=</em></p>
-
+
<p> The following format specifiers are supported in <var>value</var>:</p>
<table class="bordered"><tr class="header"><th>Format</th><th>Description</th></tr>
<em>boolean</em> expressions such as <If>:</p>
<ul>
<li>The starting point of the grammar is 'string' rather than 'expr'.</li>
- <li>Function calls use the %{funcname:arg} syntax rather than
+ <li>Function calls use the %{funcname:arg} syntax rather than
funcname(arg).</li>
<li>Multi-argument functions are not currently accessible from this
starting point</li>
- <li>Quote the entire parameter, such as
+ <li>Quote the entire parameter, such as
<pre class="prettyprint lang-config">Header set foo-checksum "expr=%{md5:foo}"</pre>
</li>
-
+
</ul>
</div>
<code class="directive">Header</code> directives are processed just
before the response is sent to the network. This means that it is
possible to set and/or override most headers, except for some headers
- added by the HTTP header filter. Prior to 2.2.12, it was not possible
+ added by the HTTP header filter. Prior to 2.2.12, it was not possible
to change the Content-Type header with this directive.</p>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>FileInfo</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_headers</td></tr>
-<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>SetIfEmpty available in 2.4.7 and later, expr=value
+<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>SetIfEmpty available in 2.4.7 and later, expr=value
available in 2.4.10 and later</td></tr>
</table>
<p>This directive can replace, merge, change or remove HTTP request
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>FileInfo</override>
-<compatibility>SetIfEmpty available in 2.4.7 and later, expr=value
+<compatibility>SetIfEmpty available in 2.4.7 and later, expr=value
available in 2.4.10 and later</compatibility>
<usage>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>FileInfo</override>
-<compatibility>SetIfEmpty available in 2.4.7 and later, expr=value
+<compatibility>SetIfEmpty available in 2.4.7 and later, expr=value
available in 2.4.10 and later</compatibility>
<usage>
<p> The optional <var>condition</var> argument determines which internal
table of responses headers this directive will operate against. Despite the
- name, the default value of <code>onsuccess</code> does <em>not</em> limit
+ name, the default value of <code>onsuccess</code> does <em>not</em> limit
an <var>action</var> to responses with a 2xx status code. Headers set under
this condition are still used when, for example, a request is <em>successfully</em>
proxied or generated by CGI, even when they have generated a failing status code.</p>
<p>When your action is a function of an existing header, you may need to specify
a condition of <code>always</code>, depending on which internal table the
original header was set in. The table that corresponds to <code>always</code> is
- used for locally generated error responses as well as successful responses.
+ used for locally generated error responses as well as successful responses.
Note also that repeating this directive with both conditions makes sense in
some scenarios because <code>always</code> is not a superset of
<code>onsuccess</code> with respect to existing headers:</p>
<code>onsuccess</code> condition.</li>
</ul>
- <p>Separately from the <var>condition</var> parameter described above, you
- can limit an action based on HTTP status codes for e.g. proxied or CGI
+ <p>Separately from the <var>condition</var> parameter described above, you
+ can limit an action based on HTTP status codes for e.g. proxied or CGI
requests. See the example that uses %{REQUEST_STATUS} in the section above.</p>
<p>The action it performs is determined by the first
<code>add</code> a <var>value</var> is specified as the next argument.
If <var>value</var>
contains spaces, it should be surrounded by double quotes.
- <var>value</var> may be a character string, a string containing
- <module>mod_headers</module> specific format specifiers (and character
+ <var>value</var> may be a character string, a string containing
+ <module>mod_headers</module> specific format specifiers (and character
literals), or an <a href="../expr.html">ap_expr</a> expression prefixed
with <em>expr=</em></p>
-
+
<p> The following format specifiers are supported in <var>value</var>:</p>
<table border="1" style="zebra">
<em>boolean</em> expressions such as <If>:</p>
<ul>
<li>The starting point of the grammar is 'string' rather than 'expr'.</li>
- <li>Function calls use the %{funcname:arg} syntax rather than
+ <li>Function calls use the %{funcname:arg} syntax rather than
funcname(arg).</li>
<li>Multi-argument functions are not currently accessible from this
starting point</li>
- <li>Quote the entire parameter, such as
+ <li>Quote the entire parameter, such as
<highlight language="config">
Header set foo-checksum "expr=%{md5:foo}"
</highlight>
</li>
-
+
</ul>
</note>
<directive>Header</directive> directives are processed just
before the response is sent to the network. This means that it is
possible to set and/or override most headers, except for some headers
- added by the HTTP header filter. Prior to 2.2.12, it was not possible
+ added by the HTTP header filter. Prior to 2.2.12, it was not possible
to change the Content-Type header with this directive.</p>
</usage>
</directivesynopsis>
</modulesynopsis>
-
<tr><th><a href="module-dict.html#Compatibility">Compatibility:</a></th><td>Available in Apache 2.3 and later</td></tr></table>
<h3>Summary</h3>
-<p> <code class="module"><a href="../mod/mod_heartbeat.html">mod_heartbeat</a></code> sends multicast messages to a <code class="module"><a href="../mod/mod_heartmonitor.html">mod_heartmonitor</a></code> listener
+<p> <code class="module"><a href="../mod/mod_heartbeat.html">mod_heartbeat</a></code> sends multicast messages to a <code class="module"><a href="../mod/mod_heartmonitor.html">mod_heartmonitor</a></code> listener
that advertises the servers current connection count. Usually, <code class="module"><a href="../mod/mod_heartmonitor.html">mod_heartmonitor</a></code>
will be running on a proxy server with <code class="module"><a href="../mod/mod_lbmethod_heartbeat.html">mod_lbmethod_heartbeat</a></code> loaded, which allows
<code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> to use the "heartbeat" <em>lbmethod</em> inside
of <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code>.</p>
<p>
- <code class="module"><a href="../mod/mod_heartbeat.html">mod_heartbeat</a></code> itself is loaded on the origin server(s) that serve requests
- through the proxy server(s).
+ <code class="module"><a href="../mod/mod_heartbeat.html">mod_heartbeat</a></code> itself is loaded on the origin server(s) that serve requests
+ through the proxy server(s).
</p>
<div class="warning">
packet is a simple ASCII format, similar to GET query parameters
in HTTP.
</p>
-
+
<div class="example"><h3>An Example Packet</h3><p><code>
v=1&ready=75&busy=0
</code></p></div>
<code class="directive"><a href="../mod/mod_heartmonitor.html#heartbeatlisten">HeartbeatListen</a></code> on a
frontend proxy system.</p>
<pre class="prettyprint lang-config">HeartbeatAddress 239.0.0.1:27999</pre>
-
+
</div>
</div>
<compatibility>Available in Apache 2.3 and later</compatibility>
<summary>
-<p> <module>mod_heartbeat</module> sends multicast messages to a <module>mod_heartmonitor</module> listener
+<p> <module>mod_heartbeat</module> sends multicast messages to a <module>mod_heartmonitor</module> listener
that advertises the servers current connection count. Usually, <module>mod_heartmonitor</module>
will be running on a proxy server with <module>mod_lbmethod_heartbeat</module> loaded, which allows
<directive module="mod_proxy">ProxyPass</directive> to use the "heartbeat" <em>lbmethod</em> inside
of <directive module="mod_proxy">ProxyPass</directive>.</p>
<p>
- <module>mod_heartbeat</module> itself is loaded on the origin server(s) that serve requests
- through the proxy server(s).
+ <module>mod_heartbeat</module> itself is loaded on the origin server(s) that serve requests
+ through the proxy server(s).
</p>
<note type="warning">
packet is a simple ASCII format, similar to GET query parameters
in HTTP.
</p>
-
+
<example><title>An Example Packet</title>
v=1&ready=75&busy=0
</example>
frontend proxy system.</p>
<highlight language="config">
HeartbeatAddress 239.0.0.1:27999
-</highlight>
+</highlight>
</usage>
</directivesynopsis>
<h3>Summary</h3>
<p>
-<code class="module"><a href="../mod/mod_heartmonitor.html">mod_heartmonitor</a></code> listens for server status messages generated
-by <code class="module"><a href="../mod/mod_heartbeat.html">mod_heartbeat</a></code> enabled origin servers and makes their status
-available to <code class="module"><a href="../mod/mod_lbmethod_heartbeat.html">mod_lbmethod_heartbeat</a></code>. This allows
-<code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> to use the "heartbeat"
+<code class="module"><a href="../mod/mod_heartmonitor.html">mod_heartmonitor</a></code> listens for server status messages generated
+by <code class="module"><a href="../mod/mod_heartbeat.html">mod_heartbeat</a></code> enabled origin servers and makes their status
+available to <code class="module"><a href="../mod/mod_lbmethod_heartbeat.html">mod_lbmethod_heartbeat</a></code>. This allows
+<code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> to use the "heartbeat"
<em>lbmethod</em> inside of <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code>.
</p>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_heartmonitor</td></tr>
</table>
<p>The <code class="directive">HeartbeatListen</code> directive specifies the
- multicast address on which the server will listen for status information from
+ multicast address on which the server will listen for status information from
<code class="module"><a href="../mod/mod_heartbeat.html">mod_heartbeat</a></code>-enabled servers. This
address will usually correspond to a configured <code class="directive"><a href="../mod/mod_heartbeat.html#heartbeataddress">HeartbeatAddress</a></code> on an origin server.
</p>
-
+
<pre class="prettyprint lang-config">HeartbeatListen 239.0.0.1:27999</pre>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="HeartbeatMaxServers" id="HeartbeatMaxServers">HeartbeatMaxServers</a> <a name="heartbeatmaxservers" id="heartbeatmaxservers">Directive</a></h2>
<table class="directive">
-<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Specifies the maximum number of servers that will be sending
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Specifies the maximum number of servers that will be sending
heartbeat requests to this server</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>HeartbeatMaxServers <var>number-of-servers</var></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>HeartbeatMaxServers 10</code></td></tr>
<summary>
<p>
-<module>mod_heartmonitor</module> listens for server status messages generated
-by <module>mod_heartbeat</module> enabled origin servers and makes their status
-available to <module>mod_lbmethod_heartbeat</module>. This allows
-<directive module="mod_proxy">ProxyPass</directive> to use the "heartbeat"
+<module>mod_heartmonitor</module> listens for server status messages generated
+by <module>mod_heartbeat</module> enabled origin servers and makes their status
+available to <module>mod_lbmethod_heartbeat</module>. This allows
+<directive module="mod_proxy">ProxyPass</directive> to use the "heartbeat"
<em>lbmethod</em> inside of <directive module="mod_proxy">ProxyPass</directive>.
</p>
<usage>
<p>The <directive>HeartbeatListen</directive> directive specifies the
- multicast address on which the server will listen for status information from
+ multicast address on which the server will listen for status information from
<module>mod_heartbeat</module>-enabled servers. This
address will usually correspond to a configured <directive
module="mod_heartbeat">HeartbeatAddress</directive> on an origin server.
</p>
-
+
<highlight language="config">
HeartbeatListen 239.0.0.1:27999
</highlight>
<directivesynopsis>
<name>HeartbeatMaxServers</name>
-<description>Specifies the maximum number of servers that will be sending
+<description>Specifies the maximum number of servers that will be sending
heartbeat requests to this server</description>
<syntax>HeartbeatMaxServers <var>number-of-servers</var></syntax>
<default>HeartbeatMaxServers 10</default>
<dd><p>The value is a message that is sent back to the
client if an error occurs while parsing the
document. This overrides any <code class="directive"><a href="#ssierrormsg">SSIErrorMsg</a></code> directives.</p>
-
+
<div class="example"><p><code>
<!--#config errmsg="[Oops, something broke.]" -->
</code></p></div>
for a count in bytes, or <code>abbrev</code> for a count
in Kb or Mb as appropriate, for example a size of 1024 bytes
will be printed as "1K".</p>
-
+
<div class="example"><p><code>
<!--#config sizefmt="abbrev" -->
</code></p></div>
-
+
</dd>
<dt><code>timefmt</code></dt>
<dd><p>The value is a string to be used by the
<code>strftime(3)</code> library routine when printing
dates.</p>
-
+
<div class="example"><p><code>
<!--#config timefmt=""%R, %B %d, %Y"" -->
</code></p></div>
-
+
</dd>
</dl>
</code></p></div>
The value of <code>file</code> cannot start with a slash
- (<code>/</code>), nor can it contain <code>../</code> so as to
+ (<code>/</code>), nor can it contain <code>../</code> so as to
refer to a file above the current directory or outside of the
document root. Attempting to so will result in the error message:
<code>The given path was above the root path</code>.
client if an error occurs while parsing the
document. This overrides any <directive
module="mod_include">SSIErrorMsg</directive> directives.</p>
-
+
<example>
<!--#config errmsg="[Oops, something broke.]" -->
</example>
for a count in bytes, or <code>abbrev</code> for a count
in Kb or Mb as appropriate, for example a size of 1024 bytes
will be printed as "1K".</p>
-
+
<example>
<!--#config sizefmt="abbrev" -->
</example>
-
+
</dd>
<dt><code>timefmt</code></dt>
<dd><p>The value is a string to be used by the
<code>strftime(3)</code> library routine when printing
dates.</p>
-
+
<example>
<!--#config timefmt=""%R, %B %d, %Y"" -->
</example>
-
+
</dd>
</dl>
</section> <!-- /config -->
</example>
The value of <code>file</code> cannot start with a slash
- (<code>/</code>), nor can it contain <code>../</code> so as to
+ (<code>/</code>), nor can it contain <code>../</code> so as to
refer to a file above the current directory or outside of the
document root. Attempting to so will result in the error message:
<code>The given path was above the root path</code>.
</directivesynopsis>
</modulesynopsis>
-
heartbeat info via the <code class="module"><a href="../mod/mod_heartbeat.html">mod_heartbeat</a></code> module.</p>
<p> This modules load balancing algorithm favors servers with more ready (idle)
-capacity over time, but does not select the server with the most ready capacity
-every time. Servers that have 0 active clients are penalized, with the
+capacity over time, but does not select the server with the most ready capacity
+every time. Servers that have 0 active clients are penalized, with the
assumption that they are not fully initialized.</p>
</div>
<div id="quickview"><h3 class="directives">Directives</h3>
heartbeat info via the <module>mod_heartbeat</module> module.</p>
<p> This modules load balancing algorithm favors servers with more ready (idle)
-capacity over time, but does not select the server with the most ready capacity
-every time. Servers that have 0 active clients are penalized, with the
+capacity over time, but does not select the server with the most ready capacity
+every time. Servers that have 0 active clients are penalized, with the
assumption that they are not fully initialized.</p>
</summary>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1607960:1673892 (outdated) -->
+<!-- English Revision: 1607960:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 579425:1673833 (outdated) -->
+<!-- English Revision: 579425:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 105989:1673833 (outdated) -->
+<!-- English Revision: 105989:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1310330:1673833 (outdated) -->
+<!-- English Revision: 1310330:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
document for details on why your security could be compromised
if the directory where logfiles are stored is writable by
anyone other than the user that starts the server.</p>
- <p>The log files may contain sensitive data such as the contents of
+ <p>The log files may contain sensitive data such as the contents of
<code>Authorization:</code> headers (which can contain passwords), so
they should not be readable by anyone except the user that starts the
server.</p>
document for details on why your security could be compromised
if the directory where logfiles are stored is writable by
anyone other than the user that starts the server.</p>
- <p>The log files may contain sensitive data such as the contents of
+ <p>The log files may contain sensitive data such as the contents of
<code>Authorization:</code> headers (which can contain passwords), so
they should not be readable by anyone except the user that starts the
server.</p>
Available in Apache 2.4.7 and later</td></tr>
<tr class="odd"><td><code>%^FB</code></td>
<td>Delay in microseconds between when the request arrived and the
- first byte of the response headers are written. Only available if
+ first byte of the response headers are written. Only available if
<code class="directive">LogIOTrackTTFB</code> is set to ON.
</td></tr>
</table>
</table>
<p>This directive configures whether this module tracks the delay
between the request being read and the first byte of the response
- headers being written. The resulting value may be logged with the
+ headers being written. The resulting value may be logged with the
<code>%^FB</code> format.</p>
</div>
<tr><td><code>%^FB</code></td>
<td>Delay in microseconds between when the request arrived and the
- first byte of the response headers are written. Only available if
+ first byte of the response headers are written. Only available if
<directive>LogIOTrackTTFB</directive> is set to ON.
</td></tr>
</table>
<usage>
<p>This directive configures whether this module tracks the delay
between the request being read and the first byte of the response
- headers being written. The resulting value may be logged with the
+ headers being written. The resulting value may be logged with the
<code>%^FB</code> format.</p>
</usage>
</directivesynopsis>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1641661:1673892 (outdated) -->
+<!-- English Revision: 1641661:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1533274:1673917 (outdated) -->
+<!-- English Revision: 1533274:1673945 (outdated) -->
<!-- French translation: Fabien Coelho -->
<!-- Updated by Lucien Gentis -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 669473:1673930 (outdated) -->
+<!-- English Revision: 669473:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1668875:1673917 (outdated) -->
+<!-- English Revision: 1668875:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<div class="example"><h3>Adding an output filter </h3><pre class="prettyprint lang-config"># In the following example, the sed filter will change the string
# "monday" to "MON" and the string "sunday" to SUN in html documents
# before sending to the client.
-<Directory "/var/www/docs/sed">
- AddOutputFilter Sed html
- OutputSed "s/monday/MON/g"
- OutputSed "s/sunday/SUN/g"
+<Directory "/var/www/docs/sed">
+ AddOutputFilter Sed html
+ OutputSed "s/monday/MON/g"
+ OutputSed "s/sunday/SUN/g"
</Directory></pre>
</div>
<div class="example"><h3>Adding an input filter </h3><pre class="prettyprint lang-config"># In the following example, the sed filter will change the string
# "monday" to "MON" and the string "sunday" to SUN in the POST data
# sent to PHP.
-<Directory "/var/www/docs/sed">
- AddInputFilter Sed php
- InputSed "s/monday/MON/g"
- InputSed "s/sunday/SUN/g"
+<Directory "/var/www/docs/sed">
+ AddInputFilter Sed php
+ InputSed "s/monday/MON/g"
+ InputSed "s/sunday/SUN/g"
</Directory></pre>
</div>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
# In the following example, the sed filter will change the string
# "monday" to "MON" and the string "sunday" to SUN in html documents
# before sending to the client.
-<Directory "/var/www/docs/sed">
- AddOutputFilter Sed html
- OutputSed "s/monday/MON/g"
- OutputSed "s/sunday/SUN/g"
-</Directory>
+<Directory "/var/www/docs/sed">
+ AddOutputFilter Sed html
+ OutputSed "s/monday/MON/g"
+ OutputSed "s/sunday/SUN/g"
+</Directory>
</highlight>
</example>
# In the following example, the sed filter will change the string
# "monday" to "MON" and the string "sunday" to SUN in the POST data
# sent to PHP.
-<Directory "/var/www/docs/sed">
- AddInputFilter Sed php
- InputSed "s/monday/MON/g"
- InputSed "s/sunday/SUN/g"
-</Directory>
+<Directory "/var/www/docs/sed">
+ AddInputFilter Sed php
+ InputSed "s/monday/MON/g"
+ InputSed "s/sunday/SUN/g"
+</Directory>
</highlight>
</example>
</section>
session from or writing the session to the chosen storage mechanism is handled
by the <code class="module"><a href="../mod/mod_session.html">mod_session</a></code> modules and corresponding configuration.
</dd>
-
+
<dt>Applications behind <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></dt>
<dd>If the <code class="directive"><a href="#sessionheader">SessionHeader</a></code>
directive is used to define an HTTP request header, the session, encoded as
above, any encryption or decryption, and the reading the session from or
writing the session to the chosen storage mechanism is handled by the
<code class="module"><a href="../mod/mod_session.html">mod_session</a></code> modules and corresponding configuration.</dd>
-
+
<dt>Standalone applications</dt>
<dd>Applications might choose to manipulate the session outside the control
of the Apache HTTP server. In this case, it is the responsibility of the
session from or writing the session to the chosen storage mechanism is handled
by the <module>mod_session</module> modules and corresponding configuration.
</dd>
-
+
<dt>Applications behind <module>mod_proxy</module></dt>
<dd>If the <directive module="mod_session">SessionHeader</directive>
directive is used to define an HTTP request header, the session, encoded as
above, any encryption or decryption, and the reading the session from or
writing the session to the chosen storage mechanism is handled by the
<module>mod_session</module> modules and corresponding configuration.</dd>
-
+
<dt>Standalone applications</dt>
<dd>Applications might choose to manipulate the session outside the control
of the Apache HTTP server. In this case, it is the responsibility of the
BrowserMatch MSIE !netscape</pre>
- <p>When the server looks up a path via an internal
- <a class="glossarylink" href="../glossary.html#subrequest" title="see glossary">subrequest</a> such as looking
- for a <code class="directive"><a href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a></code>
+ <p>When the server looks up a path via an internal
+ <a class="glossarylink" href="../glossary.html#subrequest" title="see glossary">subrequest</a> such as looking
+ for a <code class="directive"><a href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a></code>
or generating a directory listing with <code class="module"><a href="../mod/mod_autoindex.html">mod_autoindex</a></code>,
- per-request environment variables are <em>not</em> inherited in the
- subrequest. Additionally,
+ per-request environment variables are <em>not</em> inherited in the
+ subrequest. Additionally,
<code class="directive"><a href="#setenvif">SetEnvIf</a></code> directives
are not separately evaluated in the subrequest due to the API phases
<code class="module"><a href="../mod/mod_setenvif.html">mod_setenvif</a></code> takes action in.</p>
<pre class="prettyprint lang-config">SetEnvIf Request_URI "\.gif$" object_is_image=gif
SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
-
+
SetEnvIf Referer www\.mydomain\.example\.com intra_site_referral
-
+
SetEnvIf object_is_image xbm XBIT_PROCESSING=1
-
+
SetEnvIf ^TS ^[a-z] HAVE_TS</pre>
BrowserMatch MSIE !netscape
</highlight>
- <p>When the server looks up a path via an internal
- <glossary ref="subrequest">subrequest</glossary> such as looking
- for a <directive module="mod_dir" >DirectoryIndex</directive>
+ <p>When the server looks up a path via an internal
+ <glossary ref="subrequest">subrequest</glossary> such as looking
+ for a <directive module="mod_dir" >DirectoryIndex</directive>
or generating a directory listing with <module>mod_autoindex</module>,
- per-request environment variables are <em>not</em> inherited in the
- subrequest. Additionally,
+ per-request environment variables are <em>not</em> inherited in the
+ subrequest. Additionally,
<directive module="mod_setenvif">SetEnvIf</directive> directives
are not separately evaluated in the subrequest due to the API phases
<module>mod_setenvif</module> takes action in.</p>
SetEnvIf Request_URI "\.gif$" object_is_image=gif
SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
-
+
SetEnvIf Referer www\.mydomain\.example\.com intra_site_referral
-
+
SetEnvIf object_is_image xbm XBIT_PROCESSING=1
-
+
SetEnvIf ^TS ^[a-z] HAVE_TS
</highlight>
<dt>apr_status_t fgrab(ap_slotmem_instance_t *s, unsigned int item_id);</dt>
<dd>forced grab or allocate the specified slot and mark as in-use (does not do any data copying)</dd>
-
+
<dt>apr_status_t release(ap_slotmem_instance_t *s, unsigned int item_id);</dt>
<dd>release or free a slot and mark as not in-use (does not do any data copying)</dd>
</dl>
<dt>apr_status_t fgrab(ap_slotmem_instance_t *s, unsigned int item_id);</dt>
<dd>forced grab or allocate the specified slot and mark as in-use (does not do any data copying)</dd>
-
+
<dt>apr_status_t release(ap_slotmem_instance_t *s, unsigned int item_id);</dt>
<dd>release or free a slot and mark as not in-use (does not do any data copying)</dd>
</dl>
which provides for creation and access to a cache backed by a
DBM database.
</p>
-
+
<div class="example"><p><code>
dbm:/path/to/datafile
</code></p></div>
which provides for creation and access to a cache backed by a
DBM database.
</p>
-
+
<example>
dbm:/path/to/datafile
</example>
high-performance, distributed memory object caching system.
</p>
-
- <p>This shared object cache provider's "create" method requires a
+
+ <p>This shared object cache provider's "create" method requires a
comma separated list of memcached host/port specifications. If using
- this provider via another modules configuration (such as
+ this provider via another modules configuration (such as
<code class="directive"><a href="../mod/mod_ssl.html#sslsessioncache">SSLSessionCache</a></code>), provide
the list of servers as the optional "arg" parameter.</p>
<pre class="prettyprint lang-config">SSLSessionCache memcache:memcache.example.com:12345,memcache2.example.com:12345</pre>
-
+
<p>Details of other shared object cache providers can be found
<a href="../socache.html">here</a>.
</p>
high-performance, distributed memory object caching system.
</p>
-
- <p>This shared object cache provider's "create" method requires a
+
+ <p>This shared object cache provider's "create" method requires a
comma separated list of memcached host/port specifications. If using
- this provider via another modules configuration (such as
+ this provider via another modules configuration (such as
<directive module="mod_ssl">SSLSessionCache</directive>), provide
the list of servers as the optional "arg" parameter.</p>
<highlight language="config">
SSLSessionCache memcache:memcache.example.com:12345,memcache2.example.com:12345
</highlight>
-
+
<p>Details of other shared object cache providers can be found
<a href="../socache.html">here</a>.
</p>
which provides for creation and access to a cache backed by a
high-performance cyclic buffer inside a shared memory segment.
</p>
-
+
<div class="example"><p><code>
shmcb:/path/to/datafile(512000)
</code></p></div>
which provides for creation and access to a cache backed by a
high-performance cyclic buffer inside a shared memory segment.
</p>
-
+
<example>
shmcb:/path/to/datafile(512000)
</example>
<h3>Summary</h3>
-<p>This module provides an implementation of Certificate Transparency, in
+<p>This module provides an implementation of Certificate Transparency, in
conjunction with <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> and command-line tools from the
<a href="https://code.google.com/p/certificate-transparency/">certificate-transparency</a>
open source project. The goal of Certificate Transparency is to expose the
servers and proxies:</p>
<ul>
- <li>Signed Certificate Timestamps (SCTs) can be obtained from logs
+ <li>Signed Certificate Timestamps (SCTs) can be obtained from logs
automatically and, in conjunction with any statically configured SCTs, sent
to aware clients in the ServerHello (during the handshake).</li>
<li>SCTs can be received by the proxy from origin servers in the ServerHello,
- in a certificate extension, and/or within stapled OCSP responses; any SCTs
+ in a certificate extension, and/or within stapled OCSP responses; any SCTs
received can be partially validated on-line and optionally queued for off-line
audit.</li>
<li>The proxy can be configured to disallow communication with an origin
</ul>
<p>If verification fails for at least one SCT and verification was not
- successful for at least one SCT, the connection is aborted if
+ successful for at least one SCT, the connection is aborted if
<code class="directive"><a href="#ctproxyawareness">CTProxyAwareness</a></code> is set to
<em>require</em>.</p>
<dt>log URL</dt>
<dd>The URL of the log (for its API) is required by a server in order to
submit server certificates to the log. The server will submit
- each server certificate in order to obtain an SCT for each log with a
+ each server certificate in order to obtain an SCT for each log with a
configured URL, except when the log is also marked as distrusted or the
current time is not within any configured valid timestamp range.
<br />
</dl>
<p>Generally, only a small subset of this information is configured for a
- particular log. Refer to the documentation for the <code class="directive"><a href="#ctstaticlogconfig">CTStaticLogConfig</a></code> directive and the
+ particular log. Refer to the documentation for the <code class="directive"><a href="#ctstaticlogconfig">CTStaticLogConfig</a></code> directive and the
<code class="program"><a href="../programs/ctlogconfig.html">ctlogconfig</a></code> command for more specific information.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<p>Sample code in the form of a Python script to build an SCT in the correct
format from data received from a log can be found in
- <a href="https://github.com/tomrittervg/ct-tools">Tom Ritter's ct-tools
+ <a href="https://github.com/tomrittervg/ct-tools">Tom Ritter's ct-tools
repository</a>. Refer to <code>write-sct.py</code></p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<p>The directory will contain files named <code><em>PID</em>.tmp</code> for
active child processes and files named <code><em>PID</em>.out</code> for exited
- child processes. These <code>.out</code> files are ready for off-line audit.
+ child processes. These <code>.out</code> files are ready for off-line audit.
The experimental command <code>ctauditscts</code> (in the httpd source tree, not
currently installed) interfaces with <em>certificate-transparency</em> tools to
perform the audit.</p>
to that certificate; the name of the subdirectory is the SHA-256 hash of the
certificate.</p>
- <p>The certificate-specific directory contains SCTs retrieved from configured
+ <p>The certificate-specific directory contains SCTs retrieved from configured
logs, SCT lists prepared from statically configured SCTs and retrieved SCTs,
and other information used for managing SCTs.</p>
</table>
<p>This directive is used to configure information about a particular log.
This directive is appropriate when configuration information changes rarely.
- If dynamic configuration updates must be supported, refer to the
+ If dynamic configuration updates must be supported, refer to the
<code class="directive"><a href="#ctlogconfigdb">CTLogConfigDB</a></code> directive.</p>
<p>Each of the six fields must be specified, but usually only a small
Timestamps. This must be provided as a decimal number.
<br />
Specify <strong><code>-</code></strong> for one of the timestamps if it is unknown.
- For example, when configuring the minimum valid timestamp for a log which remains
+ For example, when configuring the minimum valid timestamp for a log which remains
valid, specify <strong><code>-</code></strong> for <em>max-timestamp</em>.
<br />
SCTs received from this log by the proxy are invalid if the timestamp
<p><em>sct-directory</em> should contain one or more files with extension
<code>.sct</code>, representing one or more SCTs corresponding to the
- server certificate. If <em>sct-directory</em> is not absolute, then it is
+ server certificate. If <em>sct-directory</em> is not absolute, then it is
assumed to be relative to <code class="directive"><a href="../mod/core.html#serverroot">ServerRoot</a></code>.</p>
<p>If <em>sct-directory</em> is empty, no error will be raised.</p>
<summary>
-<p>This module provides an implementation of Certificate Transparency, in
+<p>This module provides an implementation of Certificate Transparency, in
conjunction with <module>mod_ssl</module> and command-line tools from the
<a href="https://code.google.com/p/certificate-transparency/">certificate-transparency</a>
open source project. The goal of Certificate Transparency is to expose the
servers and proxies:</p>
<ul>
- <li>Signed Certificate Timestamps (SCTs) can be obtained from logs
+ <li>Signed Certificate Timestamps (SCTs) can be obtained from logs
automatically and, in conjunction with any statically configured SCTs, sent
to aware clients in the ServerHello (during the handshake).</li>
<li>SCTs can be received by the proxy from origin servers in the ServerHello,
- in a certificate extension, and/or within stapled OCSP responses; any SCTs
+ in a certificate extension, and/or within stapled OCSP responses; any SCTs
received can be partially validated on-line and optionally queued for off-line
audit.</li>
<li>The proxy can be configured to disallow communication with an origin
</ul>
<p>If verification fails for at least one SCT and verification was not
- successful for at least one SCT, the connection is aborted if
+ successful for at least one SCT, the connection is aborted if
<directive module="mod_ssl_ct">CTProxyAwareness</directive> is set to
<em>require</em>.</p>
<dt>log URL</dt>
<dd>The URL of the log (for its API) is required by a server in order to
submit server certificates to the log. The server will submit
- each server certificate in order to obtain an SCT for each log with a
+ each server certificate in order to obtain an SCT for each log with a
configured URL, except when the log is also marked as distrusted or the
current time is not within any configured valid timestamp range.
<br />
</dl>
<p>Generally, only a small subset of this information is configured for a
- particular log. Refer to the documentation for the <directive
- module="mod_ssl_ct">CTStaticLogConfig</directive> directive and the
+ particular log. Refer to the documentation for the <directive
+ module="mod_ssl_ct">CTStaticLogConfig</directive> directive and the
<program>ctlogconfig</program> command for more specific information.</p>
</section>
<p>Sample code in the form of a Python script to build an SCT in the correct
format from data received from a log can be found in
- <a href="https://github.com/tomrittervg/ct-tools">Tom Ritter's ct-tools
+ <a href="https://github.com/tomrittervg/ct-tools">Tom Ritter's ct-tools
repository</a>. Refer to <code>write-sct.py</code></p>
</section>
<p>The directory will contain files named <code><em>PID</em>.tmp</code> for
active child processes and files named <code><em>PID</em>.out</code> for exited
- child processes. These <code>.out</code> files are ready for off-line audit.
+ child processes. These <code>.out</code> files are ready for off-line audit.
The experimental command <code>ctauditscts</code> (in the httpd source tree, not
currently installed) interfaces with <em>certificate-transparency</em> tools to
perform the audit.</p>
to that certificate; the name of the subdirectory is the SHA-256 hash of the
certificate.</p>
- <p>The certificate-specific directory contains SCTs retrieved from configured
+ <p>The certificate-specific directory contains SCTs retrieved from configured
logs, SCT lists prepared from statically configured SCTs and retrieved SCTs,
and other information used for managing SCTs.</p>
</usage>
<usage>
<p>This directive is used to configure information about a particular log.
This directive is appropriate when configuration information changes rarely.
- If dynamic configuration updates must be supported, refer to the
+ If dynamic configuration updates must be supported, refer to the
<directive module="mod_ssl_ct">CTLogConfigDB</directive> directive.</p>
<p>Each of the six fields must be specified, but usually only a small
Timestamps. This must be provided as a decimal number.
<br />
Specify <strong><code>-</code></strong> for one of the timestamps if it is unknown.
- For example, when configuring the minimum valid timestamp for a log which remains
+ For example, when configuring the minimum valid timestamp for a log which remains
valid, specify <strong><code>-</code></strong> for <em>max-timestamp</em>.
<br />
SCTs received from this log by the proxy are invalid if the timestamp
<p><em>sct-directory</em> should contain one or more files with extension
<code>.sct</code>, representing one or more SCTs corresponding to the
- server certificate. If <em>sct-directory</em> is not absolute, then it is
+ server certificate. If <em>sct-directory</em> is not absolute, then it is
assumed to be relative to <directive module="core">ServerRoot</directive>.</p>
<p>If <em>sct-directory</em> is empty, no error will be raised.</p>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1331227:1673892 (outdated) -->
+<!-- English Revision: 1331227:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
<modulesynopsis metafile="mod_status.xml.meta">
-<!-- English Revision: 668628:1673892 (outdated) -->
+<!-- English Revision: 668628:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 420990:1673892 (outdated) -->
+<!-- English Revision: 420990:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1174747:1673892 (outdated) -->
+<!-- English Revision: 1174747:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1174747:1673917 (outdated) -->
+<!-- English Revision: 1174747:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<div class="toplang">
<p><span>Available Languages: </span><a href="../en/mod/mod_watchdog.html" title="English"> en </a></p>
</div>
-<table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>provides infrastructure for other modules to periodically run
+<table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>provides infrastructure for other modules to periodically run
tasks</td></tr>
<tr><th><a href="module-dict.html#Status">Status:</a></th><td>Base</td></tr>
<tr><th><a href="module-dict.html#ModuleIdentifier">Module Identifier:</a></th><td>watchdog_module</td></tr>
<tr><th><a href="module-dict.html#Compatibility">Compatibility:</a></th><td>Available in Apache 2.3 and later</td></tr></table>
<h3>Summary</h3>
-<p><code class="module"><a href="../mod/mod_watchdog.html">mod_watchdog</a></code> defines programmatic hooks for other modules to
-periodically run tasks. These modules can register handlers for
-<code class="module"><a href="../mod/mod_watchdog.html">mod_watchdog</a></code> hooks. Currently, the following modules in the
-Apache distribution use this functionality:</p>
+<p><code class="module"><a href="../mod/mod_watchdog.html">mod_watchdog</a></code> defines programmatic hooks for other modules to
+periodically run tasks. These modules can register handlers for
+<code class="module"><a href="../mod/mod_watchdog.html">mod_watchdog</a></code> hooks. Currently, the following modules in the
+Apache distribution use this functionality:</p>
<ul>
<li><code class="module"><a href="../mod/mod_heartbeat.html">mod_heartbeat</a></code></li>
<li><code class="module"><a href="../mod/mod_heartmonitor.html">mod_heartmonitor</a></code></li>
</ul>
<div class="warning">
-To allow a module to use <code class="module"><a href="../mod/mod_watchdog.html">mod_watchdog</a></code> functionality,
-<code class="module"><a href="../mod/mod_watchdog.html">mod_watchdog</a></code> itself must be statically linked to the server
-core or, if a dynamic module, be loaded before the calling module.
+To allow a module to use <code class="module"><a href="../mod/mod_watchdog.html">mod_watchdog</a></code> functionality,
+<code class="module"><a href="../mod/mod_watchdog.html">mod_watchdog</a></code> itself must be statically linked to the server
+core or, if a dynamic module, be loaded before the calling module.
</div>
</div>
<div id="quickview"><h3 class="directives">Directives</h3>
<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_watchdog</td></tr>
</table>
-<p>Sets the interval at which the watchdog_step hook runs. Default is to run every
+<p>Sets the interval at which the watchdog_step hook runs. Default is to run every
second.</p>
</div>
<modulesynopsis metafile="mod_watchdog.xml.meta">
<name>mod_watchdog</name>
-<description>provides infrastructure for other modules to periodically run
+<description>provides infrastructure for other modules to periodically run
tasks</description>
<status>Base</status>
<sourcefile>mod_watchdog.c</sourcefile>
<compatibility>Available in Apache 2.3 and later</compatibility>
<summary>
-<p><module>mod_watchdog</module> defines programmatic hooks for other modules to
-periodically run tasks. These modules can register handlers for
-<module>mod_watchdog</module> hooks. Currently, the following modules in the
-Apache distribution use this functionality:</p>
+<p><module>mod_watchdog</module> defines programmatic hooks for other modules to
+periodically run tasks. These modules can register handlers for
+<module>mod_watchdog</module> hooks. Currently, the following modules in the
+Apache distribution use this functionality:</p>
<ul>
<li><module>mod_heartbeat</module></li>
<li><module>mod_heartmonitor</module></li>
</ul>
<note type="warning">
-To allow a module to use <module>mod_watchdog</module> functionality,
-<module>mod_watchdog</module> itself must be statically linked to the server
-core or, if a dynamic module, be loaded before the calling module.
+To allow a module to use <module>mod_watchdog</module> functionality,
+<module>mod_watchdog</module> itself must be statically linked to the server
+core or, if a dynamic module, be loaded before the calling module.
</note>
</summary>
<contextlist><context>server config</context></contextlist>
<usage>
-<p>Sets the interval at which the watchdog_step hook runs. Default is to run every
+<p>Sets the interval at which the watchdog_step hook runs. Default is to run every
second.</p>
</usage>
</directivesynopsis>
</modulesynopsis>
-
Apache httpd to always create the file on the disk.</p>
<p>If <var>file-path</var> is not an absolute path, the location specified
- will be relative to the value of
+ will be relative to the value of
<code class="directive"><a href="../mod/core.html#defaultruntimedir">DefaultRuntimeDir</a></code>.</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">ScoreBoardFile /var/run/apache_runtime_status</pre>
Apache httpd to always create the file on the disk.</p>
<p>If <var>file-path</var> is not an absolute path, the location specified
- will be relative to the value of
+ will be relative to the value of
<directive module="core">DefaultRuntimeDir</directive>.</p>
<example><title>Example</title>
which launches a single child process which in turn creates
threads to handle requests</p>
- <p>Capacity is configured using the
+ <p>Capacity is configured using the
<code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code> directive,
which sets the maximum number of concurrent client connections.</p>
<p>The MPM falls back to a safer implementation, but some client requests
were not processed correctly. In order to avoid this error, use
- <code class="directive"><a href="../mod/core.html#acceptfilter">AcceptFilter</a></code> with accept filter
+ <code class="directive"><a href="../mod/core.html#acceptfilter">AcceptFilter</a></code> with accept filter
<code>none</code>.</p>
<pre class="prettyprint lang-config">AcceptFilter http none
AcceptFilter https none</pre>
-
+
<p><em>In Apache httpd 2.0 and 2.2,
<code class="directive">Win32DisableAcceptEx</code> was used for this purpose.</em></p>
inheriting the configuration from the parent. The behavior will
be the same as on Unix if the child process is created at startup
or restart, but if a child process is created because the prior
- one crashed or reached
+ one crashed or reached
<code class="directive"><a href="../mod/mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></code>,
any pending changes to the configuration will become active in the
child at that point, and the parent and child will be using a
different configuration. If planned configuration changes have been
partially implemented and the current configuration cannot be
- parsed, the replacement child process cannot start up and the server
+ parsed, the replacement child process cannot start up and the server
will halt. Because of this behavior, configuration files should not
be changed until the time of a server restart.</li>
which launches a single child process which in turn creates
threads to handle requests</p>
- <p>Capacity is configured using the
+ <p>Capacity is configured using the
<directive module="mpm_common">ThreadsPerChild</directive> directive,
which sets the maximum number of concurrent client connections.</p>
<p>The MPM falls back to a safer implementation, but some client requests
were not processed correctly. In order to avoid this error, use
- <directive module="core">AcceptFilter</directive> with accept filter
+ <directive module="core">AcceptFilter</directive> with accept filter
<code>none</code>.</p>
<highlight language="config">
AcceptFilter http none
AcceptFilter https none
</highlight>
-
+
<p><em>In Apache httpd 2.0 and 2.2,
<directive>Win32DisableAcceptEx</directive> was used for this purpose.</em></p>
inheriting the configuration from the parent. The behavior will
be the same as on Unix if the child process is created at startup
or restart, but if a child process is created because the prior
- one crashed or reached
+ one crashed or reached
<directive module="mpm_common">MaxConnectionsPerChild</directive>,
any pending changes to the configuration will become active in the
child at that point, and the parent and child will be using a
different configuration. If planned configuration changes have been
partially implemented and the current configuration cannot be
- parsed, the replacement child process cannot start up and the server
+ parsed, the replacement child process cannot start up and the server
will halt. Because of this behavior, configuration files should not
be changed until the time of a server restart.</li>
of the index listing</td></tr>
<tr><td><a href="mod_heartbeat.html#heartbeataddress">HeartbeatAddress <var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Multicast address for heartbeat packets</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatlisten">HeartbeatListen<var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">multicast address to listen for incoming heartbeat requests </td></tr>
-<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
+<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
heartbeat requests to this server</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">Path to store heartbeat data</td></tr>
<tr><td><a href="mod_lbmethod_heartbeat.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Path to read heartbeat data</td></tr>
of the index listing</td></tr>
<tr><td><a href="mod_heartbeat.html#heartbeataddress">HeartbeatAddress <var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Multicast address for heartbeat packets</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatlisten">HeartbeatListen<var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">multicast address to listen for incoming heartbeat requests </td></tr>
-<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
+<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
heartbeat requests to this server</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">Path to store heartbeat data</td></tr>
<tr><td><a href="mod_lbmethod_heartbeat.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Path to read heartbeat data</td></tr>
of the index listing</td></tr>
<tr><td><a href="mod_heartbeat.html#heartbeataddress">HeartbeatAddress <var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Multicast address for heartbeat packets</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatlisten">HeartbeatListen<var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">multicast address to listen for incoming heartbeat requests </td></tr>
-<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
+<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
heartbeat requests to this server</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">Path to store heartbeat data</td></tr>
<tr><td><a href="mod_lbmethod_heartbeat.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Path to read heartbeat data</td></tr>
インデックス一覧の先頭に挿入されるファイルの名前</td></tr>
<tr><td><a href="mod_heartbeat.html#heartbeataddress">HeartbeatAddress <var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Multicast address for heartbeat packets</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatlisten">HeartbeatListen<var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">multicast address to listen for incoming heartbeat requests </td></tr>
-<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
+<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
heartbeat requests to this server</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">Path to store heartbeat data</td></tr>
<tr><td><a href="mod_lbmethod_heartbeat.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Path to read heartbeat data</td></tr>
<tr class="odd"><td><a href="mod_autoindex.html#headername">HeaderName <var>filename</var></a></td><td></td><td>svdh</td><td>B</td></tr><tr class="odd"><td class="descr" colspan="4">ÆÄÀϸñ·Ï À§¿¡ »ðÀÔÇÒ ÆÄÀÏÀÇ À̸§</td></tr>
<tr><td><a href="mod_heartbeat.html#heartbeataddress">HeartbeatAddress <var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Multicast address for heartbeat packets</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatlisten">HeartbeatListen<var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">multicast address to listen for incoming heartbeat requests </td></tr>
-<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
+<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
heartbeat requests to this server</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">Path to store heartbeat data</td></tr>
<tr><td><a href="mod_lbmethod_heartbeat.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Path to read heartbeat data</td></tr>
belirler.</td></tr>
<tr><td><a href="mod_heartbeat.html#heartbeataddress">HeartbeatAddress <var>addr:port</var></a></td><td></td><td>s</td><td>D</td></tr><tr><td class="descr" colspan="4">Multicast address for heartbeat packets</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatlisten">HeartbeatListen<var>addr:port</var></a></td><td></td><td>s</td><td>D</td></tr><tr class="odd"><td class="descr" colspan="4">multicast address to listen for incoming heartbeat requests </td></tr>
-<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>D</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
+<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>D</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
heartbeat requests to this server</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>D</td></tr><tr class="odd"><td class="descr" colspan="4">Path to store heartbeat data</td></tr>
<tr><td><a href="mod_lbmethod_heartbeat.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>D</td></tr><tr><td class="descr" colspan="4">Path to read heartbeat data</td></tr>
of the index listing</td></tr>
<tr><td><a href="mod_heartbeat.html#heartbeataddress">HeartbeatAddress <var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Multicast address for heartbeat packets</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatlisten">HeartbeatListen<var>addr:port</var></a></td><td></td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">multicast address to listen for incoming heartbeat requests </td></tr>
-<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
+<tr><td><a href="mod_heartmonitor.html#heartbeatmaxservers">HeartbeatMaxServers <var>number-of-servers</var></a></td><td> 10 </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Specifies the maximum number of servers that will be sending
heartbeat requests to this server</td></tr>
<tr class="odd"><td><a href="mod_heartmonitor.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr class="odd"><td class="descr" colspan="4">Path to store heartbeat data</td></tr>
<tr><td><a href="mod_lbmethod_heartbeat.html#heartbeatstorage">HeartbeatStorage <var>file-path</var></a></td><td> logs/hb.dat </td><td>s</td><td>X</td></tr><tr><td class="descr" colspan="4">Path to read heartbeat data</td></tr>
<dl>
<dt>Run-time Loadable MPMs</dt>
- <dd>Multiple MPMs can now be <a href="mpm.html#dynamic">built
+ <dd>Multiple MPMs can now be <a href="mpm.html#dynamic">built
as loadable modules</a> at compile time.
The MPM of choice can be configured at run time.</dd>
<title>Core Enhancements</title>
<dl>
<dt>Run-time Loadable MPMs</dt>
- <dd>Multiple MPMs can now be <a href="mpm.html#dynamic">built
+ <dd>Multiple MPMs can now be <a href="mpm.html#dynamic">built
as loadable modules</a> at compile time.
The MPM of choice can be configured at run time.</dd>
# template from httpd<br />
cp /etc/sysconfig/httpd /etc/sysconfig/httpd-additional
</code></p></div>
-
+
<div class="example"><p><code>
# blank template<br />
touch /etc/sysconfig/httpd-additional
# template from httpd<br />
cp /etc/sysconfig/httpd /etc/sysconfig/httpd-additional
</example>
-
+
<example>
# blank template<br />
touch /etc/sysconfig/httpd-additional
</section>
</manualpage>
-
<p>The policy of the Apache HTTP Server project is to only release Unix sources.
- Windows source packages made available for download have been supplied by
- volunteers and may not be available for every release. You can still build
+ Windows source packages made available for download have been supplied by
+ volunteers and may not be available for every release. You can still build
the server on Windows from the Unix source tarball with just a few additional
steps.</p>
perl srclib\apr\build\lineends.pl
</code></p></div>
- <p>You can now build the server with the Visual Studio 6.0 development
- environment using the IDE. Command-Line builds of the server are not
- possible from Unix sources unless you export .mak files as explained
+ <p>You can now build the server with the Visual Studio 6.0 development
+ environment using the IDE. Command-Line builds of the server are not
+ possible from Unix sources unless you export .mak files as explained
below.
</p>
<h2><a name="cmake" id="cmake">Building httpd with cmake</a></h2>
- <p>The primary documentation for this build mechanism is in the
+ <p>The primary documentation for this build mechanism is in the
<code>README.cmake</code> file in the source distribution. Refer to that file
for detailed instructions.</p>
<ul>
<li>No cmake build for the APR-iconv subproject is available, and the
APR-util cmake build cannot consume an existing APR-iconv build. Thus,
- <code class="module"><a href="../mod/mod_charset_lite.html">mod_charset_lite</a></code> and possibly some third-party modules
+ <code class="module"><a href="../mod/mod_charset_lite.html">mod_charset_lite</a></code> and possibly some third-party modules
cannot be used.</li>
<li>The cmake build for the APR-util subproject does not support most of the
optional DBM and DBD libraries supported by the included Visual Studio
<title>Building from Unix sources</title>
<p>The policy of the Apache HTTP Server project is to only release Unix sources.
- Windows source packages made available for download have been supplied by
- volunteers and may not be available for every release. You can still build
+ Windows source packages made available for download have been supplied by
+ volunteers and may not be available for every release. You can still build
the server on Windows from the Unix source tarball with just a few additional
steps.</p>
perl srclib\apr\build\lineends.pl
</example>
- <p>You can now build the server with the Visual Studio 6.0 development
- environment using the IDE. Command-Line builds of the server are not
- possible from Unix sources unless you export .mak files as explained
+ <p>You can now build the server with the Visual Studio 6.0 development
+ environment using the IDE. Command-Line builds of the server are not
+ possible from Unix sources unless you export .mak files as explained
below.
</p>
<section id="cmake">
<title>Building httpd with cmake</title>
- <p>The primary documentation for this build mechanism is in the
+ <p>The primary documentation for this build mechanism is in the
<code>README.cmake</code> file in the source distribution. Refer to that file
for detailed instructions.</p>
<ul>
<li>No cmake build for the APR-iconv subproject is available, and the
APR-util cmake build cannot consume an existing APR-iconv build. Thus,
- <module>mod_charset_lite</module> and possibly some third-party modules
+ <module>mod_charset_lite</module> and possibly some third-party modules
cannot be used.</li>
<li>The cmake build for the APR-util subproject does not support most of the
optional DBM and DBD libraries supported by the included Visual Studio
</section>
</manualpage>
-
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 105989:1673892 (outdated) -->
+<!-- English Revision: 105989:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
requests within one HTTP session. Default is no KeepAlive.</dd>
<dt><code>-l</code></dt>
- <dd>Do not report errors if the length of the responses is not constant. This
+ <dd>Do not report errors if the length of the responses is not constant. This
can be usefull for dynamic pages.<br />
Available in 2.4.7 and later.
</dd>
requests within one HTTP session. Default is no KeepAlive.</dd>
<dt><code>-l</code></dt>
- <dd>Do not report errors if the length of the responses is not constant. This
+ <dd>Do not report errors if the length of the responses is not constant. This
can be usefull for dynamic pages.<br />
Available in 2.4.7 and later.
</dd>
configuration file. By default, all those directives will be commented
out except for the modules that are either required or explicitly selected
by a configure <code>--enable-foo</code> argument. You can change the set
- of loaded modules by activating or deactivating the <directive
+ of loaded modules by activating or deactivating the <directive
module="mod_so">LoadModule</directive> directives in
<code>httpd.conf</code>. In addition the
<directive module="mod_so">LoadModule</directive> directives for all
exist, or deleted and recreated if it does exist.</dd>
<dt><code><var>realm</var></code></dt>
- <dd>The realm name to which the user name belongs. See
+ <dd>The realm name to which the user name belongs. See
<a href="http://tools.ietf.org/html/rfc2617#section-3.2.1">
http://tools.ietf.org/html/rfc2617#section-3.2.1</a> for more details.
</dd>
exist, or deleted and recreated if it does exist.</dd>
<dt><code><var>realm</var></code></dt>
- <dd>The realm name to which the user name belongs. See
+ <dd>The realm name to which the user name belongs. See
<a href="http://tools.ietf.org/html/rfc2617#section-3.2.1">
http://tools.ietf.org/html/rfc2617#section-3.2.1</a> for more details.
</dd>
<p><code>httxt2dbm</code> is used to generate dbm files from text input, for
use in <code class="directive"><a href="../mod/mod_rewrite.html#rewritemap">RewriteMap</a></code> with the
<code>dbm</code> map type.</p>
-
+
<p>If the output file already exists, it will not be truncated. New keys will be
added and existing keys will be updated.</p>
</div>
<p><code>httxt2dbm</code> is used to generate dbm files from text input, for
use in <directive module="mod_rewrite">RewriteMap</directive> with the
<code>dbm</code> map type.</p>
-
+
<p>If the output file already exists, it will not be truncated. New keys will be
added and existing keys will be updated.</p>
</summary>
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1585159:1673932 (outdated) -->
+<!-- English Revision: 1585159:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<a href="../tr/rewrite/" hreflang="tr" rel="alternate" title="Türkçe"> tr </a> |
<a href="../zh-cn/rewrite/" hreflang="zh-cn" rel="alternate" title="Simplified Chinese"> zh-cn </a></p>
</div>
+<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
+ anglaise pour les changements récents.</div>
<p><code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> permet de modifier les requêtes
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision : 1328303 -->
+<!-- English Revision: 1328303:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<variants>
<variant>en</variant>
- <variant>fr</variant>
+ <variant outdated="yes">fr</variant>
<variant outdated="yes">tr</variant>
<variant outdated="yes">zh-cn</variant>
</variants>
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1174747:1328303 (outdated) -->
+<!-- English Revision: 1174747:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.zh-cn.xsl"?>
-<!-- English Revision: 1028730:1328303 (outdated) -->
+<!-- English Revision: 1028730:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<p><span>Langues Disponibles: </span><a href="../en/rewrite/intro.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/rewrite/intro.html" title="Français"> fr </a></p>
</div>
+<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
+ anglaise pour les changements récents.</div>
<p>Ce document est un complément à la <a href="../mod/mod_rewrite.html">documentation de référence</a> du module
<code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>. Il décrit les concepts de base dont la
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision : 1654831 -->
+<!-- English Revision: 1654831:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<variants>
<variant>en</variant>
- <variant>fr</variant>
+ <variant outdated="yes">fr</variant>
</variants>
</metafile>
<p><span>Langues Disponibles: </span><a href="../en/rewrite/tech.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/rewrite/tech.html" title="Français"> fr </a></p>
</div>
+<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
+ anglaise pour les changements récents.</div>
<p>Ce document passe en revue certains détails techniques à propos du
module mod_rewrite et de la mise en correspondance des URLs</p>
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision : 1533275 -->
+<!-- English Revision: 1533275:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<variants>
<variant>en</variant>
- <variant>fr</variant>
+ <variant outdated="yes">fr</variant>
</variants>
</metafile>
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1636195:1673930 (outdated) -->
+<!-- English Revision: 1636195:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
-<!-- English Revision: 420990:1673930 (outdated) -->
+<!-- English Revision: 420990:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
-<!-- English Revision: 105989:1673930 (outdated) -->
+<!-- English Revision: 105989:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>
-<!-- English Revision: 1300910:1673930 (outdated) -->
+<!-- English Revision: 1300910:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<p><span>Langues Disponibles: </span><a href="../en/ssl/ssl_faq.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/ssl/ssl_faq.html" title="Français"> fr </a></p>
</div>
+<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
+ anglaise pour les changements récents.</div>
<blockquote>
<p>Le sage n'apporte pas de bonnes réponses, il pose les bonnes questions</p>
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English revision : 1591196 -->
+<!-- English Revision: 1591196:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<variants>
<variant>en</variant>
- <variant>fr</variant>
+ <variant outdated="yes">fr</variant>
</variants>
</metafile>
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1635558:1673582 (outdated) -->
+<!-- English Revision: 1635558:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<a href="./ko/suexec.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="./tr/suexec.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div>
+<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
+ anglaise pour les changements récents.</div>
<p>La fonctionnalité <strong>suEXEC</strong> permet
l'exécution des programmes <strong>CGI</strong> et
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1342078 -->
+<!-- English Revision: 1342078:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
-<!-- English Revision: 655869:1342078 (outdated) -->
+<!-- English Revision: 655869:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
-<!-- English Revision: 105989:1342078 (outdated) -->
+<!-- English Revision: 105989:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<variants>
<variant>en</variant>
- <variant>fr</variant>
+ <variant outdated="yes">fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">ko</variant>
<variant outdated="yes">tr</variant>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>
-<!-- English Revision: 1038591:1342078 (outdated) -->
+<!-- English Revision: 1038591:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
which the authorization directives are applied.</p>
<p>Directives that control how authorization modules respond when they don't match
- the authenticated user have been removed: This includes
- AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative,
+ the authenticated user have been removed: This includes
+ AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative,
AuthzGroupFileAuthoritative, AuthzUserAuthoritative,
and AuthzOwnerAuthoritative. These directives have been replaced by the
- more expressive <code class="directive"><a href="./mod/mod_authz_core.html#requireany">RequireAny</a></code>,
+ more expressive <code class="directive"><a href="./mod/mod_authz_core.html#requireany">RequireAny</a></code>,
<code class="directive"><a href="./mod/mod_authz_core.html#requirenone">RequireNone</a></code>, and
<code class="directive"><a href="./mod/mod_authz_core.html#requireall">RequireAll</a></code>.</p>
- <p>If you use <code class="module"><a href="./mod/mod_authz_dbm.html">mod_authz_dbm</a></code>, you must port your
+ <p>If you use <code class="module"><a href="./mod/mod_authz_dbm.html">mod_authz_dbm</a></code>, you must port your
configuration to use <code>Require dbm-group ...</code> in place
of <code>Require group ...</code>.</p>
<code>jsessionid</code>.
</li>
- <li><code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code>: The second parameter to
+ <li><code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code>: The second parameter to
<code class="directive"><a href="./mod/mod_cache.html#cacheenable">CacheEnable</a></code> only
matches forward proxy content if it begins with the correct
protocol. In 2.2 and earlier, a parameter of '/' matched all
no longer supported. <code class="directive"><a href="./mod/mod_ssl.html#sslproxycheckpeercn">SSLProxyCheckPeerCN
</a></code> and <code class="directive"><a href="./mod/mod_ssl.html#sslproxycheckpeerexpire">SSLProxyCheckPeerExpire
</a></code> now default to On, causing proxy requests to HTTPS hosts
- with bad or outdated certificates to fail with a 502 status code (Bad
+ with bad or outdated certificates to fail with a 502 status code (Bad
gateway)</li>
<li><code class="program"><a href="./programs/htpasswd.html">htpasswd</a></code> now uses MD5 hash by default on
<li>The functionality provided by <code>mod_authn_alias</code>
in previous versions (i.e., the <code class="directive"><a href="./mod/mod_authn_core.html#authnprovideralias">AuthnProviderAlias</a></code> directive)
- has been moved into <code class="module"><a href="./mod/mod_authn_core.html">mod_authn_core</a></code>.
+ has been moved into <code class="module"><a href="./mod/mod_authn_core.html">mod_authn_core</a></code>.
</li>
<li><code class="module"><a href="./mod/mod_cgid.html">mod_cgid</a></code> uses the servers <code class="directive"><a href="./mod/core.html#timeout">Timeout</a></code> to limit the length of time to wait for CGI output.
- load module <code class="module"><a href="./mod/mod_access_compat.html">mod_access_compat</a></code>, or update configuration to 2.4 authorization directives.</li>
<li><code>Ignoring deprecated use of DefaultType in line NN of /path/to/httpd.conf</code> - remove <code class="directive"><a href="./mod/core.html#defaulttype">DefaultType</a></code>
and replace with other configuration settings.</li>
- <li><code>Invalid command 'AddOutputFilterByType', perhaps misspelled
+ <li><code>Invalid command 'AddOutputFilterByType', perhaps misspelled
or defined by a module not included in the server configuration
- </code> - <code class="directive"><a href="./mod/mod_filter.html#addoutputfilterbytype">AddOutputFilterByType</a></code>
+ </code> - <code class="directive"><a href="./mod/mod_filter.html#addoutputfilterbytype">AddOutputFilterByType</a></code>
has moved from the core to mod_filter, which must be loaded.</li>
</ul></li>
<li>Errors serving requests:
which the authorization directives are applied.</p>
<p>Directives that control how authorization modules respond when they don't match
- the authenticated user have been removed: This includes
- AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative,
+ the authenticated user have been removed: This includes
+ AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative,
AuthzGroupFileAuthoritative, AuthzUserAuthoritative,
and AuthzOwnerAuthoritative. These directives have been replaced by the
- more expressive <directive module="mod_authz_core">RequireAny</directive>,
+ more expressive <directive module="mod_authz_core">RequireAny</directive>,
<directive module="mod_authz_core">RequireNone</directive>, and
<directive module="mod_authz_core">RequireAll</directive>.</p>
- <p>If you use <module>mod_authz_dbm</module>, you must port your
+ <p>If you use <module>mod_authz_dbm</module>, you must port your
configuration to use <code>Require dbm-group ...</code> in place
of <code>Require group ...</code>.</p>
<code>jsessionid</code>.
</li>
- <li><module>mod_cache</module>: The second parameter to
+ <li><module>mod_cache</module>: The second parameter to
<directive module="mod_cache">CacheEnable</directive> only
matches forward proxy content if it begins with the correct
protocol. In 2.2 and earlier, a parameter of '/' matched all
no longer supported. <directive module="mod_ssl">SSLProxyCheckPeerCN
</directive> and <directive module="mod_ssl">SSLProxyCheckPeerExpire
</directive> now default to On, causing proxy requests to HTTPS hosts
- with bad or outdated certificates to fail with a 502 status code (Bad
+ with bad or outdated certificates to fail with a 502 status code (Bad
gateway)</li>
<li><program>htpasswd</program> now uses MD5 hash by default on
</li>
<li>The functionality provided by <code>mod_authn_alias</code>
- in previous versions (i.e., the <directive
+ in previous versions (i.e., the <directive
module="mod_authn_core">AuthnProviderAlias</directive> directive)
- has been moved into <module>mod_authn_core</module>.
+ has been moved into <module>mod_authn_core</module>.
</li>
<li><module>mod_cgid</module> uses the servers <directive module="core"
- load module <module>mod_access_compat</module>, or update configuration to 2.4 authorization directives.</li>
<li><code>Ignoring deprecated use of DefaultType in line NN of /path/to/httpd.conf</code> - remove <directive module="core">DefaultType</directive>
and replace with other configuration settings.</li>
- <li><code>Invalid command 'AddOutputFilterByType', perhaps misspelled
+ <li><code>Invalid command 'AddOutputFilterByType', perhaps misspelled
or defined by a module not included in the server configuration
- </code> - <directive module="mod_filter">AddOutputFilterByType</directive>
+ </code> - <directive module="mod_filter">AddOutputFilterByType</directive>
has moved from the core to mod_filter, which must be loaded.</li>
</ul></li>
<li>Errors serving requests:
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1561569:1673930 (outdated) -->
+<!-- English Revision: 1561569:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
-<!-- English Revision: 151408:1673930 (outdated) -->
+<!-- English Revision: 151408:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
-<!-- English Revision: 151408:1673930 (outdated) -->
+<!-- English Revision: 151408:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>
-<!-- English Revision: 1310494:1673930 (outdated) -->
+<!-- English Revision: 1310494:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
server does not support <a class="glossarylink" href="../glossary.html#servernameindication" title="see glossary">Server Name Indication</a>.</p>
<p>The complete list of names in the <code>VirtualHost</code>
- directive are treated just like a (non wildcard) <code>ServerAlias</code>
+ directive are treated just like a (non wildcard) <code>ServerAlias</code>
(but are not overridden by any <code>ServerAlias</code> statement).</p>
<p>For every vhost various default values are set. In
ref="servernameindication">Server Name Indication</glossary>.</p>
<p>The complete list of names in the <code>VirtualHost</code>
- directive are treated just like a (non wildcard) <code>ServerAlias</code>
+ directive are treated just like a (non wildcard) <code>ServerAlias</code>
(but are not overridden by any <code>ServerAlias</code> statement).</p>
<p>For every vhost various default values are set. In
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1628690:1673930 (outdated) -->
+<!-- English Revision: 1628690:1673945 (outdated) -->
<!-- French translation by Vincent Deffontaines, Alain B. -->
<!-- reviewed by Lucien Gentis -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 659902:1673930 (outdated) -->
+<!-- English Revision: 659902:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version='1.0' encoding='EUC-KR' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 105989:1673930 (outdated) -->
+<!-- English Revision: 105989:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1132802:1673930 (outdated) -->
+<!-- English Revision: 1132802:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1436578:1673917 (outdated) -->
+<!-- English Revision: 1436578:1673945 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!--
<?xml version='1.0' encoding='EUC-KR' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 151408:1673917 (outdated) -->
+<!-- English Revision: 151408:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1174747:1673917 (outdated) -->
+<!-- English Revision: 1174747:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.de.xsl"?>
-<!-- English Revision: 420990:1673917 (outdated) -->
+<!-- English Revision: 420990:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1647229:1673917 (outdated) -->
+<!-- English Revision: 1647229:1673945 (outdated) -->
<!-- French translation by alain B, review by Vincent Deffontaines
updated by Lucien GENTIS -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 420990:1673917 (outdated) -->
+<!-- English Revision: 420990:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version='1.0' encoding='EUC-KR' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 420990:1673917 (outdated) -->
+<!-- English Revision: 420990:1673945 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1301398:1673917 (outdated) -->
+<!-- English Revision: 1301398:1673945 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
projects / apache / commitdiff