A few typo fixes

VERSIONING

@@ -31,7 +31,7 @@ STABLE RELEASES, 2.{even}.{revision}
 
 All even numbered releases will be considered stable revisions. 
 
-Stable revisions will retain forward compatiblity to the maximum
+Stable revisions will retain forward compatibility to the maximum
 possible extent.  Features may be added during minor revisions, and
 features may be deprecated by making appropriate notations in the
 documentation, but no features may be removed.
@@ -96,7 +96,7 @@ the current stable release.  Work proceeds on development releases, permitting
 the modification of the MMN at any time in order to correct deficiencies 
 or shortcomings in the API.  This means that modules from one development
 release to another may not be binary compatible, or may not successfully
-compile without modification to accomodate the API changes.
+compile without modification to accommodate the API changes.
 
 The only 'supported' development release at any time will be the most
 recently released version.  Developers will not be answering bug reports

docs/STATUS

@@ -121,7 +121,7 @@ To Do List
   are accurate, and others are way outdated.
 
 - I'd like to expand the discussion of conditional logging, and add a
-  few more useful exmaples.
+  few more useful examples.
   That would be a good place to document logging of cache hit/miss:
   https://issues.apache.org/bugzilla/show_bug.cgi?id=48241#c2
 

docs/man/ab.1

@@ -80,7 +80,7 @@ Do HEAD requests instead of GET\&.
 Enable the HTTP KeepAlive feature, \fIi\&.e\&.\fR, perform multiple requests within one HTTP session\&. Default is no KeepAlive\&.  
 .TP
 -l
-Do not report errors if the length of the responses is not constant\&. This can be usefull for dynamic pages\&.  
+Do not report errors if the length of the responses is not constant\&. This can be useful for dynamic pages\&.  
 .TP
 -n \fIrequests\fR
 Number of requests to perform for the benchmarking session\&. The default is to just perform a single request which usually leads to non-representative benchmarking results\&.  

docs/manual/developer/lua.html.en

@@ -79,7 +79,7 @@ that every call to a Lua script will spawn a new Lua state that handles that
 script and is destroyed immediately after. This option keeps the memory 
 footprint of mod_lua low, but also affects the processing speed of a request. 
 If you have the memory to spare, you can set the scope to <code>thread</code>, 
-which will make mod_lua spawn a Lua state that lasts the entirity of a thread's 
+which will make mod_lua spawn a Lua state that lasts the entirily of a thread's 
 lifetime, speeding up request processing by 2-3 times. Since mod_lua will create 
 a state for each script, this may be an expensive move, memory-wise, so to 
 compromise between speed and memory usage, you can choose the <code>server</code> 
@@ -466,7 +466,7 @@ end</pre>
 
 <pre class="prettyprint lang-lua">--[[ 
      This script has two user groups; members and admins, and whichever 
-     is refered to by the "Require rights" directive is checked to see
+     is referred to by the "Require rights" directive is checked to see
      if the authenticated user belongs to this group.
 ]]--
 

docs/manual/developer/lua.xml

@@ -76,7 +76,7 @@ that every call to a Lua script will spawn a new Lua state that handles that
 script and is destroyed immediately after. This option keeps the memory 
 footprint of mod_lua low, but also affects the processing speed of a request. 
 If you have the memory to spare, you can set the scope to <code>thread</code>, 
-which will make mod_lua spawn a Lua state that lasts the entirity of a thread's 
+which will make mod_lua spawn a Lua state that lasts the entirely of a thread's 
 lifetime, speeding up request processing by 2-3 times. Since mod_lua will create 
 a state for each script, this may be an expensive move, memory-wise, so to 
 compromise between speed and memory usage, you can choose the <code>server</code> 
@@ -483,7 +483,7 @@ LuaAuthzProvider rights /path/to/lua/script.lua rights_handler
 <highlight language="lua">
 --[[ 
      This script has two user groups; members and admins, and whichever 
-     is refered to by the "Require rights" directive is checked to see
+     is referred to by the "Require rights" directive is checked to see
      if the authenticated user belongs to this group.
 ]]--
 

docs/manual/glossary.html.en

@@ -357,7 +357,7 @@
       See: <a href="ssl/">SSL/TLS Encryption</a>
     </dd>
 
-    <dt><a name="regularexpresion" id="regularexpresion">Regular Expression</a>
+    <dt><a name="regularexpression" id="regularexpression">Regular Expression</a>
       <a name="regex" id="regex">(Regex)</a></dt>
     <dd>A way of describing a pattern in text - for example, "all the words that
       begin with the letter A" or "every 10-digit phone number" or even "Every

