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>
-<div class="example"><pre><a href="../mod/mod_so.html#LoadModule">LoadModule</a> example_module modules/mod_example.so</pre></div>
+<pre class="prettyprint lang-config">
+<a href="../mod/mod_so.html#LoadModule">LoadModule</a> 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
called <code>example_module</code>.
<code>mod_example</code>, so we'll add a configuration directive that tells
the server to do just that:
</p>
-<div class="example"><pre>
+<pre class="prettyprint lang-config">
AddHandler example-handler .sum
-</pre></div>
+</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
telling an individual module (or a set of modules) how to behave, such as
these directives control how <code>mod_rewrite</code> works:
</p>
-<div class="example"><pre>
+<pre class="prettyprint lang-config">
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/foo/bar
RewriteRule ^/foo/bar/(.*)$ /foobar?page=$1
-</pre></div>
+</pre>
+
<p>
Each of these configuration directives are handled by a separate function,
that parses the parameters given and sets up a configuration accordingly.
So far so good. To access our new handler, we could add the following to
our configuration:
</p>
-<div class="example"><pre>
+<pre class="prettyprint lang-config">
<Location /example>
SetHandler example-handler
</Location>
-</pre></div>
+</pre>
+
<p>
When we visit, we'll see our current configuration being spit out by our
module.
In our httpd.conf file, we can now change the hard-coded configuration by
adding a few lines:
</p>
-<div class="example"><pre>
+<pre class="prettyprint lang-config">
ExampleEnabled On
ExamplePath "/usr/bin/foo"
ExampleAction file allow
-</pre></div>
+</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
configurations. This part of the process particularly apply to scenarios
where you have a parent configuration and a child, such as the following:
</p>
-<div class="example"><pre>
+<pre class="prettyprint lang-config">
<Directory "/var/www">
ExampleEnable On
ExamplePath /foo/bar
<Directory "/var/www/subdir">
ExampleAction file deny
</Directory>
-</pre></div>
+</pre>
+
<p>
In this example, it is natural to assume that the directory <code>
/var/www/subdir</code> should inherit the value set for the <code>/var/www
context aware. First off, we'll create a configuration that lets us test
how the module works:
</p>
-<div class="example"><pre>
+<pre class="prettyprint lang-config">
<Location "/a">
SetHandler example-handler
ExampleEnabled on
ExamplePath "/foo/bar/baz"
ExampleEnabled on
</Location>
-</pre></div>
+</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
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>
-<example><pre><a href="../mod/mod_so.html#LoadModule">LoadModule</a> example_module modules/mod_example.so</pre></example>
+<highlight language="config">
+<a href="../mod/mod_so.html#LoadModule">LoadModule</a> 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
called <code>example_module</code>.
<code>mod_example</code>, so we'll add a configuration directive that tells
the server to do just that:
</p>
-<example><pre>
+<highlight language="config">
AddHandler example-handler .sum
-</pre></example>
+</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
telling an individual module (or a set of modules) how to behave, such as
these directives control how <code>mod_rewrite</code> works:
</p>
-<example><pre>
+<highlight language="config">
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/foo/bar
RewriteRule ^/foo/bar/(.*)$ /foobar?page=$1
-</pre></example>
+</highlight>
<p>
Each of these configuration directives are handled by a separate function,
that parses the parameters given and sets up a configuration accordingly.
So far so good. To access our new handler, we could add the following to
our configuration:
</p>
-<example><pre>
+<highlight language="config">
<Location /example>
SetHandler example-handler
</Location>
-</pre></example>
+</highlight>
<p>
When we visit, we'll see our current configuration being spit out by our
module.
In our httpd.conf file, we can now change the hard-coded configuration by
adding a few lines:
</p>
-<example><pre>
+<highlight language="config">
ExampleEnabled On
ExamplePath "/usr/bin/foo"
ExampleAction file allow
-</pre></example>
+</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
configurations. This part of the process particularly apply to scenarios
where you have a parent configuration and a child, such as the following:
</p>
-<example><pre>
+<highlight language="config">
<Directory "/var/www">
ExampleEnable On
ExamplePath /foo/bar
<Directory "/var/www/subdir">
ExampleAction file deny
</Directory>
-</pre></example>
+</highlight>
<p>
In this example, it is natural to assume that the directory <code>
/var/www/subdir</code> should inherit the value set for the <code>/var/www
context aware. First off, we'll create a configuration that lets us test
how the module works:
</p>
-<example><pre>
+<highlight language="config">
<Location "/a">
SetHandler example-handler
ExampleEnabled on
ExamplePath "/foo/bar/baz"
ExampleEnabled on
</Location>
-</pre></example>
+</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