You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ja...@apache.org on 2019/08/18 18:29:09 UTC

svn commit: r1865402 - /httpd/httpd/trunk/docs/manual/mod/mod_authn_socache.xml

Author: jailletc36
Date: Sun Aug 18 18:29:09 2019
New Revision: 1865402

URL: http://svn.apache.org/viewvc?rev=1865402&view=rev
Log:
s/cacheing/caching/
Improve layout.

Add some missing <module> tags.
Add some missing <directive> tags.
Add some missing <directive module=...> links
Add the name of the directive in <default>, so that 'quickreference.html' is generated correctly.
In the AuthnCacheContext directive, fix the way 'directory' and 'server' are displayed. They are key-words and should not be in italic.

Modified:
    httpd/httpd/trunk/docs/manual/mod/mod_authn_socache.xml

Modified: httpd/httpd/trunk/docs/manual/mod/mod_authn_socache.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_authn_socache.xml?rev=1865402&r1=1865401&r2=1865402&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_authn_socache.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_authn_socache.xml Sun Aug 18 18:29:09 2019
@@ -35,7 +35,7 @@ the load on backends</description>
     lookup is not required for every authenticated request.</p>
 </summary>
 
-<section id="intro"><title>Authentication Cacheing</title>
+<section id="intro"><title>Authentication Caching</title>
     <p>Some users of more heavyweight authentication such as SQL database
     lookups (<module>mod_authn_dbd</module>) have reported it putting an
     unacceptable load on their authentication provider.  A typical case
@@ -43,7 +43,7 @@ the load on backends</description>
     (images, scripts, stylesheets, media, etc), and a request to the page
     generates hundreds of effectively-immediate requests for authenticated
     additional contents.</p>
-    <p>mod_authn_socache provides a solution to this problem by
+    <p><module>mod_authn_socache</module> provides a solution to this problem by
     maintaining a cache of authentication credentials.</p>
 </section>
 
@@ -53,17 +53,18 @@ the load on backends</description>
     network.  Authentication by file (<module>mod_authn_file</module>)
     or dbm (<module>mod_authn_dbm</module>) are unlikely to benefit,
     as these are fast and lightweight in their own right (though in some
-    cases, such as a network-mounted file, cacheing may be worthwhile).
+    cases, such as a network-mounted file, caching may be worthwhile).
     Other providers such as SQL or LDAP based authentication are more
     likely to benefit, particularly where there is an observed
     performance issue.  Amongst the standard modules, <module
     >mod_authnz_ldap</module> manages its own cache, so only
     <module>mod_authn_dbd</module> will usually benefit from this cache.</p>
     <p>The basic rules to cache for a provider are:</p>
-    <ol><li>Include the provider you're cacheing for in an
-            <directive>AuthnCacheProvideFor</directive> directive.</li>
+    <ol><li>Include the provider you're caching for in an
+            <directive module="mod_authn_socache"
+            >AuthnCacheProvideFor</directive> directive.</li>
         <li>List <var>socache</var> ahead of the provider you're
-            cacheing for in your <directive module="mod_auth_basic"
+            caching for in your <directive module="mod_auth_basic"
             >AuthBasicProvider</directive> or <directive module=
             "mod_auth_digest">AuthDigestProvider</directive> directive.</li>
     </ol>
@@ -85,14 +86,14 @@ AuthnCacheSOCache dbm
     </highlight>
 </section>
 
-<section id="dev"><title>Cacheing with custom modules</title>
+<section id="dev"><title>Caching with custom modules</title>
     <p>Module developers should note that their modules must be enabled
-    for cacheing with mod_authn_socache.  A single optional API function
+    for caching with <module>mod_authn_socache</module>.  A single optional API function
     <var>ap_authn_cache_store</var> is provided to cache credentials
     a provider has just looked up or generated.  Usage examples are
     available in <a
     href="http://svn.eu.apache.org/viewvc?view=revision&amp;revision=957072"
-    >r957072</a>, in which three authn providers are enabled for cacheing.</p>
+    >r957072</a>, in which three authn providers are enabled for caching.</p>
 </section>
 
 <directivesynopsis>
@@ -103,7 +104,7 @@ AuthnCacheSOCache dbm
 
 <usage>
     <p>This directive is not normally necessary: it is implied if
-    authentication cacheing is enabled anywhere in <var>httpd.conf</var>.
+    authentication caching is enabled anywhere in <var>httpd.conf</var>.
     However, if it is not enabled anywhere in <var>httpd.conf</var>
     it will by default not be initialised, and is therefore not
     available in a <var>.htaccess</var> context.  This directive
@@ -140,7 +141,7 @@ Apache HTTP Server 2.4.7 and later</comp
 <usage>
     <p>This directive specifies an authentication provider or providers
     to cache for.  Credentials found by a provider not listed in an
-    AuthnCacheProvideFor directive will not be cached.</p>
+    <directive>AuthnCacheProvideFor</directive> directive will not be cached.</p>
 
     <p>For example, to cache credentials found by <module>mod_authn_dbd</module>
     or by a custom provider <var>myprovider</var>, but leave those looked
@@ -155,13 +156,13 @@ AuthnCacheProvideFor dbd myprovider
 <name>AuthnCacheTimeout</name>
 <description>Set a timeout for cache entries</description>
 <syntax>AuthnCacheTimeout <var>timeout</var> (seconds)</syntax>
-<default>300 (5 minutes)</default>
+<default>AuthnCacheTimeout 300 (5 minutes)</default>
 <contextlist><context>directory</context><context>.htaccess</context></contextlist>
 <override>AuthConfig</override>
 
 <usage>
-    <p>Cacheing authentication data can be a security issue, though short-term
-    cacheing is unlikely to be a problem.  Typically a good solution is to
+    <p>Caching authentication data can be a security issue, though short-term
+    caching is unlikely to be a problem.  Typically a good solution is to
     cache credentials for as long as it takes to relieve the load on a
     backend, but no longer, though if changes to your users and passwords
     are infrequent then a longer timeout may suit you.  The default 300
@@ -178,8 +179,8 @@ AuthnCacheProvideFor dbd myprovider
 <directivesynopsis>
 <name>AuthnCacheContext</name>
 <description>Specify a context string for use in the cache key</description>
-<syntax>AuthnCacheContext <var>directory|server|custom-string</var></syntax>
-<default>directory</default>
+<syntax>AuthnCacheContext directory|server|<var>custom-string</var></syntax>
+<default>AuthnCacheContext directory</default>
 <contextlist><context>directory</context></contextlist>
 
 <usage>
@@ -187,10 +188,10 @@ AuthnCacheProvideFor dbd myprovider
     username (and realm in the case of Digest Authentication) in constructing
     a cache key.  This serves to disambiguate identical usernames serving
     different authentication areas on the server.</p>
-    <p>Two special values for this are <var>directory</var>, which uses
-    the directory context of the request as a string, and <var>server</var>
+    <p>Two special values for this are <code>directory</code>, which uses
+    the directory context of the request as a string, and <code>server</code>
     which uses the virtual host name.</p>
-    <p>The default is <var>directory</var>, which is also the most
+    <p>The default is <code>directory</code>, which is also the most
     conservative setting.  This is likely to be less than optimal, as it
     (for example) causes <var>$app-base</var>, <var>$app-base/images</var>,
     <var>$app-base/scripts</var> and <var>$app-base/media</var> each to