docs/manual/glossary.xml

@@ -371,7 +371,7 @@
       See: <a href="ssl/">SSL/TLS Encryption</a>
     </dd>
 
-    <dt><a name="regularexpresion" id="regularexpresion">Regular Expression</a>
+    <dt><a name="regularexpression" id="regularexpression">Regular Expression</a>
       <a name="regex" id="regex">(Regex)</a></dt>
     <dd>A way of describing a pattern in text - for example, "all the words that
       begin with the letter A" or "every 10-digit phone number" or even "Every

docs/manual/howto/auth.html.en

@@ -451,7 +451,7 @@ Require group GroupName</pre>
     and choosing how authorization will be done is now possible.</p>
 
     <h3><a name="authandororder" id="authandororder">Applying logic and ordering</a></h3>
-        <p>Controling how and in what order authorization will be applied
+        <p>Controlling how and in what order authorization will be applied
         has been a bit of a mystery in the past. In Apache 2.2 a provider-based
         authentication mechanism was introduced to decouple the actual
         authentication process from authorization and supporting functionality.

docs/manual/howto/auth.xml

@@ -448,7 +448,7 @@ Require group GroupName
     and choosing how authorization will be done is now possible.</p>
 
     <section id="authandororder"><title>Applying logic and ordering</title>
-        <p>Controling how and in what order authorization will be applied
+        <p>Controlling how and in what order authorization will be applied
         has been a bit of a mystery in the past. In Apache 2.2 a provider-based
         authentication mechanism was introduced to decouple the actual
         authentication process from authorization and supporting functionality.

docs/manual/mod/core.html.en

@@ -925,7 +925,7 @@ the contents of file-system directories matching a regular expression.</td></tr>
     <p>would match directories in <code>/www/</code> that consisted of three
     numbers.</p>
 
-   <div class="note"><h3>Compatability</h3>
+   <div class="note"><h3>Compatibility</h3>
       Prior to 2.3.9, this directive implicitly applied to sub-directories
       (like <code class="directive"><a href="#directory">&lt;Directory&gt;</a></code>) and
       could not match the end of line symbol ($).  In 2.3.9 and later,

docs/manual/mod/core.xml

@@ -872,7 +872,7 @@ the contents of file-system directories matching a regular expression.</descript
     <p>would match directories in <code>/www/</code> that consisted of three
     numbers.</p>
 
-   <note><title>Compatability</title>
+   <note><title>Compatibility</title>
       Prior to 2.3.9, this directive implicitly applied to sub-directories
       (like <directive module="core" type="section">Directory</directive>) and
       could not match the end of line symbol ($).  In 2.3.9 and later,

docs/manual/mod/mod_authnz_ldap.html.en

@@ -841,7 +841,7 @@ authorization</td></tr>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="directive-section"><h2><a name="AuthLDAPBindPassword" id="AuthLDAPBindPassword">AuthLDAPBindPassword</a> <a name="authldapbindpassword" id="authldapbindpassword">Directive</a></h2>
 <table class="directive">
-<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Password used in conjuction with the bind DN</td></tr>
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Password used in conjunction with the bind DN</td></tr>
 <tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>AuthLDAPBindPassword <em>password</em></code></td></tr>
 <tr><th><a href="directive-dict.html#Context">Context:</a></th><td>directory, .htaccess</td></tr>
 <tr><th><a href="directive-dict.html#Override">Override:</a></th><td>AuthConfig</td></tr>

docs/manual/mod/mod_authnz_ldap.xml

@@ -910,7 +910,7 @@ to perform a DN lookup</description>
 
 <directivesynopsis>
 <name>AuthLDAPBindPassword</name>
-<description>Password used in conjuction with the bind DN</description>
+<description>Password used in conjunction with the bind DN</description>
 <syntax>AuthLDAPBindPassword <em>password</em></syntax>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>

docs/manual/mod/mod_cache.html.en

@@ -706,10 +706,10 @@ header.</td></tr>
       <li><code>/someapplication/image.gif;jsessionid=123456789</code></li>
       <li><code>/someapplication/image.gif?PHPSESSIONID=12345678</code></li>
     </ul>
-    <p>This causes cachable resources to be stored separately for each session, which
+    <p>This causes cacheable resources to be stored separately for each session, which
     is often not desired. <code class="directive">CacheIgnoreURLSessionIdentifiers</code> lets
     define a list of identifiers that are removed from the key that is used to identify
