As promised, attached three migrated docs.
I also included a file that I use as a template. Might be usefull.
Vincent de Lau
[EMAIL PROTECTED]
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?>
<manualpage>
<relativepath href="."/>
<title>...</title>
<summary>
<p>...</p>
</summary>
<section id="...">
<title>...</title>
<related>
<modulelist>
<module>...</module>
</modulelist>
<directivelist>
<directive module="...">...</directive>
</directivelist>
</related>
...
</section>
</manualpage>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?>
<manualpage>
<relativepath href="."/>
<title>Environment Variables in Apache</title>
<summary>
<p>The Apache HTTP Server provides a mechanism for storing
information in named variables that are called <em>environment
variables</em>. This information can be used to control various
operations such as logging or access control. The variables are
also used as a mechanism to communicate with external programs
such as CGI scripts. This document discusses different ways to
manipulate and use these variables.</p>
<p>Although these variables are referred to as <em>environment
variables</em>, they are not the same as the environment
variables controlled by the underlying operating system.
Instead, these variables are stored and manipulated in an
internal Apache structure. They only become actual operating
system environment variables when they are provided to CGI
scripts and Server Side Include scripts. If you wish to
manipulate the operating system environment under which the
server itself runs, you must use the standard environment
manipulation mechanisms provided by your operating system
shell.</p>
</summary>
<section id="setting">
<title>Setting Environment Variables</title>
<related>
<modulelist>
<module>mod_env</module>
<module>mod_rewrite</module>
<module>mod_setenvif</module>
<module>mod_unique_id</module>
</modulelist>
<directivelist>
<directive module="mod_setenvif">BrowserMatch</directive>
<directive module="mod_setenvif">BrowserMatchNoCase</directive>
<directive module="mod_env">PassEnv</directive>
<directive module="mod_rewrite">RewriteRule</directive>
<directive module="mod_env">SetEnv</directive>
<directive module="mod_setenvif">SetEnvIf</directive>
<directive module="mod_setenvif">SetEnvIfNoCase</directive>
<directive module="mod_env.html">UnsetEnv</directive>
</directivelist>
</related>
<section id="basic-manipulation">
<title>Basic Environment Manipulation</title>
<p>The most basic way to set an environment variable in Apache
is using the unconditional <directive module="mod_env"
>SetEnv</directive> directive. Variables may also be passed from
the environment of the shell which started the server using the
<directive module="mod_env">PassEnv</directive> directive.</p>
</section>
<section id="conditional">
<title>Conditional Per-Request Settings</title>
<p>For additional flexibility, the directives provided by
mod_setenvif allow environment variables to be set on a
per-request basis, conditional on characteristics of particular
requests. For example, a variable could be set only when a
specific browser (User-Agent) is making a request, or only when
a specific Referer [sic] header is found. Even more flexibility
is available through the mod_rewrite's <directive
module="mod_rewrite">RewriteRule</directive> which uses the
<code>[E=...]</code> option to set environment variables.</p>
</section>
<section id="unique-identifiers">
<title>Unique Identifiers</title>
<p>Finally, mod_unique_id sets the environment variable
<code>UNIQUE_ID</code> for each request to a value which is
guaranteed to be unique across "all" requests under very
specific conditions.</p>
</section>
<section id="standard-cgi">
<title>Standard CGI Variables</title>
<p>In addition to all environment variables set within the
Apache configuration and passed from the shell, CGI scripts and
SSI pages are provided with a set of environment variables
containing meta-information about the request as required by
the <a href="http://cgi-spec.golux.com/";>CGI
specification</a>.</p>
</section>
<section id="caveats">
<title>Some Caveats</title>
<ul>
<li>It is not possible to override or change the standard CGI
variables using the environment manipulation directives.</li>
<li>When <a href="suexec.html">suexec</a> is used to launch
CGI scripts, the environment will be cleaned down to a set of
<em>safe</em> variables before CGI scripts are launched. The
list of <em>safe</em> variables is defined at compile-time in
<code>suexec.c</code>.</li>
<li>For portability reasons, the names of environment
variables may contain only letters, numbers, and the
underscore character. In addition, the first character may
not be a number. Characters which do not match this
restriction will be replaced by an underscore when passed to
CGI scripts and SSI pages.</li>
</ul>
</section>
</section>
<section id="using">
<title>Using Environment Variables</title>
<related>
<modulelist>
<module>mod_access</module>
<module>mod_cgi</module>
<module>mod_headers</module>
<module>mod_include</module>
<module>mod_log_config</module>
<module>mod_rewrite</module>
</modulelist>
<directivelist>
<directive module="mod_access">Allow</directive>
<directive module="mod_log_config">CustomLog</directive>
<directive module="mod_access">Deny</directive>
<directive module="mod_headers">Header</directive>
<directive module="mod_log_config">LogFormat</directive>
<directive module="mod_rewrite">RewriteCond</directive>
<directive module="mod_rewrite">RewriteRule</directive>
</directivelist>
</related>
<section id="cgi-scripts">
<title>CGI Scripts</title>
<p>One of the primary uses of environment variables is to
communicate information to CGI scripts. As discussed above, the
environment passed to CGI scripts includes standard
meta-information about the request in addition to any variables
set within the Apache configuration. For more details, see the
<a href="howto/cgi.html">CGI tutorial</a>.</p>
</section>
<section id="ssi-pages">
<title>SSI Pages</title>
<p>Server-parsed (SSI) documents processed by mod_include's
<code>INCLUDES</code> filter can print environment variables
using the <code>echo</code> element, and can use environment
variables in flow control elements to makes parts of a page
conditional on characteristics of a request. Apache also
provides SSI pages with the standard CGI environment variables
as discussed above. For more details, see the <a
href="howto/ssi.html">SSI tutorial</a>.</p>
</section>
<section id="access-control">
<title>Access Control</title>
<p>Access to the server can be controlled based on the value of
environment variables using the <code>allow from env=</code>
and <code>deny from env=</code> directives. In combination with
<directive module="mod_setenvif">SetEnvIf</directive>, this
allows for flexible control of access to the server based on
characteristics of the client. For example, you can use these
directives to deny access to a particular browser (User-Agent).
</p>
</section>
<section id="logging">
<title>Conditional Logging</title>
<p>Environment variables can be logged in the access log using
the <directive module="mod_log_config">LogFormat</directive>
option <code>%e</code>. In addition, the decision on whether
or not to log requests can be made based on the status of
environment variables using the conditional form of the
<directive module="mod_log_config">CustomLog</directive>
directive. In combination with <directive module="mod_setenvif"
>SetEnvIf</directive> this allows for flexible control of which
requests are logged. For example, you can choose not to log
requests for filenames ending in <code>gif</code>, or you can
choose to only log requests from clients which are outside your
subnet.</p>
</section>
<section id="response-headers">
<title>Conditional Response Headers</title>
<p>The <directive module="mod_headers">Header</directive>
directive can use the presence or
absence of an environment variable to determine whether or not
a certain HTTP header will be placed in the response to the
client. This allows, for example, a certain response header to
be sent only if a corresponding header is received in the
request from the client.</p>
</section>
<section id="url-rewriting">
<title>URL Rewriting</title>
<p>The <code>%{ENV:...}</code> form of <em>TestString</em> in
the <directive module="mod_rewrite">RewriteCond</directive>
allows mod_rewrite's rewrite
engine to make decisions conditional on environment variables.
Note that the variables accessible in mod_rewrite without the
<code>ENV:</code> prefix are not actually environment
variables. Rather, they are variables special to mod_rewrite
which cannot be accessed from other modules.</p>
</section>
</section>
<section id="special">
<title>Special Purpose Environment Variables</title>
<p>Interoperability problems have led to the introduction of
mechanisms to modify the way Apache behaves when talking to
particular clients. To make these mechanisms as flexible as
possible, they are invoked by defining environment variables,
typically with <directive module="mod_setenvif">BrowserMatch</directive>,
though <directive module="mod_env">SetEnv</directive> and
<directive module="mod_env">PassEnv</directive> could also be used,
for example.</p>
<section id="downgrade">
<title>downgrade-1.0</title>
<p>This forces the request to be treated as a HTTP/1.0 request
even if it was in a later dialect.</p>
</section>
<section id="force-no-vary">
<title>force-no-vary</title>
<p>This causes any <code>Vary</code> fields to be removed from
the response header before it is sent back to the client. Some
clients don't interpret this field correctly (see the <a
href="misc/known_client_problems.html">known client
problems</a> page); setting this variable can work around this
problem. Setting this variable also implies
<strong>force-response-1.0</strong>.</p>
</section>
<section id="force-response">
<title>force-response-1.0</title>
<p>This forces an HTTP/1.0 response when set. It was originally
implemented as a result of a problem with AOL's proxies. Some
clients may not behave correctly when given an HTTP/1.1
response, and this can be used to interoperate with them.</p>
</section>
<section id="nokeepalive">
<title>nokeepalive</title>
<p>This disables <directive module="core">KeepAlive</directive> when set.</p>
</section>
<section id="redirect-carefully">
<title>redirect-carefully</title>
<p>This forces the server to be more careful when sending a redirect
to the client. This is typically used when a client has a known
problem handling redirects. This was originally implemented as a
result of a problem with Microsoft's WebFolders software which has
a problem handling redirects on directory resources via DAV
methods.</p>
</section>
</section>
<section id="examples">
<title>Examples</title>
<section id="misbehaving">
<title>Changing protocol behavior with misbehaving clients</title>
<p>We recommend that the following lines be included in
httpd.conf to deal with known client problems.</p>
<example><pre>
#
# The following directives modify normal HTTP response behavior.
# The first directive disables keepalive for Netscape 2.x and browsers that
# spoof it. There are known problems with these browser implementations.
# The second directive is for Microsoft Internet Explorer 4.0b2
# which has a broken HTTP/1.1 implementation and does not properly
# support keepalive when it is used on 301 or 302 (redirect) responses.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
#
# The following directive disables HTTP/1.1 responses to browsers which
# are in violation of the HTTP/1.0 spec by not being able to grok a
# basic 1.1 response.
#
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0</pre></example>
</section>
<section id="no-img-log">
<title>Do not log requests for images in the access log</title>
<p>This example keeps requests for images from appearing in the
access log. It can be easily modified to prevent logging of
particular directories, or to prevent logging of requests
coming from particular hosts.</p>
<example><pre>
SetEnvIf Request_URI \.gif image-request
SetEnvIf Request_URI \.jpg image-request
SetEnvIf Request_URI \.png image-request
CustomLog logs/access_log common env=!image-request</pre></example>
</section>
<section id="image-theft">
<title>Prevent "Image Theft"</title>
<p>This example shows how to keep people not on your server
from using images on your server as inline-images on their
pages. This is not a recommended configuration, but it can work
in limited circumstances. We assume that all your images are in
a directory called /web/images.</p>
<example><pre>
SetEnvIf Referer "^http://www.example.com/"; local_referal
# Allow browsers that do not send Referer info
SetEnvIf Referer "^$" local_referal
<Directory /web/images>
Order Deny,Allow
Deny from all
Allow from env=local_referal
</Directory></pre></example>
<p>For more information about this technique, see the
ApacheToday tutorial " <a
href="http://apachetoday.com/news_story.php3?ltsn=2000-06-14-002-01-PS";>
Keeping Your Images from Adorning Other Sites</a>".</p>
</section>
</section>
</manualpage>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?>
<manualpage>
<relativepath href="."/>
<title>Filters</title>
<summary>
<p>This document describes the use of filters in Apache.</p>
</summary>
<section id="filters">
<title>Filters</title>
<related>
<modulelist>
<module>mod_deflate</module>
<module>mod_ext_filter</module>
<module>mod_include</module>
</modulelist>
<directivelist>
<directive module="mod_mime">AddInputFilter</directive>
<directive module="mod_mime">AddOutputFilter</directive>
<directive module="mod_ext_filter">ExtFilterDefine</directive>
<directive module="mod_ext_filter">ExtFilterOptions</directive>
<directive module="core.html">SetInputFilter</directive>
<directive module="core.html">SetOutputFilter</directive>
</directivelist>
</related>
<p>A <em>filter</em> is a process that is applied to data that
is sent or received by the server. Data sent by clients to the
server is processed by <em>input filters</em> while data sent
by the server to the client is processed by <em>output
filters</em>. Multiple filters can be applied to the data, and
the order of the filters can be explicitly specified.</p>
<p>Filters are used internally by Apache to perform functions such
as chunking and byte-range request handling. In addition, modules
can provide filters that are selectable using run-time
configuration directives. The set of filters that apply to data
can be manipulated with the <directive module="core.html"
>SetInputFilter</directive>, <directive module="core.html"
>SetOutputFilter</directive>, <directive module="mod_mime"
>AddInputFilter</directive>, and <directive module="mod_mime"
>AddOutputFilter</directive> directives.</p>
<p>The following user-selectable filters are currently provided
with the Apache HTTP Server distribution.</p>
<dl>
<dt>INCLUDES</dt>
<dd>Server-Side Includes processing by <module>mod_include</module></dd>
<dt>DEFLATE</dt>
<dd>Compress output before sending it to the client using <module
>mod_include</module></dd>
</dl>
<p>In addition, the module <module>mod_ext_filter</module> allows
for external programs to be defined as filters.</p>
</section>
</manualpage>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?>
<manualpage>
<relativepath href="."/>
<title>Apache's Handler Use</title>
<summary>
<p>This document describes the use of Apache's Handlers.</p>
</summary>
<section id="definition">
<title>What is a Handler</title>
<related>
<modulelist>
<module>mod_actions</module>
<module>mod_asis</module>
<module>mod_cgi</module>
<module>mod_imap</module>
<module>mod_info</module>
<module>mod_mime</module>
<module>mod_negotiation</module>
<module>mod_status</module>
</modulelist>
<directivelist>
<directive module="mod_actions">Action</directive>
<directive module="mod_mime">AddHandler</directive>
<directive module="mod_mime">RemoveHandler</directive>
<directive module="mod_mime">SetHandler</directive>
</directivelist>
</related>
<p>A "handler" is an internal Apache representation of the
action to be performed when a file is called. Generally, files
have implicit handlers, based on the file type. Normally, all
files are simply served by the server, but certain file types
are "handled" separately.</p>
<p>Apache 1.1 adds the ability to use handlers explicitly.
Based on either filename extensions or on location, handlers
can be specified without relation to file type. This is
advantageous both because it is a more elegant solution, and
because it also allows for both a type <strong>and</strong> a
handler to be associated with a file. (See also <a
href="mod/mod_mime.html#multipleext">Files with Multiple
Extensions</a>.)</p>
<p>Handlers can either be built into the server or included in
a module, or they can be added with the <directive
module="mod_actions">Action</directive> directive. The
built-in handlers in the standard distribution are as
follows:</p>
<ul>
<li><strong>default-handler</strong>: Send the file using the
<code>default_handler()</code>, which is the handler used by
default to handle static content. (core)</li>
<li><strong>send-as-is</strong>: Send file with HTTP headers
as is. (<module>mod_asis</module>)</li>
<li><strong>cgi-script</strong>: Treat the file as a CGI
script. (<module>mod_cgi</module>)</li>
<li><strong>imap-file</strong>: Parse as an imagemap rule
file. (<module>mod_imap</module>)</li>
<li><strong>server-info</strong>: Get the server's
configuration information. (<module>mod_info</module>)</li>
<li><strong>server-status</strong>: Get the server's status
report. (<module>mod_status</module>)</li>
<li><strong>type-map</strong>: Parse as a type map file for
content negotiation. (<module>mod_negotiation</module>)</li>
</ul>
</section>
<section id="examples">
<title>Examples</title>
<section id="example1">
<title>Modifying static content using a CGI script</title>
<p>The following directives will cause requests for files with
the <code>html</code> extension to trigger the launch of the
<code>footer.pl</code> CGI script.</p>
<example><code>
Action add-footer /cgi-bin/footer.pl<br/>
AddHandler add-footer .html
</code></example>
<p>Then the CGI script is responsible for sending the
originally requested document (pointed to by the
<code>PATH_TRANSLATED</code> environment variable) and making
whatever modifications or additions are desired.</p>
</section>
<section id="example2">
<title>Files with HTTP headers</title>
<p>The following directives will enable the
<code>send-as-is</code> handler, which is used for files which
contain their own HTTP headers. All files in the
<code>/web/htdocs/asis/</code> directory will be processed by
the <code>send-as-is</code> handler, regardless of their
filename extensions.</p>
<example><code>
<Directory /web/htdocs/asis><br/>
SetHandler send-as-is<br/>
</Directory>
</code></example>
</section>
</section>
<section id="programmer">
<title>Programmer's Note</title>
<p>In order to implement the handler features, an addition has
been made to the <a href="developer/API.html">Apache API</a> that
you may wish to make use of. Specifically, a new record has
been added to the <code>request_rec</code> structure:</p>
<pre>
char *handler
</pre>
<p>If you wish to have your module engage a handler, you need
only to set <code>r->handler</code> to the name of the
handler at any time prior to the <code>invoke_handler</code>
stage of the request. Handlers are implemented as they were
before, albeit using the handler name instead of a content
type. While it is not necessary, the naming convention for
handlers is to use a dash-separated word, with no slashes, so
as to not invade the media type name-space.</p>
</section>
</manualpage>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
