Imported Upstream version 2.4.6upstream/2.4.6

3 files changed, 38 insertions, 23 deletions

diff --git a/docs/manual/developer/modguide.html.en b/docs/manual/developer/modguide.html.en
index 5e44f7e6..5f3ed86a 100644
--- a/docs/manual/developer/modguide.html.en
+++ b/docs/manual/developer/modguide.html.en
@@ -55,7 +55,7 @@ http://www.example.com/index.html.sum</code>.
 <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 
-write out its own configuration to the client.
+writes out its own configuration to the client.
 </p>
 
 
@@ -314,11 +314,11 @@ looks like
 <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_req* </code> structure passed along with every call that is made. 
-This struct, typically just refered to as <code>r</code> in modules, 
+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_req </code> structure are:
+request_rec </code> structure are:
 </p>
 <ul>
 <li><code>r-&gt;handler (char*):</code> Contains the name of the handler the server is currently asking to do the handling of this request</li>
@@ -333,7 +333,7 @@ request_req </code> structure are:
 "<a href="#memory">Memory management</a>" chapter.</li>
 </ul>
 <p>
-A complete list of all the values contained with in the <code>request_req</code> structure can be found in 
+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>
@@ -428,7 +428,7 @@ the next, without informing other handlers.
 
 <ul>
 <li>
-    <code>ap_rputs(const char *string, request_req *r)</code>: <br />
+    <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>.
     
@@ -454,7 +454,7 @@ the next, without informing other handlers.
 </li>
 <li>
     <code>
-    <a href="http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__PROTO.html#gaa2f8412c400197338ec509f4a45e4579">ap_set_content_type</a>(request_req *r, const char *type)</code>: <br />
+    <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.
     
 
@@ -728,7 +728,7 @@ static int example_handler(request_rec *r)
 
 
 <p>
-This version in its entirity 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>
 
@@ -917,7 +917,7 @@ set them.</em>)
 
 <h3><a name="directive_handler" id="directive_handler">The directive handler function</a></h3>
 <p>
-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:</p>
 
 
 <pre class="prettyprint lang-c">
-/* 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 <code>ACCESS_CONF</code>, which lets us use 
-the directive inside &lt;Directory&gt; and &lt;Location&gt; blocks.
+the directive inside &lt;Directory&gt; and &lt;Location&gt; blocks. For more 
+control over the placement of your directives, you can combine the following 
+restrictions together to form a specific rule:
 </p>
+<ul>
+<li><code>RSRC_CONF</code>: Allow in .conf files (not .htaccess) outside &lt;Directory&gt; or &lt;Location&gt;</li>
+<li><code>ACCESS_CONF</code>: Allow in .conf files (not .htaccess) inside &lt;Directory&gt; or &lt;Location&gt;</li>
+<li><code>OR_OPTIONS</code>: Allow in .conf files and .htaccess when <code>AllowOverride Options</code> is set</li>
+<li><code>OR_FILEINFO</code>: Allow in .conf files and .htaccess when <code>AllowOverride FileInfo</code> is set</li>
+<li><code>OR_AUTHCFG</code>: Allow in .conf files and .htaccess when <code>AllowOverride AuthConfig</code> is set</li>
+<li><code>OR_INDEXES</code>: Allow in .conf files and .htaccess when <code>AllowOverride Indexes</code> is set</li>
+<li><code>OR_ALL</code>: Allow anywhere in .conf files and .htaccess</li>
+</ul>
 
 
 <h3><a name="context_pool" id="context_pool">Using the server to allocate configuration slots</a></h3>
@@ -1279,12 +1290,12 @@ void* example_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 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: 
 </p>
 <pre class="prettyprint lang-config">
 &lt;Directory "/var/www"&gt;
-    ExampleEnable On
+    ExampleEnabled On
     ExamplePath /foo/bar
     ExampleAction file allow
 &lt;/Directory&gt;
@@ -1295,8 +1306,8 @@ where you have a parent configuration and a child, such as the following:
 
 <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
-</code> directory, as we did not specify a <code>ExampleEnable</code> nor 
+/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 
 know if this is true, but cleverly does the following:
 </p>
@@ -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)
 
 
 <pre class="prettyprint lang-c">
-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)
 
       <p>In the <code>mod_mmap_static</code> case I didn't care about the
       <code>post_config</code> stage, but the <code>mmap_static_xlat</code>
-      <strong>must</strong> be called after the core module had done it's name
+      <strong>must</strong> be called after the core module had done its name
       translation, hence the use of the aszPre to define a modifier to the
       position <code>HOOK_LAST</code>.</p>
     
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 @@
       <dt><code>unixd_config</code></dt>
       <dd>This has been renamed to ap_unixd_config.</dd>
 
+      <dt><code>unixd_setup_child()</code></dt>
+      <dd>This has been renamed to ap_unixd_setup_child(), but most callers
+          should call the added ap_run_drop_privileges() hook.</dd>
+
       <dt><code>conn_rec-&gt;remote_ip</code> and 
           <code>conn_rec-&gt;remote_addr</code></dt>
       <dd>These fields have been renamed in order to distinguish between