-    an entity in the cache, such that cachable resources are not stored separately for
+    an entity in the cache, such that cacheable resources are not stored separately for
     each session.
     </p>
     <p><code>CacheIgnoreURLSessionIdentifiers None</code> clears the list of ignored
@@ -857,7 +857,7 @@ CacheLock on</pre>
 <tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_cache</td></tr>
 </table>
     <p>The <code class="directive">CacheMaxExpire</code> directive specifies the maximum number of
-    seconds for which cachable HTTP documents will be retained without checking the origin
+    seconds for which cacheable HTTP documents will be retained without checking the origin
     server. Thus, documents will be out of date at most this number of seconds. This maximum
     value is enforced even if an expiry date was supplied with the document.</p>
 
@@ -876,7 +876,7 @@ CacheLock on</pre>
 <tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_cache</td></tr>
 </table>
     <p>The <code class="directive">CacheMinExpire</code> directive specifies the minimum number of
-    seconds for which cachable HTTP documents will be retained without checking the origin
+    seconds for which cacheable HTTP documents will be retained without checking the origin
     server. This is only used if no valid expire time was supplied with the document.</p>
 
 

docs/manual/mod/mod_cache.xml

@@ -470,7 +470,7 @@ CacheEnable  disk  http://.example.org/
 
 <usage>
     <p>The <directive>CacheMaxExpire</directive> directive specifies the maximum number of
-    seconds for which cachable HTTP documents will be retained without checking the origin
+    seconds for which cacheable HTTP documents will be retained without checking the origin
     server. Thus, documents will be out of date at most this number of seconds. This maximum
     value is enforced even if an expiry date was supplied with the document.</p>
 
@@ -493,7 +493,7 @@ CacheEnable  disk  http://.example.org/
 
 <usage>
     <p>The <directive>CacheMinExpire</directive> directive specifies the minimum number of
-    seconds for which cachable HTTP documents will be retained without checking the origin
+    seconds for which cacheable HTTP documents will be retained without checking the origin
     server. This is only used if no valid expire time was supplied with the document.</p>
 
 
@@ -723,10 +723,10 @@ LastModified date.</description>
       <li><code>/someapplication/image.gif;jsessionid=123456789</code></li>
       <li><code>/someapplication/image.gif?PHPSESSIONID=12345678</code></li>
     </ul>
-    <p>This causes cachable resources to be stored separately for each session, which
+    <p>This causes cacheable resources to be stored separately for each session, which
     is often not desired. <directive>CacheIgnoreURLSessionIdentifiers</directive> lets
     define a list of identifiers that are removed from the key that is used to identify
-    an entity in the cache, such that cachable resources are not stored separately for
+    an entity in the cache, such that cacheable resources are not stored separately for
     each session.
     </p>
     <p><code>CacheIgnoreURLSessionIdentifiers None</code> clears the list of ignored

docs/manual/mod/mod_headers.html.en

@@ -220,7 +220,7 @@ Header merge Cache-Control no-store env=NO_STORE</pre>
     components of the server may have stored their response headers in either
     the table that corresponds to <code>onsuccess</code> or the table that
     corresponds to <code>always</code>.  "Always" in this context refers to
-    whether headers you add will be sent during both a successful and unsucessful
+    whether headers you add will be sent during both a successful and unsuccessful
     response, but if your action is a function of an existing header, you
     will have to read on for further complications.</p>
 

docs/manual/mod/mod_headers.xml

@@ -321,7 +321,7 @@ Header merge Cache-Control no-store env=NO_STORE
     components of the server may have stored their response headers in either
     the table that corresponds to <code>onsuccess</code> or the table that
     corresponds to <code>always</code>.  "Always" in this context refers to
-    whether headers you add will be sent during both a successful and unsucessful
+    whether headers you add will be sent during both a successful and unsuccessful
     response, but if your action is a function of an existing header, you
     will have to read on for further complications.</p>
 

docs/manual/mod/mod_ldap.html.en

@@ -366,7 +366,7 @@ LDAPTrustedGlobalCert KEY_BASE64 /certs/key1.pem [password]
         <p>Both CA and client certificates may be specified globally
         (LDAPTrustedGlobalCert) or per-connection (LDAPTrustedClientCert).
         When any settings are specified per-connection, the global
-        settings are superceded.</p>
+        settings are superseded.</p>
 
         <p>The documentation for the SDK claims to support both SSL and
         STARTTLS, however STARTTLS does not seem to work on all versions

