httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From n.@apache.org
Subject cvs commit: httpd-2.0/docs/manual/mod obs_mod_access.xml obs_mod_auth.xml obs_mod_auth_anon.xml obs_mod_auth_dbm.xml obs_mod_auth_digest.xml
Date Wed, 16 Oct 2002 06:56:36 GMT
nd          2002/10/15 23:56:36

  Modified:    docs/manual sitemap.xml
  Added:       docs/manual/mod obs_mod_access.xml obs_mod_auth.xml
                        obs_mod_auth_anon.xml obs_mod_auth_dbm.xml
                        obs_mod_auth_digest.xml
  Log:
  (re-)add the obsolete module docs.
  This commit is a base for some discussion and better work on the
  documents, feel free to add or change the files
  I stuck with mod_access for now, since there's no decision about yet.
  
  Revision  Changes    Path
  1.8       +6 -0      httpd-2.0/docs/manual/sitemap.xml
  
  Index: sitemap.xml
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/sitemap.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- sitemap.xml	7 Oct 2002 08:46:31 -0000	1.7
  +++ sitemap.xml	16 Oct 2002 06:56:35 -0000	1.8
  @@ -181,6 +181,12 @@
     <modulefile>perchild.xml</modulefile>
     <modulefile>prefork.xml</modulefile>
     <modulefile>worker.xml</modulefile>
  +
  +  <modulefile>obs_mod_access.xml</modulefile>
  +  <modulefile>obs_mod_auth.xml</modulefile>
  +  <modulefile>obs_mod_auth_anon.xml</modulefile>
  +  <modulefile>obs_mod_auth_dbm.xml</modulefile>
  +  <modulefile>obs_mod_auth_digest.xml</modulefile>
   </modulefilelist>
   </category>
   
  
  
  
  1.1                  httpd-2.0/docs/manual/mod/obs_mod_access.xml
  
  Index: obs_mod_access.xml
  ===================================================================
  <?xml version="1.0"?>
  <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
  <modulesynopsis>
  
  <name>mod_access</name> 
  
  <description>Provides access control based on client hostname, IP
  address, or other characteristics of the client request.</description>
  
  <status>Obsolete</status>
  <hint>replaced by <module>mod_authz_host</module> since 2.0.44</hint>
  <sourcefile>mod_access.c</sourcefile>
  <identifier>access_module</identifier>
  <compatibility>Available only in versions up to 2.0.43</compatibility>
  
  <summary>
      <note type="warning"><title>This module is obsolete!</title>
      <p>Note, that this module has been marked as obsolete. A bunch
      of modules was introduced in Apache version 2.0.44 that
      support the new Authentication/Authorization provider mechnism.</p>
  
      <p>If you want to use host based access control, you have to invoke the
      <module>mod_authz_host</module> module now.</p>
  
      <p>This document is kept only for historical reasons and no
      longer maintained.</p>
      </note>
  
      <p>The directives provided by mod_access are used in <directive
      module="core" type="section">Directory</directive>, <directive
      module="core" type="section">Files</directive>, and <directive
      module="core" type="section">Location</directive> sections as well as
      <code><a href="core.html#accessfilename">.htaccess</a></code>
      files to control access to particular parts of the server. Access
      can be controlled based on the client hostname, IP address, or
      other characteristics of the client request, as captured in <a
      href="../env.html">environment variables</a>. The <directive
      module="mod_access" status="obsolete">Allow</directive> and <directive
      module="mod_access" status="obsolete">Deny</directive> directives are used to
      specify which clients are or are not allowed access to the server,
      while the <directive module="mod_access" status="obsolete">Order</directive>
      directive sets the default access state, and configures how the
      <directive module="mod_access" status="obsolete">Allow</directive> and <directive
      module="mod_access" status="obsolete">Deny</directive> directives interact with each
      other.</p>
  
      <p>Both host-based access restrictions and password-based
      authentication may be implemented simultaneously. In that case,
      the <directive module="core">Satisfy</directive> directive is used
      to determine how the two sets of restrictions interact.</p>
  
      <p>In general, access restriction directives apply to all
      access methods (<code>GET</code>, <code>PUT</code>,
      <code>POST</code>, etc). This is the desired behavior in most
      cases. However, it is possible to restrict some methods, while
      leaving other methods unrestricted, by enclosing the directives
      in a <directive module="core" type="section">Limit</directive> section.</p>
  </summary>
  
  <seealso><directive module="core">Satisfy</directive></seealso>
  <seealso><directive module="core">Require</directive></seealso>
  
  <directivesynopsis>
  <name>Allow</name>
  
  <description>Controls which hosts can access an area of the
  server</description>
  <syntax> Allow from
      all|<var>host</var>|env=<var>env-variable</var>
      [<var>host</var>|env=<var>env-variable</var>] ...</syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>Limit</override>
  
  <usage>
  
      <p>The <directive>Allow</directive> directive affects which hosts can
      access an area of the server. Access can be controlled by
      hostname, IP Address, IP Address range, or by other
      characteristics of the client request captured in environment
      variables.</p>
  
      <p>The first argument to this directive is always
      <code>from</code>. The subsequent arguments can take three
      different forms. If <code>Allow from all</code> is specified, then
      all hosts are allowed access, subject to the configuration of the
      <directive module="mod_access" status="obsolete">Deny</directive> and <directive
      module="mod_access" status="obsolete">Order</directive> directives as discussed
      below. To allow only particular hosts or groups of hosts to access
      the server, the <var>host</var> can be specified in any of the
      following formats:</p>
  
      <dl>
        <dt>A (partial) domain-name</dt>
  
        <dd>Example: <code>Allow from apache.org</code><br />
         Hosts whose names match, or end in, this string are allowed
        access. Only complete components are matched, so the above
        example will match <code>foo.apache.org</code> but it will
        not match <code>fooapache.org</code>. This configuration will
        cause the server to perform a reverse DNS lookup on the
        client IP address, regardless of the setting of the <directive
        module="core">HostnameLookups</directive>
        directive.</dd>
  
        <dt>A full IP address</dt>
  
        <dd>Example: <code>Allow from 10.1.2.3</code><br />
         An IP address of a host allowed access</dd>
  
        <dt>A partial IP address</dt>
  
        <dd>Example: <code>Allow from 10.1</code><br />
         The first 1 to 3 bytes of an IP address, for subnet
        restriction.</dd>
  
        <dt>A network/netmask pair</dt>
  
        <dd>Example: <code>Allow from
        10.1.0.0/255.255.0.0</code><br />
         A network a.b.c.d, and a netmask w.x.y.z. For more
        fine-grained subnet restriction.</dd>
  
        <dt>A network/nnn CIDR specification</dt>
  
        <dd>Example: <code>Allow from 10.1.0.0/16</code><br />
         Similar to the previous case, except the netmask consists of
        nnn high-order 1 bits.</dd>
      </dl>
  
      <p>Note that the last three examples above match exactly the
      same set of hosts.</p>
  
      <p>IPv6 addresses and IPv6 subnets can be specified as shown
      below:</p>
  
      <example>
         Allow from fe80::a00:20ff:fea7:ccea<br />
         Allow from fe80::a00:20ff:fea7:ccea/10
      </example>
  
      <p>The third format of the arguments to the
      <directive>Allow</directive> directive allows access to the server
      to be controlled based on the existence of an <a
      href="../env.html">environment variable</a>. When <code>Allow from
      env=<var>env-variable</var></code> is specified, then the request is
      allowed access if the environment variable <var>env-variable</var>
      exists. The server provides the ability to set environment
      variables in a flexible way based on characteristics of the client
      request using the directives provided by
      <module>mod_setenvif</module>.  Therefore, this directive can be
      used to allow access based on such factors as the clients
      <code>User-Agent</code> (browser type), <code>Referer</code>, or
      other HTTP request header fields.</p>
  
      <example><title>Example:</title>
        SetEnvIf User-Agent ^KnockKnock/2.0 let_me_in<br />
        &lt;Directory /docroot&gt;<br />
        <indent>
          Order Deny,Allow<br />
          Deny from all<br />
          Allow from env=let_me_in<br />
        </indent>
        &lt;/Directory&gt;
      </example>
  
      <p>In this case, browsers with a user-agent string beginning
      with <code>KnockKnock/2.0</code> will be allowed access, and all
      others will be denied.</p>
  </usage>
  
  </directivesynopsis>
  
  <directivesynopsis>
  
  <name>Deny</name>
  
  <description>Controls which hosts are denied access to the
  server</description>
  
  <syntax> Deny from
      all|<var>host</var>|env=<var>env-variable</var>
      [<var>host</var>|env=<var>env-variable</var>] ...</syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>Limit</override>
  
  <usage>
      <p>This directive allows access to the server to be restricted
      based on hostname, IP address, or environment variables. The
      arguments for the <directive>Deny</directive> directive are
      identical to the arguments for the <directive
      module="mod_access" status="obsolete">Allow</directive> directive.</p>
  </usage>
  
  </directivesynopsis>
  
  <directivesynopsis>
  
  <name>Order</name>
  
  <description>Controls the default access state and the order in which
  <directive>Allow</directive> and <directive>Deny</directive> are
  evaluated.</description>
  
  <syntax> Order <var>ordering</var></syntax>
  <default>Order Deny,Allow</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>Limit</override>
  
  <usage>
  
      <p>The <directive>Order</directive> directive controls the default
      access state and the order in which <directive
      module="mod_access" status="obsolete">Allow</directive> and <directive
      module="mod_access" status="obsolete">Deny</directive> directives are evaluated.
      <var>Ordering</var> is one of</p>
  
      <dl>
        <dt>Deny,Allow</dt>
  
        <dd>The <directive module="mod_access" status="obsolete">Deny</directive> directives
        are evaluated before the <directive
        module="mod_access" status="obsolete">Allow</directive> directives. Access is
        allowed by default.  Any client which does not match a
        <directive module="mod_access" status="obsolete">Deny</directive> directive or does
        match an <directive module="mod_access" status="obsolete">Allow</directive>
        directive will be allowed access to the server.</dd>
  
        <dt>Allow,Deny</dt>
  
        <dd>The <directive module="mod_access" status="obsolete">Allow</directive>
        directives are evaluated before the <directive
        module="mod_access" status="obsolete">Deny</directive> directives. Access is denied
        by default. Any client which does not match an <directive
        module="mod_access" status="obsolete">Allow</directive> directive or does match a
        <directive module="mod_access" status="obsolete">Deny</directive> directive will be
        denied access to the server.</dd>
  
        <dt>Mutual-failure</dt>
  
        <dd>Only those hosts which appear on the <directive
        module="mod_access" status="obsolete">Allow</directive> list and do not appear on
        the <directive module="mod_access" status="obsolete">Deny</directive> list are
        granted access. This ordering has the same effect as <code>Order
        Allow,Deny</code> and is deprecated in favor of that
        configuration.</dd>
      </dl>
  
      <p>Keywords may only be separated by a comma; no whitespace is
      allowed between them. Note that in all cases every <directive
      module="mod_access" status="obsolete">Allow</directive> and <directive
      module="mod_access" status="obsolete">Deny</directive> statement is evaluated.</p>
  
      <p>In the following example, all hosts in the apache.org domain
      are allowed access; all other hosts are denied access.</p>
  
      <example>
        Order Deny,Allow<br />
        Deny from all<br />
        Allow from apache.org
      </example>
  
      <p>In the next example, all hosts in the apache.org domain are
      allowed access, except for the hosts which are in the
      foo.apache.org subdomain, who are denied access. All hosts not
      in the apache.org domain are denied access because the default
      state is to deny access to the server.</p>
  
      <example>
        Order Allow,Deny<br />
        Allow from apache.org<br />
        Deny from foo.apache.org
      </example>
  
      <p>On the other hand, if the <directive>Order</directive> in the last
      example is changed to <code>Deny,Allow</code>, all hosts will
      be allowed access. This happens because, regardless of the
      actual ordering of the directives in the configuration file,
      the <code>Allow from apache.org</code> will be evaluated last
      and will override the <code>Deny from foo.apache.org</code>.
      All hosts not in the <code>apache.org</code> domain will also
      be allowed access because the default state will change to
      <var>allow</var>.</p>
  
      <p>The presence of an <directive>Order</directive> directive can affect
      access to a part of the server even in the absence of accompanying
      <directive module="mod_access" status="obsolete">Allow</directive> and <directive
      module="mod_access" status="obsolete">Deny</directive> directives because of its effect
      on the default access state.  For example,</p>
  
      <example>
        &lt;Directory /www&gt;<br />
        <indent>
          Order Allow,Deny<br />
        </indent>
        &lt;/Directory&gt;
      </example>
  
      <p>will deny all access to the <code>/www</code> directory
      because the default access state will be set to
      <var>deny</var>.</p>
  
      <p>The <directive>Order</directive> directive controls the order of access
      directive processing only within each phase of the server's
      configuration processing. This implies, for example, that an
      <directive module="mod_access" status="obsolete">Allow</directive> or <directive
      module="mod_access" status="obsolete">Deny</directive> directive occurring in a
      <directive module="core" type="section">Location</directive> section will
      always be evaluated after an <directive
      module="mod_access" status="obsolete">Allow</directive> or <directive
      module="mod_access" status="obsolete">Deny</directive> directive occurring in a
      <directive module="core" type="section">Directory</directive> section or
      <code>.htaccess</code> file, regardless of the setting of the
      <directive>Order</directive> directive. For details on the merging
      of configuration sections, see the documentation on <a
      href="../sections.html">How Directory, Location and Files sections
      work</a>.</p>
  </usage>
  
  </directivesynopsis>
  
  </modulesynopsis>
  
  
  
  1.1                  httpd-2.0/docs/manual/mod/obs_mod_auth.xml
  
  Index: obs_mod_auth.xml
  ===================================================================
  <?xml version="1.0"?>
  <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
  <modulesynopsis>
  
  <name>mod_auth</name>
  <description>User authentication using text files</description>
  <status>Obsolete</status>
  <hint>obsolete since 2.0.44</hint>
  <sourcefile>mod_auth.c</sourcefile>
  <identifier>auth_module</identifier>
  <compatibility>Available only in versions up to 2.0.43</compatibility>
  
  <summary>
      <note type="warning"><title>This module is obsolete!</title>
      <p>Note, that this module has been marked as obsolete. A bunch
      of modules was introduced in Apache version 2.0.44 that
      support the new Authentication/Authorization provider mechnism.</p>
  
      <p>In order to get the ability of HTTP Basic Authentication, you have
      to use the <module>mod_auth_basic</module> module that implements
      the HTTP part. <module>mod_authn_file</module> provides for user
      authentication based on plain text files. File based group
      authorization is now done by the <module>mod_authz_groupfile</module>
      module.</p>
  
      <p>This document is kept only for historical reasons and no
      longer maintained.</p>
      </note>
  
      <p>This module allows the use of HTTP Basic Authentication to
      restrict access by looking up users in plain text password and
      group files. Similar functionality and greater scalability is
      provided by <module status="obsolete">mod_auth_dbm</module>. HTTP Digest
      Authentication is provided by
      <module status="obsolete">mod_auth_digest</module>.</p>
  
  </summary>
  <seealso><directive module="core">Require</directive></seealso>
  <seealso><directive module="core">Satisfy</directive></seealso>
  <seealso><directive module="core">AuthName</directive></seealso>
  <seealso><directive module="core">AuthType</directive></seealso>
  
  <directivesynopsis>
  <name>AuthGroupFile</name>
  <description>Sets the name of a text file containing the list
  of user groups for authentication</description>
  <syntax>AuthGroupFile <var>file-path</var></syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthGroupFile</directive> directive sets the
      name of a textual file containing the list of user groups for user
      authentication.  <var>File-path</var> is the path to the group
      file. If it is not absolute (<em>i.e.</em>, if it doesn't begin
      with a slash), it is treated as relative to the <directive
      module="core">ServerRoot</directive>.</p>
  
      <p>Each line of the group file contains a groupname followed by a
      colon, followed by the member usernames separated by spaces.
      Example:</p> 
  
      <example>mygroup: bob joe anne</example> 
  
      <p>Note that searching large text files is <em>very</em>
      inefficient; <directive
      module="mod_auth_dbm" status="obsolete">AuthDBMGroupFile</directive> should be used
      instead.</p>
  
      <note><title>Security</title>
      <p>Make sure that the <directive>AuthGroupFile</directive> 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 <directive>AuthGroupFile</directive>.</p>
      </note>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthUserFile</name>
  <description>Sets the name of a text file containing the list of users and
  passwords for authentication</description>
  <syntax>AuthUserFile <var>file-path</var></syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthUserFile</directive> directive sets the name
      of a textual file containing the list of users and passwords for
      user authentication. <var>File-path</var> is the path to the user
      file. If it is not absolute (<em>i.e.</em>, if it doesn't begin
      with a slash), it is treated as relative to the <directive
      module="core">ServerRoot</directive>.</p>
  
      <p>Each line of the user file contains a username followed by
      a colon, followed by the <code>crypt()</code> encrypted
      password. The behavior of multiple occurrences of the same user is
      undefined.</p>
  
      <p>The utility <a href="../programs/htpasswd.html">htpasswd</a>
      which is installed as part of the binary distribution, or which
      can be found in <code>src/support</code>, is used to maintain
      this password file. See the <code>man</code> page for more
      details. In short:</p>
  
      <p>Create a password file 'Filename' with 'username' as the
      initial ID. It will prompt for the password:</p>
  
      <example>htpasswd -c Filename username</example>
  
      <p>Add or modify 'username2' in the password file 'Filename':</p>
  
      <example>htpasswd Filename username2</example>
  
      <p>Note that searching large text files is <em>very</em>
      inefficient; <directive
      module="mod_auth_dbm" status="obsolete">AuthDBMUserFile</directive> should be used
      instead.</p>
  
      <note><title>Security</title>
      <p>Make sure that the <directive>AuthUserFile</directive> 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 <directive>AuthUserFile</directive>.</p>
      </note>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthAuthoritative</name>
  <description>Sets whether authorization and authentication are
  passed to lower level modules</description>
  <syntax>AuthAuthoritative on|off</syntax>
  <default>AuthAuthoritative on</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <note>This information has not been updated for Apache 2.0, which
      uses a different system for module ordering.</note>
  
      <p>Setting the <directive>AuthAuthoritative</directive> directive
      explicitly to <strong>'off'</strong> allows for both
      authentication and authorization to be passed on to lower level
      modules (as defined in the <code>Configuration</code> and
      <code>modules.c</code> files) if there is <strong>no
      userID</strong> or <strong>rule</strong> 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>
  
      <p>So if a userID appears in the database of more than one module;
      or if a valid <directive module="core">Require</directive>
      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>
  
      <p>A common use for this is in conjunction with one of the
      database modules; such as <module status="obsolete">mod_auth_dbm</module>,
      <code>mod_auth_msql</code>, and <module status="obsolete">mod_auth_anon</module>.
      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 <directive
      module="mod_auth" status="obsolete">AuthUserFile</directive>.</p>
  
      <p>By default; control is not passed on; and an unknown userID or
      rule will result in an Authorization Required reply. Not setting
      it thus keeps the system secure; and forces an NCSA compliant
      behaviour.</p>
  
      <note><title>Security</title> 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 <directive
      module="mod_auth" status="obsolete">AuthUserFile</directive> and the <directive
      module="mod_auth" status="obsolete">AuthGroupFile</directive> are stored outside the
      document tree of the web-server; do <em>not</em> put them in the
      directory that they protect. Otherwise, clients will be able to
      download the <directive module="mod_auth" status="obsolete">AuthUserFile</directive>
      and the <directive module="mod_auth" status="obsolete">AuthGroupFile</directive>.
      </note>
  </usage>
  </directivesynopsis>
  
  </modulesynopsis>
  
  
  
  1.1                  httpd-2.0/docs/manual/mod/obs_mod_auth_anon.xml
  
  Index: obs_mod_auth_anon.xml
  ===================================================================
  <?xml version="1.0"?>
  <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
  <modulesynopsis>
  
  <name>mod_auth_anon</name>
  <description>Allows "anonymous" user access to authenticated
      areas</description>
  <status>Obsolete</status>
  <hint>replaced by <module>mod_authn_anon</module> since 2.0.44</hint>
  <sourcefile>mod_auth_anon.c</sourcefile>
  <identifier>auth_anon_module</identifier>
  <compatibility>Available only in versions up to 2.0.43</compatibility>
  
  <summary>
      <note type="warning"><title>This module is obsolete!</title>
      <p>Note, that this module has been marked as obsolete. A bunch
      of modules was introduced in Apache version 2.0.44 that
      support the new Authentication/Authorization provider mechnism.</p>
  
      <p>In order to get the same functionality, you have to invoke the
      <module>mod_authn_anon</module> module now.</p>
  
      <!-- XXX: I think `AuthBasicProvider anon' comes soon, doesn't it? -->
      <!--
      <p>In order to get the same functionality, you have
      to use the <module>mod_auth_basic</module> module that implements
      the HTTP part. <module>mod_authn_anon</module> provides for
      anonymous user authentication.</p>
      -->
  
      <p>This document is kept only for historical reasons and no
      longer maintained.</p>
      </note>
  
      <p>This module does access control in a manner similar to
      anonymous-ftp sites; <em>i.e.</em> have a 'magic' user id
      'anonymous' and the email address as a password. These email
      addresses can be logged.</p>
  
      <p>Combined with other (database) access control methods, this
      allows for effective user tracking and customization according
      to a user profile while still keeping the site open for
      'unregistered' users. One advantage of using Auth-based user
      tracking is that, unlike magic-cookies and funny URL
      pre/postfixes, it is completely browser independent and it
      allows users to share URLs.</p>
  </summary>
  
  <section id="example"><title>Example</title>
  
      <p>The example below (when combined with the Auth directives of a
      htpasswd-file based (or GDM, mSQL etc.) base access
      control system allows users in as 'guests' with the following
      properties:</p>
  
      <ul>
        <li>It insists that the user enters a userId.
        (<code>Anonymous_NoUserId</code>)</li>
  
        <li>It insists that the user enters a password.
        (<code>Anonymous_MustGiveEmail</code>)</li>
  
        <li>The password entered must be a valid email address, ie.
        contain at least one '@' and a '.'.
        (<code>Anonymous_VerifyEmail</code>)</li>
  
        <li>The userID must be one of <code>anonymous guest www test
        welcome</code> and comparison is <strong>not</strong> case
        sensitive.</li>
  
        <li>And the Email addresses entered in the passwd field are
        logged to the error log file
        (<code>Anonymous_LogEmail</code>)</li>
      </ul>
  
      <p>Excerpt of httpd.conf:</p>
  
      <example>
        Anonymous_NoUserId off<br />
        Anonymous_MustGiveEmail on<br />
        Anonymous_VerifyEmail on<br />
        Anonymous_LogEmail on<br />
        Anonymous anonymous guest www test welcome<br />
        <br />
        AuthName "Use 'anonymous' &amp; Email address for guest entry"<br />
        AuthType basic<br />
        <br />
        # An
        AuthUserFile/AuthDBUserFile/AuthDBMUserFile<br />
        # directive must be specified, or use<br />
        # Anonymous_Authoritative for public access.<br />
        # In the .htaccess for the public directory, add:<br />
        &lt;Files *&gt;<br />
        <indent>
          Order Deny,Allow<br />
          Allow from all<br />
          <br />
          Require valid-user<br />
        </indent>
        &lt;/Files&gt;
      </example>
  </section>
  
  <directivesynopsis>
  <name>Anonymous</name>
  <description>Specifies userIDs that areallowed access without
  password verification</description>
  <syntax>Anonymous <var>user</var> [<var>user</var>] ...</syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>A list of one or more 'magic' userIDs which are allowed
      access without password verification. The userIDs are space
      separated. It is possible to use the ' and " quotes to allow a
      space in a userID as well as the \ escape character.</p>
  
      <p>Please note that the comparison is
      <strong>case-IN-sensitive</strong>.<br />
       I strongly suggest that the magic username
      '<code>anonymous</code>' is always one of the allowed
      userIDs.</p>
  
      <example><title>Example:</title>
        Anonymous anonymous "Not Registered" 'I don\'t know'
      </example>
  
      <p>This would allow the user to enter without password
      verification by using the userId's 'anonymous',
      'AnonyMous','Not Registered' and 'I Don't Know'.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>Anonymous_Authoritative</name>
  <description>Configures if authorization will fall-through
  to other methods</description>
  <syntax>Anonymous_Authoritative on|off</syntax>
  <default>Anonymous_Authoritative off</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>When set 'on', there is no fall-through to other authorization
      methods. So if a userID does not match the values specified in the
      <directive module="mod_auth_anon" status="obsolete">Anonymous</directive> directive,
      access is denied.</p>
  
      <p>Be sure you know what you are doing when you decide to
      switch it on. And remember that it is the linking order of the
      modules (in the Configuration / Make file) which details the
      order in which the Authorization modules are queried.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>Anonymous_LogEmail</name>
  <description>Sets whether the password entered will be logged in the
  error log</description>
  <syntax>Anonymous_LogEmail on|off</syntax>
  <default>Anonymous_LogEmail on</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>When set <code>on</code>, the default, the 'password' entered
      (which hopefully contains a sensible email address) is logged in
      the error log.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>Anonymous_MustGiveEmail</name>
  <description>Specifies whether blank passwords are allowed</description>
  <syntax>Anonymous_MustGiveEmail on|off</syntax>
  <default>Anonymous_MustGiveEmail on</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>Specifies whether the user must specify an email address as
      the password. This prohibits blank passwords.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>Anonymous_NoUserID</name>
  <description>Sets whether the userID field may be empty</description>
  <syntax>Anonymous_NoUserID on|off</syntax>
  <default>Anonymous_NoUserID off</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>When set <code>on</code>, users can leave the userID (and
      perhaps the password field) empty. This can be very convenient for
      MS-Explorer users who can just hit return or click directly on the
      OK button; which seems a natural reaction.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>Anonymous_VerifyEmail</name>
  <description>Sets whether to check the password field for a correctly
  formatted email address</description>
  <syntax>Anonymous_VerifyEmail on|off</syntax>
  <default>Anonymous_VerifyEmail off</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>When set <code>on</code> the 'password' entered is checked for
      at least one '@' and a '.' to encourage users to enter valid email
      addresses (see the above <directive
      module="mod_auth_anon" status="obsolete">Auth_LogEmail</directive>).</p>
  </usage>
  </directivesynopsis>
  
  </modulesynopsis>
  
  
  1.1                  httpd-2.0/docs/manual/mod/obs_mod_auth_dbm.xml
  
  Index: obs_mod_auth_dbm.xml
  ===================================================================
  <?xml version="1.0"?>
  <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
  <modulesynopsis>
  
  <name>mod_auth_dbm</name>
  <description>Provides for user authentication using DBM
      files</description>
  <status>Obsolete</status>
  <hint>obsolete since 2.0.44</hint>
  <sourcefile>mod_auth_dbm.c</sourcefile>
  <identifier>auth_dbm_module</identifier>
  <compatibility>Available only in versions up to 2.0.43</compatibility>
  
  <summary>
      <note type="warning"><title>This module is obsolete!</title>
      <p>Note, that this module has been marked as obsolete. A bunch
      of modules was introduced in Apache version 2.0.44 that
      support the new Authentication/Authorization provider mechnism.</p>
  
      <p>In order to get the ability of HTTP Basic Authentication, you have
      to use the <module>mod_auth_basic</module> module that implements
      the HTTP part. <module>mod_authn_dbm</module> provides for user
      authentication based on DBM-files. DBM-File based group
      authorization is now done by the <module>mod_authz_dbm</module>
      module.</p>
  
      <p>This document is kept only for historical reasons and no
      longer maintained.</p>
      </note>
  
      <p>This module provides for HTTP Basic Authentication, where
      the usernames and passwords are stored in DBM type database
      files. It is an alternative to the plain text password files
      provided by <module status="obsolete">mod_auth</module>.</p>
  </summary>
  
  <seealso><directive module="core">AuthName</directive></seealso>
  <seealso><directive module="core">AuthType</directive></seealso>
  <seealso><directive module="core">Require</directive></seealso>
  <seealso><directive module="core">Satisfy</directive></seealso>
  
  <directivesynopsis>
  <name>AuthDBMGroupFile</name>
  <description>Sets the name of the database file containing the list
  of user groups for authentication</description>
  <syntax>AuthDBMGroupFile <var>file-path</var></syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthDBMGroupFile</directive> directive sets the
      name of a DBM file containing the list of user groups for user
      authentication. <var>File-path</var> is the absolute path to the
      group file.</p>
  
      <p>The group file is keyed on the username. The value for a
      user is a comma-separated list of the groups to which the users
      belongs. There must be no whitespace within the value, and it
      must never contain any colons.</p>
  
      <p>Security: make sure that the
      <directive>AuthDBMGroupFile</directive> 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 <directive>AuthDBMGroupFile</directive> unless
      otherwise protected.</p>
  
      <p>Combining Group and Password DBM files: In some cases it is
      easier to manage a single database which contains both the
      password and group details for each user. This simplifies any
      support programs that need to be written: they now only have to
      deal with writing to and locking a single DBM file. This can be
      accomplished by first setting the group and password files to
      point to the same DBM:</p>
  
      <example>
        AuthDBMGroupFile /www/userbase<br />
        AuthDBMUserFile /www/userbase
      </example>
  
      <p>The key for the single DBM is the username. The value consists
      of</p>
  
      <example>
        <var>Unix Crypt-ed Password</var>:<var>List of Groups</var>[:(ignored)]
      </example>
  
      <p>The password section contains the Unix <code>crypt()</code>
      password as before. This is followed by a colon and the comma
      separated list of groups. Other data may optionally be left in the
      DBM file after another colon; it is ignored by the authentication
      module. This is what www.telescope.org uses for its combined
      password and group database.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDBMUserFile</name>
  <description>Sets thename of a database file containing the list of users and
  passwords for authentication</description>
  <syntax>AuthDBMUserFile <var>file-path</var></syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthDBMUserFile</directive> directive sets the
      name of a DBM file containing the list of users and passwords for
      user authentication. <var>File-path</var> is the absolute path to
      the user file.</p>
  
      <p>The user file is keyed on the username. The value for a user is
      the <code>crypt()</code> encrypted password, optionally followed
      by a colon and arbitrary data. The colon and the data following it
      will be ignored by the server.</p>
  
      <p>Security: make sure that the
      <directive>AuthDBMUserFile</directive> 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 <directive>AuthDBMUserFile</directive>.</p>
  
      <p>Important compatibility note: The implementation of
      "dbmopen" in the apache modules reads the string length of the
      hashed values from the DBM data structures, rather than relying
      upon the string being NULL-appended. Some applications, such as
      the Netscape web server, rely upon the string being
      NULL-appended, so if you are having trouble using DBM files
      interchangeably between applications this may be a part of the
      problem.</p>
  
      <p>A perl script called
      <a href="../programs/dbmmanage.html">dbmmanage</a> is included with
      Apache. This program can be used to create and update DBM
      format password files for use with this module.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDBMType</name>
  <description>Sets the type of database file that is used to
  store passwords</description>
  <syntax>AuthDBMType default|SDBM|GDBM|NDBM|DB</syntax>
  <default>AuthDBMType default</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  <compatibility>Available in version 2.0.30 and later.</compatibility>
  
  <usage>
  
  <p>Sets the type of database file that is used to store the passwords.
  The default database type is determined at compile time.  The
  availability of other types of database files also depends on
  <a href="../install.html#dbm">compile-time settings</a>.</p>
  
  <p>It is crucial that whatever program you use to create your password
  files is configured to use the same type of database.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDBMAuthoritative</name>
  <description>Sets whether authentication and authorization will be
  passwed on to lower level modules</description>
  <syntax>AuthDBMAuthoritative on|off</syntax>
  <default>AuthDBMAuthoritative on</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
  
  <note>This information has not been updated to take into account the
  new module ordering techniques in Apache 2.0</note>
  
      <p>Setting the <directive>AuthDBMAuthoritative</directive>
      directive explicitly to <strong>'off'</strong> allows for both
      authentication 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 <strong>no userID</strong>
      or <strong>rule</strong> 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>
  
      <p>So if a userID appears in the database of more than one module;
      or if a valid <directive module="core">Require</directive>
      directive applies to more than one module; then the first module
      will verify the credentials; and no access is passed on;
      regardless of the <directive>AuthAuthoritative</directive> setting.</p>
  
      <p>A common use for this is in conjunction with one of the
      basic auth modules; such as <module status="obsolete">mod_auth</module>. Whereas this
      DBM module supplies the bulk of the user credential checking; a
      few (administrator) related accesses fall through to a lower
      level with a well protected .htpasswd file.</p>
  
      <p>By default, control is not passed on and an unknown userID
      or rule will result in an Authorization Required reply. Not
      setting it thus keeps the system secure and forces an NCSA
      compliant behaviour.</p>
  
      <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 which
      might have more access interfaces.</p>
  </usage>
  </directivesynopsis>
  
  </modulesynopsis>
  
  
  1.1                  httpd-2.0/docs/manual/mod/obs_mod_auth_digest.xml
  
  Index: obs_mod_auth_digest.xml
  ===================================================================
  <?xml version="1.0"?>
  <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
  <modulesynopsis>
  <name>mod_auth_digest</name>
  <description>User authentication using MD5
      Digest Authentication.</description>
  <status>Obsolete</status>
  <hint>obsolete since 2.0.44</hint>
  <sourcefile>mod_auth_digest.c</sourcefile>
  <identifier>auth_digest_module</identifier>
  <compatibility>Available only in versions up to 2.0.43. The new module
  that unfortunately is also named <module>mod_auth_digest</module>
  includes support for the auth provider mechanism introduced
  in 2.0.44.</compatibility>
  
  <summary>
      <note type="warning"><title>This module is obsolete!</title>
      <p>Note, that this module has been marked as obsolete. A bunch
      of modules was introduced in Apache version 2.0.44 that
      support the new Authentication/Authorization provider mechnism.</p>
  
      <p>In order to get the ability of HTTP Digest Authentication, you have
      to use the new <module>mod_auth_digest</module> module that implements
      the HTTP part. The user and group data management is provided by the
      <code>mod_authn_*</code> and <code>mod_authz_*</code> modules. If you
      want to use your existing user files, have a look at <module
      >mod_authn_file</module>.</p>
  
      <p>This document is kept only for historical reasons and no
      longer maintained.</p>
      </note>
  
      <p>This module implements HTTP Digest Authentication.  However, it
      has not been extensively tested and is therefore marked
      experimental.</p>
  </summary>
  
  <seealso><directive module="core">AuthName</directive></seealso>
  <seealso><directive module="core">AuthType</directive></seealso>
  <seealso><directive module="core">Require</directive></seealso>
  <seealso><directive module="core">Satisfy</directive></seealso>
  
  <section id="using"><title>Using Digest Authentication</title>
  
      <p>Using MD5 Digest authentication is very simple. Simply set
      up authentication normally, using "AuthType Digest" and
      "AuthDigestFile" instead of the normal "AuthType Basic" and
      "AuthUserFile"; also, replace any "AuthGroupFile" with
      "AuthDigestGroupFile". Then add a "AuthDigestDomain" directive
      containing at least the root URI(s) for this protection space.
      Example:</p>
  
      <example>
        &lt;Location /private/&gt;<br />
        <indent>
          AuthType Digest<br />
          AuthName "private area"<br />
          AuthDigestDomain /private/ http://mirror.my.dom/private2/<br />
          AuthDigestFile /web/auth/.digest_pw<br />
          Require valid-user<br />
        </indent>
        &lt;/Location&gt;
      </example>
  
      <note><title>Note</title> 
      <p>Digest authentication provides a more secure password system
      than Basic authentication, but only works with supporting
      browsers. As of July 2002, the major browsers that support digest
      authentication are <a href="http://www.opera.com/">Opera</a>, <a
      href="http://www.microsoft.com/windows/ie/">MS Internet
      Explorer</a> (fails when used with a query string), <a
      href="http://www.w3.org/Amaya/">Amaya</a> and <a
      href="http://www.mozilla.org">Mozilla</a>.  Since digest
      authentication is not as widely implemented as basic
      authentication, you should use it only in controlled settings.</p>
      </note>
  </section>
  
  <directivesynopsis>
  <name>AuthDigestFile</name>
  <description>Location of the text file containing the list
  of users and encoded passwords for digest authentication</description>
  <syntax>AuthDigestFile <var>file-path</var></syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthDigestFile</directive> directive sets the
      name of a textual file containing the list of users and encoded
      passwords for digest authentication. <var>File-path</var> is the
      absolute path to the user file.</p>
  
      <p>The digest file uses a special format. Files in this format
      can be created using the <a
      href="../programs/htdigest.html">htdigest</a> utility found in
      the support/ subdirectory of the Apache distribution.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDigestGroupFile</name>
  <description>Name of the text file containing the list of groups
  for digest authentication</description>
  <syntax>AuthDigestGroupFile <var>file-path</var></syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthDigestGroupFile</directive> directive sets
      the name of a textual file containing the list of groups and their
      members (user names). <var>File-path</var> is the absolute path to
      the group file.</p>
  
      <p>Each line of the group file contains a groupname followed by
      a colon, followed by the member usernames separated by spaces.
      Example:</p>
  
      <example>mygroup: bob joe anne</example>
  
      <p>Note that searching large text files is <em>very</em>
      inefficient.</p>
  
      <p>Security: make sure that the AuthGroupFile 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 AuthGroupFile.</p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDigestQop</name>
  <description>Determines the quality-of-protection to use in digest
  authentication</description>
  <syntax>AuthDigestQop none|auth|auth-int [auth|auth-int]</syntax>
  <default>AuthDigestQop auth</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthDigestQop</directive> directive determines
      the quality-of-protection to use. <code>auth</code> will only do
      authentication (username/password); <code>auth-int</code> is
      authentication plus integrity checking (an MD5 hash of the entity
      is also computed and checked); <code>none</code> will cause the module
      to use the old RFC-2069 digest algorithm (which does not include
      integrity checking). Both <code>auth</code> and <code>auth-int</code> may
      be specified, in which the case the browser will choose which of
      these to use. <code>none</code> should only be used if the browser for
      some reason does not like the challenge it receives otherwise.</p>
  
      <note>
        <code>auth-int</code> is not implemented yet.
      </note>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDigestNonceLifetime</name>
  <description>How long the server nonce is valid</description>
  <syntax>AuthDigestNonceLifetime <var>seconds</var></syntax>
  <default>AuthDigestNonceLifetime 300</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthDigestNonceLifetime</directive> directive
      controls how long the server nonce is valid. When the client
      contacts the server using an expired nonce the server will send
      back a 401 with <code>stale=true</code>. If <var>seconds</var> is
      greater than 0 then it specifies the amount of time for which the
      nonce is valid; this should probably never be set to less than 10
      seconds. If <var>seconds</var> is less than 0 then the nonce never
      expires. <!-- Not implemented yet If <var>seconds</var> is 0 then
      the nonce may be used exactly once by the client. Note that while
      one-time-nonces provide higher security against replay attacks,
      they also have significant performance implications, as the
      browser cannot pipeline or multiple connections for the
      requests. Because browsers cannot easily detect that
      one-time-nonces are being used, this may lead to browsers trying
      to pipeline requests and receiving 401 responses for all but the
      first request, requiring the browser to resend the requests. Note
      also that the protection against reply attacks only makes sense
      for dynamically generated content and things like POST requests;
      for static content the attacker may already have the complete
      response, so one-time-nonces do not make sense here.  -->
      </p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDigestNonceFormat</name>
  <description>Determines how the nonce is generated</description>
  <syntax>AuthDigestNonceFormat <var>format</var></syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p><strong>Not implemented yet.</strong> <!--
              <P>The AuthDigestNonceFormat directive determines how the nonce is
              generated.
              -->
      </p>
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDigestNcCheck</name>
  <description>Enables or disables checking of the nonce-count sent by the
  server</description>
  <syntax>AuthDigestNcCheck On|Off</syntax>
  <default>AuthDigestNcCheck Off</default>
  <contextlist><context>server config</context></contextlist>
  
  <usage>
      <note>
        Not implemented yet.
      </note>
      <!--
              <P>The AuthDigestNcCheck directive enables or disables the checking of the
              nonce-count sent by the server.
  
              <P>While recommended from a security standpoint, turning this directive
              On has one important performance implication. To check the nonce-count
              *all* requests (which have an Authorization header, irrespective of
              whether they require digest authentication) must be serialized through
              a critical section. If the server is handling a large number of
              requests which contain the Authorization header then this may noticeably
              impact performance.
       -->
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDigestAlgorithm</name>
  <description>Selects the algorithm used to calculate the challenge and
  response hases in digest authentication</description>
  <syntax>AuthDigestAlgorithm MD5|MD5-sess</syntax>
  <default>AuthDigestAlgorithm MD5</default>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthDigestAlgorithm</directive> directive
      selects the algorithm used to calculate the challenge and response
      hashes.</p>
  
      <note>
        <code>MD5-sess</code> is not correctly implemented yet.
      </note>
      <!--
              <P>To use <EM>MD5-sess</EM> you must first code up the
              <VAR>get_userpw_hash()</VAR> function in <VAR>mod_auth_digest.c</VAR> .
      -->
  </usage>
  </directivesynopsis>
  
  <directivesynopsis>
  <name>AuthDigestDomain</name>
  <description>URIs that are in the same protection space for digest
  authentication</description>
  <syntax>AuthDigestDomain <var>URI</var> [<var>URI</var>] ...</syntax>
  <contextlist><context>directory</context><context>.htaccess</context>
  </contextlist>
  <override>AuthConfig</override>
  
  <usage>
      <p>The <directive>AuthDigestDomain</directive> directive allows
      you to specify one or more URIs which are in the same protection
      space (i.e. use the same realm and username/password info). The
      specified URIs are prefixes, i.e. the client will assume that all
      URIs "below" these are also protected by the same
      username/password. The URIs may be either absolute URIs
      (i.e. inluding a scheme, host, port, etc) or relative URIs.</p>
  
      <p>This directive <em>should</em> always be specified and
      contain at least the (set of) root URI(s) for this space.
      Omitting to do so will cause the client to send the
      Authorization header for <em>every request</em> sent to this
      server. Apart from increasing the size of the request, it may
      also have a detrimental effect on performance if
      "AuthDigestNcCheck" is on.</p>
  
      <p>The URIs specified can also point to different servers, in
      which case clients (which understand this) will then share
      username/password info across multiple servers without
      prompting the user each time. </p>
  </usage>
  </directivesynopsis>
  
  </modulesynopsis>
  
  
  
  
  
  

Mime
View raw message