From: Daniel Gruno Date: Wed, 25 Apr 2012 06:53:02 +0000 (+0000) Subject: Change remaining tags to X-Git-Tag: 2.5.0-alpha~7054 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=d84d3e8e857403be9ced928f8c995b015b699cf5;p=apache Change remaining tags to git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1330134 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/developer/modguide.html.en b/docs/manual/developer/modguide.html.en index 6a4f67437a..24c93cf698 100644 --- a/docs/manual/developer/modguide.html.en +++ b/docs/manual/developer/modguide.html.en @@ -125,7 +125,10 @@ of the module is used primarily for two things:
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:

-
LoadModule example_module modules/mod_example.so
+
+LoadModule example_module modules/mod_example.so
+
+

In essence, this tells the server to open up mod_example.so and look for a module called example_module. @@ -168,9 +171,10 @@ our example case, we want every request ending with .sum to be served by mod_example, so we'll add a configuration directive that tells the server to do just that:

-
+
 AddHandler example-handler .sum
-
+ +

What this tells the server is the following: Whenever we receive a request for a URI ending in .sum, we are to let all modules know that we are @@ -742,11 +746,12 @@ 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 mod_rewrite works:

-
+
 RewriteEngine On
 RewriteCond %{REQUEST_URI} ^/foo/bar
 RewriteRule ^/foo/bar/(.*)$ /foobar?page=$1
-
+ +

Each of these configuration directives are handled by a separate function, that parses the parameters given and sets up a configuration accordingly. @@ -822,11 +827,12 @@ module AP_MODULE_DECLARE_DATA example_module = So far so good. To access our new handler, we could add the following to our configuration:

-
+
 <Location /example>
     SetHandler example-handler
 </Location>
-
+ +

When we visit, we'll see our current configuration being spit out by our module. @@ -1077,11 +1083,12 @@ module AP_MODULE_DECLARE_DATA example_module = In our httpd.conf file, we can now change the hard-coded configuration by adding a few lines:

-
+
 ExampleEnabled On
 ExamplePath "/usr/bin/foo"
 ExampleAction file allow
-
+ +

And thus we apply the configuration, visit /example on our web site, and we see the configuration has adapted to what we wrote in our @@ -1269,7 +1276,7 @@ Our next step in creating a context aware configuration is merging configurations. This part of the process particularly apply to scenarios where you have a parent configuration and a child, such as the following:

-
+
 <Directory "/var/www">
     ExampleEnable On
     ExamplePath /foo/bar
@@ -1278,7 +1285,8 @@ where you have a parent configuration and a child, such as the following:
 <Directory "/var/www/subdir">
     ExampleAction file deny
 </Directory>
-
+ +

In this example, it is natural to assume that the directory /var/www/subdir should inherit the value set for the /var/www @@ -1325,7 +1333,7 @@ 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:

-
+
 <Location "/a">
     SetHandler example-handler
     ExampleEnabled on
@@ -1343,7 +1351,8 @@ how the module works:
     ExamplePath "/foo/bar/baz"
     ExampleEnabled on
 </Location>
-
+ +

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 diff --git a/docs/manual/developer/modguide.xml b/docs/manual/developer/modguide.xml index f03911eec8..3376e645d2 100644 --- a/docs/manual/developer/modguide.xml +++ b/docs/manual/developer/modguide.xml @@ -120,7 +120,9 @@ of the module is used primarily for two things:
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:

-
LoadModule example_module modules/mod_example.so
 + +LoadModule example_module modules/mod_example.so +

In essence, this tells the server to open up mod_example.so and look for a module called example_module. @@ -162,9 +164,9 @@ our example case, we want every request ending with .sum to be served by mod_example, so we'll add a configuration directive that tells the server to do just that:

-
+
 AddHandler example-handler .sum
-
 +

What this tells the server is the following: Whenever we receive a request for a URI ending in .sum, we are to let all modules know that we are @@ -725,11 +727,11 @@ 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 mod_rewrite works:

-
+
 RewriteEngine On
 RewriteCond %{REQUEST_URI} ^/foo/bar
 RewriteRule ^/foo/bar/(.*)$ /foobar?page=$1
-
 +

Each of these configuration directives are handled by a separate function, that parses the parameters given and sets up a configuration accordingly. @@ -803,11 +805,11 @@ module AP_MODULE_DECLARE_DATA example_module = So far so good. To access our new handler, we could add the following to our configuration:

-
+
 <Location /example>
     SetHandler example-handler
 </Location>
-
 +

When we visit, we'll see our current configuration being spit out by our module. @@ -1054,11 +1056,11 @@ module AP_MODULE_DECLARE_DATA example_module = In our httpd.conf file, we can now change the hard-coded configuration by adding a few lines:

-
+
 ExampleEnabled On
 ExamplePath "/usr/bin/foo"
 ExampleAction file allow
-
 +

And thus we apply the configuration, visit /example on our web site, and we see the configuration has adapted to what we wrote in our @@ -1239,7 +1241,7 @@ Our next step in creating a context aware configuration is merging configurations. This part of the process particularly apply to scenarios where you have a parent configuration and a child, such as the following:

-
+
 <Directory "/var/www">
     ExampleEnable On
     ExamplePath /foo/bar
@@ -1248,7 +1250,7 @@ where you have a parent configuration and a child, such as the following:
 <Directory "/var/www/subdir">
     ExampleAction file deny
 </Directory>
-
 +

In this example, it is natural to assume that the directory /var/www/subdir should inherit the value set for the /var/www @@ -1294,7 +1296,7 @@ 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:

-
+
 <Location "/a">
     SetHandler example-handler
     ExampleEnabled on
@@ -1312,7 +1314,7 @@ how the module works:
     ExamplePath "/foo/bar/baz"
     ExampleEnabled on
 </Location>
-
 +

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