docs/manual/mod/mod_ldap.xml

@@ -340,7 +340,7 @@ LDAPTrustedGlobalCert KEY_BASE64 /certs/key1.pem [password]
         <p>Both CA and client certificates may be specified globally
         (LDAPTrustedGlobalCert) or per-connection (LDAPTrustedClientCert).
         When any settings are specified per-connection, the global
-        settings are superceded.</p>
+        settings are superseded.</p>
 
         <p>The documentation for the SDK claims to support both SSL and
         STARTTLS, however STARTTLS does not seem to work on all versions

docs/manual/mod/mod_lua.html.en

@@ -918,10 +918,10 @@ end</pre>
                                           -- cost: only valid with BCRYPT algorithm (default = 5).</pre>
 
 
-<pre class="prettyprint lang-lua">r:mkdir(dir [,mode]) -- Creates a directory and sets mode to optional mode paramter.</pre>
+<pre class="prettyprint lang-lua">r:mkdir(dir [,mode]) -- Creates a directory and sets mode to optional mode parameter.</pre>
 
 
-<pre class="prettyprint lang-lua">r:mkrdir(dir [,mode]) -- Creates directories recursive and sets mode to optional mode paramter.</pre>
+<pre class="prettyprint lang-lua">r:mkrdir(dir [,mode]) -- Creates directories recursive and sets mode to optional mode parameter.</pre>
 
 
 <pre class="prettyprint lang-lua">r:rmdir(dir) -- Removes a directory.</pre>
@@ -1063,7 +1063,7 @@ local line = r:wsread()</pre>
     <pre class="prettyprint lang-lua">function filter(r)
     -- Our first yield is to signal that we are ready to receive buckets.
     -- Before this yield, we can set up our environment, check for conditions,
-    -- and, if we deem it necessary, decline filtering a request alltogether:
+    -- and, if we deem it necessary, decline filtering a request altogether:
     if something_bad then
         return -- This would skip this filter.
     end

docs/manual/mod/mod_lua.xml

@@ -934,11 +934,11 @@ r:htpassword(string [,algorithm [,cost]]) -- Creates a password hash from a stri
 </highlight>
 
 <highlight language="lua">
-r:mkdir(dir [,mode]) -- Creates a directory and sets mode to optional mode paramter.
+r:mkdir(dir [,mode]) -- Creates a directory and sets mode to optional mode parameter.
 </highlight>
 
 <highlight language="lua">
-r:mkrdir(dir [,mode]) -- Creates directories recursive and sets mode to optional mode paramter.
+r:mkrdir(dir [,mode]) -- Creates directories recursive and sets mode to optional mode parameter.
 </highlight>
 
 <highlight language="lua">
@@ -1093,7 +1093,7 @@ local line = r:wsread()
 function filter(r)
     -- Our first yield is to signal that we are ready to receive buckets.
     -- Before this yield, we can set up our environment, check for conditions,
-    -- and, if we deem it necessary, decline filtering a request alltogether:
+    -- and, if we deem it necessary, decline filtering a request altogether:
     if something_bad then
         return -- This would skip this filter.
     end

docs/manual/mod/mod_speling.html.en

@@ -77,7 +77,7 @@ misspellings.</td></tr>
 <div class="directive-section"><h2><a name="CheckBasenameMatch" id="CheckBasenameMatch">CheckBasenameMatch</a> <a name="checkbasenamematch" id="checkbasenamematch">Directive</a></h2>
 <table class="directive">
 <tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Extend the action of the speling module to also check filename
-without paying attention to the extention. (e.g. foo.gif and foo.jpg).
+without paying attention to the extension. (e.g. foo.gif and foo.jpg).
 This can be particulary useful in conjunction with
 <a href="../content-negotiation.html">MultiViews</a></td></tr>
 <tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>CheckBasenameMatch on|off</code></td></tr>

docs/manual/mod/mod_speling.xml

@@ -136,7 +136,7 @@ module</description>
 <directivesynopsis>
 <name>CheckBasenameMatch</name>
 <description>Extend the action of the speling module to also check filename
-without paying attention to the extention. (e.g. foo.gif and foo.jpg).
+without paying attention to the extension. (e.g. foo.gif and foo.jpg).
 This can be particulary useful in conjunction with
 <a href="../content-negotiation.html">MultiViews</a></description>
 <syntax>CheckBasenameMatch on|off</syntax>