Cleanups, looks like a placeholder was forgotten. Also, lines really

shouldn't be more than 75 characters long, unless they need to be.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@77469 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/docs/manual/mod/mod_auth.html b/docs/manual/mod/mod_auth.html
index ea26099968e9f3152895417d86d5b06d5affec30..ac44fd6103542c910a4e0e4ae957ce55351c29d2 100644 (file)
--- a/docs/manual/mod/mod_auth.html
+++ b/docs/manual/mod/mod_auth.html
@@ -56,15 +56,15 @@ See also <A HREF="core.html#authname">AuthName</A>,
 <strong>Status:</strong> Base<br>
 <strong>Module:</strong> mod_auth<p>
 
-The AuthUserFile directive sets the name of a textual file containing the list
-of users and passwords for user authentication. <em>Filename</em> is the
-absolute path to the user file.<p>
-Each line of the user file file contains a username followed by a colon,
-followed by the crypt() encrypted password. The behavior of multiple
-occurrences of the same user is undefined.<p>
-Note that searching user groups files is inefficient;
-<A HREF="mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</A> should
-be used instead.<p>
+The AuthUserFile directive sets the name of a textual file containing
+the list of users and passwords for user
+authentication. <em>Filename</em> is the absolute path to the user
+file.<p> Each line of the user file file contains a username followed
+by a colon, followed by the crypt() encrypted password. The behavior
+of multiple occurrences of the same user is undefined.<p> Note that
+searching user groups files is inefficient; <A
+HREF="mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</A> should be
+used instead.<p>
 
 Security: make sure that the AuthUserFile is stored outside the
 document tree of the web-server; do <em>not</em> put it in the directory that
@@ -82,19 +82,51 @@ See also <A HREF="core.html#authname">AuthName</A>,
 <strong>Status:</strong> Base<br>
 <strong>Module:</strong> mod_auth<p>
 
-Setting the AuthAuthoritative directive explicitly to <b>'off'</b> allows for both authentification and authorization to be passed on to lower level modules (as defined in the <code>Configuration</code> and <code>modules.c</code> file if there is <b>no userID</b> or <b>rule</b> matching the supplied userID. If there is a userID and/or rule specified; the usual password and access checks will be applied and a failure will give an Authorization Required reply.
+Setting the AuthAuthoritative directive explicitly to <b>'off'</b>
+allows for both authentification and authorization to be passed on to
+lower level modules (as defined in the <code>Configuration</code> and
+<code>modules.c</code> file if there is <b>no userID</b> or
+<b>rule</b> matching the supplied userID. If there is a userID and/or
+rule specified; the usual password and access checks will be applied
+and a failure will give an Authorization Required reply.
+
 <p>
-So if a userID appears in the database of more than one module; or if a valid require directive applies to more than one module; then the first module will verify the credentials; and no access is passed on; regardless of the AuthAuthoritative setting.
+
+So if a userID appears in the database of more than one module; or if
+a valid require directive applies to more than one module; then the
+first module will verify the credentials; and no access is passed on;
+regardless of the AuthAuthoritative setting.
+
 <p>
-A common use for this is in conjection with one of the database modules; such
-as <a href="mod_auth_anon.c"><code>mod_auth_db.c</code></a>, <a href="mod_auth_anon.c"><code>mod_auth_dbm.c</code></a>, 
-<a href="mod_auth_anon.c"><code>mod_auth_msql.c</code></a> and <a href="mod_auth_anon.c"><code>mod_auth_anon.c</code></a>. These modules supply the bulk of the user credential checking; but a few (administrator) related accesses fall through to a lower level with a well protected AuthUserFile.
+
+A common use for this is in conjection with one of the database
+modules; such as <a
+href="mod_auth_db.html"><code>mod_auth_db.c</code></a>, <a
+href="mod_auth_dbm.html"><code>mod_auth_dbm.c</code></a>, <a
+href="mod_auth_msql.html"><code>mod_auth_msql.c</code></a> and <a
+href="mod_auth_anon.html"><code>mod_auth_anon.c</code></a>. These modules
+supply the bulk of the user credential checking; but a few
+(administrator) related accesses fall through to a lower level with a
+well protected AuthUserFile.
+
 <p>
-<b>Default:</b> By default; control is not passed on; and an unkown userID or rule will result in an Authorization Required reply. Not setting it thus keeps the system secure; and forces an NSCA compliant behaviour.
+
+<b>Default:</b> By default; control is not passed on; and an unkown
+userID or rule will result in an Authorization Required reply. Not
+setting it thus keeps the system secure; and forces an NSCA compliant
+behaviour.
+
 <p>
-Security: Do consider the implications of allowing a user to allow fall-through in his .htaccess file; and verify that this is really what you want; Generally it is easier to just secure a single .htpasswd file, than it is to secure a database such as mSQL. Make sure that the AuthUserFile is stored outside the
-document tree of the web-server; do <em>not</em> put it in the directory that
-it protects. Otherwise, clients will be able to download the AuthUserFile.
+
+Security: Do consider the implications of allowing a user to allow
+fall-through in his .htaccess file; and verify that this is really
+what you want; Generally it is easier to just secure a single
+.htpasswd file, than it is to secure a database such as mSQL. Make
+sure that the AuthUserFile is stored outside the document tree of the
+web-server; do <em>not</em> put it in the directory that it
+protects. Otherwise, clients will be able to download the
+AuthUserFile.
+
 <p>
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and