From 4a336a5b117419c33c29eadd6409c69df78cd586 Mon Sep 17 00:00:00 2001
From: Stefan Fritsch
In the second part of this document, which deals with configuration
directive and context awareness, we will be looking at a module that simply
-write out its own configuration to the client.
+writes out its own configuration to the client.
The most essential part of any request is the request record
. In a call to a handler function, this is represented by the Some key elements of the
-A complete list of all the values contained with in the
-This version in its entirity can be found here:
+This version in its entirety can be found here:
mod_example_2.c.
-Now that we've told the server to expect some directives for our module, it's
+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
@@ -927,7 +927,7 @@ has an additional parameter defined:The request_rec structure
-request_req*
structure passed along with every call that is made.
-This struct, typically just refered to as r
in modules,
+request_rec* structure passed along with every call that is made.
+This struct, typically just referred to as r
in modules,
contains all the information you need for your module to fully process any
HTTP request and respond accordingly.
-request_req
structure are:
+request_rec structure are:
r->handler (char*):
Contains the name of the handler the server is currently asking to do the handling of this requestrequest_req
structure can be found in
+A complete list of all the values contained within the request_rec
structure can be found in
the httpd.h
header
file or at http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html.
ap_rputs(const char *string, request_req *r)
:
+ ap_rputs(const char *string, request_rec *r)
:
Sends a string of text to the client. This is a shorthand version of
ap_rwrite.
@@ -454,7 +454,7 @@ the next, without informing other handlers.
- ap_set_content_type(request_req *r, const char *type)
:
+ ap_set_content_type(request_rec *r, const char *type):
Sets the content type of the output you are sending.
@@ -728,7 +728,7 @@ static int example_handler(request_rec *r)
The directive handler function
-/* Handler for the "exambleEnabled" directive */
+/* Handler for the "exampleEnabled" directive */
const char *example_set_enabled(cmd_parms *cmd, void *cfg, const char *arg)
{
if(!strcasecmp(arg, "on")) config.enabled = 1;
@@ -998,7 +998,7 @@ static example_config config;
Our directive handlers:
==============================================================================
*/
-/* Handler for the "exambleEnabled" directive */
+/* Handler for the "exampleEnabled" directive */
const char *example_set_enabled(cmd_parms *cmd, void *cfg, const char *arg)
{
if(!strcasecmp(arg, "on")) config.enabled = 1;
@@ -1217,8 +1217,19 @@ AP_INIT_TAKE1("exampleEnabled", example_set_enabled, NULL, RSRC_CONF, "Enable or
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
ACCESS_CONF
, which lets us use
-the directive inside <Directory> and <Location> blocks.
+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:
RSRC_CONF
: Allow in .conf files (not .htaccess) outside <Directory> or <Location>ACCESS_CONF
: Allow in .conf files (not .htaccess) inside <Directory> or <Location>OR_OPTIONS
: Allow in .conf files and .htaccess when AllowOverride Options
is setOR_FILEINFO
: Allow in .conf files and .htaccess when AllowOverride FileInfo
is setOR_AUTHCFG
: Allow in .conf files and .htaccess when AllowOverride AuthConfig
is setOR_INDEXES
: Allow in .conf files and .htaccess when AllowOverride Indexes
is setOR_ALL
: Allow anywhere in .conf files and .htaccessOur next step in creating a context aware configuration is merging -configurations. This part of the process particularly apply to scenarios +configurations. This part of the process particularly applies to scenarios where you have a parent configuration and a child, such as the following:
<Directory "/var/www"> - ExampleEnable On + ExampleEnabled On ExamplePath /foo/bar ExampleAction file allow </Directory> @@ -1295,8 +1306,8 @@ where you have a parent configuration and a child, such as the following:In this example, it is natural to assume that the directory
@@ -1478,7 +1489,7 @@ static int example_handler(request_rec *r) /* ======================================================================================================================= - Handler for the "exambleEnabled" directive + Handler for the "exampleEnabled" directive ======================================================================================================================= */ const char *example_set_enabled(cmd_parms *cmd, void *cfg, const char *arg) @@ -1625,7 +1636,7 @@ typedef struct { const char* value; } keyValuePair; -keyValuePair* readPost(request_req* r) { +keyValuePair* readPost(request_rec* r) { apr_array_header_t *pairs = NULL; apr_off_t len; apr_size_t size; @@ -1651,14 +1662,14 @@ keyValuePair* readPost(request_req* r) { return kvp; } -static int example_handler(request_req *r) +static int example_handler(request_rec *r) { /*~~~~~~~~~~~~~~~~~~~~~~*/ keyValuePair* formData; /*~~~~~~~~~~~~~~~~~~~~~~*/ - formData = readPost(); + formData = readPost(r); if (formData) { int i; for (i = 0; formData[i]; i++) { @@ -1679,7 +1690,7 @@ static int example_handler(request_req *r)-/var/www/subdir
should inherit the value set for the/var/www -
directory, as we did not specify aExampleEnable
nor +/var/www/subdir should inherit the values set for the/var/www +
directory, as we did not specify anExampleEnabled
nor anExamplePath
for this directory. The server does not presume to know if this is true, but cleverly does the following:-static int example_handler(request_req *r) +static int example_handler(request_rec *r) { /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/ const apr_array_header_t *fields; @@ -1741,7 +1752,7 @@ static int util_read(request_rec *r, const char **rbuf, apr_off_t *size) return(rc); } -static int example_handler(request_req* r) +static int example_handler(request_rec* r) { /*~~~~~~~~~~~~~~~~*/ apr_off_t size; diff --git a/docs/manual/developer/modules.html.en b/docs/manual/developer/modules.html.en index 5feb8af6..a600d5b6 100644 --- a/docs/manual/developer/modules.html.en +++ b/docs/manual/developer/modules.html.en @@ -121,7 +121,7 @@ static void register_hooks(void)In the
diff --git a/docs/manual/developer/new_api_2_4.html.en b/docs/manual/developer/new_api_2_4.html.en index 137bdbd5..ba10c06e 100644 --- a/docs/manual/developer/new_api_2_4.html.en +++ b/docs/manual/developer/new_api_2_4.html.en @@ -493,6 +493,10 @@mod_mmap_static
case I didn't care about thepost_config
stage, but themmap_static_xlat
- must be called after the core module had done it's name + must be called after the core module had done its name translation, hence the use of the aszPre to define a modifier to the positionHOOK_LAST
.
unixd_config
unixd_setup_child()
conn_rec->remote_ip
and
conn_rec->remote_addr