From: Ken Coar Date: Wed, 15 Apr 2015 17:46:53 +0000 (+0000) Subject: Enclose parameters in quotation marks for <{Files,Directory,Location}{,Match}> X-Git-Tag: 2.5.0-alpha~3281 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=57ef10245b3cf962dcbe40d205d94c241bed7f0e;p=apache Enclose parameters in quotation marks for <{Files,Directory,Location}{,Match}> containers. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1673892 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/developer/lua.html.en b/docs/manual/developer/lua.html.en index f81d36503c..beec032f7f 100644 --- a/docs/manual/developer/lua.html.en +++ b/docs/manual/developer/lua.html.en @@ -456,10 +456,10 @@ end groups with different permissions: 

LuaAuthzProvider rights /path/to/lua/script.lua rights_handler
-<Directory /www/private>
+<Directory "/www/private">
     Require rights member
 </Directory>
-<Directory /www/admin>
+<Directory "/www/admin">
     Require rights admin
 </Directory>
diff --git a/docs/manual/developer/lua.xml b/docs/manual/developer/lua.xml index 06d9087624..c85b445a60 100644 --- a/docs/manual/developer/lua.xml +++ b/docs/manual/developer/lua.xml @@ -472,10 +472,10 @@ end

LuaAuthzProvider rights /path/to/lua/script.lua rights_handler -<Directory /www/private> +<Directory "/www/private"> Require rights member </Directory> -<Directory /www/admin> +<Directory "/www/admin"> Require rights admin </Directory> diff --git a/docs/manual/env.html.en b/docs/manual/env.html.en index 4df20490d8..23b95e0025 100644 --- a/docs/manual/env.html.en +++ b/docs/manual/env.html.en @@ -484,7 +484,7 @@ CustomLog logs/access_log common env=!image-request 
SetEnvIf Referer "^http://www\.example\.com/" local_referal
 # Allow browsers that do not send Referer info
 SetEnvIf Referer "^$" local_referal
-<Directory /web/images>
+<Directory "/web/images">
     Require env local_referal
 </Directory>
diff --git a/docs/manual/env.xml b/docs/manual/env.xml index 5bfefb285f..d4375cf688 100644 --- a/docs/manual/env.xml +++ b/docs/manual/env.xml @@ -526,7 +526,7 @@ CustomLog logs/access_log common env=!image-request SetEnvIf Referer "^http://www\.example\.com/" local_referal # Allow browsers that do not send Referer info SetEnvIf Referer "^$" local_referal -<Directory /web/images> +<Directory "/web/images"> Require env local_referal </Directory> diff --git a/docs/manual/expr.html.en b/docs/manual/expr.html.en index 7defa17d22..46d0565c52 100644 --- a/docs/manual/expr.html.en +++ b/docs/manual/expr.html.en @@ -546,7 +546,7 @@ listfunction ::= listfuncname "(" word ")"(" word ")" </If> # Check result of URI mapping by running in Directory context with -f -<Directory /var/www> +<Directory "/var/www"> AddEncoding x-gzip gz <If "-f '%{REQUEST_FILENAME}.unzipme' && ! %{HTTP:Accept-Encoding} =~ /gzip/"> SetOutputFilter INFLATE diff --git a/docs/manual/handler.html.en b/docs/manual/handler.html.en index 5f1700350e..72683d8fd3 100644 --- a/docs/manual/handler.html.en +++ b/docs/manual/handler.html.en @@ -117,7 +117,7 @@ AddHandler add-footer .html the send-as-is handler, regardless of their filename extensions.

- 
<Directory /web/htdocs/asis>
+      
<Directory "/web/htdocs/asis">
     SetHandler send-as-is
 </Directory>

 
diff --git a/docs/manual/handler.xml b/docs/manual/handler.xml
index 98dc9599bf..fd37d5603e 100644
--- a/docs/manual/handler.xml
+++ b/docs/manual/handler.xml
@@ -127,7 +127,7 @@ AddHandler add-footer .html
       filename extensions.

 
       
-<Directory /web/htdocs/asis>
+<Directory "/web/htdocs/asis">
     SetHandler send-as-is
 </Directory>
       
diff --git a/docs/manual/howto/cgi.html.en b/docs/manual/howto/cgi.html.en
index c47a64232f..5a7c34f828 100644
--- a/docs/manual/howto/cgi.html.en
+++ b/docs/manual/howto/cgi.html.en
@@ -137,7 +137,7 @@
       file, to specify that CGI execution was permitted in a particular
       directory:

 
-      
<Directory /usr/local/apache2/htdocs/somedir>
+      
<Directory "/usr/local/apache2/htdocs/somedir">
     Options +ExecCGI
 </Directory>

 
@@ -167,7 +167,7 @@
       .cgi in users' directories, you can use the
       following configuration.

 
-      
<Directory /home/*/public_html>
+      
<Directory "/home/*/public_html">
     Options +ExecCGI
     AddHandler cgi-script .cgi
 </Directory>

@@ -177,7 +177,7 @@
       a user's directory where everything will be treated as a CGI
       program, you can use the following.

 
-      
<Directory /home/*/public_html/cgi-bin>
+      
<Directory "/home/*/public_html/cgi-bin">
     Options ExecCGI
     SetHandler cgi-script
 </Directory>

diff --git a/docs/manual/howto/cgi.xml b/docs/manual/howto/cgi.xml
index bf6f4dc6c8..9ca0e6b436 100644
--- a/docs/manual/howto/cgi.xml
+++ b/docs/manual/howto/cgi.xml
@@ -146,7 +146,7 @@
       directory:

 
       
-<Directory /usr/local/apache2/htdocs/somedir>
+<Directory "/usr/local/apache2/htdocs/somedir">
     Options +ExecCGI
 </Directory>
       
@@ -179,7 +179,7 @@
       following configuration.

 
       
-<Directory /home/*/public_html>
+<Directory "/home/*/public_html">
     Options +ExecCGI
     AddHandler cgi-script .cgi
 </Directory>
@@ -190,7 +190,7 @@
       program, you can use the following.

 
       
-<Directory /home/*/public_html/cgi-bin>
+<Directory "/home/*/public_html/cgi-bin">
     Options ExecCGI
     SetHandler cgi-script
 </Directory>
diff --git a/docs/manual/howto/public_html.html.en b/docs/manual/howto/public_html.html.en
index fa55b63edb..a329b6e13a 100644
--- a/docs/manual/howto/public_html.html.en
+++ b/docs/manual/howto/public_html.html.en
@@ -154,7 +154,7 @@
     directive to make a particular subdirectory of a user's home directory
     cgi-enabled.

 
-    
<Directory /home/*/public_html/cgi-bin/>
+    
<Directory "/home/*/public_html/cgi-bin/">
     Options ExecCGI
     SetHandler cgi-script
 </Directory>

diff --git a/docs/manual/howto/public_html.xml b/docs/manual/howto/public_html.xml
index fbcef0fb7f..063501378b 100644
--- a/docs/manual/howto/public_html.xml
+++ b/docs/manual/howto/public_html.xml
@@ -154,7 +154,7 @@
     cgi-enabled.

 
     
-<Directory /home/*/public_html/cgi-bin/>
+<Directory "/home/*/public_html/cgi-bin/">
     Options ExecCGI
     SetHandler cgi-script
 </Directory>
diff --git a/docs/manual/misc/perf-scaling.html.en b/docs/manual/misc/perf-scaling.html.en
index 6a794830e0..be5acff59e 100644
--- a/docs/manual/misc/perf-scaling.html.en
+++ b/docs/manual/misc/perf-scaling.html.en
@@ -1285,8 +1285,7 @@ Swap:       3903784      12540  3891244

       ServerName blog.sandla.org:8001
       ServerAdmin sander@temme.net
       DocumentRoot "/home/sctemme/inst/blog/httpd/htdocs"
-      <Directory
-      "/home/sctemme/inst/blog/httpd/htdocs">
+      <Directory "/home/sctemme/inst/blog/httpd/htdocs">
           Options +Indexes
           Require all granted
           RewriteEngine on
@@ -1418,7 +1417,7 @@ CacheMaxExpire 21600

                     Unfortunately there does currently not exist a way to cache
                     these headers. 
                 

-
<FilesMatch \.(jpe?g|png|gif|js|css|x?html|xml)>
+
<FilesMatch "\.(jpe?g|png|gif|js|css|x?html|xml)">
     FileETag None
 </FilesMatch>

 
diff --git a/docs/manual/misc/perf-scaling.xml b/docs/manual/misc/perf-scaling.xml
index 6fcb818da0..cb88b8bf11 100644
--- a/docs/manual/misc/perf-scaling.xml
+++ b/docs/manual/misc/perf-scaling.xml
@@ -1284,8 +1284,7 @@ Listen *:8001
       ServerName blog.sandla.org:8001
       ServerAdmin sander@temme.net
       DocumentRoot "/home/sctemme/inst/blog/httpd/htdocs"
-      <Directory
-      "/home/sctemme/inst/blog/httpd/htdocs">
+      <Directory "/home/sctemme/inst/blog/httpd/htdocs">
           Options +Indexes
           Require all granted
           RewriteEngine on
@@ -1420,7 +1419,7 @@ CacheMaxExpire 21600
                     these headers. 
                 

 
-<FilesMatch \.(jpe?g|png|gif|js|css|x?html|xml)>
+<FilesMatch "\.(jpe?g|png|gif|js|css|x?html|xml)">
     FileETag None
 </FilesMatch>
 
diff --git a/docs/manual/misc/perf-tuning.html.en b/docs/manual/misc/perf-tuning.html.en
index 7b529c7b52..4f36d3676f 100644
--- a/docs/manual/misc/perf-tuning.html.en
+++ b/docs/manual/misc/perf-tuning.html.en
@@ -132,7 +132,7 @@
       using these directives, if possible.

 
       
Note that it's possible to scope the directives, such as
-      within a <Location /server-status> section.
+      within a <Location "/server-status"> section.
       In this case the DNS lookups are only performed on requests
       matching the criteria. Here's an example which disables lookups
       except for .html and .cgi files:

@@ -160,7 +160,7 @@
       filename component. For example, if you had:

 
       
DocumentRoot /www/htdocs
-<Directory />
+<Directory "/">
   Options SymLinksIfOwnerMatch
 </Directory>

 
@@ -174,11 +174,11 @@
       security checking you can do something like this:

 
       
DocumentRoot /www/htdocs
-<Directory />
+<Directory "/">
   Options FollowSymLinks
 </Directory>
 
-<Directory /www/htdocs>
+<Directory "/www/htdocs">
   Options -FollowSymLinks +SymLinksIfOwnerMatch
 </Directory>

 
@@ -204,7 +204,7 @@
       example,

 
       
DocumentRoot /www/htdocs
-<Directory />
+<Directory "/">
   AllowOverride all
 </Directory>

 
diff --git a/docs/manual/misc/perf-tuning.xml b/docs/manual/misc/perf-tuning.xml
index bb44c33a82..6853e68e27 100644
--- a/docs/manual/misc/perf-tuning.xml
+++ b/docs/manual/misc/perf-tuning.xml
@@ -147,7 +147,7 @@
       using these directives, if possible.

 
       
Note that it's possible to scope the directives, such as
-      within a <Location /server-status> section.
+      within a <Location "/server-status"> section.
       In this case the DNS lookups are only performed on requests
       matching the criteria. Here's an example which disables lookups
       except for .html and .cgi files:

@@ -177,7 +177,7 @@ HostnameLookups off
 
       
 DocumentRoot /www/htdocs
-<Directory />
+<Directory "/">
   Options SymLinksIfOwnerMatch
 </Directory>
       
@@ -192,11 +192,11 @@ DocumentRoot /www/htdocs
 
       
 DocumentRoot /www/htdocs
-<Directory />
+<Directory "/">
   Options FollowSymLinks
 </Directory>
 
-<Directory /www/htdocs>
+<Directory "/www/htdocs">
   Options -FollowSymLinks +SymLinksIfOwnerMatch
 </Directory>
       
@@ -223,7 +223,7 @@ DocumentRoot /www/htdocs
 
       
 DocumentRoot /www/htdocs
-<Directory />
+<Directory "/">
   AllowOverride all
 </Directory>
       
diff --git a/docs/manual/misc/security_tips.html.en b/docs/manual/misc/security_tips.html.en
index 522083f665..b3da0c96cf 100644
--- a/docs/manual/misc/security_tips.html.en
+++ b/docs/manual/misc/security_tips.html.en
@@ -334,7 +334,7 @@
 
     
In the server configuration file, put

 
-    
<Directory />
+    
<Directory "/">
     AllowOverride None
 </Directory>

 
@@ -366,7 +366,7 @@
     work around this, add the following block to your server's
     configuration:

 
-    
<Directory />
+    
<Directory "/">
     Require all denied
 </Directory>

 
@@ -375,17 +375,17 @@
     appropriate Directory blocks to
     allow access only in those areas you wish. For example,

 
-    
<Directory /usr/users/*/public_html>
+    
<Directory "/usr/users/*/public_html">
     Require all granted
 </Directory>
-<Directory /usr/local/httpd>
+<Directory "/usr/local/httpd">
     Require all granted
 </Directory>

 
 
     
Pay particular attention to the interactions of Location and Directory directives; for instance, even
-    if <Directory /> denies access, a 
-    <Location /> directive might overturn it.

+    if <Directory "/"> denies access, a 
+    <Location "/"> directive might overturn it.

 
     
Also be wary of playing games with the UserDir directive; setting it to
     something like ./ would have the same effect, for root, as
diff --git a/docs/manual/misc/security_tips.xml b/docs/manual/misc/security_tips.xml
index 5664ff9d3e..af003eb889 100644
--- a/docs/manual/misc/security_tips.xml
+++ b/docs/manual/misc/security_tips.xml
@@ -328,7 +328,7 @@
     
In the server configuration file, put

 
     
-<Directory />
+<Directory "/">
     AllowOverride None
 </Directory>
     
@@ -361,7 +361,7 @@
     configuration:

 
     
-<Directory />
+<Directory "/">
     Require all denied
 </Directory>
     
@@ -371,10 +371,10 @@
     allow access only in those areas you wish. For example,

 
     
-<Directory /usr/users/*/public_html>
+<Directory "/usr/users/*/public_html">
     Require all granted
 </Directory>
-<Directory /usr/local/httpd>
+<Directory "/usr/local/httpd">
     Require all granted
 </Directory>
     
@@ -382,8 +382,8 @@
     
Pay particular attention to the interactions of Location and Directory directives; for instance, even
-    if <Directory /> denies access, a 
-    <Location /> directive might overturn it.

+    if <Directory "/"> denies access, a 
+    <Location "/"> directive might overturn it.

 
     
Also be wary of playing games with the UserDir directive; setting it to
diff --git a/docs/manual/mod/core.html.de b/docs/manual/mod/core.html.de
index c574b61e1b..c287b322a3 100644
--- a/docs/manual/mod/core.html.de
+++ b/docs/manual/mod/core.html.de
@@ -124,6 +124,7 @@ Servers
 
  •  Warning
    • 
 
 
+
 
    top
    
 
    AcceptFilter-Direktive
    
 
@@ -3660,7 +3661,6 @@ IP-Adressen angewendet werden
    
 
    Die Dokumentation zu dieser Direktive wurde
             noch nicht übersetzt. Bitte schauen Sie in die englische
             Version.
    
-
 
 
    
 
    Verfügbare Sprachen:  de  |
diff --git a/docs/manual/mod/core.html.en b/docs/manual/mod/core.html.en
index ce3ff4da0b..ae927b47c4 100644
--- a/docs/manual/mod/core.html.en
+++ b/docs/manual/mod/core.html.en
@@ -121,6 +121,7 @@ available
 
  •  Warning
    • 
 
 
    
+
 
    top
    
 
    AcceptFilter Directive
    
 
@@ -294,7 +295,7 @@ AcceptFilter https data/usr/local/.acl and /usr/local/web/.acl
     for directives, unless they have been disabled with
    
 
-    
    <Directory />
+    
    <Directory "/">
     AllowOverride None
 </Directory>
    
 
@@ -533,7 +534,7 @@ NoDecode option available in 2.3.12 and later.
 
     
    For security and performance reasons, do not set
     AllowOverride to anything other than None
-    in your <Directory /> block. Instead, find (or
+    in your <Directory "/"> block. Instead, find (or
     create) the <Directory> block that refers to the
     directory where you're actually planning to place a
     .htaccess file.
    
@@ -836,9 +837,9 @@ named file-system directory, sub-directories, and their contents.
     any single character, and * matches any sequences of
     characters. You may also use [] character ranges. None
     of the wildcards match a `/' character, so <Directory
-    /*/public_html> will not match
+    "/*/public_html"> will not match
     /home/user/public_html, but <Directory
-    /home/*/public_html> will match. Example:
    
+    "/home/*/public_html"> will match. Example:
    
 
     
    <Directory "/usr/local/httpd/htdocs">
   Options Indexes FollowSymLinks
@@ -876,7 +877,7 @@ named file-system directory, sub-directories, and their contents.
     first, interspersed with the directives from the .htaccess files. For example,
     with
    
 
-    
    <Directory />
+    
    <Directory "/">
   AllowOverride None
 </Directory>
 
@@ -918,12 +919,12 @@ named file-system directory, sub-directories, and their contents.
     be applied.
    
 
    
    Note that the default access for
-    <Directory /> is to permit all access.
+    <Directory "/"> is to permit all access.
     This means that Apache httpd will serve any file mapped from an URL. It is
     recommended that you change this with a block such
     as
    
 
-    
    <Directory />
+    
    <Directory "/">
   Require all denied
 </Directory>
    
 
@@ -991,7 +992,7 @@ the contents of file-system directories matching a regular expression.
     mod_rewrite. In order to prevent confusion, numbered
     (unnamed) backreferences are ignored. Use named groups instead.
    
 
-
    <DirectoryMatch ^/var/www/combined/(?<sitename>[^/]+)>
+
    <DirectoryMatch "^/var/www/combined/(?<sitename>[^/]+)">
     Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 </DirectoryMatch>
    
 
@@ -1335,7 +1336,7 @@ ErrorDocument 403 /cgi-bin/forbidden.pl?referrer=%{escape:%{HTTP_REFERER}}
    
 
     
    ErrorDocument 404 /cgi-bin/bad_urls.pl
 
-<Directory /web/docs>
+<Directory "/web/docs">
   ErrorDocument 404 default
 </Directory>
    
 
@@ -1817,7 +1818,7 @@ filenames
     mod_rewrite. In order to prevent confusion, numbered
     (unnamed) backreferences are ignored. Use named groups instead.
    
 
-
    <FilesMatch ^(?<sitename>[^/]+)>
+
    <FilesMatch "^(?<sitename>[^/]+)">
     require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 </FilesMatch>
    
 
@@ -1862,12 +1863,12 @@ media type in the HTTP Content-Type header field
     by using the value of None:
    
 
     
    # force all files to be image/gif:
-<Location /images>
+<Location "/images">
   ForceType image/gif
 </Location>
 
 # but normal mime-type associations here:
-<Location /images/mixed>
+<Location "/images/mixed">
   ForceType None
 </Location>
    
 
@@ -2649,7 +2650,7 @@ URLs
     /private1, /private1/ and /private1/file.txt will have the enclosed
     directives applied, but /private1other would not.
     
    
-    
    <Location /private1>
+    
    <Location "/private1">
     #  ...
 </Location>
    
 
@@ -2658,7 +2659,7 @@ URLs
     /private2/ and /private2/file.txt will have the enclosed
     directives applied, but /private2 and /private2other would not.
     
    
-    
    <Location /private2/>
+    
    <Location "/private2/">
     # ...
 </Location>
    
 
@@ -2668,7 +2669,7 @@ URLs
     
    Use <Location> to apply
     directives to content that lives outside the filesystem.  For
     content that lives in the filesystem, use <Directory> and <Files>.  An exception is
-    <Location />, which is an easy way to
+    <Location "/">, which is an easy way to
     apply a configuration to the entire server.
    
     
    
 
@@ -2704,7 +2705,7 @@ URLs
     directive. For example, to enable status requests, but allow them
     only from browsers at example.com, you might use:
    
 
-    
    <Location /status>
+    
    <Location "/status">
   SetHandler server-status
   Require host example.com
 </Location>
    
@@ -2720,12 +2721,12 @@ URLs
       directive and the regex version of <Location> require you to explicitly specify multiple
       slashes if that is your intention.
    
 
-      
    For example, <LocationMatch ^/abc> would match
+      
    For example, <LocationMatch "^/abc"> would match
       the request URL /abc but not the request URL 
       //abc. The (non-regex) <Location> directive behaves similarly when used for
       proxy requests. But when (non-regex) <Location> is used for non-proxy requests it will
       implicitly match multiple slashes with a single slash. For example,
-      if you specify <Location /abc/def> and the
+      if you specify <Location "/abc/def"> and the
       request is to /abc//def then it will match.
    
     
 
@@ -2778,7 +2779,7 @@ matching URLs
     mod_rewrite. In order to prevent confusion, numbered
     (unnamed) backreferences are ignored. Use named groups instead.
    
 
-
    <LocationMatch ^/combined/(?<sitename>[^/]+)>
+
    <LocationMatch "^/combined/(?<sitename>[^/]+)">
     require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 </LocationMatch>
    
 
@@ -4212,7 +4213,7 @@ handler
     
    You could also use this directive to configure a particular
     handler for files with a particular file extension. For example:
    
 
-    
    <FilesMatch \.php$>
+    
    <FilesMatch "\.php$">
     SetHandler application/x-httpd-php
 </FilesMatch>
    
 
@@ -4639,7 +4640,6 @@ hostname or IP address
 
 
 
-
 
 
    
 
    Available Languages:  de  |
diff --git a/docs/manual/mod/core.html.es b/docs/manual/mod/core.html.es
index 98d1915621..61acd5605a 100644
--- a/docs/manual/mod/core.html.es
+++ b/docs/manual/mod/core.html.es
@@ -124,6 +124,7 @@
 
  •  Warning
    • 
 
 
    
+
 
    top
    
 
    AcceptFilter Directiva
    
 
    
     
    
@@ -4359,7 +4360,6 @@ hostname or IP address
    
 
    The documentation for this directive has
             not been translated yet. Please have a look at the English
             version.
    
-
 
 
    
 
    Idiomas disponibles:  de  |
diff --git a/docs/manual/mod/core.html.fr b/docs/manual/mod/core.html.fr
index ea2eb10b58..8a3c7dcd7b 100644
--- a/docs/manual/mod/core.html.fr
+++ b/docs/manual/mod/core.html.fr
@@ -123,6 +123,7 @@ disponibles
 
  •  Warning
    • 
 
 
    
+
 
    top
    
 
    Directive AcceptFilter
    
 
@@ -4960,7 +4961,6 @@ Apache.
-
 
    
 
    Langues Disponibles:  de  |
diff --git a/docs/manual/mod/core.html.ja.utf8 b/docs/manual/mod/core.html.ja.utf8
index f8aee4e117..00e11a9aca 100644
--- a/docs/manual/mod/core.html.ja.utf8
+++ b/docs/manual/mod/core.html.ja.utf8
@@ -124,6 +124,7 @@
 
  •  Warning
    • 
 
 
    
+
 
    top
    AcceptFilter ディレクティブ
    
 
    
 
 
 
 
 
    
@@ -3575,7 +3576,6 @@ of a request or the last 63, assuming the request itself is greater than
 
    このディレクティブの解説文書は
             まだ翻訳されていません。英語版をご覧ください。
             
    
-
 
 
    
 
    翻訳済み言語:  de  |
diff --git a/docs/manual/mod/core.html.tr.utf8 b/docs/manual/mod/core.html.tr.utf8
index 2466055c6e..06df756384 100644
--- a/docs/manual/mod/core.html.tr.utf8
+++ b/docs/manual/mod/core.html.tr.utf8
@@ -122,6 +122,7 @@
 
  •  Warning
    • 
 
 
    
+
 
    top
    
 
    AcceptFilter Yönergesi
    
 
@@ -4510,7 +4511,6 @@ gerçekleşmesi için sunucunun geçmesini bekleyeceği süre.
    
 
    Uyumluluk:2.5 and later
    
 
    Bu yönergenin belgesi henüz Türkçeye çevrilmedi.
             Lütfen İngilizce sürümüne bakınız.
    
-
 
 
    
 
    Mevcut Diller:  de  |
diff --git a/docs/manual/mod/core.xml b/docs/manual/mod/core.xml
index ffca5551de..113103e4e6 100644
--- a/docs/manual/mod/core.xml
+++ b/docs/manual/mod/core.xml
@@ -204,7 +204,7 @@ AcceptFilter https data
     for directives, unless they have been disabled with
    
 
     
-<Directory />
+<Directory "/">
     AllowOverride None
 </Directory>
     
@@ -472,7 +472,7 @@ NoDecode option available in 2.3.12 and later.
 
     
    For security and performance reasons, do not set
     AllowOverride to anything other than None
-    in your <Directory /> block. Instead, find (or
+    in your <Directory "/"> block. Instead, find (or
     create) the <Directory> block that refers to the
     directory where you're actually planning to place a
     .htaccess file.
    
@@ -774,9 +774,9 @@ named file-system directory, sub-directories, and their contents.
     any single character, and * matches any sequences of
     characters. You may also use [] character ranges. None
     of the wildcards match a `/' character, so <Directory
-    /*/public_html> will not match
+    "/*/public_html"> will not match
     /home/user/public_html, but <Directory
-    /home/*/public_html> will match. Example:
    
+    "/home/*/public_html"> will match. Example:
    
 
     
 <Directory "/usr/local/httpd/htdocs">
@@ -819,7 +819,7 @@ named file-system directory, sub-directories, and their contents.
     with
    
 
     
-<Directory />
+<Directory "/">
   AllowOverride None
 </Directory>
 
@@ -862,13 +862,13 @@ named file-system directory, sub-directories, and their contents.
     be applied.
    
 
    
    Note that the default access for
-    <Directory /> is to permit all access.
+    <Directory "/"> is to permit all access.
     This means that Apache httpd will serve any file mapped from an URL. It is
     recommended that you change this with a block such
     as
    
 
     
-<Directory />
+<Directory "/">
   Require all denied
 </Directory>
     
@@ -938,7 +938,7 @@ the contents of file-system directories matching a regular expression.
 
 
-<DirectoryMatch ^/var/www/combined/(?<sitename>[^/]+)>
+<DirectoryMatch "^/var/www/combined/(?<sitename>[^/]+)">
     Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 </DirectoryMatch>
 
@@ -1286,7 +1286,7 @@ ErrorDocument 403 /cgi-bin/forbidden.pl?referrer=%{escape:%{HTTP_REFERER}}
     
 ErrorDocument 404 /cgi-bin/bad_urls.pl
 
-<Directory /web/docs>
+<Directory "/web/docs">
   ErrorDocument 404 default
 </Directory>
     
@@ -1810,7 +1810,7 @@ filenames
     (unnamed) backreferences are ignored. Use named groups instead.
    
 
 
-<FilesMatch ^(?<sitename>[^/]+)>
+<FilesMatch "^(?<sitename>[^/]+)">
     require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 </FilesMatch>
 
@@ -1853,12 +1853,12 @@ media type in the HTTP Content-Type header field
 
     
 # force all files to be image/gif:
-<Location /images>
+<Location "/images">
   ForceType image/gif
 </Location>
 
 # but normal mime-type associations here:
-<Location /images/mixed>
+<Location "/images/mixed">
   ForceType None
 </Location>
     
@@ -2651,7 +2651,7 @@ URLs
     directives applied, but /private1other would not.
     
    
     
-<Location /private1>
+<Location "/private1">
     #  ...
 </Location>
     
@@ -2661,7 +2661,7 @@ URLs
     directives applied, but /private2 and /private2other would not.
     
    
     
-<Location /private2/>
+<Location "/private2/">
     # ...
 </Location>
     
@@ -2674,7 +2674,7 @@ URLs
     content that lives in the filesystem, use Directory and Files.  An exception is
-    <Location />, which is an easy way to
+    <Location "/">, which is an easy way to
     apply a configuration to the entire server.
    
         
 
@@ -2714,7 +2714,7 @@ URLs
     only from browsers at example.com, you might use:
    
 
     
-<Location /status>
+<Location "/status">
   SetHandler server-status
   Require host example.com
 </Location>
@@ -2731,14 +2731,14 @@ URLs
       >Location require you to explicitly specify multiple
       slashes if that is your intention.
    
 
-      
    For example, <LocationMatch ^/abc> would match
+      
    For example, <LocationMatch "^/abc"> would match
       the request URL /abc but not the request URL 
       //abc. The (non-regex) Location directive behaves similarly when used for
       proxy requests. But when (non-regex) Location is used for non-proxy requests it will
       implicitly match multiple slashes with a single slash. For example,
-      if you specify <Location /abc/def> and the
+      if you specify <Location "/abc/def"> and the
       request is to /abc//def then it will match.
    
     
 
@@ -2791,7 +2791,7 @@ matching URLs
     (unnamed) backreferences are ignored. Use named groups instead.
    
 
 
-<LocationMatch ^/combined/(?<sitename>[^/]+)>
+<LocationMatch "^/combined/(?<sitename>[^/]+)">
     require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 </LocationMatch>
 
@@ -4177,7 +4177,7 @@ handler
     handler for files with a particular file extension. For example:
    
 
     
-<FilesMatch \.php$>
+<FilesMatch "\.php$">
     SetHandler application/x-httpd-php
 </FilesMatch>
     
diff --git a/docs/manual/mod/event.html.en b/docs/manual/mod/event.html.en
index 6643e05365..964fca8cd7 100644
--- a/docs/manual/mod/event.html.en
+++ b/docs/manual/mod/event.html.en
@@ -80,58 +80,6 @@ of consuming threads only for connections with active processing
 
  • The worker MPM
    • 
 
    
 
    top
    
-
    AsyncRequestWorkerFactor Directive
    
-
-
-
-
-
-
-
-
-
    Description:Limit concurrent connections per process
    Syntax:AsyncRequestWorkerFactor factor
    Default:2
    Context:server config
    Status:MPM
    Module:event
    Compatibility:Available in version 2.3.13 and later
    
-    
    The event MPM handles some connections in an asynchronous way, where
-    request worker threads are only allocated for short periods of time as
-    needed, and other connections with one request worker thread reserved per
-    connection. This can lead to situations where all workers are tied up and
-    no worker thread is available to handle new work on established async
-    connections.
    
-
-    
    To mitigate this problem, the event MPM does two things: Firstly, it
-    limits the number of connections accepted per process, depending on the
-    number of idle request workers. Secondly, if all workers are busy, it will
-    close connections in keep-alive state even if the keep-alive timeout has
-    not expired. This allows the respective clients to reconnect to a
-    different process which may still have worker threads available.
    
-
-    
    This directive can be used to fine-tune the per-process connection
-    limit. A process will only accept new connections if the current number of
-    connections (not counting connections in the "closing" state) is lower
-    than:
    
-
-    
    
-        ThreadsPerChild +
-        (AsyncRequestWorkerFactor *
-        number of idle workers)
-    
    
-
-    
    This means the absolute maximum numbers of concurrent connections is:
    
-
-    
    
-        (AsyncRequestWorkerFactor + 1) *
-        MaxRequestWorkers
-    
    
-
-    
    MaxRequestWorkers was called
-    MaxClients prior to version 2.3.13. The above value
-    shows that the old name did not accurately describe its meaning for the event MPM.
    
-
-    
    AsyncRequestWorkerFactor can take non-integer
-    arguments, e.g "1.5".
    
-
-
-
    
-
    top
    
 
    
 
    How it Works
    
     
    This MPM tries to fix the 'keep alive problem' in HTTP. After a client
@@ -197,6 +145,58 @@ of consuming threads only for connections with active processing
       with support for EPoll.
 
     
+
    
+
    top
    
+
    AsyncRequestWorkerFactor Directive
    
+
+
+
+
+
+
+
+
+
    Description:Limit concurrent connections per process
    Syntax:AsyncRequestWorkerFactor factor
    Default:2
    Context:server config
    Status:MPM
    Module:event
    Compatibility:Available in version 2.3.13 and later
    
+    
    The event MPM handles some connections in an asynchronous way, where
+    request worker threads are only allocated for short periods of time as
+    needed, and other connections with one request worker thread reserved per
+    connection. This can lead to situations where all workers are tied up and
+    no worker thread is available to handle new work on established async
+    connections.
    
+
+    
    To mitigate this problem, the event MPM does two things: Firstly, it
+    limits the number of connections accepted per process, depending on the
+    number of idle request workers. Secondly, if all workers are busy, it will
+    close connections in keep-alive state even if the keep-alive timeout has
+    not expired. This allows the respective clients to reconnect to a
+    different process which may still have worker threads available.
    
+
+    
    This directive can be used to fine-tune the per-process connection
+    limit. A process will only accept new connections if the current number of
+    connections (not counting connections in the "closing" state) is lower
+    than:
    
+
+    
    
+        ThreadsPerChild +
+        (AsyncRequestWorkerFactor *
+        number of idle workers)
+    
    
+
+    
    This means the absolute maximum numbers of concurrent connections is:
    
+
+    
    
+        (AsyncRequestWorkerFactor + 1) *
+        MaxRequestWorkers
+    
    
+
+    
    MaxRequestWorkers was called
+    MaxClients prior to version 2.3.13. The above value
+    shows that the old name did not accurately describe its meaning for the event MPM.
    
+
+    
    AsyncRequestWorkerFactor can take non-integer
+    arguments, e.g "1.5".
    
+
+
 
    
 
 
    
diff --git a/docs/manual/mod/event.html.fr b/docs/manual/mod/event.html.fr
index 7f674fe799..f9cd764124 100644
--- a/docs/manual/mod/event.html.fr
+++ b/docs/manual/mod/event.html.fr
@@ -50,7 +50,11 @@ mobiliser des threads que pour les connexions en cours de traitement
     httpd.
    
 
 
    
-
    Directives
    
+
    Sujets
    
+
    Directives
    
 
-
    Sujets
    
-
    Voir aussi
    
+
    Voir aussi
    
 
    
 
    top
    
-
    Directive AsyncRequestWorkerFactor
    
-
-
-
-
-
-
-
-
-
    Description:Limite le nombre de connexions simultanées par thread
    Syntaxe:AsyncRequestWorkerFactor facteur
    Défaut:2
    Contexte:configuration du serveur
    Statut:MPM
    Module:event
    Compatibilité:Disponible depuis la version 2.3.13
    
-    
    Le MPM event gère certaines connexions de manière asynchrone ;
-    dans ce cas, les threads traitant la requête sont alloués selon les
-    besoins et pour de courtes périodes. Dans les autres cas, un
-    thread est réservé par
-    connexion. Ceci peut conduire à des situations où tous les threads
-    sont saturés et où aucun thread n'est capable d'effectuer de
-    nouvelles tâches pour les connexions asynchrones établies.
    
-
-    
    Pour minimiser les effets de ce problème, le MPM event utilise
-    deux méthodes : tout d'abord, il limite le nombre de connexions
-    simultanées par thread en fonction du nombre de processus
-    inactifs. Ensuite, si tous les processus sont occupés, il ferme des
-    connexions permanentes, même si la limite de durée de la connexion
-    n'a pas été atteinte. Ceci autorise les clients concernés à se
-    reconnecter à un autre processus possèdant encore des threads
-    disponibles.
    
-
-    
    Cette directive permet de personnaliser finement la limite du
-    nombre de connexions par thread. Un processus n'acceptera de
-    nouvelles connexions que si le nombre actuel de connexions (sans
-    compter les connexions à l'état "closing") est
-    inférieur à :
    
-
-    
    
-        ThreadsPerChild +
-        (AsyncRequestWorkerFactor *
-        nombre de threads inactifs)
-    
    
-
-    
    En d'autres termes, le nombre maximum de connexions simultanées
-    sera :
    
-
-    
    
-        (AsyncRequestWorkerFactor + 1) *
-        MaxRequestWorkers
-    
    
-
-    
    La directive MaxRequestWorkers se nommait
-    MaxClients avant la version 2.3.13. La valeur
-    ci-dessus montre que cet ancien nom ne correspondait pas à sa
-    signification exacte pour le MPM event.
    
-
-    
    La directive AsyncRequestWorkerFactor
-    accepte des valeurs d'argument de type non entier, comme "1.5".
    
-
-
-
    
-
    top
    
 
    
 
    Comment tout cela fonctionne
    
     
    Ce MPM essaie de résoudre le 'problème keep alive' de HTTP.
@@ -217,6 +159,64 @@ mobiliser des threads que pour les connexions en cours de traitement
       avec le support pour EPoll.
 
     
+
    
+
    top
    
+
    Directive AsyncRequestWorkerFactor
    
+
+
+
+
+
+
+
+
+
    Description:Limite le nombre de connexions simultanées par thread
    Syntaxe:AsyncRequestWorkerFactor facteur
    Défaut:2
    Contexte:configuration du serveur
    Statut:MPM
    Module:event
    Compatibilité:Disponible depuis la version 2.3.13
    
+    
    Le MPM event gère certaines connexions de manière asynchrone ;
+    dans ce cas, les threads traitant la requête sont alloués selon les
+    besoins et pour de courtes périodes. Dans les autres cas, un
+    thread est réservé par
+    connexion. Ceci peut conduire à des situations où tous les threads
+    sont saturés et où aucun thread n'est capable d'effectuer de
+    nouvelles tâches pour les connexions asynchrones établies.
    
+
+    
    Pour minimiser les effets de ce problème, le MPM event utilise
+    deux méthodes : tout d'abord, il limite le nombre de connexions
+    simultanées par thread en fonction du nombre de processus
+    inactifs. Ensuite, si tous les processus sont occupés, il ferme des
+    connexions permanentes, même si la limite de durée de la connexion
+    n'a pas été atteinte. Ceci autorise les clients concernés à se
+    reconnecter à un autre processus possèdant encore des threads
+    disponibles.
    
+
+    
    Cette directive permet de personnaliser finement la limite du
+    nombre de connexions par thread. Un processus n'acceptera de
+    nouvelles connexions que si le nombre actuel de connexions (sans
+    compter les connexions à l'état "closing") est
+    inférieur à :
    
+
+    
    
+        ThreadsPerChild +
+        (AsyncRequestWorkerFactor *
+        nombre de threads inactifs)
+    
    
+
+    
    En d'autres termes, le nombre maximum de connexions simultanées
+    sera :
    
+
+    
    
+        (AsyncRequestWorkerFactor + 1) *
+        MaxRequestWorkers
+    
    
+
+    
    La directive MaxRequestWorkers se nommait
+    MaxClients avant la version 2.3.13. La valeur
+    ci-dessus montre que cet ancien nom ne correspondait pas à sa
+    signification exacte pour le MPM event.
    
+
+    
    La directive AsyncRequestWorkerFactor
+    accepte des valeurs d'argument de type non entier, comme "1.5".
    
+
+
 
    
 
    
 
    
diff --git a/docs/manual/mod/mod_access_compat.html.en b/docs/manual/mod/mod_access_compat.html.en
index ce8c254358..9eaf18ffbe 100644
--- a/docs/manual/mod/mod_access_compat.html.en
+++ b/docs/manual/mod/mod_access_compat.html.en
@@ -91,6 +91,7 @@ have been deprecated by the new authz refactoring.  Please see
 
  • mod_authz_host
    • 
 
  • mod_authz_core
    • 
 
    
+
 
    top
    
 
    Allow Directive
    
 
@@ -198,7 +199,7 @@ Allow from 2001:db8::a00:20ff:fea7:ccea/10
     other HTTP request header fields.
    SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
-<Directory /docroot>
+<Directory "/docroot">
     Order Deny,Allow
     Deny from all
     Allow from env=let_me_in
@@ -358,7 +359,7 @@ Deny from foo.example.org
    
     directives because of its effect on the default access state. For
     example,
    
 
-    
    <Directory /www>
+    
    <Directory "/www">
     Order Allow,Deny
 </Directory>
    
 
@@ -426,11 +427,11 @@ Satisfy Any
    
     is to relax access restrictions for a subdirectory:
     
    
 
-    
    <Directory /var/www/private>
+    
    <Directory "/var/www/private">
     Require valid-user
 </Directory>
 
-<Directory /var/www/private/public>
+<Directory "/var/www/private/public">
     Allow from all
     Satisfy Any
 </Directory>
    
@@ -456,7 +457,6 @@ Satisfy Any
  • Require
    • 
-
 
    
 
    Available Languages:  en  |
diff --git a/docs/manual/mod/mod_access_compat.html.fr b/docs/manual/mod/mod_access_compat.html.fr
index b8ce55d420..4a729fd150 100644
--- a/docs/manual/mod/mod_access_compat.html.fr
+++ b/docs/manual/mod/mod_access_compat.html.fr
@@ -96,6 +96,7 @@ ce module sont devenues obsol
 
  • mod_authz_host
    • 
 
  • mod_authz_core
    • 
 
    
+
 
    top
    Directive Allow
    
 
    
 
     
 
 
 
 
 
    
@@ -480,7 +481,6 @@ Satisfy Any
  • Require
    • 
-
 
    
 
    Langues Disponibles:  en  |
diff --git a/docs/manual/mod/mod_access_compat.html.ja.utf8 b/docs/manual/mod/mod_access_compat.html.ja.utf8
index 1a9ba5cfa3..1b21dde70e 100644
--- a/docs/manual/mod/mod_access_compat.html.ja.utf8
+++ b/docs/manual/mod/mod_access_compat.html.ja.utf8
@@ -92,6 +92,7 @@
 
  • mod_authz_host
    • 
 
  • mod_authz_core
    • 
 
    
+
 
    top
    Allow ディレクティブ
    
 
    
 
 
 
 
 
    
@@ -441,7 +442,6 @@
 
  • Require
    • 
-
 
    
 
    翻訳済み言語:  en  |
diff --git a/docs/manual/mod/mod_access_compat.xml b/docs/manual/mod/mod_access_compat.xml
index d0acbc0587..390bef2380 100644
--- a/docs/manual/mod/mod_access_compat.xml
+++ b/docs/manual/mod/mod_access_compat.xml
@@ -198,7 +198,7 @@ Allow from 2001:db8::a00:20ff:fea7:ccea/10
 
     
 SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
-<Directory /docroot>
+<Directory "/docroot">
     Order Deny,Allow
     Deny from all
     Allow from env=let_me_in
@@ -376,7 +376,7 @@ Deny from foo.example.org
     example,
    
 
     
-<Directory /www>
+<Directory "/www">
     Order Allow,Deny
 </Directory>
     
@@ -452,11 +452,11 @@ Satisfy Any
     
    
 
     
-<Directory /var/www/private>
+<Directory "/var/www/private">
     Require valid-user
 </Directory>
 
-<Directory /var/www/private/public>
+<Directory "/var/www/private/public">
     Allow from all
     Satisfy Any
 </Directory>
diff --git a/docs/manual/mod/mod_actions.html.de b/docs/manual/mod/mod_actions.html.de
index cf360ed5f1..75bf752204 100644
--- a/docs/manual/mod/mod_actions.html.de
+++ b/docs/manual/mod/mod_actions.html.de
@@ -57,6 +57,7 @@
 
  • Dynamische Inhalte mit CGI
    • 
 
  • Die Verwendung von Handlern
    • 
 
    
+
 
    top
    Action-Direktive
    
 
    
 
 
 
 
    
@@ -160,7 +161,6 @@
     
    
-
 
    
 
    Verfügbare Sprachen:  de  |
diff --git a/docs/manual/mod/mod_actions.html.en b/docs/manual/mod/mod_actions.html.en
index 0dffd02393..bc2504336a 100644
--- a/docs/manual/mod/mod_actions.html.en
+++ b/docs/manual/mod/mod_actions.html.en
@@ -53,6 +53,7 @@
 
  • Dynamic Content with CGI
    • 
 
  • Apache httpd's Handler Use
    • 
 
    
+
 
    top
    Action Directive
    
 
    
 
 
 
 
    
@@ -95,7 +96,7 @@ Action my-file-type /cgi-bin/program.cgi
     if you want to use the Action directive in
     virtual locations.
    
 
-    
    <Location /news>
+    
    <Location "/news">
     SetHandler news-handler
     Action news-handler /cgi-bin/news.cgi virtual
 </Location>
    
@@ -147,7 +148,6 @@ Script PUT /~bob/put.cgi
    
-
 
    
 
    Available Languages:  de  |
diff --git a/docs/manual/mod/mod_actions.html.fr b/docs/manual/mod/mod_actions.html.fr
index 6a489ce49c..7ef602376b 100644
--- a/docs/manual/mod/mod_actions.html.fr
+++ b/docs/manual/mod/mod_actions.html.fr
@@ -56,6 +56,7 @@ type de m
 
  • Utilisation des gestionnaires
 d'Apache httpd
    • 
 
    
+
 
    top
    Directive Action
    
 
    
 
 
 
 
 
    
@@ -157,7 +158,6 @@ Script PUT /~bob/put.cgi
-
 
    
 
    Langues Disponibles:  de  |
diff --git a/docs/manual/mod/mod_actions.html.ja.utf8 b/docs/manual/mod/mod_actions.html.ja.utf8
index a22b43485c..ba212c5a55 100644
--- a/docs/manual/mod/mod_actions.html.ja.utf8
+++ b/docs/manual/mod/mod_actions.html.ja.utf8
@@ -59,6 +59,7 @@ CGI スクリプトを実行する機能を提供
 
  • CGI による動的コンテンツ
    • 
 
  • Apache のハンドラの使用
    • 
 
    
+
 
    top
    Action ディレクティブ
    
 
    
 
 
 
 
 
    
@@ -168,7 +169,6 @@ Apache 2.1 で導入されました
    
-
 
    
 
    翻訳済み言語:  de  |
diff --git a/docs/manual/mod/mod_actions.html.ko.euc-kr b/docs/manual/mod/mod_actions.html.ko.euc-kr
index b3284ca2d7..a287e02122 100644
--- a/docs/manual/mod/mod_actions.html.ko.euc-kr
+++ b/docs/manual/mod/mod_actions.html.ko.euc-kr
@@ -56,6 +56,7 @@
 
  • CGI·Î µ¿Àû ÆäÀÌÁö »ý¼º
    • 
 
  • ¾ÆÆÄÄ¡¿¡¼­ Çڵ鷯 »ç¿ë
    • 
 
    
+
 
    top
    Action Áö½Ã¾î
    
 
    
     
 
 
 
 
    
@@ -157,7 +158,6 @@
     
    
-
 
    
 
    °¡´ÉÇÑ ¾ð¾î:  de  |
diff --git a/docs/manual/mod/mod_actions.xml b/docs/manual/mod/mod_actions.xml
index fc23f614a4..d9a9457ca3 100644
--- a/docs/manual/mod/mod_actions.xml
+++ b/docs/manual/mod/mod_actions.xml
@@ -99,7 +99,7 @@ Action my-file-type /cgi-bin/program.cgi
     virtual locations.
    
 
     
-<Location /news>
+<Location "/news">
     SetHandler news-handler
     Action news-handler /cgi-bin/news.cgi virtual
 </Location>
diff --git a/docs/manual/mod/mod_alias.html.en b/docs/manual/mod/mod_alias.html.en
index 5c6b4899ae..c18fe02199 100644
--- a/docs/manual/mod/mod_alias.html.en
+++ b/docs/manual/mod/mod_alias.html.en
@@ -86,6 +86,47 @@
 
  • Mapping URLs to the filesystem
    • 
 
    top
    
+
    
+
    Order of Processing
    
+
+    
    Aliases and Redirects occurring in different contexts are processed
+    like other directives according to standard merging rules.  But when multiple
+    Aliases or Redirects occur in the same context (for example, in the
+    same <VirtualHost>
+    section) they are processed in a particular order.
    
+
+    
    First, all Redirects are processed before Aliases are processed,
+    and therefore a request that matches a Redirect or RedirectMatch will never have Aliases
+    applied.  Second, the Aliases and Redirects are processed in the order
+    they appear in the configuration files, with the first match taking
+    precedence.
    
+
+    
    For this reason, when two or more of these directives apply to the
+    same sub-path, you must list the most specific path first in order for
+    all the directives to have an effect.  For example, the following
+    configuration will work as expected:
    
+
+    
    Alias /foo/bar /baz
+Alias /foo /gaq
    
+
+
+    
    But if the above two directives were reversed in order, the
+    /foo Alias
+    would always match before the /foo/bar Alias, so the latter directive would be
+    ignored.
    
+
+    
    When the Alias,
+    ScriptAlias and 
+    Redirect directives are used
+    within a <Location>
+    or <LocationMatch>
+    section, these directives will take precedence over any globally
+    defined Alias,
+    ScriptAlias and 
+    Redirect directives.
    
+
+
    
+
    top
    Alias Directive
    
 
    
 
 
 
 
 
    
@@ -138,7 +179,7 @@
     permit access to the target directory.
    Alias /image /ftp/pub/image
-<Directory /ftp/pub/image>
+<Directory "/ftp/pub/image">
     Require all granted
 </Directory>
    
 
@@ -152,10 +193,10 @@
     section the URL-path is omitted, and the file-path is interpreted
     using expression syntax.
    
 
-    
    <Location /image>
+    
    <Location "/image">
     Alias /ftp/pub/image
 </Location>
-<LocationMatch /error/(?<NUMBER>[0-9]+)>
+<LocationMatch "/error/(?<NUMBER>[0-9]+)">
     Alias /usr/local/apache/errors/%{env:MATCH_NUMBER}.html
 </LocationMatch>
    
 
@@ -349,13 +390,13 @@ Redirect 303 /three http://example.com/other
    
     section with the URL-path omitted, then the URL parameter will be
     interpreted using expression syntax.
    
 
-    
    <Location /one>
+    
    <Location "/one">
     Redirect permanent http://example.com/two
 </Location>
    
-<Location /three>
+<Location "/three">
     Redirect 303 http://example.com/other
 </Location>
    
-<LocationMatch /error/(?<NUMBER>[0-9]+)>
+<LocationMatch "/error/(?<NUMBER>[0-9]+)">
     Redirect permanent http://example.com/errors/%{env:MATCH_NUMBER}.html
 </LocationMatch>
    
     
    
@@ -457,7 +498,7 @@ target as a CGI script
     server to run the script /web/cgi-bin/foo.  This configuration
     is essentially equivalent to:
    
     
    Alias /cgi-bin/ /web/cgi-bin/
-<Location /cgi-bin >
+<Location "/cgi-bin" >
     SetHandler cgi-script
     Options +ExecCGI
 </Location>
    
@@ -483,7 +524,7 @@ target as a CGI script
     choose to place your CGI scripts in a directory already
     accessible from the web, do not use
     ScriptAlias.  Instead, use <Directory>, SetHandler, and Options as in:
-    
    <Directory /usr/local/apache2/htdocs/cgi-bin >
+    
    <Directory "/usr/local/apache2/htdocs/cgi-bin">
     SetHandler cgi-script
     Options ExecCGI
 </Directory>
    
@@ -500,10 +541,10 @@ target as a CGI script
     section with the URL-path omitted, then the URL parameter will be
     interpreted using expression syntax.
    
 
-    
    <Location /cgi-bin >
+    
    <Location "/cgi-bin">
     ScriptAlias /web/cgi-bin/
 </Location>
-<LocationMatch /cgi-bin/errors/(?<NUMBER>[0-9]+)>
+<LocationMatch "/cgi-bin/errors/(?<NUMBER>[0-9]+)">
     ScriptAlias /web/cgi-bin/errors/%{env:MATCH_NUMBER}.cgi
 </LocationMatch>
    
     
    
@@ -556,47 +597,6 @@ and designates the target as a CGI script
     details.
    
 
 
-
-
    top
    
-
    
-
    Order of Processing
    
-
-    
    Aliases and Redirects occurring in different contexts are processed
-    like other directives according to standard merging rules.  But when multiple
-    Aliases or Redirects occur in the same context (for example, in the
-    same <VirtualHost>
-    section) they are processed in a particular order.
    
-
-    
    First, all Redirects are processed before Aliases are processed,
-    and therefore a request that matches a Redirect or RedirectMatch will never have Aliases
-    applied.  Second, the Aliases and Redirects are processed in the order
-    they appear in the configuration files, with the first match taking
-    precedence.
    
-
-    
    For this reason, when two or more of these directives apply to the
-    same sub-path, you must list the most specific path first in order for
-    all the directives to have an effect.  For example, the following
-    configuration will work as expected:
    
-
-    
    Alias /foo/bar /baz
-Alias /foo /gaq
    
-
-
-    
    But if the above two directives were reversed in order, the
-    /foo Alias
-    would always match before the /foo/bar Alias, so the latter directive would be
-    ignored.
    
-
-    
    When the Alias,
-    ScriptAlias and 
-    Redirect directives are used
-    within a <Location>
-    or <LocationMatch>
-    section, these directives will take precedence over any globally
-    defined Alias,
-    ScriptAlias and 
-    Redirect directives.
    
-
 
    
 
 
    
diff --git a/docs/manual/mod/mod_alias.html.fr b/docs/manual/mod/mod_alias.html.fr
index eb8fc64099..da042c04cc 100644
--- a/docs/manual/mod/mod_alias.html.fr
+++ b/docs/manual/mod/mod_alias.html.fr
@@ -68,7 +68,10 @@ redirection d'URL
     plutôt les outils fournis par le module mod_rewrite
    
 
 
    
-
    Directives
    
+
 
    top
    
+
    
+
    Chronologie du traitement
    
+
+    
    Les alias et redirections apparaissant dans différents contextes
+    sont traités comme les autres directives en respectant les règles de fusion standards. Par
+    contre, ils sont traités selon une chronologie particulière
+    lorsqu'ils apparaissent dans le même contexte (par exemple, dans la
+    même section <VirtualHost>).
    
+
+    
    Premièrement, toutes les redirections sont traitées avant les
+    alias, et ainsi, une requête qui correspond à une directive
+    Redirect ou RedirectMatch ne se verra jamais
+    appliquer d'alias. Deuxièmement, les alias et redirections sont
+    traités selon l'ordre dans lequel ils apparaissent dans le fichier
+    de configuration, seule la première correspondance étant prise en
+    compte.
    
+
+    
    Ainsi, lorsqu'une ou plusieurs de ces directives s'appliquent au
+    même sous-répertoire, vous devez classer les chemins du plus précis
+    au moins précis afin que toutes les directives puissent
+    éventuellement s'appliquer, comme dans l'exemple suivant :
    
+
+    
    Alias /foo/bar /baz
+Alias /foo /gaq
    
+
+
+    
    Si l'ordre des directives était inversé, la directive Alias ayant pour argument
+    /foo serait toujours appliquée avant la directive
+    Alias ayant pour argument
+    /foo/bar, et cette dernière serait toujours
+    ignorée.
    
+
+    
    La définition de directives Alias, ScriptAlias ou Redirect au sein de sections
+    <Location> ou
+    <LocationMatch>
+    l'emporte sur d'autres définitions éventuelles de ces mêmes
+    directives au niveau de la configuration générale du serveur.
    
+
+
    
+
    top
    
 
    Directive Alias
    
 
    
 
    Description:Maps URLs to filesystem locations
    
 
     
    
     détails.
    
 
 
-
-
    top
    
-
    
-
    Chronologie du traitement
    
-
-    
    Les alias et redirections apparaissant dans différents contextes
-    sont traités comme les autres directives en respectant les règles de fusion standards. Par
-    contre, ils sont traités selon une chronologie particulière
-    lorsqu'ils apparaissent dans le même contexte (par exemple, dans la
-    même section <VirtualHost>).
    
-
-    
    Premièrement, toutes les redirections sont traitées avant les
-    alias, et ainsi, une requête qui correspond à une directive
-    Redirect ou RedirectMatch ne se verra jamais
-    appliquer d'alias. Deuxièmement, les alias et redirections sont
-    traités selon l'ordre dans lequel ils apparaissent dans le fichier
-    de configuration, seule la première correspondance étant prise en
-    compte.
    
-
-    
    Ainsi, lorsqu'une ou plusieurs de ces directives s'appliquent au
-    même sous-répertoire, vous devez classer les chemins du plus précis
-    au moins précis afin que toutes les directives puissent
-    éventuellement s'appliquer, comme dans l'exemple suivant :
    
-
-    
    Alias /foo/bar /baz
-Alias /foo /gaq
    
-
-
-    
    Si l'ordre des directives était inversé, la directive Alias ayant pour argument
-    /foo serait toujours appliquée avant la directive
-    Alias ayant pour argument
-    /foo/bar, et cette dernière serait toujours
-    ignorée.
    
-
-    
    La définition de directives Alias, ScriptAlias ou Redirect au sein de sections
-    <Location> ou
-    <LocationMatch>
-    l'emporte sur d'autres définitions éventuelles de ces mêmes
-    directives au niveau de la configuration générale du serveur.
    
-
 
    
diff --git a/docs/manual/mod/mod_alias.html.ja.utf8 b/docs/manual/mod/mod_alias.html.ja.utf8
index 44129cbc44..eee433c765 100644
--- a/docs/manual/mod/mod_alias.html.ja.utf8
+++ b/docs/manual/mod/mod_alias.html.ja.utf8
@@ -64,7 +64,10 @@
     で提供されるツールを使用してください。
    
 
 
    
-
    ディレクティブ
    
+
 
    top
    
+
    
+
    処理の順番
    
+
+
    様々なコンテキスト中での Alias や Redirect は他のディレクティブと
+同じように標準の マージ規則 に
+従って処理されます。ただし、(例えば <VirtualHost> セクションの中のように) 複数の Alias や Redirect が
+同じコンテキスト中に現れた場合は決まった順番で処理されます。
    
+
+
    まず、Alias の前にすべての Redirect が処理されます。ですから、Redirect か RedirectMatch にマッチするリクエストには
+Alias は決して適用されません。次に、Alias と Redirect が設定ファイル中の
+順番に適用され、最初にマッチしたものが優先されます。
    
+
+
    ですから、二つ以上のディレクティブが同じパスに適用されるときは、
+すべてのディレクティブの効果を得るためにはより詳しいパスを先に書く
+必要があります。例えば、次の設定は期待通りの動作をします:
    
+
+
    
+Alias /foo/bar /baz
    
+Alias /foo /gaq
+
    
+
+
    しかし、上記の二つのディレクティブの順番が逆になると、
+/foo Alias が
+常に /foo/bar Alias より先にマッチしますので、後者は
+決して適用されることはありません。
    
+
+
    
+
    top
    
 
    Alias ディレクティブ
    
 
    
 
    Description:Met en correspondance des URLs avec des chemins du système
@@ -567,46 +607,6 @@ comme un script CGI
    
 
 
    
@@ -354,34 +382,6 @@ CGI スクリプトに指定
       ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1
     
    
 
-
-
    top
    
-
    
-
    処理の順番
    
-
-
    様々なコンテキスト中での Alias や Redirect は他のディレクティブと
-同じように標準の マージ規則 に
-従って処理されます。ただし、(例えば <VirtualHost> セクションの中のように) 複数の Alias や Redirect が
-同じコンテキスト中に現れた場合は決まった順番で処理されます。
    
-
-
    まず、Alias の前にすべての Redirect が処理されます。ですから、Redirect か RedirectMatch にマッチするリクエストには
-Alias は決して適用されません。次に、Alias と Redirect が設定ファイル中の
-順番に適用され、最初にマッチしたものが優先されます。
    
-
-
    ですから、二つ以上のディレクティブが同じパスに適用されるときは、
-すべてのディレクティブの効果を得るためにはより詳しいパスを先に書く
-必要があります。例えば、次の設定は期待通りの動作をします:
    
-
-
    
-Alias /foo/bar /baz
    
-Alias /foo /gaq
-
    
-
-
    しかし、上記の二つのディレクティブの順番が逆になると、
-/foo Alias が
-常に /foo/bar Alias より先にマッチしますので、後者は
-決して適用されることはありません。
    
-
 
    
diff --git a/docs/manual/mod/mod_alias.html.ko.euc-kr b/docs/manual/mod/mod_alias.html.ko.euc-kr
index db6fb49c06..b98b4e9d21 100644
--- a/docs/manual/mod/mod_alias.html.ko.euc-kr
+++ b/docs/manual/mod/mod_alias.html.ko.euc-kr
@@ -54,7 +54,10 @@
     mod_rewrite°¡ Á¦°øÇÏ´Â ±â´ÉÀ» ÀÌ¿ëÇ϶ó.
    
 
 
    
-
    Áö½Ã¾îµé
    
+
    ÁÖÁ¦
    
+
    Áö½Ã¾îµé
    
 
-
    ÁÖÁ¦
    
-
    Âü°í
    
+
    Âü°í
    
 
    
 
    top
    
+
    
+
    ó¸® ¼ø¼­
    
+
+
    ¼­·Î ´Ù¸¥ »ç¿ëÀå¼Ò¿¡¼­ Alias¿Í Redirect¸¦ »ç¿ëÇÏ¸é ´Ù¸¥ Áö½Ã¾î¿Í
+°°ÀÌ Ç¥ÁØ °áÇÕ ¹æ¹ý¿¡
+µû¶ó ó¸®ÇÑ´Ù. ±×·¯³ª °°Àº »ç¿ëÀå¼Ò¿¡ (¿¹¸¦ µé¾î, °°Àº <VirtualHost> ¼½¼Ç¿¡)
+Alias¿Í Redirect¸¦ »ç¿ëÇÏ¸é ¾Æ·¡ ¼ø¼­´ë·Î ó¸®ÇÑ´Ù.
    
+
+
    ¸ÕÀú ¸ðµç Redirect¸¦ ó¸®ÇÑ ÈÄ Alias¸¦ ó¸®ÇÑ´Ù. ±×·¡¼­
+Redirect³ª RedirectMatch¿¡ ÇØ´çÇÏ´Â ¿äûÀº
+Àý´ë·Î AliasÇÏÁö ¾Ê´Â´Ù. ±×¸®°í Alias¿Í Redirect´Â ¼³Á¤ÆÄÀÏ¿¡¼­
+ù¹ø°·Î ³ª¿À´Â °ÍÀ» »ç¿ëÇÑ´Ù.
    
+
+
    ±×·¡¼­ ¿©·¯ Áö½Ã¾î°¡ µ¿ÀÏÇÑ ÇÏÀ§°æ·Î¿¡ ÇØ´çÇÏ´Â °æ¿ì ¸ðµç
+Áö½Ã¾î¸¦ Àû¿ëÇϱâÀ§Çؼ­´Â °¡Àå »ó¼¼ÇÑ °æ·Î¸¦ ¸ÕÀú »ç¿ëÇØ¾ß ÇÑ´Ù.
+¿¹¸¦ µé¾î, ´ÙÀ½ ¼³Á¤Àº ÀǵµÇÑ´ë·Î µ¿ÀÛÇÑ´Ù:
    
+
+
    
+Alias /foo/bar /baz
    
+Alias /foo /gaq
+
    
+
+
    ±×·¯³ª À§ÀÇ µÎ Áö½Ã¾î ¼ø¼­¸¦ ¹Ù²Ù¸é /foo/bar
+Alias ÀÌÀü¿¡
+/foo Alias¸¦
+Àû¿ëÇϹǷΠÇ×»ó µÎ¹ø° Áö½Ã¾î¸¦ ¹«½ÃÇÑ´Ù.
    
+
+
    
+
    top
    
 
    Alias Áö½Ã¾î
    
 
    
 
    説明:URL をファイルシステムの位置にマップする
    
 
 
    
@@ -320,35 +349,6 @@
       ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1
     
    
 
-
-
    top
    
-
    
-
    ó¸® ¼ø¼­
    
-
-
    ¼­·Î ´Ù¸¥ »ç¿ëÀå¼Ò¿¡¼­ Alias¿Í Redirect¸¦ »ç¿ëÇÏ¸é ´Ù¸¥ Áö½Ã¾î¿Í
-°°ÀÌ Ç¥ÁØ °áÇÕ ¹æ¹ý¿¡
-µû¶ó ó¸®ÇÑ´Ù. ±×·¯³ª °°Àº »ç¿ëÀå¼Ò¿¡ (¿¹¸¦ µé¾î, °°Àº <VirtualHost> ¼½¼Ç¿¡)
-Alias¿Í Redirect¸¦ »ç¿ëÇÏ¸é ¾Æ·¡ ¼ø¼­´ë·Î ó¸®ÇÑ´Ù.
    
-
-
    ¸ÕÀú ¸ðµç Redirect¸¦ ó¸®ÇÑ ÈÄ Alias¸¦ ó¸®ÇÑ´Ù. ±×·¡¼­
-Redirect³ª RedirectMatch¿¡ ÇØ´çÇÏ´Â ¿äûÀº
-Àý´ë·Î AliasÇÏÁö ¾Ê´Â´Ù. ±×¸®°í Alias¿Í Redirect´Â ¼³Á¤ÆÄÀÏ¿¡¼­
-ù¹ø°·Î ³ª¿À´Â °ÍÀ» »ç¿ëÇÑ´Ù.
    
-
-
    ±×·¡¼­ ¿©·¯ Áö½Ã¾î°¡ µ¿ÀÏÇÑ ÇÏÀ§°æ·Î¿¡ ÇØ´çÇÏ´Â °æ¿ì ¸ðµç
-Áö½Ã¾î¸¦ Àû¿ëÇϱâÀ§Çؼ­´Â °¡Àå »ó¼¼ÇÑ °æ·Î¸¦ ¸ÕÀú »ç¿ëÇØ¾ß ÇÑ´Ù.
-¿¹¸¦ µé¾î, ´ÙÀ½ ¼³Á¤Àº ÀǵµÇÑ´ë·Î µ¿ÀÛÇÑ´Ù:
    
-
-
    
-Alias /foo/bar /baz
    
-Alias /foo /gaq
-
    
-
-
    ±×·¯³ª À§ÀÇ µÎ Áö½Ã¾î ¼ø¼­¸¦ ¹Ù²Ù¸é /foo/bar
-Alias ÀÌÀü¿¡
-/foo Alias¸¦
-Àû¿ëÇϹǷΠÇ×»ó µÎ¹ø° Áö½Ã¾î¸¦ ¹«½ÃÇÑ´Ù.
    
-
 
    
diff --git a/docs/manual/mod/mod_alias.html.tr.utf8 b/docs/manual/mod/mod_alias.html.tr.utf8
index d6e65c8b44..636de7e1f1 100644
--- a/docs/manual/mod/mod_alias.html.tr.utf8
+++ b/docs/manual/mod/mod_alias.html.tr.utf8
@@ -55,7 +55,10 @@ eşlenmesini sağlar ve URL yönlendirmesi yapar.
       sağlanan araçlar kullanılır.
    
 
   
    
-
    Yönergeler
    
+
    Konular
    
+
    Yönergeler
    
 
-
    Konular
    
-
    Ayrıca bakınız:
    
+
    Ayrıca bakınız:
    
 
    
 
    top
    
+
    
+
    İşlem Sırası
    
+
+    
    Farklı bağlamlarda bulunan Alias ve Redirect
+      yönergeleri standart katıştırma
+      kuralları ile ilgili diğer yönergeler gibi işleme sokulur. Fakat
+      aynı bağlam dahilinde (örneğin, aynı <VirtualHost> bölümünde) çok fazla Alias ve Redirect varsa bunlar belli bir
+      sıraya göre işleme sokulurlar.
    
+
+    
    İlk adımda, Alias’lardan önce
+      bütün Redirect yönergeleri
+      işleme sokulur. Bu bakımdan bir Redirect veya RedirectMatch ile eşleşen bir istek için
+      hiçbir Alias
+      uygulanmayacaktır. İkinci adımda yapılandırma dosyasında yer aldıkları
+      sıraya göre Redirect ve
+      Alias yönergeleri işleme
+      sokulurlar, dolayısıyla ilk eşleşme öncelikli olmuş olur.
    
+
+    
    İlk eşleşmenin öncelikli olması sebebiyle, bu yönergelerin birden
+      fazlası aynı alt yola uygulandığı takdirde, tüm yönergelerin etkili
+      olabilmesi için en uzun yolu sıralamada en öne almalısınız. Örneğin
+      aşağıdaki yapılandırma beklendiği gibi çalışacaktır:
    
+
+    
    
+    Alias /foo/bar /baz
    
+    Alias /foo /gaz
+    
    
+
+    
    Ama yukarıdaki iki satır ters sırada yerleştirilmiş olsaydı,
+      /foo rumuzu  daima /foo/bar rumuzundan önce
+      eşleşecek, dolayısıyla ikinci yönerge yok sayılacaktı.
    
+
+  
    
+
    top
    
 
    Alias Yönergesi
    
 
    
 
    ¼³¸í:URLÀ» ƯÁ¤ ÆÄÀϽýºÅÛ Àå¼Ò·Î ´ëÀÀÇÑ´Ù
    
 
 
    
@@ -493,40 +527,6 @@ eşler ve hedefi bir CGI betiği olarak çalıştırır.
-
    top
    
-
    
-
    İşlem Sırası
    
-
-    
    Farklı bağlamlarda bulunan Alias ve Redirect
-      yönergeleri standart katıştırma
-      kuralları ile ilgili diğer yönergeler gibi işleme sokulur. Fakat
-      aynı bağlam dahilinde (örneğin, aynı <VirtualHost> bölümünde) çok fazla Alias ve Redirect varsa bunlar belli bir
-      sıraya göre işleme sokulurlar.
    
-
-    
    İlk adımda, Alias’lardan önce
-      bütün Redirect yönergeleri
-      işleme sokulur. Bu bakımdan bir Redirect veya RedirectMatch ile eşleşen bir istek için
-      hiçbir Alias
-      uygulanmayacaktır. İkinci adımda yapılandırma dosyasında yer aldıkları
-      sıraya göre Redirect ve
-      Alias yönergeleri işleme
-      sokulurlar, dolayısıyla ilk eşleşme öncelikli olmuş olur.
    
-
-    
    İlk eşleşmenin öncelikli olması sebebiyle, bu yönergelerin birden
-      fazlası aynı alt yola uygulandığı takdirde, tüm yönergelerin etkili
-      olabilmesi için en uzun yolu sıralamada en öne almalısınız. Örneğin
-      aşağıdaki yapılandırma beklendiği gibi çalışacaktır:
    
-
-    
    
-    Alias /foo/bar /baz
    
-    Alias /foo /gaz
-    
    
-
-    
    Ama yukarıdaki iki satır ters sırada yerleştirilmiş olsaydı,
-      /foo rumuzu  daima /foo/bar rumuzundan önce
-      eşleşecek, dolayısıyla ikinci yönerge yok sayılacaktı.
    
-
-  
    
 
    Mevcut Diller:  en  |
diff --git a/docs/manual/mod/mod_alias.xml b/docs/manual/mod/mod_alias.xml
index b4e2711c04..d6572d4395 100644
--- a/docs/manual/mod/mod_alias.xml
+++ b/docs/manual/mod/mod_alias.xml
@@ -170,7 +170,7 @@ Alias /foo /gaq
 
     
 Alias /image /ftp/pub/image
-<Directory /ftp/pub/image>
+<Directory "/ftp/pub/image">
     Require all granted
 </Directory>
     
@@ -185,10 +185,10 @@ Alias /image /ftp/pub/image
     using expression syntax.
    
 
     
-<Location /image>
+<Location "/image">
     Alias /ftp/pub/image
 </Location>
-<LocationMatch /error/(?<NUMBER>[0-9]+)>
+<LocationMatch "/error/(?<NUMBER>[0-9]+)">
     Alias /usr/local/apache/errors/%{env:MATCH_NUMBER}.html
 </LocationMatch>
     
@@ -393,13 +393,13 @@ Redirect 303 /three http://example.com/other
     interpreted using expression syntax.
    
 
     
-<Location /one>
+<Location "/one">
     Redirect permanent http://example.com/two
 </Location>
    
-<Location /three>
+<Location "/three">
     Redirect 303 http://example.com/other
 </Location>
    
-<LocationMatch /error/(?<NUMBER>[0-9]+)>
+<LocationMatch "/error/(?<NUMBER>[0-9]+)">
     Redirect permanent http://example.com/errors/%{env:MATCH_NUMBER}.html
 </LocationMatch>
    
         
@@ -506,7 +506,7 @@ target as a CGI script
     is essentially equivalent to:
    
     
 Alias /cgi-bin/ /web/cgi-bin/
-<Location /cgi-bin >
+<Location "/cgi-bin" >
     SetHandler cgi-script
     Options +ExecCGI
 </Location>
@@ -537,7 +537,7 @@ Alias /cgi-bin/ /web/cgi-bin/
     module="core">SetHandler, and Options as in:
     
-<Directory /usr/local/apache2/htdocs/cgi-bin >
+<Directory "/usr/local/apache2/htdocs/cgi-bin">
     SetHandler cgi-script
     Options ExecCGI
 </Directory>
@@ -555,10 +555,10 @@ Alias /cgi-bin/ /web/cgi-bin/
     interpreted using expression syntax.
    
 
     
-<Location /cgi-bin >
+<Location "/cgi-bin">
     ScriptAlias /web/cgi-bin/
 </Location>
-<LocationMatch /cgi-bin/errors/(?<NUMBER>[0-9]+)>
+<LocationMatch "/cgi-bin/errors/(?<NUMBER>[0-9]+)">
     ScriptAlias /web/cgi-bin/errors/%{env:MATCH_NUMBER}.cgi
 </LocationMatch>
    
         
diff --git a/docs/manual/mod/mod_allowhandlers.html.en b/docs/manual/mod/mod_allowhandlers.html.en
index e770dca70d..855227eb01 100644
--- a/docs/manual/mod/mod_allowhandlers.html.en
+++ b/docs/manual/mod/mod_allowhandlers.html.en
@@ -35,7 +35,7 @@
 
    This module makes it easy to restrict which handlers may be used for a
 request. A possible configuration would be:
    
 
-
    <Location />
+
    <Location "/">
   AllowHandlers not server-info server-status balancer-manager ldap-status
 </Location>
    
 
@@ -54,6 +54,7 @@ returns 403 FORBIDDEN to the client. This can be used with directives like
 
  • SetHandler
    • 
 
  • AddHandler
    • 
 
    
+
 
    top
    AllowHandlers Directive
    
 
    
 
    Açıklama:URL’leri dosya sistemi konumlarıyla eşler.
    
 
 
 
 
 
 
    
@@ -72,7 +73,7 @@ set. The special vallue all can be used to allow all
 handlers again in a later config section, even if some headers were denied
 earlier in the configuration merge order:
    
 
-
    <Location /server-status>
+
    <Location "/server-status">
   AllowHandlers all
   SetHandler server-status
 </Location>
    
@@ -80,7 +81,6 @@ earlier in the configuration merge order:
    
 
 
 
-
 
 
    
 
    Available Languages:  en 
    
diff --git a/docs/manual/mod/mod_allowhandlers.xml b/docs/manual/mod/mod_allowhandlers.xml
index 2dcd165af5..aa4d16ccc1 100644
--- a/docs/manual/mod/mod_allowhandlers.xml
+++ b/docs/manual/mod/mod_allowhandlers.xml
@@ -33,7 +33,7 @@
 request. A possible configuration would be:
    
 
 
-<Location />
+<Location "/">
   AllowHandlers not server-info server-status balancer-manager ldap-status
 </Location>
 
@@ -65,7 +65,7 @@ handlers again in a later config section, even if some headers were denied
 earlier in the configuration merge order:
    
 
 
-<Location /server-status>
+<Location "/server-status">
   AllowHandlers all
   SetHandler server-status
 </Location>
diff --git a/docs/manual/mod/mod_allowmethods.html.en b/docs/manual/mod/mod_allowmethods.html.en
index b5eb35cdda..f3c0459586 100644
--- a/docs/manual/mod/mod_allowmethods.html.en
+++ b/docs/manual/mod/mod_allowmethods.html.en
@@ -36,7 +36,7 @@
 
    This module makes it easy to restrict what HTTP methods can
 used on an server. The most common configuration would be:
    
 
-
    <Location />
+
    <Location "/">
    AllowMethods GET POST OPTIONS
 </Location>
    
 
@@ -47,6 +47,7 @@ used on an server. The most common configuration would be:
    
 
  •  AllowMethods
    • 
 
 
    
+
 
    top
    
 
    AllowMethods Directive
    
 
    
@@ -64,7 +65,7 @@ RFC given in upper case. The GET and HEAD methods are treated as
 equivalent. The reset keyword can be used
 turn off mod_allowmethods in a deeper nested context:
    
 
-
    <Location /svn>
+
    <Location "/svn">
    AllowMethods reset
 </Location>
    
 
@@ -79,7 +80,6 @@ kludgy implementation of LimitExcept.
    
 
 
-
 
 
    
 
    Available Languages:  en  |
diff --git a/docs/manual/mod/mod_allowmethods.html.fr b/docs/manual/mod/mod_allowmethods.html.fr
index 21bdb70d0c..bc50398c72 100644
--- a/docs/manual/mod/mod_allowmethods.html.fr
+++ b/docs/manual/mod/mod_allowmethods.html.fr
@@ -48,6 +48,7 @@ est du style :
    
 
  •  AllowMethods
    • 
 
 
    
+
 
    top
    
 
    Directive AllowMethods
    
 
    
@@ -81,7 +82,6 @@ d'imbrication :
    
 remplacer l'implémentation "bricolée" des directives Limit et LimitExcept.
    
-
 
    
 
    Langues Disponibles:  en  |
diff --git a/docs/manual/mod/mod_allowmethods.xml b/docs/manual/mod/mod_allowmethods.xml
index d743b657c3..3fe9a00276 100644
--- a/docs/manual/mod/mod_allowmethods.xml
+++ b/docs/manual/mod/mod_allowmethods.xml
@@ -43,7 +43,7 @@ in order for it to rebuild correctly.
 used on an server. The most common configuration would be:
    
 
 
-<Location />
+<Location "/">
    AllowMethods GET POST OPTIONS
 </Location>
 
@@ -67,7 +67,7 @@ equivalent. The reset keyword can be used
 turn off mod_allowmethods in a deeper nested context:
    
 
 
-<Location /svn>
+<Location "/svn">
    AllowMethods reset
 </Location>
 
diff --git a/docs/manual/mod/mod_asis.html.fr b/docs/manual/mod/mod_asis.html.fr
index 1f5b596479..4251b5e992 100644
--- a/docs/manual/mod/mod_asis.html.fr
+++ b/docs/manual/mod/mod_asis.html.fr
@@ -47,12 +47,12 @@ HTTP
     
    Pour des raisons historiques, ce module traitera aussi tout
     fichier dont le type MIME est httpd/send-as-is.
    
 
    
-
    Directives
    
-
    Ce module ne fournit aucune directive.
    
-
    Sujets
    
+
    Sujets
    
 
    Voir aussi
    
+
    Directives
    
+
    Ce module ne fournit aucune directive.
    
+
    Voir aussi
    
 
      
 
    • mod_headers
      • 
 
    • mod_cern_meta
      • 
diff --git a/docs/manual/mod/mod_asis.html.ja.utf8 b/docs/manual/mod/mod_asis.html.ja.utf8
index 1af9c46ad5..b56bc62883 100644
--- a/docs/manual/mod/mod_asis.html.ja.utf8
+++ b/docs/manual/mod/mod_asis.html.ja.utf8
@@ -50,12 +50,12 @@
     
      歴史的な理由により、このモジュールは mime タイプ
     httpd/send-as-is のファイルも処理します。
      
 
    
-
    ディレクティブ
    
-
    このモジュールにディレクティブはありません。
    
-
    トピック
    
+
    トピック
    
 
    参照
    
+
    ディレクティブ
    
+
    このモジュールにディレクティブはありません。
    
+
    参照
    
 
      
 
    • mod_headers
      • 
 
    • mod_cern_meta
      • 
diff --git a/docs/manual/mod/mod_asis.html.ko.euc-kr b/docs/manual/mod/mod_asis.html.ko.euc-kr
index f2de124cc6..86ba6a51bc 100644
--- a/docs/manual/mod/mod_asis.html.ko.euc-kr
+++ b/docs/manual/mod/mod_asis.html.ko.euc-kr
@@ -48,12 +48,12 @@
     
      °ú°Å¿¡ ÀÌ ¸ðµâÀº mime typeÀÌ httpd/send-as-isÀÎ
     ÆÄÀϵµ ó¸®Çß´Ù.
      
 
    
-
    Áö½Ã¾îµé
    
-
    ÀÌ ¸ðµâ¿¡´Â Áö½Ã¾î°¡ ¾ø½À´Ï´Ù.
    
-
    ÁÖÁ¦
    
+
    ÁÖÁ¦
    
 
    Âü°í
    
+
    Áö½Ã¾îµé
    
+
    ÀÌ ¸ðµâ¿¡´Â Áö½Ã¾î°¡ ¾ø½À´Ï´Ù.
    
+
    Âü°í
    
 
      
 
    • mod_headers
      • 
 
    • mod_cern_meta
      • 
diff --git a/docs/manual/mod/mod_auth_basic.html.en b/docs/manual/mod/mod_auth_basic.html.en
index d4885e8434..0e78f816d6 100644
--- a/docs/manual/mod/mod_auth_basic.html.en
+++ b/docs/manual/mod/mod_auth_basic.html.en
@@ -57,6 +57,7 @@
 
    • Require
      • 
 
    • Authentication howto
      • 
 
    
+
 
    top
    
 
    AuthBasicAuthoritative Directive
    
 
    
 
 
 
    
@@ -251,7 +252,6 @@ Digest Authentication was in force instead of Basic Authentication.
     
-
 
    
 
    Available Languages:  en  |
diff --git a/docs/manual/mod/mod_auth_basic.html.fr b/docs/manual/mod/mod_auth_basic.html.fr
index 92c5cbd031..c2aa3f9a64 100644
--- a/docs/manual/mod/mod_auth_basic.html.fr
+++ b/docs/manual/mod/mod_auth_basic.html.fr
@@ -61,6 +61,7 @@
 
  • Mode d'emploi de
 l'authentification
    • 
 
    
+
 
    top
    Directive AuthBasicAuthoritative
    
 
    
 
 
 
 
    
@@ -280,7 +281,6 @@ Apache
       refuser l'accès.
-
 
    
 
    Langues Disponibles:  en  |
diff --git a/docs/manual/mod/mod_auth_basic.html.ja.utf8 b/docs/manual/mod/mod_auth_basic.html.ja.utf8
index a8934c7c47..9f55380602 100644
--- a/docs/manual/mod/mod_auth_basic.html.ja.utf8
+++ b/docs/manual/mod/mod_auth_basic.html.ja.utf8
@@ -66,6 +66,7 @@
 
  • <SatisfyOne>
    • 
 
  • Authentication howto
    • 
 
    
+
 
    top
    AuthBasicAuthoritative ディレクティブ
    
 
    
 
 
 
 
    
@@ -162,7 +163,6 @@ Digest Authentication was in force instead of Basic Authentication.
 
    このディレクティブの解説文書は
             まだ翻訳されていません。英語版をご覧ください。
             
    
-
 
 
    
 
    翻訳済み言語:  en  |
diff --git a/docs/manual/mod/mod_auth_basic.html.ko.euc-kr b/docs/manual/mod/mod_auth_basic.html.ko.euc-kr
index 5860430e82..6edd089b4e 100644
--- a/docs/manual/mod/mod_auth_basic.html.ko.euc-kr
+++ b/docs/manual/mod/mod_auth_basic.html.ko.euc-kr
@@ -55,6 +55,7 @@
 
  • AuthName
    • 
 
  • AuthType
    • 
 
    
+
 
    top
    
 
    AuthBasicAuthoritative Áö½Ã¾î
    
 
@@ -155,7 +156,6 @@ Digest Authentication was in force instead of Basic Authentication.
 
    The documentation for this directive has
             not been translated yet. Please have a look at the English
             version.
    
-
 
 
    
 
    °¡´ÉÇÑ ¾ð¾î:  en  |
diff --git a/docs/manual/mod/mod_auth_digest.html.en b/docs/manual/mod/mod_auth_digest.html.en
index 7e1a8cead4..6d5a605beb 100644
--- a/docs/manual/mod/mod_auth_digest.html.en
+++ b/docs/manual/mod/mod_auth_digest.html.en
@@ -68,6 +68,48 @@
 
  • Authentication howto
    • 
 
    
 
    top
    
+
    
+
    Using Digest Authentication
    
+
+    
    To use MD5 Digest authentication, simply
+    change the normal AuthType Basic and
+    AuthBasicProvider
+    to AuthType Digest and
+    AuthDigestProvider,
+    when setting up authentication, then add a
+    AuthDigestDomain directive containing at least the root
+    URI(s) for this protection space.
    
+
+    
    Appropriate user (text) files can be created using the
+    htdigest tool.
    
+
+    
    Example:
    <Location "/private/">
+    AuthType Digest
+    AuthName "private area"
+    AuthDigestDomain "/private/" "http://mirror.my.dom/private2/"
+    
+    AuthDigestProvider file
+    AuthUserFile "/web/auth/.digest_pw"
+    Require valid-user
+</Location>
    
+
    
+
+    
    Note
    
+    
    Digest authentication was intended to be more secure than basic
+    authentication, but no longer fulfills that design goal. A
+    man-in-the-middle attacker can trivially force the browser to downgrade
+    to basic authentication. And even a passive eavesdropper can brute-force
+    the password using today's graphics hardware, because the hashing
+    algorithm used by digest authentication is too fast. Another problem is
+    that the storage of the passwords on the server is insecure. The contents
+    of a stolen htdigest file can be used directly for digest authentication.
+    Therefore using mod_ssl to encrypt the whole connection is
+    strongly recommended.
    
+    
    mod_auth_digest only works properly on platforms
+      where APR supports shared memory.
    
+    
    
+
    
+
    top
    
 
    AuthDigestAlgorithm Directive
    
 
     via mod_ssl constitue une bien meilleure
     alternative.
    
-
    Directives
    
+
 
    top
    
+
    
+
    Utilisation de l'authentification à base de
+condensés
    
+
+    
    Pour utiliser l'authentification à base de condensés MD5, vous
+    devez simplement remplacer AuthType Basic et AuthBasicProvider respectivement
+    par AuthType Digest et AuthDigestProvider lorsque vous
+    configurez l'authentification, puis ajouter une directive AuthDigestDomain contenant au
+    moins la(les) URI(s) racine(s) de la zone à protéger.
    
+
+    
    On peut créer les fichiers utilisateur appropriés (au format
+    texte) à l'aide de l'outil htdigest.
    
+
+    
    Exemple :
    <Location /private/>
+    AuthType Digest
+    AuthName "private area"
+    AuthDigestDomain /private/ http://mirror.my.dom/private2/
+    
+    AuthDigestProvider file
+    AuthUserFile /web/auth/.digest_pw
+    Require valid-user
+</Location>
    
+
    
+
+    
    Note
    
+    
    L'authentification à base de condensé a été conçue pour améliorer
+    la sécurité par rapport à l'authentification basique, mais il
+    s'avère que ce but n'a pas été atteint. Un attaquant de type
+    "man-in-the-middle" peut facilement forcer le navigateur à revenir à
+    une authentification basique. Même une oreille indiscrète passive
+    peut retrouver le mot de passe par force brute avec les moyens
+    modernes, car l'algorithme de hashage utilisé par l'authentification
+    à base de condensé est trop rapide. Autre problème, le stockage des
+    mots de passe sur le serveur n'est pas sûr. Le contenu d'un fichier
+    htdigest volé peut être utilisé directement pour l'authentification
+    à base de condensé. Il est donc fortement recommandé d'utiliser
+    mod_ssl pour chiffrer la connexion.
    
+    
    mod_auth_digest ne fonctionne correctement que
+    sur les plates-formes où APR supporte la mémoire partagée.
    
+    
    
+
    
+
    top
    
 
    Directive AuthDigestAlgorithm
    
 
    
 
    Description:Selects the algorithm used to calculate the challenge and
@@ -256,48 +298,6 @@ AuthDigestShmemSize 1024K
 AuthDigestShmemSize 1M
 
 
-
-
    top
    
-
    
-
    Using Digest Authentication
    
-
-    
    To use MD5 Digest authentication, simply
-    change the normal AuthType Basic and
-    AuthBasicProvider
-    to AuthType Digest and
-    AuthDigestProvider,
-    when setting up authentication, then add a
-    AuthDigestDomain directive containing at least the root
-    URI(s) for this protection space.
    
-
-    
    Appropriate user (text) files can be created using the
-    htdigest tool.
    
-
-    
    Example:
    <Location "/private/">
-    AuthType Digest
-    AuthName "private area"
-    AuthDigestDomain "/private/" "http://mirror.my.dom/private2/"
-    
-    AuthDigestProvider file
-    AuthUserFile "/web/auth/.digest_pw"
-    Require valid-user
-</Location>
    
-
    
-
-    
    Note
    
-    
    Digest authentication was intended to be more secure than basic
-    authentication, but no longer fulfills that design goal. A
-    man-in-the-middle attacker can trivially force the browser to downgrade
-    to basic authentication. And even a passive eavesdropper can brute-force
-    the password using today's graphics hardware, because the hashing
-    algorithm used by digest authentication is too fast. Another problem is
-    that the storage of the passwords on the server is insecure. The contents
-    of a stolen htdigest file can be used directly for digest authentication.
-    Therefore using mod_ssl to encrypt the whole connection is
-    strongly recommended.
    
-    
    mod_auth_digest only works properly on platforms
-      where APR supports shared memory.
    
-    
    
 
    
 
 
    
diff --git a/docs/manual/mod/mod_auth_digest.html.fr b/docs/manual/mod/mod_auth_digest.html.fr
index 7354f919c1..ec7e2221d5 100644
--- a/docs/manual/mod/mod_auth_digest.html.fr
+++ b/docs/manual/mod/mod_auth_digest.html.fr
@@ -50,7 +50,11 @@ MD5
    
 
  • mod_authz_groupfile
    • top
    
-
    AuthLDAPAuthorizePrefix Directive
    
-
    
 
    Description:Sélectionne l'algorithme utilisé pour calculer les
@@ -278,48 +320,6 @@ AuthDigestShmemSize 1024K
 AuthDigestShmemSize 1M
 
 
-
-
    top
    
-
    
-
    Utilisation de l'authentification à base de
-condensés
    
-
-    
    Pour utiliser l'authentification à base de condensés MD5, vous
-    devez simplement remplacer AuthType Basic et AuthBasicProvider respectivement
-    par AuthType Digest et AuthDigestProvider lorsque vous
-    configurez l'authentification, puis ajouter une directive AuthDigestDomain contenant au
-    moins la(les) URI(s) racine(s) de la zone à protéger.
    
-
-    
    On peut créer les fichiers utilisateur appropriés (au format
-    texte) à l'aide de l'outil htdigest.
    
-
-    
    Exemple :
    <Location /private/>
-    AuthType Digest
-    AuthName "private area"
-    AuthDigestDomain /private/ http://mirror.my.dom/private2/
-    
-    AuthDigestProvider file
-    AuthUserFile /web/auth/.digest_pw
-    Require valid-user
-</Location>
    
-
    
-
-    
    Note
    
-    
    L'authentification à base de condensé a été conçue pour améliorer
-    la sécurité par rapport à l'authentification basique, mais il
-    s'avère que ce but n'a pas été atteint. Un attaquant de type
-    "man-in-the-middle" peut facilement forcer le navigateur à revenir à
-    une authentification basique. Même une oreille indiscrète passive
-    peut retrouver le mot de passe par force brute avec les moyens
-    modernes, car l'algorithme de hashage utilisé par l'authentification
-    à base de condensé est trop rapide. Autre problème, le stockage des
-    mots de passe sur le serveur n'est pas sûr. Le contenu d'un fichier
-    htdigest volé peut être utilisé directement pour l'authentification
-    à base de condensé. Il est donc fortement recommandé d'utiliser
-    mod_ssl pour chiffrer la connexion.
    
-    
    mod_auth_digest ne fonctionne correctement que
-    sur les plates-formes où APR supporte la mémoire partagée.
    
-    
    
 
    
 
 
    
diff --git a/docs/manual/mod/mod_auth_digest.html.ko.euc-kr b/docs/manual/mod/mod_auth_digest.html.ko.euc-kr
index e79a403995..ccdc540b07 100644
--- a/docs/manual/mod/mod_auth_digest.html.ko.euc-kr
+++ b/docs/manual/mod/mod_auth_digest.html.ko.euc-kr
@@ -39,7 +39,11 @@
     
    ÀÌ ¸ðµâÀº HTTP Digest AuthenticationÀ» ±¸ÇöÇÑ´Ù.
     ±×·¯³ª ¸¹Àº Å×½ºÆ®¸¦ °ÅÄ¡Áö ¾ÊÀº ½ÇÇèÀûÀÎ ¸ðµâÀÌ´Ù.
    
 
    
-
    Áö½Ã¾îµé
    
+
 
    top
    
+
    
+
    Digest Authentication »ç¿ëÇϱâ
    
+
+    
    MD5 Digest authenticationÀº ¸Å¿ì ½±°Ô »ç¿ëÇÒ ¼ö ÀÖ´Ù.
+    AuthType Basic°ú AuthBasicProvider ´ë½Å
+    AuthType Digest¿Í AuthDigestProvider¸¦
+    »ç¿ëÇÏ¿© °£´ÜÈ÷ ÀÎÁõÀ» ¼³Á¤ÇÒ ¼ö ÀÖ´Ù. ±×¸®°í ÃÖ¼ÒÇÑ º¸È£ÇÏ·Á´Â
+    ¿µ¿ªÀÇ ±âº» URIÀ» AuthDigestDomain Áö½Ã¾î¿¡ »ç¿ëÇÑ´Ù.
    
+
+    
    htdigest µµ±¸¸¦
+    »ç¿ëÇÏ¿© »ç¿ëÀÚ (¹®ÀÚ)ÆÄÀÏÀ» ¸¸µé ¼ö ÀÖ´Ù.
    
+
+    
    ¿¹Á¦:
    
+      <Location /private/>
    
+      
+        AuthType Digest
    
+        AuthName "private area"
    
+        AuthDigestDomain /private/ http://mirror.my.dom/private2/
    
+	
    
+	AuthDigestProvider file
    
+        AuthUserFile /web/auth/.digest_pw
    
+        Require valid-user
    
+          
+      </Location>
+    
    
+
+    
    ÁÖÀÇ
     
+    
    Digest authenticationÀº Basic authenticationº¸´Ù ´õ
+    ¾ÈÀüÇÏÁö¸¸, ºê¶ó¿ìÀú°¡ Áö¿øÇØ¾ß ÇÑ´Ù. 2002³â 11¿ù ÇöÀç digest
+    authenticationÀ» Áö¿øÇÏ´Â ºê¶ó¿ìÀú¿¡´Â Amaya, Konqueror, (Windows¿ëÀº
+    ÁúÀǹ®ÀÚ¿­°ú ÇÔ²² »ç¿ëÇÏ¸é ¾ÈµÇÁö¸¸ - ÇØ°á¹æ¹ýÀº ¾Æ·¡ "MS Internet Explorer ¹®Á¦ ÇØ°áÇϱâ"¸¦ Âü°í)
+    Mac OS X¿Í Windows¿ë MS Internet
+    Explorer, Mozilla,
+    Netscape ¹öÀü 7, Opera,
+    Safari µîÀÌ ÀÖ´Ù.
+    lynx´Â digest authenticationÀ»
+    Áö¿øÇÏÁö ¾Ê´Â´Ù. digest authenticationÀÌ
+    basic authentication ¸¸Å­ ³Î¸® ±¸ÇöµÇÁö ¾Ê¾Ò±â¶§¹®¿¡ ¸ðµç
+    »ç¿ëÀÚ°¡ Áö¿øÇÏ´Â ºê¶ó¿ìÀú¸¦ »ç¿ëÇÏ´Â °æ¿ì¿¡¸¸ »ç¿ëÇؾß
+    ÇÑ´Ù.
    
+    
    
+
    top
    
+
    
+
    MS Internet Explorer ¹®Á¦ ÇØ°áÇϱâ
    
+    
    ÇöÀç Windows¿ë Internet Explorer´Â Digest authentication
+    »ç¿ë½Ã ÁúÀǹ®ÀÚ¿­ÀÌ ÀÖ´Â GET ¿äûÀ» RFC¿Í ´Ù¸£°Ô
+    ó¸®ÇÏ´Â ¹®Á¦°¡ ÀÖ´Ù. ¸î°¡Áö ¹æ¹ýÀ¸·Î ÀÌ ¹®Á¦¸¦ ÇØ°áÇÒ ¼ö
+    ÀÖ´Ù.
    
+
+    
    
+    ù¹ø°´Â ÇÁ·Î±×·¥¿¡ ÀڷḦ ³Ñ°ÜÁÖ±âÀ§ÇØ GET
+    ´ë½Å POST ¿äûÀ» »ç¿ëÇÏ´Â ¹æ¹ýÀÌ´Ù. ÀÌ ¹æ¹ýÀÌ
+    °¡´ÉÇÏ´Ù¸é °¡Àå °£´ÜÇÑ ÇØ°áÃ¥ÀÌ´Ù.
+    
    
+
+    
    ¶Ç, ¾ÆÆÄÄ¡ 2.0.51ºÎÅÍ AuthDigestEnableQueryStringHack
+    ȯ°æº¯¼ö¸¦ Á¦°øÇÏ¿© ¹®Á¦¸¦ ÇØ°áÇÑ´Ù. ¿äû¿¡
+    AuthDigestEnableQueryStringHackÀ» ¼³Á¤Çϸé
+    ¾ÆÆÄÄ¡´Â MSIE ¹ö±×¸¦ ÇÇÇØ°¥ Á¶Ä¡¸¦ ÃëÇÏ°í ¿äû URI¸¦ digest
+    ºñ±³¿¡¼­ Á¦¿ÜÇÑ´Ù. ÀÌ ¹æ¹ýÀº ´ÙÀ½°ú °°ÀÌ »ç¿ëÇÑ´Ù.
    
+
+    
    MSIE¿¡¼­ Digest Authentication »ç¿ëÇϱâ:
    
+    BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On
+    
    
+
+    
    ¼±ÅÃÀûÀΠȯ°æº¯¼ö ¼³Á¤¿¡ ´ëÇÑ ÀÚ¼¼ÇÑ ³»¿ëÀº BrowserMatch Áö½Ã¾î¸¦
+    Âü°íÇ϶ó.
    
+
    
+
    top
    
 
    AuthDigestAlgorithm Áö½Ã¾î
    
 mod_auth_digest, on peut invoquer ce module en
     affectant la valeur dbd à la directive AuthBasicProvider ou AuthDigestProvider.
    
-
    
 
    ¼³¸í:digest authentication¿¡¼­ challenge¿Í response
@@ -246,75 +315,6 @@ URI
     
    
 
 
-
    top
    
-
    
-
    Digest Authentication »ç¿ëÇϱâ
    
-
-    
    MD5 Digest authenticationÀº ¸Å¿ì ½±°Ô »ç¿ëÇÒ ¼ö ÀÖ´Ù.
-    AuthType Basic°ú AuthBasicProvider ´ë½Å
-    AuthType Digest¿Í AuthDigestProvider¸¦
-    »ç¿ëÇÏ¿© °£´ÜÈ÷ ÀÎÁõÀ» ¼³Á¤ÇÒ ¼ö ÀÖ´Ù. ±×¸®°í ÃÖ¼ÒÇÑ º¸È£ÇÏ·Á´Â
-    ¿µ¿ªÀÇ ±âº» URIÀ» AuthDigestDomain Áö½Ã¾î¿¡ »ç¿ëÇÑ´Ù.
    
-
-    
    htdigest µµ±¸¸¦
-    »ç¿ëÇÏ¿© »ç¿ëÀÚ (¹®ÀÚ)ÆÄÀÏÀ» ¸¸µé ¼ö ÀÖ´Ù.
    
-
-    
    ¿¹Á¦:
    
-      <Location /private/>
    
-      
-        AuthType Digest
    
-        AuthName "private area"
    
-        AuthDigestDomain /private/ http://mirror.my.dom/private2/
    
-	
    
-	AuthDigestProvider file
    
-        AuthUserFile /web/auth/.digest_pw
    
-        Require valid-user
    
-          
-      </Location>
-    
    
-
-    
    ÁÖÀÇ
     
-    
    Digest authenticationÀº Basic authenticationº¸´Ù ´õ
-    ¾ÈÀüÇÏÁö¸¸, ºê¶ó¿ìÀú°¡ Áö¿øÇØ¾ß ÇÑ´Ù. 2002³â 11¿ù ÇöÀç digest
-    authenticationÀ» Áö¿øÇÏ´Â ºê¶ó¿ìÀú¿¡´Â Amaya, Konqueror, (Windows¿ëÀº
-    ÁúÀǹ®ÀÚ¿­°ú ÇÔ²² »ç¿ëÇÏ¸é ¾ÈµÇÁö¸¸ - ÇØ°á¹æ¹ýÀº ¾Æ·¡ "MS Internet Explorer ¹®Á¦ ÇØ°áÇϱâ"¸¦ Âü°í)
-    Mac OS X¿Í Windows¿ë MS Internet
-    Explorer, Mozilla,
-    Netscape ¹öÀü 7, Opera,
-    Safari µîÀÌ ÀÖ´Ù.
-    lynx´Â digest authenticationÀ»
-    Áö¿øÇÏÁö ¾Ê´Â´Ù. digest authenticationÀÌ
-    basic authentication ¸¸Å­ ³Î¸® ±¸ÇöµÇÁö ¾Ê¾Ò±â¶§¹®¿¡ ¸ðµç
-    »ç¿ëÀÚ°¡ Áö¿øÇÏ´Â ºê¶ó¿ìÀú¸¦ »ç¿ëÇÏ´Â °æ¿ì¿¡¸¸ »ç¿ëÇؾß
-    ÇÑ´Ù.
    
-    
    
-
    top
    
-
    
-
    MS Internet Explorer ¹®Á¦ ÇØ°áÇϱâ
    
-    
    ÇöÀç Windows¿ë Internet Explorer´Â Digest authentication
-    »ç¿ë½Ã ÁúÀǹ®ÀÚ¿­ÀÌ ÀÖ´Â GET ¿äûÀ» RFC¿Í ´Ù¸£°Ô
-    ó¸®ÇÏ´Â ¹®Á¦°¡ ÀÖ´Ù. ¸î°¡Áö ¹æ¹ýÀ¸·Î ÀÌ ¹®Á¦¸¦ ÇØ°áÇÒ ¼ö
-    ÀÖ´Ù.
    
-
-    
    
-    ù¹ø°´Â ÇÁ·Î±×·¥¿¡ ÀڷḦ ³Ñ°ÜÁÖ±âÀ§ÇØ GET
-    ´ë½Å POST ¿äûÀ» »ç¿ëÇÏ´Â ¹æ¹ýÀÌ´Ù. ÀÌ ¹æ¹ýÀÌ
-    °¡´ÉÇÏ´Ù¸é °¡Àå °£´ÜÇÑ ÇØ°áÃ¥ÀÌ´Ù.
-    
    
-
-    
    ¶Ç, ¾ÆÆÄÄ¡ 2.0.51ºÎÅÍ AuthDigestEnableQueryStringHack
-    ȯ°æº¯¼ö¸¦ Á¦°øÇÏ¿© ¹®Á¦¸¦ ÇØ°áÇÑ´Ù. ¿äû¿¡
-    AuthDigestEnableQueryStringHackÀ» ¼³Á¤Çϸé
-    ¾ÆÆÄÄ¡´Â MSIE ¹ö±×¸¦ ÇÇÇØ°¥ Á¶Ä¡¸¦ ÃëÇÏ°í ¿äû URI¸¦ digest
-    ºñ±³¿¡¼­ Á¦¿ÜÇÑ´Ù. ÀÌ ¹æ¹ýÀº ´ÙÀ½°ú °°ÀÌ »ç¿ëÇÑ´Ù.
    
-
-    
    MSIE¿¡¼­ Digest Authentication »ç¿ëÇϱâ:
    
-    BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On
-    
    
-
-    
    ¼±ÅÃÀûÀΠȯ°æº¯¼ö ¼³Á¤¿¡ ´ëÇÑ ÀÚ¼¼ÇÑ ³»¿ëÀº BrowserMatch Áö½Ã¾î¸¦
-    Âü°íÇ϶ó.
    
-
    
 
 
    
 
    °¡´ÉÇÑ ¾ð¾î:  en  |
diff --git a/docs/manual/mod/mod_auth_form.html.en b/docs/manual/mod/mod_auth_form.html.en
index 6eb6c9731a..58375e3e37 100644
--- a/docs/manual/mod/mod_auth_form.html.en
+++ b/docs/manual/mod/mod_auth_form.html.en
@@ -96,6 +96,253 @@
 
  • Authentication howto
    • 
 
    
 
    top
    
+
    
+
    Basic Configuration
    
+
+      
    To protect a particular URL with mod_auth_form, you need to
+      decide where you will store your session, and you will need to
+      decide what method you will use to authenticate. In this simple example, the
+      login details will be stored in a session based on
+      mod_session_cookie, and authentication will be attempted against
+      a file using mod_authn_file. If authentication is unsuccessful,
+      the user will be redirected to the form login page.
    
+
+      
    Basic example
    AuthFormProvider file
+AuthUserFile "conf/passwd"
+AuthType form
+AuthName realm
+AuthFormLoginRequiredLocation "http://example.com/login.html"
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    
+
    
+
+      
    The directive AuthType will enable
+      the mod_auth_form authentication when set to the value form.
+      The directives AuthFormProvider and
+      AuthUserFile specify that usernames
+      and passwords should be checked against the chosen file.
    
+
+      
    The directives Session,
+      SessionCookieName and
+      SessionCryptoPassphrase create an
+      encrypted session stored within an HTTP cookie on the browser. For more information
+      on the different options for configuring a session, read the documentation for
+      mod_session.
    
+
+      
    In the simple example above, a URL has been protected by
+      mod_auth_form, but the user has yet to be given an opportunity to
+      enter their username and password. Options for doing so include providing a
+      dedicated standalone login page for this purpose, or for providing the login
+      page inline.
    
+    
    top
    
+
    
+
    Standalone Login
    
+
+      
    The login form can be hosted as a standalone page, or can be provided inline on
+      the same page.
    
+
+      
    When configuring the login as a standalone page, unsuccessful authentication
+      attempts should be redirected to a login form created by the website for this purpose,
+      using the AuthFormLoginRequiredLocation
+      directive. Typically this login page will contain an HTML form, asking the user to
+      provide their usename and password.
    
+
+      
    Example login form
    <form method="POST" action="/dologin.html">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+</form>
    
+
    
+
+      
    The part that does the actual login is handled by the form-login-handler.
+      The action of the form should point at this handler, which is configured within
+      Apache httpd as follows:
    
+
+      
    Form login handler example
    <Location "/dologin.html">
+    SetHandler form-login-handler
+    AuthFormLoginRequiredLocation "http://example.com/login.html"
+    AuthFormLoginSuccessLocation "http://example.com/success.html"
+    AuthFormProvider file
+    AuthUserFile "conf/passwd"
+    AuthType form
+    AuthName realm
+    Session On
+    SessionCookieName session path=/
+    SessionCryptoPassphrase secret
+</Location>
    
+
    
+
+      
    The URLs specified by the
+      AuthFormLoginRequiredLocation directive will typically
+      point to a page explaining to the user that their login attempt was unsuccessful, and they
+      should try again.  The AuthFormLoginSuccessLocation
+      directive specifies the URL the user should be redirected to upon successful login.
    
+
+      
    Alternatively, the URL to redirect the user to on success can be embedded within the login
+      form, as in the example below. As a result, the same form-login-handler can be
+      reused for different areas of a website.
    
+
+      
    Example login form with location
    <form method="POST" action="/dologin.html">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+  <input type="hidden" name="httpd_location" value="http://example.com/success.html" />
+</form>
    
+
    
+
+    
    top
    
+
    
+
    Inline Login
    
+
+      
    Warning
    
+        
    A risk exists that under certain circumstances, the login form configured
+        using inline login may be submitted more than once, revealing login credentials to
+        the application running underneath. The administrator must ensure that the underlying
+        application is properly secured to prevent abuse. If in doubt, use the
+        standalone login configuration.
    
+      
    
+
+      
    As an alternative to having a dedicated login page for a website, it is possible to
+      configure mod_auth_form to authenticate users inline, without being
+      redirected to another page. This allows the state of the current page to be preserved
+      during the login attempt. This can be useful in a situation where a time limited
+      session is in force, and the session times out in the middle of the user request. The
+      user can be re-authenticated in place, and they can continue where they left off.
    
+
+      
    If a non-authenticated user attempts to access a page protected by
+      mod_auth_form that isn't configured with a
+      AuthFormLoginRequiredLocation directive,
+      a HTTP_UNAUTHORIZED status code is returned to the browser indicating to the user
+      that they are not authorized to view the page.
    
+
+      
    To configure inline authentication, the administrator overrides the error document
+      returned by the HTTP_UNAUTHORIZED status code with a custom error document
+      containing the login form, as follows:
    
+
+      
    Basic inline example
    AuthFormProvider file
+ErrorDocument 401 "/login.shtml"
+AuthUserFile "conf/passwd"
+AuthType form
+AuthName realm
+AuthFormLoginRequiredLocation "http://example.com/login.html"
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    
+
    
+
+      
    The error document page should contain a login form with an empty action property,
+      as per the example below.  This has the effect of submitting the form to
+      the original protected URL, without the page having to know what that
+      URL is.
    
+
+      
    Example inline login form
    <form method="POST" action="">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+</form>
    
+
    
+
+      
    When the end user has filled in their login details, the form will make
+      an HTTP POST request to the original password protected URL.
+      mod_auth_form will intercept this POST request, and if
+      HTML fields are found present for the username and password, the user
+      will be logged in, and the original password protected URL will be returned
+      to the user as a GET request.
    
+
+    
    top
    
+
    
+
    Inline Login with Body Preservation
    
+
+      
    A limitation of the inline login technique described above is that should an
+      HTML form POST have resulted in the request to authenticate or
+      reauthenticate, the
+      contents of the original form posted by the browser will be lost. Depending on
+      the function of the website, this could present significant inconvenience for the
+      end user.
    
+
+      
    mod_auth_form addresses this by allowing the method and body
+      of the original request to be embedded in the login form. If authentication
+      is successful, the original method and body will be retried by Apache httpd, preserving
+      the state of the original request.
    
+
+      
    To enable body preservation, add three additional fields to the login form as
+      per the example below.
    
+
+      
    Example with body preservation
    <form method="POST" action="">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+  
      <input type="hidden" name="httpd_method" value="POST" />
+  <input type="hidden" name="httpd_mimetype" value="application/x-www-form-urlencoded" />
+  <input type="hidden" name="httpd_body" value="name1=value1&name2=value2" />
    
+</form>
    
+
    
+
+      
    How the method, mimetype and body of the original request are embedded within the
+      login form will depend on the platform and technology being used within the website.
+      
    
+
+      
    One option is to use the mod_include module along with the
+      KeptBodySize directive, along with a suitable
+      CGI script to embed the variables in the form.
    
+
+      
    Another option is to render the login form using a CGI script or other dynamic
+      technology.
    
+
+      
    CGI example
            AuthFormProvider file
+        ErrorDocument 401 "/cgi-bin/login.cgi"
+        ...
    
+
    
+
+    
    top
    
+
    
+
    Logging Out
    
+
+      
    To enable a user to log out of a particular session, configure a page to
+      be handled by the form-logout-handler. Any attempt to access this
+      URL will cause the username and password to be removed from the current
+      session, effectively logging the user out.
    
+
+      
    By setting the
+      AuthFormLogoutLocation directive,
+      a URL can be specified that the browser will be redirected to on successful
+      logout. This URL might explain to the user that they have been logged out, and
+      give the user the option to log in again.
    
+
+      
    Basic logout example
    SetHandler form-logout-handler
+AuthName realm
+AuthFormLogoutLocation "http://example.com/loggedout.html"
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    
+
    
+
+      
    Note that logging a user out does not delete the session; it merely removes
+      the username and password from the session. If this results in an empty session,
+      the net effect will be the removal of that session, but this is not
+      guaranteed. If you want to guarantee the removal of a session, set the
+      SessionMaxAge directive to a small
+      value, like 1 (setting the directive to zero would mean no session age limit).
+      
    
+
+      
    Basic session expiry example
    SetHandler form-logout-handler
+AuthFormLogoutLocation "http://example.com/loggedout.html"
+Session On
+SessionMaxAge 1
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    
+
    
+
+    
    top
    
+
    
+
    Usernames and Passwords
    
+    
    Note that form submission involves URLEncoding the form data:
+    in this case the username and password.  You should therefore
+    pick usernames and passwords that avoid characters that are
+    URLencoded in form submission, or you may get unexpected results.
    
+    
    
+
    top
    
 
    AuthFormAuthoritative Directive
    
 
    When a URI is accessed that is served by the handler form-logout-handler,
     the page specified by this directive will be shown to the end user. For example:
    
 
-    
    Example
    <Location /logout>
+    
    Example
    <Location "/logout">
     SetHandler form-logout-handler
     AuthFormLogoutLocation "http://example.com/loggedout.html"
     Session on
@@ -361,7 +608,7 @@ parser has been added in 2.4.4.
     by the mod_authn_file module.  Make sure
     that the chosen provider module is present in the server.
    
 
-    
    Example
    <Location /secure>
+    
    Example
    <Location "/secure">
     AuthType form
     AuthName "private area"
     AuthFormProvider  dbm
@@ -451,253 +698,6 @@ parser has been added in 2.4.4.
     in.
    
 
 
    
-
    top
    
-
    
-
    Basic Configuration
    
-
-      
    To protect a particular URL with mod_auth_form, you need to
-      decide where you will store your session, and you will need to
-      decide what method you will use to authenticate. In this simple example, the
-      login details will be stored in a session based on
-      mod_session_cookie, and authentication will be attempted against
-      a file using mod_authn_file. If authentication is unsuccessful,
-      the user will be redirected to the form login page.
    
-
-      
    Basic example
    AuthFormProvider file
-AuthUserFile "conf/passwd"
-AuthType form
-AuthName realm
-AuthFormLoginRequiredLocation "http://example.com/login.html"
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    
-
    
-
-      
    The directive AuthType will enable
-      the mod_auth_form authentication when set to the value form.
-      The directives AuthFormProvider and
-      AuthUserFile specify that usernames
-      and passwords should be checked against the chosen file.
    
-
-      
    The directives Session,
-      SessionCookieName and
-      SessionCryptoPassphrase create an
-      encrypted session stored within an HTTP cookie on the browser. For more information
-      on the different options for configuring a session, read the documentation for
-      mod_session.
    
-
-      
    In the simple example above, a URL has been protected by
-      mod_auth_form, but the user has yet to be given an opportunity to
-      enter their username and password. Options for doing so include providing a
-      dedicated standalone login page for this purpose, or for providing the login
-      page inline.
    
-    
    top
    
-
    
-
    Standalone Login
    
-
-      
    The login form can be hosted as a standalone page, or can be provided inline on
-      the same page.
    
-
-      
    When configuring the login as a standalone page, unsuccessful authentication
-      attempts should be redirected to a login form created by the website for this purpose,
-      using the AuthFormLoginRequiredLocation
-      directive. Typically this login page will contain an HTML form, asking the user to
-      provide their usename and password.
    
-
-      
    Example login form
    <form method="POST" action="/dologin.html">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-</form>
    
-
    
-
-      
    The part that does the actual login is handled by the form-login-handler.
-      The action of the form should point at this handler, which is configured within
-      Apache httpd as follows:
    
-
-      
    Form login handler example
    <Location "/dologin.html">
-    SetHandler form-login-handler
-    AuthFormLoginRequiredLocation "http://example.com/login.html"
-    AuthFormLoginSuccessLocation "http://example.com/success.html"
-    AuthFormProvider file
-    AuthUserFile "conf/passwd"
-    AuthType form
-    AuthName realm
-    Session On
-    SessionCookieName session path=/
-    SessionCryptoPassphrase secret
-</Location>
    
-
    
-
-      
    The URLs specified by the
-      AuthFormLoginRequiredLocation directive will typically
-      point to a page explaining to the user that their login attempt was unsuccessful, and they
-      should try again.  The AuthFormLoginSuccessLocation
-      directive specifies the URL the user should be redirected to upon successful login.
    
-
-      
    Alternatively, the URL to redirect the user to on success can be embedded within the login
-      form, as in the example below. As a result, the same form-login-handler can be
-      reused for different areas of a website.
    
-
-      
    Example login form with location
    <form method="POST" action="/dologin.html">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-  <input type="hidden" name="httpd_location" value="http://example.com/success.html" />
-</form>
    
-
    
-
-    
    top
    
-
    
-
    Inline Login
    
-
-      
    Warning
    
-        
    A risk exists that under certain circumstances, the login form configured
-        using inline login may be submitted more than once, revealing login credentials to
-        the application running underneath. The administrator must ensure that the underlying
-        application is properly secured to prevent abuse. If in doubt, use the
-        standalone login configuration.
    
-      
    
-
-      
    As an alternative to having a dedicated login page for a website, it is possible to
-      configure mod_auth_form to authenticate users inline, without being
-      redirected to another page. This allows the state of the current page to be preserved
-      during the login attempt. This can be useful in a situation where a time limited
-      session is in force, and the session times out in the middle of the user request. The
-      user can be re-authenticated in place, and they can continue where they left off.
    
-
-      
    If a non-authenticated user attempts to access a page protected by
-      mod_auth_form that isn't configured with a
-      AuthFormLoginRequiredLocation directive,
-      a HTTP_UNAUTHORIZED status code is returned to the browser indicating to the user
-      that they are not authorized to view the page.
    
-
-      
    To configure inline authentication, the administrator overrides the error document
-      returned by the HTTP_UNAUTHORIZED status code with a custom error document
-      containing the login form, as follows:
    
-
-      
    Basic inline example
    AuthFormProvider file
-ErrorDocument 401 "/login.shtml"
-AuthUserFile "conf/passwd"
-AuthType form
-AuthName realm
-AuthFormLoginRequiredLocation "http://example.com/login.html"
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    
-
    
-
-      
    The error document page should contain a login form with an empty action property,
-      as per the example below.  This has the effect of submitting the form to
-      the original protected URL, without the page having to know what that
-      URL is.
    
-
-      
    Example inline login form
    <form method="POST" action="">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-</form>
    
-
    
-
-      
    When the end user has filled in their login details, the form will make
-      an HTTP POST request to the original password protected URL.
-      mod_auth_form will intercept this POST request, and if
-      HTML fields are found present for the username and password, the user
-      will be logged in, and the original password protected URL will be returned
-      to the user as a GET request.
    
-
-    
    top
    
-
    
-
    Inline Login with Body Preservation
    
-
-      
    A limitation of the inline login technique described above is that should an
-      HTML form POST have resulted in the request to authenticate or
-      reauthenticate, the
-      contents of the original form posted by the browser will be lost. Depending on
-      the function of the website, this could present significant inconvenience for the
-      end user.
    
-
-      
    mod_auth_form addresses this by allowing the method and body
-      of the original request to be embedded in the login form. If authentication
-      is successful, the original method and body will be retried by Apache httpd, preserving
-      the state of the original request.
    
-
-      
    To enable body preservation, add three additional fields to the login form as
-      per the example below.
    
-
-      
    Example with body preservation
    <form method="POST" action="">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-  
      <input type="hidden" name="httpd_method" value="POST" />
-  <input type="hidden" name="httpd_mimetype" value="application/x-www-form-urlencoded" />
-  <input type="hidden" name="httpd_body" value="name1=value1&name2=value2" />
    
-</form>
    
-
    
-
-      
    How the method, mimetype and body of the original request are embedded within the
-      login form will depend on the platform and technology being used within the website.
-      
    
-
-      
    One option is to use the mod_include module along with the
-      KeptBodySize directive, along with a suitable
-      CGI script to embed the variables in the form.
    
-
-      
    Another option is to render the login form using a CGI script or other dynamic
-      technology.
    
-
-      
    CGI example
            AuthFormProvider file
-        ErrorDocument 401 "/cgi-bin/login.cgi"
-        ...
    
-
    
-
-    
    top
    
-
    
-
    Logging Out
    
-
-      
    To enable a user to log out of a particular session, configure a page to
-      be handled by the form-logout-handler. Any attempt to access this
-      URL will cause the username and password to be removed from the current
-      session, effectively logging the user out.
    
-
-      
    By setting the
-      AuthFormLogoutLocation directive,
-      a URL can be specified that the browser will be redirected to on successful
-      logout. This URL might explain to the user that they have been logged out, and
-      give the user the option to log in again.
    
-
-      
    Basic logout example
    SetHandler form-logout-handler
-AuthName realm
-AuthFormLogoutLocation "http://example.com/loggedout.html"
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    
-
    
-
-      
    Note that logging a user out does not delete the session; it merely removes
-      the username and password from the session. If this results in an empty session,
-      the net effect will be the removal of that session, but this is not
-      guaranteed. If you want to guarantee the removal of a session, set the
-      SessionMaxAge directive to a small
-      value, like 1 (setting the directive to zero would mean no session age limit).
-      
    
-
-      
    Basic session expiry example
    SetHandler form-logout-handler
-AuthFormLogoutLocation "http://example.com/loggedout.html"
-Session On
-SessionMaxAge 1
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    
-
    
-
-    
    top
    
-
    
-
    Usernames and Passwords
    
-    
    Note that form submission involves URLEncoding the form data:
-    in this case the username and password.  You should therefore
-    pick usernames and passwords that avoid characters that are
-    URLencoded in form submission, or you may get unexpected results.
    
-    
    
 
    
 
    
 
    Available Languages:  en  |
diff --git a/docs/manual/mod/mod_auth_form.html.fr b/docs/manual/mod/mod_auth_form.html.fr
index 1d47e5d234..6c88bd5dbb 100644
--- a/docs/manual/mod/mod_auth_form.html.fr
+++ b/docs/manual/mod/mod_auth_form.html.fr
@@ -67,7 +67,17 @@
     
    
 
 
    
-
    
 
    Description:Sets whether authorization and authentication are passed to
@@ -266,7 +513,7 @@ parser has been added in 2.4.4.
    
     
    
-
-
-
-
-
-
-
-
    Description:Détermine si l'autorisation et l'authentification sont confiés à
-des modules de plus bas niveau
    Syntaxe:AuthFormAuthoritative On|Off
    Défaut:AuthFormAuthoritative On
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Base
    Module:mod_auth_form
    
-    
    Normalement, chacun des modules d'autorisation spécifiés par la
-    directive AuthFormProvider va tenter de
-    vérifier l'identité de l'utilisateur, et si ce dernier n'est trouvé
-    dans aucun fournisseur, l'accès sera refusé. En définissant
-    explicitement la directive
-    AuthFormAuthoritative à Off on
-    confie les processus d'authentification et d'autorisation à des
-    modules ne s'appuyant pas sur des fournisseurs, si aucun
-    identifiant utilisateur ou aucune règle ne
-    correspond à l'identifiant utilisateur fourni. Ceci ne peut s'avérer
-    nécessaire que si l'on combine mod_auth_form avec
-    des modules tiers qui ne se configurent pas avec la directive
-    AuthFormProvider.
-    Lorsqu'on utilise de tels modules, la chronologie du processus est
-    déterminée dans leur code source, et n'est pas configurable.
    
+
    
+
    Configuration de base
    
+
+      
    Pour protéger une URL particulière avec le module
+      mod_auth_form, vous devez déterminer l'endroit où
+      vous allez stocker votre session, ainsi que la méthode
+      d'authentification. Dans cet exemple simple, les informations de
+      connexion sont stockées dans une session à l'aide du module
+      mod_session_cookie, et l'authentification utilise
+      un fichier en s'appuyant sur le module
+      mod_authn_file. Si l'authentification échoue,
+      l'utilisateur dera redirigé vers la page du formulaire de
+      connexion.
    
 
+      
    Exemple simple
    AuthFormProvider file
+AuthUserFile conf/passwd
+AuthType form
+AuthName realm
+AuthFormLoginRequiredLocation http://example.com/login.html
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    
 
    
-
    top
    
-
    Directive AuthFormBody
    
-
-
-
-
-
-
-
-
-
    Description:Le nom du champ de formulaire contenant le corps de la
-requête à effectuer en cas de connexion réussie
    Syntaxe:AuthFormBody nom du champ
    Défaut:httpd_body
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    
-    
    La directive AuthFormBody
-    spécifie le nom du champ HTML qui, s'il existe, contiendra le corps
-    de la requête à effectuer en cas de connexion réussie.
    
 
-    
    En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en
-    mesure de relancer une requête qui a été éventuellement interrompue
-    par l'écran de connexion, ou par l'expiration d'un délai de
-    session.
    
+      
    L'authentification mod_auth_form est activée
+      en affectant la valeur form à la directive AuthType. Les directives
+      AuthFormProvider et
+      AuthUserFile
+      spécifient que les noms d'utilisateurs et mots de passe seront
+      vérifiés en utilisant le fichier choisi.
    
 
-
    
-
    top
    
-
    Directive AuthFormDisableNoStore
    
-
-
-
-
-
-
-
-
-
    Description:Désactive l'en-tête CacheControl no-store sur la page de
-connexion
    Syntaxe:AuthFormDisableNoStore On|Off
    Défaut:AuthFormDisableNoStore Off
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    
-    
    Le drapeau AuthFormDisableNoStore supprime
-    l'envoi d'un en-tête Cache-Control no-store lorsqu'une
-    page avec code d'erreur 401 est renvoyée, si l'utilisateur n'est pas
-    encore connecté. Avec cette en-tête, il est plus difficile pour une
-    application ecmascript de resoumettre un formulaire de connexion, et
-    ainsi révéler le nom d'utilisateur et le mot de passe à
-    l'application sous-jacente. Vous devez être conscient des risques
-    encourus si vous le désactivez.
    
+      
    Les directives Session, SessionCookieName et
+      SessionCryptoPassphrase
+      créent une session chiffrée stockée dans un cookie HTTP au niveau
+      du navigateur. Pour plus d'informations à propos des différentes
+      options de configuration des sessions, reportez-vous à la
+      documentation du module mod_session.
    
 
+      
    Dans l'exemple simple ci-dessus, une URL a été protégée par
+      mod_auth_form, mais on doit maintenant fournir
+      à l'utilisateur un moyen d'entrer un nom et un mot de passe. À cet
+      effet, on peut soit écrire une page de connexion indépendante
+      dédiée, soit inclure le formulaire de connexion dans la page
+      courante.
    
+    
    top
    
+
    
+
    Page de connexion dédiée
    
 
-
    
-
    top
    
-
    Directive AuthFormFakeBasicAuth
    
-
-
-
-
-
-
-
-
-
    Description:Simule une en-tête d'authentification de base
    Syntaxe:AuthFormFakeBasicAuth On|Off
    Défaut:AuthFormFakeBasicAuth Off
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    
-    
    Le drapeau AuthFormFakeBasicAuth
-    détermine si une en-tête d'Authentification de base
-    sera ajoutée aux en-têtes de la requête. On peut utiliser cette
-    méthode pour présenter le nom d'utilisateur et le mot de passe à
-    l'application sous-jacente, sans que cette dernière ait besoin de
-    connaître la manière dont le processus de connexion a été mené à
-    bien.
    
+      
    Le formulaire de connexion peut être contenu dans une page
+      indépendante, ou être inclus dans la page courante. 
    
 
+      
    Lorsque la connexion s'effectue à partir d'une page
+      indépendante et si la tentative d'authentification échoue,
+      l'utilisateur doit être redirigé vers un formulaire de connexion,
+      créé à cet effet sur le site web, en utilisant la directive
+      AuthFormLoginRequiredLocation.
+      En général, la page de connexion contiendra un formulaire HTML
+      demandant à l'utilisateur de fournir un nom et un mot de passe.
    
 
+      
    Exemple de formulaire de connexion
    <form method="POST" action="/dologin.html">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+</form>
    
 
    
-
    top
    
-
    Directive AuthFormLocation
    
-
-
-
-
-
-
-
-
-
    Description:Le nom du champ de formulaire qui contiendra l'URL vers
-laquelle l'utilisateur sera redirigé en cas de connexion
-réussie
    Syntaxe:AuthFormLocation nom du champ
    Défaut:httpd_location
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    
-    
    La directive AuthFormLocation
-    spécifie le nom du champ HTML qui, s'il existe, contiendra l'URL
-    vers laquelle rediriger le navigateur en cas de connexion
-    réussie.
    
 
+      
    La partie où s'effectue la connexion proprement dite est
+      traitée par le gestionnaire form-login-handler.
+      L'action de ce formulaire doit pointer vers ce gestionnaire, ce
+      que l'on configure dans Apache httpd comme suit :
    
+
+      
    Exemple de configuration du gestionnaire de
+      formulaire de connexion
    <Location /dologin.html>
+    SetHandler form-login-handler
+    AuthFormLoginRequiredLocation http://example.com/login.html
+    AuthFormLoginSuccessLocation http://example.com/success.html
+    AuthFormProvider file
+    AuthUserFile conf/passwd
+    AuthType form
+    AuthName realm
+    Session On
+    SessionCookieName session path=/
+    SessionCryptoPassphrase secret
+</Location>
    
 
    
-
    top
    
-
    Directive AuthFormLoginRequiredLocation
    
-
-
-
-
-
-
-
-
-
    Description:L'URL de la page vers laquelle on doit être redirigé si une
-authentification est requise
    Syntaxe:AuthFormLoginRequiredLocation url
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP
-Apache. L'interprétation des expressions rationnelles est supportée
-depuis la version 2.4.4.
    
-    
    La directive AuthFormLoginRequiredLocation
-    spécifie l'URL vers laquelle l'utilisateur devra être
-    redirigé s'il n'est pas autorisé à accéder à une page. Sa valeur est
-    interprétée via l'interpréteur ap_expr
-    avant d'être envoyée au client. Par défaut,
-    si un utilisateur n'est pas autorisé à accéder à une page, le code
-    de réponse HTTP HTTP_UNAUTHORIZED est renvoyé avec la
-    page spécifiée par la directive ErrorDocument. La directive AuthFormLoginRequiredLocation
-    permet de remplacer cette valeur par défaut.
    
 
-    
    Vous pouvez utiliser cette directive si vous voulez présenter une
-    page de connexion personnalisée à vos utilisateurs.
    
+      
    L'URL spécifiée par la directive
+      AuthFormLoginRequiredLocation
+      référencera en général une page expliquant à l'utilisateur que sa
+      tentative de connexion a échoué, et qu'il doit la renouveler. La
+      directive AuthFormLoginSuccessLocation
+      spécifie l'URL vers laquelle l'utilisateur doit être redirigé s'il
+      s'est authentifié avec succès.
    
 
+      
    Alternativement, l'URL vers laquelle doit être redirigé
+      l'utilisateur s'il s'est authentifié avec succès peut être
+      intégrée dans le formulaire de connexion, comme dans l'exemple
+      ci-dessous. Il en découle que le même gestionnaire
+      form-login-handler pourra être utilisé pour différentes
+      zones du site web.
    
 
+      
    Exemple de formulaire d'authentification multizone
    <form method="POST" action="/dologin.html">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+  <input type="hidden" name="httpd_location" value="http://example.com/success.html" />
+</form>
    
 
    
-
    top
    
-
    Directive AuthFormLoginSuccessLocation
    
-
-
-
-
-
-
-
-
-
    Description:L'URL de la page vers laquelle on doit être redirigé en cas
-de connexion réussie
    Syntaxe:AuthFormLoginSuccessLocation url
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP
-Apache. L'interprétation des expressions rationnelles est supportée
-depuis la version 2.4.4.
    
-    
    La directive AuthFormLoginSuccessLocation
-    spécifie l'URL vers laquelle l'utilisateur doit être
-    redirigé en cas de connexion réussie. Sa valeur est
-    interprétée via l'interpréteur ap_expr
-    avant d'être envoyée au client. L'effet de cette directive
-    peut être annulé si l'on a défini un champ de formulaire contenant
-    une autre URL à l'aide de la directive AuthFormLocation.
    
 
-    
    Vous pouvez utiliser cette directive si vous possédez une URL de
-    connexion personnalisée, et si vous n'avez pas intégré la page de
-    destination dans le formulaire de connexion.
    
+    
    top
    
+
    
+
    Connexion à la volée
    
+
+      
    Avertissement
    
+        
    Il existe un risque, dans certaines circonstances, que le
+	formulaire de connexion configuré pour une connexion à la volée
+	soit soumis plusieurs fois, révélant de ce fait les paramètres
+	de connexion à l'application sous-jacente. L'administrateur doit
+	s'assurer que cette dernière est correctement sécurisée afin
+	d'éviter les éventuels abus. En cas de doute, utilisez une page
+	de connexion indépendante dédiée.
    
+      
    
+
+      
    Comme alternative à la page de connexion dédiée pour un site
+      web, il est possible de configurer mod_auth_form
+      pour authentifier les utilisateurs à la volée, sans les rediriger
+      vers une autre page, ce qui permet de conserver l'état de la page
+      courante au cours de la tentative de connexion. Ceci peut s'avérer
+      utile dans le cas d'une session limitée dans le temps, si le délai
+      de la session a expiré pendant la requête de l'utilisateur. Ce
+      dernier peut alors se réauthentifier à la même place, et
+      poursuivre son activité à partir du point où il en était resté.
    
+
+      
    Si un utilisateur non authentifié tente d'accéder à une page
+      protégée par mod_auth_form, et si ce dernier
+      n'est pas configuré avec une directive AuthFormLoginRequiredLocation,
+      un code de statut HTTP_UNAUTHORIZED est renvoyé vers le
+      navigateur, indiquant à l'utilisateur qu'il n'est pas autorisé à
+      accéder à cette page.
    
 
+      
    Pour configurer l'authentification à la volée, l'administrateur
+      remplace le message d'erreur renvoyé par le code de statut
+      HTTP_UNAUTHORIZED par un message d'erreur personnalisé
+      contenant le formulaire de connexion comme suit :
    
 
+      
    Exemple simple d'authentification à la volée
    AuthFormProvider file
+ErrorDocument 401 /login.shtml
+AuthUserFile conf/passwd
+AuthType form
+AuthName realm
+AuthFormLoginRequiredLocation http://example.com/login.html
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    
 
    
-
    top
    
-
    Directive AuthFormLogoutLocation
    
-
-
-
-
-
-
-
-
-
    Description:L'URL vers laquelle un utilisateur devra être redirigé
-après s'être déconnecté
    Syntaxe:AuthFormLogoutLocation uri
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP
-Apache. L'interprétation des expressions rationnelles est supportée
-depuis la version 2.4.4.
    
-    
    La directive AuthFormLogoutLocation
-    spécifie l'URL de la page du serveur vers laquelle l'utilisateur
-    devra être redirigé s'il se déconnecte. Sa valeur est
-    interprétée via l'interpréteur ap_expr
-    avant d'être envoyée au client.
    
 
-    
    Lorsqu'un accès est tenté sur un URI traité par le gestionnaire
-    form-logout-handler, la page spécifiée par cette
-    directive sera présentée à l'utilisateur final. Par exemple :
    
+      
    La page du message d'erreur doit contenir un formulaire de
+      connexion dont la propriété action est vide, comme dans l'exemple
+      ci-dessous. Ceci a pour effet de soumettre le formulaire à l'URL
+      protégée originale, cette dernière n'ayant pas besoin d'être
+      connue de la page en cours.
    
 
-    
    Exemple
    <Location /logout>
-    SetHandler form-logout-handler
-    AuthFormLogoutLocation http://example.com/loggedout.html
-    Session on
-    #...
-</Location>
    
+      
    Exemple de formulaire de connexion à la volée
    <form method="POST" action="">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+</form>
    
 
    
 
-    
    Si un utilisateur tente d'accéder à l'URI /logout/, il
-    sera déconnecté, et la page /loggedout.html lui sera
-    présentée. Assurez-vous que la page loggedout.html n'est
-    pas protégée par mot de passe, car dans le cas contraire, elle ne
-    serait pas affichée.
    
+      
    Lorsque l'utilisateur final a entré ses informations de
+      connexion, le formulaire effectue une requête HTTP POST pour l'URL
+      originale protégée par mot de passe.
+      mod_auth_form va alors intercepter cette requête
+      POST, et dans le cas où des champs HTML Utilisateur et Mot de
+      passe corrects sont présents, l'utilisateur sera connecté, et
+      l'URL originale protégée par mot de passe lui sera retournée en
+      tant que requête GET.
    
+
+    
    top
    
+
    
+
    Connexion à la volée avec
+    conservation du contenu
    
+
+      
    Il existe une limite à la technique de connexion à la volée
+      décrite ci-dessus ; si un formulaire HTML POST entraîne une
+      demande d'authentification ou de réauthentification, le contenu du
+      formulaire original envoyé par le navigateur sera perdu. Cela peut
+      s'avérer plus ou moins gênant pour l'utilisateur final selon la
+      fonction du site web.
    
+
+      
    Comme solution à ce problème, mod_auth_form
+      permet d'intégrer la méthode et le contenu de la requête originale
+      dans le formulaire de connexion. Si l'authentification réussit,
+      Apache httpd pourra refaire une tentative avec la méthode et le contenu
+      originaux, tout en conservant l'état de la requête originale.
    
+
+      
    Pour mettre en oeuvre la conservation du contenu, vous devez
+      ajouter trois champs supplémentaires au formulaire de connexion
+      comme dans l'exemple suivant :
    
+
+      
    Exemple de formulaire avec conservation du
+      contenu
    <form method="POST" action="">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+  
      <input type="hidden" name="httpd_method" value="POST" />
+  <input type="hidden" name="httpd_mimetype" value="application/x-www-form-urlencoded" />
+  <input type="hidden" name="httpd_body" value="name1=value1&name2=value2" />
    
+</form>
    
+
    
+
+      
    La manière dont la méthode, le type MIME et le contenu de la
+      requête originale seront intégrés dans le formulaire de connexion
+      vont dépendre de la plate-forme et de la technologie utilisées au
+      sein du site web.
+      
    
+
+      
    Une option consiste à utiliser le module
+      mod_include en association avec la directive
+      KeptBodySize, ainsi
+      qu'un script CGI adapté pour intégrer les variables dans le
+      formulaire.
    
+
+      
    Une autre option consiste à présenter le formulaire de
+      connexion en utilisant un script CGI ou une autre technologie
+      dynamique.
    
+
+      
    Exemple avec script CGI
            AuthFormProvider file
+        ErrorDocument 401 /cgi-bin/login.cgi
+        ...
    
+
    
+
+    
    top
    
+
    
+
    Déconnexion
    
+
+      
    Pour permettre à un utilisateur de se déconnecter d'une session
+      particulière, vous devez configurer une page pour qu'elle soit
+      traitée par le gestionnaire form-logout-handler. Tout
+      accès à cette URL va entraîner la suppression de l'Utilisateur et
+      du Mot de passe de la session courante, ce qui aura pour effet de
+      déconnecter l'utilisateur.
    
+
+      
    Vous pouvez spécifier une URL vers laquelle le navigateur sera
+      redirigé en cas de déconnection réussie, en définissant la
+      directive AuthFormLogoutLocation. Cette
+      URL devra expliquer à l'utilisateur qu'il a été déconnecté, et lui
+      donner la possibilité de se connecter à nouveau.
    
+
+      
    Exemple simple de configuration de la
+      déconnexion
    SetHandler form-logout-handler
+AuthName realm
+AuthFormLogoutLocation http://example.com/loggedout.html
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    
+
    
+
+      
    Notez que la déconnexion d'un utilisateur ne supprime pas la
+      session ; elle supprime seulement l'utilisateur et le mot de passe
+      de la session. Si la session qui en résulte est vide, elle sera
+      probablement supprimée, mais ce n'est pas garanti. Si vous voulez
+      être sûr que la session sera supprimée, affectez une valeur faible
+      à la directive SessionMaxAge, par exemple 1
+      (affecter à cette directive la valeur zéro signifie une session
+      sans limite d'âge).
+      
    
+
+      
    Exemple simple avec durée de validité de session
+      limitée
    SetHandler form-logout-handler
+AuthFormLogoutLocation http://example.com/loggedout.html
+Session On
+SessionMaxAge 1
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    
+
    
 
+    
    top
    
+
    
+
    Noms d'utilisateurs et mots de
+    passe
    
+    
    Notez que la soumission d'un formulaire implique l'encodage URL
+    (URLEncoding) des données du formulaire, ici le nom d'utilisateur et
+    le mot de passe. Vous devez donc choisir des noms d'utilisateurs et
+    mots de passe qui ne contiennent pas de caractères susceptibles
+    d'être encodés URL lors de la soumission du formulaire, sous peine
+    d'obtenir des résultats inattendus.
    
+    
    
+
    top
    
+
    Directive AuthFormAuthoritative
    
+
+
+
+
+
+
+
+
+
    Description:Détermine si l'autorisation et l'authentification sont confiés à
+des modules de plus bas niveau
    Syntaxe:AuthFormAuthoritative On|Off
    Défaut:AuthFormAuthoritative On
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Base
    Module:mod_auth_form
    
+    
    Normalement, chacun des modules d'autorisation spécifiés par la
+    directive AuthFormProvider va tenter de
+    vérifier l'identité de l'utilisateur, et si ce dernier n'est trouvé
+    dans aucun fournisseur, l'accès sera refusé. En définissant
+    explicitement la directive
+    AuthFormAuthoritative à Off on
+    confie les processus d'authentification et d'autorisation à des
+    modules ne s'appuyant pas sur des fournisseurs, si aucun
+    identifiant utilisateur ou aucune règle ne
+    correspond à l'identifiant utilisateur fourni. Ceci ne peut s'avérer
+    nécessaire que si l'on combine mod_auth_form avec
+    des modules tiers qui ne se configurent pas avec la directive
+    AuthFormProvider.
+    Lorsqu'on utilise de tels modules, la chronologie du processus est
+    déterminée dans leur code source, et n'est pas configurable.
    
 
 
    
 
    top
    
-
    Directive AuthFormMethod
    
+
    Directive AuthFormBody
    
 
-
-
-
+
+
    Description:Le nom du champ de formulaire contenant la méthode de la
+
    Description:Le nom du champ de formulaire contenant le corps de la
 requête à effectuer en cas de connexion réussie
    Syntaxe:AuthFormMethod nom du champ
    Défaut:httpd_method
    Syntaxe:AuthFormBody nom du champ
    Défaut:httpd_body
    
 
    Contexte:répertoire
    
 
    Statut:Base
    
 
    Module:mod_auth_form
    
 
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    
 
    
-    
    La directive AuthFormMethod
-    spécifie le nom du champ HTML qui, s'il existe, contiendra le type
-    MIME de la requête à effectuer en cas de connexion réussie.
    
+    
    La directive AuthFormBody
+    spécifie le nom du champ HTML qui, s'il existe, contiendra le corps
+    de la requête à effectuer en cas de connexion réussie.
    
 
     
    En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en
     mesure de relancer une requête qui a été éventuellement interrompue
@@ -338,11 +445,193 @@ requ
 
 
    
 
    top
    
-
    Directive AuthFormMimetype
    
+
    Directive AuthFormDisableNoStore
    
 
-
+
+
+
+
+
+
+
+
    Description:Le nom du champ de formulaire contenant le type MIME du
-corps de la requête à effectuer en cas de connexion
-réussie
    Description:Désactive l'en-tête CacheControl no-store sur la page de
+connexion
    Syntaxe:AuthFormDisableNoStore On|Off
    Défaut:AuthFormDisableNoStore Off
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    
+    
    Le drapeau AuthFormDisableNoStore supprime
+    l'envoi d'un en-tête Cache-Control no-store lorsqu'une
+    page avec code d'erreur 401 est renvoyée, si l'utilisateur n'est pas
+    encore connecté. Avec cette en-tête, il est plus difficile pour une
+    application ecmascript de resoumettre un formulaire de connexion, et
+    ainsi révéler le nom d'utilisateur et le mot de passe à
+    l'application sous-jacente. Vous devez être conscient des risques
+    encourus si vous le désactivez.
    
+
+
+
    
+
    top
    
+
    Directive AuthFormFakeBasicAuth
    
+
+
+
+
+
+
+
+
+
    Description:Simule une en-tête d'authentification de base
    Syntaxe:AuthFormFakeBasicAuth On|Off
    Défaut:AuthFormFakeBasicAuth Off
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    
+    
    Le drapeau AuthFormFakeBasicAuth
+    détermine si une en-tête d'Authentification de base
+    sera ajoutée aux en-têtes de la requête. On peut utiliser cette
+    méthode pour présenter le nom d'utilisateur et le mot de passe à
+    l'application sous-jacente, sans que cette dernière ait besoin de
+    connaître la manière dont le processus de connexion a été mené à
+    bien.
    
+
+
+
    
+
    top
    
+
    Directive AuthFormLocation
    
+
+
+
+
+
+
+
+
+
    Description:Le nom du champ de formulaire qui contiendra l'URL vers
+laquelle l'utilisateur sera redirigé en cas de connexion
+réussie
    Syntaxe:AuthFormLocation nom du champ
    Défaut:httpd_location
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    
+    
    La directive AuthFormLocation
+    spécifie le nom du champ HTML qui, s'il existe, contiendra l'URL
+    vers laquelle rediriger le navigateur en cas de connexion
+    réussie.
    
+
+
    
+
    top
    
+
    Directive AuthFormLoginRequiredLocation
    
+
+
+
+
+
+
+
+
+
    Description:L'URL de la page vers laquelle on doit être redirigé si une
+authentification est requise
    Syntaxe:AuthFormLoginRequiredLocation url
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP
+Apache. L'interprétation des expressions rationnelles est supportée
+depuis la version 2.4.4.
    
+    
    La directive AuthFormLoginRequiredLocation
+    spécifie l'URL vers laquelle l'utilisateur devra être
+    redirigé s'il n'est pas autorisé à accéder à une page. Sa valeur est
+    interprétée via l'interpréteur ap_expr
+    avant d'être envoyée au client. Par défaut,
+    si un utilisateur n'est pas autorisé à accéder à une page, le code
+    de réponse HTTP HTTP_UNAUTHORIZED est renvoyé avec la
+    page spécifiée par la directive ErrorDocument. La directive AuthFormLoginRequiredLocation
+    permet de remplacer cette valeur par défaut.
    
+
+    
    Vous pouvez utiliser cette directive si vous voulez présenter une
+    page de connexion personnalisée à vos utilisateurs.
    
+
+
+
    
+
    top
    
+
    Directive AuthFormLoginSuccessLocation
    
+
+
+
+
+
+
+
+
+
    Description:L'URL de la page vers laquelle on doit être redirigé en cas
+de connexion réussie
    Syntaxe:AuthFormLoginSuccessLocation url
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP
+Apache. L'interprétation des expressions rationnelles est supportée
+depuis la version 2.4.4.
    
+    
    La directive AuthFormLoginSuccessLocation
+    spécifie l'URL vers laquelle l'utilisateur doit être
+    redirigé en cas de connexion réussie. Sa valeur est
+    interprétée via l'interpréteur ap_expr
+    avant d'être envoyée au client. L'effet de cette directive
+    peut être annulé si l'on a défini un champ de formulaire contenant
+    une autre URL à l'aide de la directive AuthFormLocation.
    
+
+    
    Vous pouvez utiliser cette directive si vous possédez une URL de
+    connexion personnalisée, et si vous n'avez pas intégré la page de
+    destination dans le formulaire de connexion.
    
+
+
+
    
+
    top
    
+
    Directive AuthFormLogoutLocation
    
+
+
+
+
+
+
+
+
+
    Description:L'URL vers laquelle un utilisateur devra être redirigé
+après s'être déconnecté
    Syntaxe:AuthFormLogoutLocation uri
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP
+Apache. L'interprétation des expressions rationnelles est supportée
+depuis la version 2.4.4.
    
+    
    La directive AuthFormLogoutLocation
+    spécifie l'URL de la page du serveur vers laquelle l'utilisateur
+    devra être redirigé s'il se déconnecte. Sa valeur est
+    interprétée via l'interpréteur ap_expr
+    avant d'être envoyée au client.
    
+
+    
    Lorsqu'un accès est tenté sur un URI traité par le gestionnaire
+    form-logout-handler, la page spécifiée par cette
+    directive sera présentée à l'utilisateur final. Par exemple :
    
+
+    
    Exemple
    <Location /logout>
+    SetHandler form-logout-handler
+    AuthFormLogoutLocation http://example.com/loggedout.html
+    Session on
+    #...
+</Location>
    
+
    
+
+    
    Si un utilisateur tente d'accéder à l'URI /logout/, il
+    sera déconnecté, et la page /loggedout.html lui sera
+    présentée. Assurez-vous que la page loggedout.html n'est
+    pas protégée par mot de passe, car dans le cas contraire, elle ne
+    serait pas affichée.
    
+
+
+
    
+
    top
    
+
    Directive AuthFormMethod
    
+
+
+
+
+
+
+
+
+
    Description:Le nom du champ de formulaire contenant la méthode de la
+requête à effectuer en cas de connexion réussie
    Syntaxe:AuthFormMethod nom du champ
    Défaut:httpd_method
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    
+    
    La directive AuthFormMethod
+    spécifie le nom du champ HTML qui, s'il existe, contiendra le type
+    MIME de la requête à effectuer en cas de connexion réussie.
    
+
+    
    En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en
+    mesure de relancer une requête qui a été éventuellement interrompue
+    par l'écran de connexion, ou par l'expiration d'un délai de
+    session.
    
+
+
    
+
    top
    
+
    Directive AuthFormMimetype
    
+
+
@@ -497,295 +786,6 @@ connexion
     d'utilisateur qui sera utilisé pour la connexion.
    
-
    top
    
-
    
-
    Configuration de base
    
-
-      
    Pour protéger une URL particulière avec le module
-      mod_auth_form, vous devez déterminer l'endroit où
-      vous allez stocker votre session, ainsi que la méthode
-      d'authentification. Dans cet exemple simple, les informations de
-      connexion sont stockées dans une session à l'aide du module
-      mod_session_cookie, et l'authentification utilise
-      un fichier en s'appuyant sur le module
-      mod_authn_file. Si l'authentification échoue,
-      l'utilisateur dera redirigé vers la page du formulaire de
-      connexion.
    
-
-      
    Exemple simple
    AuthFormProvider file
-AuthUserFile conf/passwd
-AuthType form
-AuthName realm
-AuthFormLoginRequiredLocation http://example.com/login.html
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    
-
    
-
-      
    L'authentification mod_auth_form est activée
-      en affectant la valeur form à la directive AuthType. Les directives
-      AuthFormProvider et
-      AuthUserFile
-      spécifient que les noms d'utilisateurs et mots de passe seront
-      vérifiés en utilisant le fichier choisi.
    
-
-      
    Les directives Session, SessionCookieName et
-      SessionCryptoPassphrase
-      créent une session chiffrée stockée dans un cookie HTTP au niveau
-      du navigateur. Pour plus d'informations à propos des différentes
-      options de configuration des sessions, reportez-vous à la
-      documentation du module mod_session.
    
-
-      
    Dans l'exemple simple ci-dessus, une URL a été protégée par
-      mod_auth_form, mais on doit maintenant fournir
-      à l'utilisateur un moyen d'entrer un nom et un mot de passe. À cet
-      effet, on peut soit écrire une page de connexion indépendante
-      dédiée, soit inclure le formulaire de connexion dans la page
-      courante.
    
-    
    top
    
-
    
-
    Page de connexion dédiée
    
-
-      
    Le formulaire de connexion peut être contenu dans une page
-      indépendante, ou être inclus dans la page courante. 
    
-
-      
    Lorsque la connexion s'effectue à partir d'une page
-      indépendante et si la tentative d'authentification échoue,
-      l'utilisateur doit être redirigé vers un formulaire de connexion,
-      créé à cet effet sur le site web, en utilisant la directive
-      AuthFormLoginRequiredLocation.
-      En général, la page de connexion contiendra un formulaire HTML
-      demandant à l'utilisateur de fournir un nom et un mot de passe.
    
-
-      
    Exemple de formulaire de connexion
    <form method="POST" action="/dologin.html">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-</form>
    
-
    
-
-      
    La partie où s'effectue la connexion proprement dite est
-      traitée par le gestionnaire form-login-handler.
-      L'action de ce formulaire doit pointer vers ce gestionnaire, ce
-      que l'on configure dans Apache httpd comme suit :
    
-
-      
    Exemple de configuration du gestionnaire de
-      formulaire de connexion
    <Location /dologin.html>
-    SetHandler form-login-handler
-    AuthFormLoginRequiredLocation http://example.com/login.html
-    AuthFormLoginSuccessLocation http://example.com/success.html
-    AuthFormProvider file
-    AuthUserFile conf/passwd
-    AuthType form
-    AuthName realm
-    Session On
-    SessionCookieName session path=/
-    SessionCryptoPassphrase secret
-</Location>
    
-
    
-
-      
    L'URL spécifiée par la directive
-      AuthFormLoginRequiredLocation
-      référencera en général une page expliquant à l'utilisateur que sa
-      tentative de connexion a échoué, et qu'il doit la renouveler. La
-      directive AuthFormLoginSuccessLocation
-      spécifie l'URL vers laquelle l'utilisateur doit être redirigé s'il
-      s'est authentifié avec succès.
    
-
-      
    Alternativement, l'URL vers laquelle doit être redirigé
-      l'utilisateur s'il s'est authentifié avec succès peut être
-      intégrée dans le formulaire de connexion, comme dans l'exemple
-      ci-dessous. Il en découle que le même gestionnaire
-      form-login-handler pourra être utilisé pour différentes
-      zones du site web.
    
-
-      
    Exemple de formulaire d'authentification multizone
    <form method="POST" action="/dologin.html">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-  <input type="hidden" name="httpd_location" value="http://example.com/success.html" />
-</form>
    
-
    
-
-    
    top
    
-
    
-
    Connexion à la volée
    
-
-      
    Avertissement
    
-        
    Il existe un risque, dans certaines circonstances, que le
-	formulaire de connexion configuré pour une connexion à la volée
-	soit soumis plusieurs fois, révélant de ce fait les paramètres
-	de connexion à l'application sous-jacente. L'administrateur doit
-	s'assurer que cette dernière est correctement sécurisée afin
-	d'éviter les éventuels abus. En cas de doute, utilisez une page
-	de connexion indépendante dédiée.
    
-      
    
-
-      
    Comme alternative à la page de connexion dédiée pour un site
-      web, il est possible de configurer mod_auth_form
-      pour authentifier les utilisateurs à la volée, sans les rediriger
-      vers une autre page, ce qui permet de conserver l'état de la page
-      courante au cours de la tentative de connexion. Ceci peut s'avérer
-      utile dans le cas d'une session limitée dans le temps, si le délai
-      de la session a expiré pendant la requête de l'utilisateur. Ce
-      dernier peut alors se réauthentifier à la même place, et
-      poursuivre son activité à partir du point où il en était resté.
    
-
-      
    Si un utilisateur non authentifié tente d'accéder à une page
-      protégée par mod_auth_form, et si ce dernier
-      n'est pas configuré avec une directive AuthFormLoginRequiredLocation,
-      un code de statut HTTP_UNAUTHORIZED est renvoyé vers le
-      navigateur, indiquant à l'utilisateur qu'il n'est pas autorisé à
-      accéder à cette page.
    
-
-      
    Pour configurer l'authentification à la volée, l'administrateur
-      remplace le message d'erreur renvoyé par le code de statut
-      HTTP_UNAUTHORIZED par un message d'erreur personnalisé
-      contenant le formulaire de connexion comme suit :
    
-
-      
    Exemple simple d'authentification à la volée
    AuthFormProvider file
-ErrorDocument 401 /login.shtml
-AuthUserFile conf/passwd
-AuthType form
-AuthName realm
-AuthFormLoginRequiredLocation http://example.com/login.html
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    
-
    
-
-      
    La page du message d'erreur doit contenir un formulaire de
-      connexion dont la propriété action est vide, comme dans l'exemple
-      ci-dessous. Ceci a pour effet de soumettre le formulaire à l'URL
-      protégée originale, cette dernière n'ayant pas besoin d'être
-      connue de la page en cours.
    
-
-      
    Exemple de formulaire de connexion à la volée
    <form method="POST" action="">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-</form>
    
-
    
-
-      
    Lorsque l'utilisateur final a entré ses informations de
-      connexion, le formulaire effectue une requête HTTP POST pour l'URL
-      originale protégée par mot de passe.
-      mod_auth_form va alors intercepter cette requête
-      POST, et dans le cas où des champs HTML Utilisateur et Mot de
-      passe corrects sont présents, l'utilisateur sera connecté, et
-      l'URL originale protégée par mot de passe lui sera retournée en
-      tant que requête GET.
    
-
-    
    top
    
-
    
-
    Connexion à la volée avec
-    conservation du contenu
    
-
-      
    Il existe une limite à la technique de connexion à la volée
-      décrite ci-dessus ; si un formulaire HTML POST entraîne une
-      demande d'authentification ou de réauthentification, le contenu du
-      formulaire original envoyé par le navigateur sera perdu. Cela peut
-      s'avérer plus ou moins gênant pour l'utilisateur final selon la
-      fonction du site web.
    
-
-      
    Comme solution à ce problème, mod_auth_form
-      permet d'intégrer la méthode et le contenu de la requête originale
-      dans le formulaire de connexion. Si l'authentification réussit,
-      Apache httpd pourra refaire une tentative avec la méthode et le contenu
-      originaux, tout en conservant l'état de la requête originale.
    
-
-      
    Pour mettre en oeuvre la conservation du contenu, vous devez
-      ajouter trois champs supplémentaires au formulaire de connexion
-      comme dans l'exemple suivant :
    
-
-      
    Exemple de formulaire avec conservation du
-      contenu
    <form method="POST" action="">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-  
      <input type="hidden" name="httpd_method" value="POST" />
-  <input type="hidden" name="httpd_mimetype" value="application/x-www-form-urlencoded" />
-  <input type="hidden" name="httpd_body" value="name1=value1&name2=value2" />
    
-</form>
    
-
    
-
-      
    La manière dont la méthode, le type MIME et le contenu de la
-      requête originale seront intégrés dans le formulaire de connexion
-      vont dépendre de la plate-forme et de la technologie utilisées au
-      sein du site web.
-      
    
-
-      
    Une option consiste à utiliser le module
-      mod_include en association avec la directive
-      KeptBodySize, ainsi
-      qu'un script CGI adapté pour intégrer les variables dans le
-      formulaire.
    
-
-      
    Une autre option consiste à présenter le formulaire de
-      connexion en utilisant un script CGI ou une autre technologie
-      dynamique.
    
-
-      
    Exemple avec script CGI
            AuthFormProvider file
-        ErrorDocument 401 /cgi-bin/login.cgi
-        ...
    
-
    
-
-    
    top
    
-
    
-
    Déconnexion
    
-
-      
    Pour permettre à un utilisateur de se déconnecter d'une session
-      particulière, vous devez configurer une page pour qu'elle soit
-      traitée par le gestionnaire form-logout-handler. Tout
-      accès à cette URL va entraîner la suppression de l'Utilisateur et
-      du Mot de passe de la session courante, ce qui aura pour effet de
-      déconnecter l'utilisateur.
    
-
-      
    Vous pouvez spécifier une URL vers laquelle le navigateur sera
-      redirigé en cas de déconnection réussie, en définissant la
-      directive AuthFormLogoutLocation. Cette
-      URL devra expliquer à l'utilisateur qu'il a été déconnecté, et lui
-      donner la possibilité de se connecter à nouveau.
    
-
-      
    Exemple simple de configuration de la
-      déconnexion
    SetHandler form-logout-handler
-AuthName realm
-AuthFormLogoutLocation http://example.com/loggedout.html
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    
-
    
-
-      
    Notez que la déconnexion d'un utilisateur ne supprime pas la
-      session ; elle supprime seulement l'utilisateur et le mot de passe
-      de la session. Si la session qui en résulte est vide, elle sera
-      probablement supprimée, mais ce n'est pas garanti. Si vous voulez
-      être sûr que la session sera supprimée, affectez une valeur faible
-      à la directive SessionMaxAge, par exemple 1
-      (affecter à cette directive la valeur zéro signifie une session
-      sans limite d'âge).
-      
    
-
-      
    Exemple simple avec durée de validité de session
-      limitée
    SetHandler form-logout-handler
-AuthFormLogoutLocation http://example.com/loggedout.html
-Session On
-SessionMaxAge 1
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    
-
    
-
-    
    top
    
-
    
-
    Noms d'utilisateurs et mots de
-    passe
    
-    
    Notez que la soumission d'un formulaire implique l'encodage URL
-    (URLEncoding) des données du formulaire, ici le nom d'utilisateur et
-    le mot de passe. Vous devez donc choisir des noms d'utilisateurs et
-    mots de passe qui ne contiennent pas de caractères susceptibles
-    d'être encodés URL lors de la soumission du formulaire, sous peine
-    d'obtenir des résultats inattendus.
    
-    
    
 
    Langues Disponibles:  en  |
diff --git a/docs/manual/mod/mod_auth_form.xml b/docs/manual/mod/mod_auth_form.xml
index 57450fd5ae..8f2dc1fe24 100644
--- a/docs/manual/mod/mod_auth_form.xml
+++ b/docs/manual/mod/mod_auth_form.xml
@@ -358,7 +358,7 @@ SessionCryptoPassphrase secret
 
     Example
     
-<Location /secure>
+<Location "/secure">
     AuthType form
     AuthName "private area"
     AuthFormProvider  dbm
@@ -634,7 +634,7 @@ parser has been added in 2.4.4.
 
     Example
     
-<Location /logout>
+<Location "/logout">
     SetHandler form-logout-handler
     AuthFormLogoutLocation "http://example.com/loggedout.html"
     Session on
diff --git a/docs/manual/mod/mod_authn_anon.html.en b/docs/manual/mod/mod_authn_anon.html.en
index 8d8076f66f..ed7c11af71 100644
--- a/docs/manual/mod/mod_authn_anon.html.en
+++ b/docs/manual/mod/mod_authn_anon.html.en
@@ -67,6 +67,49 @@
 
 
    top
    
+
    
+
    Example
    
+    
    The example below is combined with "normal" htpasswd-file based
+    authentication and allows users in additionally as 'guests' with the
+    following properties:
    
+
+    
      
+      
    • It insists that the user enters a userID.
+      (Anonymous_NoUserID)
      • 
+
+      
    • It insists that the user enters a password.
+      (Anonymous_MustGiveEmail)
      • 
+
+      
    • The password entered must be a valid email address, i.e.
+      contain at least one '@' and a '.'.
+      (Anonymous_VerifyEmail)
      • 
+
+      
    • The userID must be one of anonymous guest www test
+      welcome and comparison is not case
+      sensitive. (Anonymous)
      • 
+
+      
    • And the Email addresses entered in the passwd field are
+      logged to the error log file.
+      (Anonymous_LogEmail)
      • 
+    
    
+
+    
    Example
    <Directory "/var/www/html/private">
+    AuthName "Use 'anonymous' & Email address for guest entry"
+    AuthType Basic
+    AuthBasicProvider file anon
+    AuthUserFile "/path/to/your/.htpasswd"
+    
+    Anonymous_NoUserID off
+    Anonymous_MustGiveEmail on
+    Anonymous_VerifyEmail on
+    Anonymous_LogEmail on
+    Anonymous anonymous guest www test welcome
+    
+    Require valid-user
+</Directory>
    
+
    
+
    
+
    top
    Anonymous Directive
    
 
    Description:Le nom du champ de formulaire contenant le type MIME du
+corps de la requête à effectuer en cas de connexion
+réussie
    
 
    Syntaxe:AuthFormMimetype nom du champ
    
 
    Défaut:httpd_mimetype
    
 
    Contexte:répertoire
    
 
 
 
 
 
 
    
     at least one '@' and a '.' to encourage users to enter valid email
     addresses (see the above Anonymous_LogEmail).
    
 
-
-
    top
    
-
    
-
    Example
    
-    
    The example below is combined with "normal" htpasswd-file based
-    authentication and allows users in additionally as 'guests' with the
-    following properties:
    
-
-    
      
-      
    • It insists that the user enters a userID.
-      (Anonymous_NoUserID)
      • 
-
-      
    • It insists that the user enters a password.
-      (Anonymous_MustGiveEmail)
      • 
-
-      
    • The password entered must be a valid email address, i.e.
-      contain at least one '@' and a '.'.
-      (Anonymous_VerifyEmail)
      • 
-
-      
    • The userID must be one of anonymous guest www test
-      welcome and comparison is not case
-      sensitive. (Anonymous)
      • 
-
-      
    • And the Email addresses entered in the passwd field are
-      logged to the error log file.
-      (Anonymous_LogEmail)
      • 
-    
    
-
-    
    Example
    <Directory "/var/www/html/private">
-    AuthName "Use 'anonymous' & Email address for guest entry"
-    AuthType Basic
-    AuthBasicProvider file anon
-    AuthUserFile "/path/to/your/.htpasswd"
-    
-    Anonymous_NoUserID off
-    Anonymous_MustGiveEmail on
-    Anonymous_VerifyEmail on
-    Anonymous_LogEmail on
-    Anonymous anonymous guest www test welcome
-    
-    Require valid-user
-</Directory>
    
-
    
 
    
diff --git a/docs/manual/mod/mod_authn_anon.html.fr b/docs/manual/mod/mod_authn_anon.html.fr
index 959aceac65..2a645d6acf 100644
--- a/docs/manual/mod/mod_authn_anon.html.fr
+++ b/docs/manual/mod/mod_authn_anon.html.fr
@@ -59,7 +59,10 @@ authentifi
     module mod_authn_anon est invoqué en affectant la
     valeur anon à la directive AuthBasicProvider.
    
 
    
-
    Directives
    
+
    Sujets
    
+
    Directives
    
 
-
    Sujets
    
-
    
+
    
+
    top
    
+
    
+
    Exemple
    
+    
    L'exemple ci-dessous présente un exemple de combinaison avec
+    l'authentification à base de fichier htpasswd "normale", et permet
+    la connexion d'utilisateurs en tant qu'invités avec les propriétés
+    suivantes :
    
+
+    
      
+      
    • Il incite l'utilisateur à fournir un identifiant.
+      (Anonymous_NoUserID)
      • 
+
+      
    • Il incite l'utilisateur à fournir un mot de passe.
+      (Anonymous_MustGiveEmail)
      • 
+
+      
    • Le mot de passe fourni doit être une adresse email valide,
+      c'est à dire contenant au moins un '@' et un '.'.
+      (Anonymous_VerifyEmail)
      • 
+
+      
    • Les valeurs possibles pour l'identifiant utilisateur sont
+      anonymous, guest, www, test ou welcome, et la
+      vérification n'est pas sensible à la casse.
+      (Anonymous)
      • 
+
+      
    • Les adresses email entrées dans le champ passwd sont
+      enregistrées dans le fichier journal des erreurs.
+      (Anonymous_LogEmail)
      • 
+    
    
+
+    
    Exemple
    <Directory /var/www/html/private>
+    AuthName "Use 'anonymous' & Email address for guest entry"
+    AuthType Basic
+    AuthBasicProvider file anon
+    AuthUserFile /path/to/your/.htpasswd
+
+    Anonymous_NoUserID off
+    Anonymous_MustGiveEmail on
+    Anonymous_VerifyEmail on
+    Anonymous_LogEmail on
+    Anonymous anonymous guest www test welcome
+
+    Require valid-user
+</Directory>
    
+
    
+
    top
    Directive Anonymous
    
 
    
 
    Description:Specifies userIDs that are allowed access without
@@ -165,49 +208,6 @@ formatted email address
    
 
 
 
 
    
@@ -180,51 +225,6 @@ email fournie comme mot de passe est correct
     '.' afin d'inciter les utilisateurs à fournir des adresses email
     valides (voir ci-dessus la directive Anonymous_LogEmail).
    
 
-
-
    top
    
-
    
-
    Exemple
    
-    
    L'exemple ci-dessous présente un exemple de combinaison avec
-    l'authentification à base de fichier htpasswd "normale", et permet
-    la connexion d'utilisateurs en tant qu'invités avec les propriétés
-    suivantes :
    
-
-    
      
-      
    • Il incite l'utilisateur à fournir un identifiant.
-      (Anonymous_NoUserID)
      • 
-
-      
    • Il incite l'utilisateur à fournir un mot de passe.
-      (Anonymous_MustGiveEmail)
      • 
-
-      
    • Le mot de passe fourni doit être une adresse email valide,
-      c'est à dire contenant au moins un '@' et un '.'.
-      (Anonymous_VerifyEmail)
      • 
-
-      
    • Les valeurs possibles pour l'identifiant utilisateur sont
-      anonymous, guest, www, test ou welcome, et la
-      vérification n'est pas sensible à la casse.
-      (Anonymous)
      • 
-
-      
    • Les adresses email entrées dans le champ passwd sont
-      enregistrées dans le fichier journal des erreurs.
-      (Anonymous_LogEmail)
      • 
-    
    
-
-    
    Exemple
    <Directory /var/www/html/private>
-    AuthName "Use 'anonymous' & Email address for guest entry"
-    AuthType Basic
-    AuthBasicProvider file anon
-    AuthUserFile /path/to/your/.htpasswd
-
-    Anonymous_NoUserID off
-    Anonymous_MustGiveEmail on
-    Anonymous_VerifyEmail on
-    Anonymous_LogEmail on
-    Anonymous anonymous guest www test welcome
-
-    Require valid-user
-</Directory>
    
-
    
 
    
diff --git a/docs/manual/mod/mod_authn_anon.html.ja.utf8 b/docs/manual/mod/mod_authn_anon.html.ja.utf8
index c145264dc0..2e1033cff4 100644
--- a/docs/manual/mod/mod_authn_anon.html.ja.utf8
+++ b/docs/manual/mod/mod_authn_anon.html.ja.utf8
@@ -59,7 +59,10 @@
     AuthBasicProvider に
     anon という値を設定することで起動されます。
    
 
    
-
    ディレクティブ
    
+
    トピック
    
+
    ディレクティブ
    
 
-
    トピック
    
-
    
+
    
+
    top
    
+
    
+
    例
    
+    
    以下の例は「普通」の htpasswd ファイルに基づいた認証と組み合わされて
+    おり、以下の要件を見たすユーザを「ゲスト」として許可します:
    
+
+    
      
+      
    • ユーザは userID を入力しなければなりません。
+      (Anonymous_NoUserID)
      • 
+
+      
    • ユーザはパスワードを入力しなければなりません。
+      (Anonymous_MustGiveEmail)
      • 
+
+      
    • 入力されたパスワードは有効な電子メールアドレスでなければ
+      なりません。すなわち、少くとも一つの '@' と '.' が
+      含まれている必要があります。
+      (Anonymous_VerifyEmail)
      • 
+
+      
    • userID は anonymous guest www test
+      welcome のどれかでなければなりません。
+      ユーザ名の比較は大文字小文字を区別しません。
      • 
+
+      
    • パスワード欄に入力された電子メールアドレスはエラーログファイルに
+      ロギングされます。
+      (Anonymous_LogEmail)
      • 
+    
    
+
+    
    例
    <Directory /var/www/html/private>
+    AuthName "Use 'anonymous' & Email address for guest entry"
+    AuthType Basic
+    AuthBasicProvider file anon
+    AuthUserFile /path/to/your/.htpasswd
+    
+    Anonymous_NoUserID off
+    Anonymous_MustGiveEmail on
+    Anonymous_VerifyEmail on
+    Anonymous_LogEmail on
+    Anonymous anonymous guest www test welcome
+    
+    Require valid-user
+</Directory>
    
+
    
+
    top
    Anonymous ディレクティブ
    
 
    
 
 
 
 
    
@@ -169,49 +212,6 @@
     少なくとも一つの '@' と '.' を含んでいるかどうかを調べます
     (上の Anonymous_LogEmail 参照)。
    
 
-
-
    top
    
-
    
-
    例
    
-    
    以下の例は「普通」の htpasswd ファイルに基づいた認証と組み合わされて
-    おり、以下の要件を見たすユーザを「ゲスト」として許可します:
    
-
-    
      
-      
    • ユーザは userID を入力しなければなりません。
-      (Anonymous_NoUserID)
      • 
-
-      
    • ユーザはパスワードを入力しなければなりません。
-      (Anonymous_MustGiveEmail)
      • 
-
-      
    • 入力されたパスワードは有効な電子メールアドレスでなければ
-      なりません。すなわち、少くとも一つの '@' と '.' が
-      含まれている必要があります。
-      (Anonymous_VerifyEmail)
      • 
-
-      
    • userID は anonymous guest www test
-      welcome のどれかでなければなりません。
-      ユーザ名の比較は大文字小文字を区別しません。
      • 
-
-      
    • パスワード欄に入力された電子メールアドレスはエラーログファイルに
-      ロギングされます。
-      (Anonymous_LogEmail)
      • 
-    
    
-
-    
    例
    <Directory /var/www/html/private>
-    AuthName "Use 'anonymous' & Email address for guest entry"
-    AuthType Basic
-    AuthBasicProvider file anon
-    AuthUserFile /path/to/your/.htpasswd
-    
-    Anonymous_NoUserID off
-    Anonymous_MustGiveEmail on
-    Anonymous_VerifyEmail on
-    Anonymous_LogEmail on
-    Anonymous anonymous guest www test welcome
-    
-    Require valid-user
-</Directory>
    
-
    
 
    
diff --git a/docs/manual/mod/mod_authn_anon.html.ko.euc-kr b/docs/manual/mod/mod_authn_anon.html.ko.euc-kr
index 686d382397..915848e0bc 100644
--- a/docs/manual/mod/mod_authn_anon.html.ko.euc-kr
+++ b/docs/manual/mod/mod_authn_anon.html.ko.euc-kr
@@ -53,7 +53,10 @@
     
    mod_auth_basicÀ» »ç¿ëÇÒ¶§ AuthBasicProviderÀÇ
     °ªÀ¸·Î anonÀ» ¼³Á¤Çϸé ÀÌ ¸ðµâÀ» »ç¿ëÇÑ´Ù.
    
 
    
-
    Áö½Ã¾îµé
    
+
    ÁÖÁ¦
    
+
    Áö½Ã¾îµé
    
 
-
    ÁÖÁ¦
    
-
    
+
    
+
    top
    
+
    
+
    ¿¹Á¦
    
+    
    ´ÙÀ½ ¿¹´Â "ÀϹÝÀûÀÎ" htpasswd-ÆÄÀϱâ¹Ý ÀÎÁõ¿¡ Ãß°¡·Î
+    »ç¿ëÀÚ°¡ ´ÙÀ½ Á¶°ÇÀ» ¸¸Á·ÇÑ´Ù¸é '¼Õ´Ô(guest)'À¸·Î Á¢±ÙÇÒ
+    ¼ö ÀÖµµ·Ï ÇÑ´Ù:
    
+
+    
      
+      
    • »ç¿ëÀÚ´Â »ç¿ëÀÚ ¾ÆÀ̵𸦠ÀÔ·ÂÇØ¾ß ÇÑ´Ù. (Anonymous_NoUserID)
      • 
+
+      
    • »ç¿ëÀÚ´Â ¾ÏÈ£¸¦ ÀÔ·ÂÇØ¾ß ÇÑ´Ù. (Anonymous_MustGiveEmail)
      • 
+
+      
    • ¾ÏÈ£·Î À¯È¿ÇÑ ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ ÀÔ·ÂÇØ¾ß ÇÑ´Ù. ¿¹¸¦
+      µé¾î ÃÖ¼ÒÇÑ '@'¿Í '.' ÇÑ°³¸¦ Æ÷ÇÔÇØ¾ß ÇÑ´Ù. (Anonymous_VerifyEmail)
      • 
+
+      
    • »ç¿ëÀÚ ¾ÆÀ̵ð´Â anonymous guest www test
+      welcome Áß ÇϳªÀ̸ç, ´ë¼Ò¹®ÀÚ¸¦ ±¸º°ÇÏÁö
+      ¾Ê´Â´Ù. (Anonymous)
      • 
+
+      
    • ±×¸®°í ¾ÏÈ£·Î ÀÔ·ÂÇÑ ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ ¿À·ù·Î±×ÆÄÀÏ¿¡
+      ±â·ÏÇÑ´Ù. (Anonymous_LogEmail)
      • 
+    
    
+
+    
    ¿¹Á¦
    
+      <Directory /foo>
+      
+        AuthName "¼Õ´ÔÀ¸·Î ¹æ¹®ÇÏ·Á¸é 'anonymous'¿Í ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ »ç¿ëÇ϶ó"
    
+        AuthType Basic
    
+        AuthBasicProvider file anon
    
+        AuthUserFile /path/to/your/.htpasswd
    
+        
    
+        Anonymous_NoUserID off
    
+        Anonymous_MustGiveEmail on
    
+        Anonymous_VerifyEmail on
    
+        Anonymous_LogEmail on
    
+        Anonymous anonymous guest www test welcome
    
+        
    
+        Order Deny,Allow
    
+        Allow from all
    
+        
    
+        Require valid-user
    
+          
+      </Directory>
+    
    
+
    top
    Anonymous Áö½Ã¾î
    
 
    
 
 
 
 
    
@@ -161,51 +206,6 @@
     Æ÷ÇÔÇÏ´ÂÁö °Ë»çÇÑ´Ù (À§ÀÇ Anonymous_LogEmail Âü°í).
    
-
    top
    
-
    
-
    ¿¹Á¦
    
-    
    ´ÙÀ½ ¿¹´Â "ÀϹÝÀûÀÎ" htpasswd-ÆÄÀϱâ¹Ý ÀÎÁõ¿¡ Ãß°¡·Î
-    »ç¿ëÀÚ°¡ ´ÙÀ½ Á¶°ÇÀ» ¸¸Á·ÇÑ´Ù¸é '¼Õ´Ô(guest)'À¸·Î Á¢±ÙÇÒ
-    ¼ö ÀÖµµ·Ï ÇÑ´Ù:
    
-
-    
      
-      
    • »ç¿ëÀÚ´Â »ç¿ëÀÚ ¾ÆÀ̵𸦠ÀÔ·ÂÇØ¾ß ÇÑ´Ù. (Anonymous_NoUserID)
      • 
-
-      
    • »ç¿ëÀÚ´Â ¾ÏÈ£¸¦ ÀÔ·ÂÇØ¾ß ÇÑ´Ù. (Anonymous_MustGiveEmail)
      • 
-
-      
    • ¾ÏÈ£·Î À¯È¿ÇÑ ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ ÀÔ·ÂÇØ¾ß ÇÑ´Ù. ¿¹¸¦
-      µé¾î ÃÖ¼ÒÇÑ '@'¿Í '.' ÇÑ°³¸¦ Æ÷ÇÔÇØ¾ß ÇÑ´Ù. (Anonymous_VerifyEmail)
      • 
-
-      
    • »ç¿ëÀÚ ¾ÆÀ̵ð´Â anonymous guest www test
-      welcome Áß ÇϳªÀ̸ç, ´ë¼Ò¹®ÀÚ¸¦ ±¸º°ÇÏÁö
-      ¾Ê´Â´Ù. (Anonymous)
      • 
-
-      
    • ±×¸®°í ¾ÏÈ£·Î ÀÔ·ÂÇÑ ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ ¿À·ù·Î±×ÆÄÀÏ¿¡
-      ±â·ÏÇÑ´Ù. (Anonymous_LogEmail)
      • 
-    
    
-
-    
    ¿¹Á¦
    
-      <Directory /foo>
-      
-        AuthName "¼Õ´ÔÀ¸·Î ¹æ¹®ÇÏ·Á¸é 'anonymous'¿Í ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ »ç¿ëÇ϶ó"
    
-        AuthType Basic
    
-        AuthBasicProvider file anon
    
-        AuthUserFile /path/to/your/.htpasswd
    
-        
    
-        Anonymous_NoUserID off
    
-        Anonymous_MustGiveEmail on
    
-        Anonymous_VerifyEmail on
    
-        Anonymous_LogEmail on
    
-        Anonymous anonymous guest www test welcome
    
-        
    
-        Order Deny,Allow
    
-        Allow from all
    
-        
    
-        Require valid-user
    
-          
-      </Directory>
-    
    
-
    
 
    °¡´ÉÇÑ ¾ð¾î:  en  |
diff --git a/docs/manual/mod/mod_authn_core.html.en b/docs/manual/mod/mod_authn_core.html.en
index 42800860bd..4192656142 100644
--- a/docs/manual/mod/mod_authn_core.html.en
+++ b/docs/manual/mod/mod_authn_core.html.en
@@ -50,6 +50,78 @@
 
 
    top
    
+
    
+
    Creating Authentication Provider Aliases
    
+
+    
    Extended authentication providers can be created
+    within the configuration file and assigned an alias name.  The alias
+    providers can then be referenced through the directives
+    AuthBasicProvider or
+    AuthDigestProvider in
+    the same way as a base authentication provider.  Besides the ability
+    to create and alias an extended provider, it also allows the same
+    extended authentication provider to be reference by multiple
+    locations.
    
+
+    
    Examples
    
+
+        
    This example checks for passwords in two different text
+        files.
    
+
+        
    Checking multiple text password files
    # Check here first
+<AuthnProviderAlias file file1>
+    AuthUserFile "/www/conf/passwords1"
+</AuthnProviderAlias>
+
+# Then check here
+<AuthnProviderAlias file file2>   
+    AuthUserFile "/www/conf/passwords2"
+</AuthnProviderAlias>
+
+<Directory "/var/web/pages/secure">
+    AuthBasicProvider file1 file2
+    
+    AuthType Basic
+    AuthName "Protected Area"
+    Require valid-user
+</Directory>
    
+
    
+
+        
    The example below creates two different ldap authentication
+        provider aliases based on the ldap provider.  This allows
+        a single authenticated location to be serviced by multiple ldap
+        hosts:
    
+
+        
    Checking multiple LDAP servers
    <AuthnProviderAlias ldap ldap-alias1>
+    AuthLDAPBindDN "cn=youruser,o=ctx"
+    AuthLDAPBindPassword yourpassword
+    AuthLDAPURL "ldap://ldap.host/o=ctx"
+</AuthnProviderAlias>
+<AuthnProviderAlias ldap ldap-other-alias>
+    AuthLDAPBindDN "cn=yourotheruser,o=dev"
+    AuthLDAPBindPassword yourotherpassword
+    AuthLDAPURL "ldap://other.ldap.host/o=dev?cn"
+</AuthnProviderAlias>
+
+Alias "/secure" "/webpages/secure"
+<Directory "/webpages/secure">
+    Order deny,allow
+    Allow from all
+    
+    AuthBasicProvider ldap-other-alias  ldap-alias1
+    
+    AuthType Basic
+    AuthName "LDAP Protected Place"
+    Require valid-user
+    # Note that Require ldap-* would not work here, since the 
+    # AuthnProviderAlias does not provide the config to authorization providers
+    # that are implemented in the same module as the authentication provider.
+</Directory>
    
+
    
+    
+
+
    
+
    top
    AuthName Directive
    
 
    
 
 
 
 
 
 
  • Authentication, Authorization,
     and Access Control
    • 
-
-
    top
    
-
    
-
    Creating Authentication Provider Aliases
    
-
-    
    Extended authentication providers can be created
-    within the configuration file and assigned an alias name.  The alias
-    providers can then be referenced through the directives
-    AuthBasicProvider or
-    AuthDigestProvider in
-    the same way as a base authentication provider.  Besides the ability
-    to create and alias an extended provider, it also allows the same
-    extended authentication provider to be reference by multiple
-    locations.
    
-
-    
    Examples
    
-
-        
    This example checks for passwords in two different text
-        files.
    
-
-        
    Checking multiple text password files
    # Check here first
-<AuthnProviderAlias file file1>
-    AuthUserFile "/www/conf/passwords1"
-</AuthnProviderAlias>
-
-# Then check here
-<AuthnProviderAlias file file2>   
-    AuthUserFile "/www/conf/passwords2"
-</AuthnProviderAlias>
-
-<Directory "/var/web/pages/secure">
-    AuthBasicProvider file1 file2
-    
-    AuthType Basic
-    AuthName "Protected Area"
-    Require valid-user
-</Directory>
    
-
    
-
-        
    The example below creates two different ldap authentication
-        provider aliases based on the ldap provider.  This allows
-        a single authenticated location to be serviced by multiple ldap
-        hosts:
    
-
-        
    Checking multiple LDAP servers
    <AuthnProviderAlias ldap ldap-alias1>
-    AuthLDAPBindDN "cn=youruser,o=ctx"
-    AuthLDAPBindPassword yourpassword
-    AuthLDAPURL "ldap://ldap.host/o=ctx"
-</AuthnProviderAlias>
-<AuthnProviderAlias ldap ldap-other-alias>
-    AuthLDAPBindDN "cn=yourotheruser,o=dev"
-    AuthLDAPBindPassword yourotherpassword
-    AuthLDAPURL "ldap://other.ldap.host/o=dev?cn"
-</AuthnProviderAlias>
-
-Alias "/secure" "/webpages/secure"
-<Directory "/webpages/secure">
-    Order deny,allow
-    Allow from all
-    
-    AuthBasicProvider ldap-other-alias  ldap-alias1
-    
-    AuthType Basic
-    AuthName "LDAP Protected Place"
-    Require valid-user
-    # Note that Require ldap-* would not work here, since the 
-    # AuthnProviderAlias does not provide the config to authorization providers
-    # that are implemented in the same module as the authentication provider.
-</Directory>
    
-
    
-    
-
 
    
diff --git a/docs/manual/mod/mod_authn_core.html.fr b/docs/manual/mod/mod_authn_core.html.fr
index 72d5537fe3..26b30bd014 100644
--- a/docs/manual/mod/mod_authn_core.html.fr
+++ b/docs/manual/mod/mod_authn_core.html.fr
@@ -42,17 +42,95 @@
     mod_authn_core sont communes à tous les
     fournisseurs d'authentification.
    
 
    
-
+
    top
    
+
    
+
    Création d'alias de fournisseurs
+d'authentification
    
+
+    
    Il est possible de créer des fournisseurs d'authentification
+    étendus dans le fichier de configuration et de leur assigner un
+    alias. Le fournisseur ainsi nommé peut alors être référencé à l'aide
+    des directives AuthBasicProvider ou AuthDigestProvider tout comme
+    un fournisseur d'authentification de base. Outre la possibilité de
+    créer et attribuer un alias à un fournisseur étendu, le même
+    fournisseur d'authentification peut aussi être référencé par
+    plusieurs sections relatives à une zone du site web.
    
+
+    
    Exemples
    
+
+	
    Cet exemple vérifie les mots de passe dans deux fichiers
+	textes différents.
    
+
+	
    Vérification dans plusieurs fichiers de mots de
+	passe au format texte
    # Première vérification
+<AuthnProviderAlias file file1>
+    AuthUserFile /www/conf/passwords1
+</AuthnProviderAlias>
+
+# Vérification suivante
+<AuthnProviderAlias file file2>   
+    AuthUserFile /www/conf/passwords2
+</AuthnProviderAlias>
+
+<Directory /var/web/pages/secure>
+    AuthBasicProvider file1 file2
+    
+    AuthType Basic
+    AuthName "Protected Area"
+    Require valid-user
+</Directory>
    
+
    
+
+
+
+        
    Dans l'exemple ci-dessous, deux fournisseurs
+	d'authentification ldap sont créés à partir du fournisseur ldap
+	de base, et se voient attribuer un alias. L'authentification
+	d'une même zone peut alors être traitée par plusieurs serveurs
+	ldap :
    
+
+        
    Vérification auprès de plusieurs serveurs
+	LDAP
    <AuthnProviderAlias ldap ldap-alias1>
+    AuthLDAPBindDN cn=youruser,o=ctx
+    AuthLDAPBindPassword yourpassword
+    AuthLDAPURL ldap://ldap.host/o=ctx
+    </AuthnProviderAlias>
+    <AuthnProviderAlias ldap ldap-other-alias>
+    AuthLDAPBindDN cn=yourotheruser,o=dev
+    AuthLDAPBindPassword yourotherpassword
+    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
+</AuthnProviderAlias>
+
+Alias /secure /webpages/secure
+<Directory /webpages/secure>
+    Order deny,allow
+    Allow from all
+    
+    AuthBasicProvider ldap-other-alias  ldap-alias1
+    
+    AuthType Basic
+    AuthName LDAP_Protected Place
+    Require valid-user
+    # Notez que Require ldap-* ne fonctionnerait pas ici, car
+    # AuthnProviderAlias ne fournit pas de configuration pour les
+    # fournisseurs d'autorisation implémentés dans le même module que le
+    # fournisseur d'authentification.
+</Directory>
    
+
    
+    
+
+
    top
    Directive AuthName
    
 
    
 
    Description:Authorization realm for use in HTTP
@@ -176,78 +248,6 @@ the specified alias
    
 
 
 
 
 
 
    
@@ -186,84 +264,6 @@ l'alias sp
 
  • Authentification, autorisation et contrôle
     d'accès
    • 
-
-
    top
    
-
    
-
    Création d'alias de fournisseurs
-d'authentification
    
-
-    
    Il est possible de créer des fournisseurs d'authentification
-    étendus dans le fichier de configuration et de leur assigner un
-    alias. Le fournisseur ainsi nommé peut alors être référencé à l'aide
-    des directives AuthBasicProvider ou AuthDigestProvider tout comme
-    un fournisseur d'authentification de base. Outre la possibilité de
-    créer et attribuer un alias à un fournisseur étendu, le même
-    fournisseur d'authentification peut aussi être référencé par
-    plusieurs sections relatives à une zone du site web.
    
-
-    
    Exemples
    
-
-	
    Cet exemple vérifie les mots de passe dans deux fichiers
-	textes différents.
    
-
-	
    Vérification dans plusieurs fichiers de mots de
-	passe au format texte
    # Première vérification
-<AuthnProviderAlias file file1>
-    AuthUserFile /www/conf/passwords1
-</AuthnProviderAlias>
-
-# Vérification suivante
-<AuthnProviderAlias file file2>   
-    AuthUserFile /www/conf/passwords2
-</AuthnProviderAlias>
-
-<Directory /var/web/pages/secure>
-    AuthBasicProvider file1 file2
-    
-    AuthType Basic
-    AuthName "Protected Area"
-    Require valid-user
-</Directory>
    
-
    
-
-
-
-        
    Dans l'exemple ci-dessous, deux fournisseurs
-	d'authentification ldap sont créés à partir du fournisseur ldap
-	de base, et se voient attribuer un alias. L'authentification
-	d'une même zone peut alors être traitée par plusieurs serveurs
-	ldap :
    
-
-        
    Vérification auprès de plusieurs serveurs
-	LDAP
    <AuthnProviderAlias ldap ldap-alias1>
-    AuthLDAPBindDN cn=youruser,o=ctx
-    AuthLDAPBindPassword yourpassword
-    AuthLDAPURL ldap://ldap.host/o=ctx
-    </AuthnProviderAlias>
-    <AuthnProviderAlias ldap ldap-other-alias>
-    AuthLDAPBindDN cn=yourotheruser,o=dev
-    AuthLDAPBindPassword yourotherpassword
-    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
-</AuthnProviderAlias>
-
-Alias /secure /webpages/secure
-<Directory /webpages/secure>
-    Order deny,allow
-    Allow from all
-    
-    AuthBasicProvider ldap-other-alias  ldap-alias1
-    
-    AuthType Basic
-    AuthName LDAP_Protected Place
-    Require valid-user
-    # Notez que Require ldap-* ne fonctionnerait pas ici, car
-    # AuthnProviderAlias ne fournit pas de configuration pour les
-    # fournisseurs d'autorisation implémentés dans le même module que le
-    # fournisseur d'authentification.
-</Directory>
    
-
    
-    
-
 
    
diff --git a/docs/manual/mod/mod_authn_dbd.html.en b/docs/manual/mod/mod_authn_dbd.html.en
index 703ddb9c18..065c53c56d 100644
--- a/docs/manual/mod/mod_authn_dbd.html.en
+++ b/docs/manual/mod/mod_authn_dbd.html.en
@@ -74,70 +74,6 @@
 
  • Password Formats
    • 
 
    top
    
-
    AuthDBDUserPWQuery Directive
    
-
    
 
 
 
 
    
-
-
-
-
-
-
    Description:SQL query to look up a password for a user
    Syntax:AuthDBDUserPWQuery query
    Context:directory
    Status:Extension
    Module:mod_authn_dbd
    
-    
    The AuthDBDUserPWQuery specifies an
-    SQL query to look up a password for a specified user.  The user's ID
-    will be passed as a single string parameter when the SQL query is
-    executed.  It may be referenced within the query statement using
-    a %s format specifier.
    
-    
    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
    
-
-    
    The first column value of the first row returned by the query
-    statement should be a string containing the encrypted password.
-    Subsequent rows will be ignored.  If no rows are returned, the user
-    will not be authenticated through mod_authn_dbd.
    
-    
    If httpd was built against APR version 1.3.0
-    or higher, any additional column values in the first row returned by
-    the query statement will be stored as environment variables with
-    names of the form AUTHENTICATE_COLUMN.
-    
    
-    
    The encrypted password format depends on which authentication
-    frontend (e.g. mod_auth_basic or
-    mod_auth_digest) is being used.  See Password Formats for
-    more information.
    
-
-
    
-
    top
    
-
    AuthDBDUserRealmQuery Directive
    
-
-
-
-
-
-
-
    Description:SQL query to look up a password hash for a user and realm.
-
    Syntax:AuthDBDUserRealmQuery query
    Context:directory
    Status:Extension
    Module:mod_authn_dbd
    
-    
    The AuthDBDUserRealmQuery specifies an
-    SQL query to look up a password for a specified user and realm in a
-    digest authentication process.
-    The user's ID and the realm, in that order, will be passed as string
-    parameters when the SQL query is executed.  They may be referenced
-    within the query statement using %s format specifiers.
    
-    
    AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
    
-
-    
    The first column value of the first row returned by the query
-    statement should be a string containing the encrypted password.
-    Subsequent rows will be ignored.  If no rows are returned, the user
-    will not be authenticated through mod_authn_dbd.
    
-    
    If httpd was built against APR version 1.3.0
-    or higher, any additional column values in the first row returned by
-    the query statement will be stored as environment variables with
-    names of the form AUTHENTICATE_COLUMN.
-    
    
-    
    The encrypted password format depends on which authentication
-    frontend (e.g. mod_auth_basic or
-    mod_auth_digest) is being used.  See Password Formats for
-    more information.
    
-
-
    
-
    top
    
 
    
 
    Performance and Cacheing
    
 
@@ -163,7 +99,7 @@ DBDKeep 8
 DBDMax  20
 DBDExptime 300
 
-<Directory /usr/www/myhost/private>
+<Directory "/usr/www/myhost/private">
   # mod_authn_core and mod_auth_basic configuration
   # for mod_authn_dbd
   AuthType Basic
@@ -212,6 +148,70 @@ configuration required in some web applications.
   
    Please read mod_dbd documentation for more information
   about security on this scope.
    
 
    
+
    top
    
+
    AuthDBDUserPWQuery Directive
    
+
+
+
+
+
+
+
    Description:SQL query to look up a password for a user
    Syntax:AuthDBDUserPWQuery query
    Context:directory
    Status:Extension
    Module:mod_authn_dbd
    
+    
    The AuthDBDUserPWQuery specifies an
+    SQL query to look up a password for a specified user.  The user's ID
+    will be passed as a single string parameter when the SQL query is
+    executed.  It may be referenced within the query statement using
+    a %s format specifier.
    
+    
    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
    
+
+    
    The first column value of the first row returned by the query
+    statement should be a string containing the encrypted password.
+    Subsequent rows will be ignored.  If no rows are returned, the user
+    will not be authenticated through mod_authn_dbd.
    
+    
    If httpd was built against APR version 1.3.0
+    or higher, any additional column values in the first row returned by
+    the query statement will be stored as environment variables with
+    names of the form AUTHENTICATE_COLUMN.
+    
    
+    
    The encrypted password format depends on which authentication
+    frontend (e.g. mod_auth_basic or
+    mod_auth_digest) is being used.  See Password Formats for
+    more information.
    
+
+
    
+
    top
    
+
    AuthDBDUserRealmQuery Directive
    
+
+
+
+
+
+
+
    Description:SQL query to look up a password hash for a user and realm.
+
    Syntax:AuthDBDUserRealmQuery query
    Context:directory
    Status:Extension
    Module:mod_authn_dbd
    
+    
    The AuthDBDUserRealmQuery specifies an
+    SQL query to look up a password for a specified user and realm in a
+    digest authentication process.
+    The user's ID and the realm, in that order, will be passed as string
+    parameters when the SQL query is executed.  They may be referenced
+    within the query statement using %s format specifiers.
    
+    
    AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
    
+
+    
    The first column value of the first row returned by the query
+    statement should be a string containing the encrypted password.
+    Subsequent rows will be ignored.  If no rows are returned, the user
+    will not be authenticated through mod_authn_dbd.
    
+    
    If httpd was built against APR version 1.3.0
+    or higher, any additional column values in the first row returned by
+    the query statement will be stored as environment variables with
+    names of the form AUTHENTICATE_COLUMN.
+    
    
+    
    The encrypted password format depends on which authentication
+    frontend (e.g. mod_auth_basic or
+    mod_auth_digest) is being used.  See Password Formats for
+    more information.
    
+
+
    
 
    
 
    
 
    Available Languages:  en  |
diff --git a/docs/manual/mod/mod_authn_dbd.html.fr b/docs/manual/mod/mod_authn_dbd.html.fr
index e4a127f927..7274e6d071 100644
--- a/docs/manual/mod/mod_authn_dbd.html.fr
+++ b/docs/manual/mod/mod_authn_dbd.html.fr
@@ -48,18 +48,18 @@ SQL
    
     
 
    
-
-
-
-
-
-
    Description:Requête SQL servant à vérifier le mot de passe d'un
-utilisateur
    Syntaxe:AuthDBDUserPWQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authn_dbd
    
-    
    La directive AuthDBDUserPWQuery permet de
-    spécifier une requête servant à vérifier le mot de passe d'un
-    utilisateur donné. L'identifiant utilisateur sera transmis comme
-    paramètre sous forme d'une seule chaîne de caractères lorsque la
-    requête sera exécutée. Cet identifiant est référencé dans la requête
-    en utilisant le spécificateur de format %s.
    
-    
    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
    
-
-    
    La première colonne du premier enregistrement renvoyé par la
-    requête se présentera sous la forme d'une chaîne de caractères
-    contenant le mot de passe chiffré. Les enregistrements suivants sont
-    ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur ne
-    sera pas authentifié par mod_authn_dbd.
    
-    
    Si httpd a été compilé avec la version 1.3.0 ou supérieure de
-    l'APR, toute valeur de colonne supplémentaire
-    du premier enregistrement renvoyé par la requête sera stockée dans
-    une variable d'environnement dont le nom aura la forme
-    AUTHENTICATE_valeur-colonne.
-    
    
-    
    Le format du mot de passe chiffré dépend du frontal
-    d'authentification utilisé (par exemple
-    mod_auth_basic ou
-    mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour
-    plus de détails.
    
-
-
    
-
    top
    
-
    Directive AuthDBDUserRealmQuery
    
-
-
-
-
-
-
-
    Description:Requête SQL servant à vérifier une empreinte de mot de
-passe pour un utilisateur et un identifiant d'authentification.
-
    Syntaxe:AuthDBDUserRealmQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authn_dbd
    
-    
    La directive AuthDBDUserRealmQuery spécifie
-    une requête SQL servant à vérifier une empreinte de mot
-    de passe pour un utilisateur et un identifiant d'authentification
-    donnés au cours d'un processus d'authentification digest. Les
-    identifiants de l'utilisateur et de l'authentification
-    sont passés dans cet ordre comme paramètres à l'exécution de la
-    requête. Ils sont référencés dans la chaîne de la requête en
-    utilisant des spécificateurs de format %s.
    
-    
    AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
    
-
-    
    La première colonne du premier enregistrement renvoyé par la
-    requête se présentera sous la forme d'une chaîne de caractères
-    contenant le mot de passe chiffré. Les enregistrements suivants
-    seront ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur
-    ne sera pas authentifié par mod_authn_dbd.
    
-    
    Si httpd a été compilé avec une version 1.3.0 ou supérieure de
-    l'APR, toute valeur de colonne supplémentaire
-    du premier enregistrement renvoyé par la requête sera stockée dans
-    une variable d'environnement avec un nom de la forme
-    AUTHENTICATE_COLONNE.
-    
    
-    
    Le format du mot de passe chiffré dépend du frontal
-    d'authentification utilisé (par exemple
-    mod_auth_basic ou
-    mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour
-    plus de détails.
    
-
-
    
-
    top
    
 
    
 
    Performances et mise en cache
    
 
@@ -233,6 +158,81 @@ configuration n
   mod_dbd pour plus d'informations à propos de la
   sécurité dans ce domaine.
    
 
    
+
    top
    
+
    Directive AuthDBDUserPWQuery
    
+
+
+
+
+
+
+
    Description:Requête SQL servant à vérifier le mot de passe d'un
+utilisateur
    Syntaxe:AuthDBDUserPWQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authn_dbd
    
+    
    La directive AuthDBDUserPWQuery permet de
+    spécifier une requête servant à vérifier le mot de passe d'un
+    utilisateur donné. L'identifiant utilisateur sera transmis comme
+    paramètre sous forme d'une seule chaîne de caractères lorsque la
+    requête sera exécutée. Cet identifiant est référencé dans la requête
+    en utilisant le spécificateur de format %s.
    
+    
    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
    
+
+    
    La première colonne du premier enregistrement renvoyé par la
+    requête se présentera sous la forme d'une chaîne de caractères
+    contenant le mot de passe chiffré. Les enregistrements suivants sont
+    ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur ne
+    sera pas authentifié par mod_authn_dbd.
    
+    
    Si httpd a été compilé avec la version 1.3.0 ou supérieure de
+    l'APR, toute valeur de colonne supplémentaire
+    du premier enregistrement renvoyé par la requête sera stockée dans
+    une variable d'environnement dont le nom aura la forme
+    AUTHENTICATE_valeur-colonne.
+    
    
+    
    Le format du mot de passe chiffré dépend du frontal
+    d'authentification utilisé (par exemple
+    mod_auth_basic ou
+    mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour
+    plus de détails.
    
+
+
    
+
    top
    
+
    Directive AuthDBDUserRealmQuery
    
+
+
+
+
+
+
+
    Description:Requête SQL servant à vérifier une empreinte de mot de
+passe pour un utilisateur et un identifiant d'authentification.
+
    Syntaxe:AuthDBDUserRealmQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authn_dbd
    
+    
    La directive AuthDBDUserRealmQuery spécifie
+    une requête SQL servant à vérifier une empreinte de mot
+    de passe pour un utilisateur et un identifiant d'authentification
+    donnés au cours d'un processus d'authentification digest. Les
+    identifiants de l'utilisateur et de l'authentification
+    sont passés dans cet ordre comme paramètres à l'exécution de la
+    requête. Ils sont référencés dans la chaîne de la requête en
+    utilisant des spécificateurs de format %s.
    
+    
    AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
    
+
+    
    La première colonne du premier enregistrement renvoyé par la
+    requête se présentera sous la forme d'une chaîne de caractères
+    contenant le mot de passe chiffré. Les enregistrements suivants
+    seront ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur
+    ne sera pas authentifié par mod_authn_dbd.
    
+    
    Si httpd a été compilé avec une version 1.3.0 ou supérieure de
+    l'APR, toute valeur de colonne supplémentaire
+    du premier enregistrement renvoyé par la requête sera stockée dans
+    une variable d'environnement avec un nom de la forme
+    AUTHENTICATE_COLONNE.
+    
    
+    
    Le format du mot de passe chiffré dépend du frontal
+    d'authentification utilisé (par exemple
+    mod_auth_basic ou
+    mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour
+    plus de détails.
    
+
+
    
 
    
 
    
 
    Langues Disponibles:  en  |
diff --git a/docs/manual/mod/mod_authn_dbd.xml b/docs/manual/mod/mod_authn_dbd.xml
index 9eda1bf208..2ee2e9fa6d 100644
--- a/docs/manual/mod/mod_authn_dbd.xml
+++ b/docs/manual/mod/mod_authn_dbd.xml
@@ -82,7 +82,7 @@ DBDKeep 8
 DBDMax  20
 DBDExptime 300
 
-<Directory /usr/www/myhost/private>
+<Directory "/usr/www/myhost/private">
   # mod_authn_core and mod_auth_basic configuration
   # for mod_authn_dbd
   AuthType Basic
diff --git a/docs/manual/mod/mod_authn_dbm.html.en b/docs/manual/mod/mod_authn_dbm.html.en
index 66cf82cbc7..59671c91cf 100644
--- a/docs/manual/mod/mod_authn_dbm.html.en
+++ b/docs/manual/mod/mod_authn_dbm.html.en
@@ -66,6 +66,7 @@
 
  • htdbm
    • 
 
  • Password Formats
    • 
 
    
+
 
    top
    
 
    AuthDBMType Directive
    
 
@@ -137,7 +138,6 @@ passwords for authenticationhtdbm.
    
-
 
    
 
    Available Languages:  en  |
diff --git a/docs/manual/mod/mod_authn_dbm.html.fr b/docs/manual/mod/mod_authn_dbm.html.fr
index da49cd1670..fba73c24d2 100644
--- a/docs/manual/mod/mod_authn_dbm.html.fr
+++ b/docs/manual/mod/mod_authn_dbm.html.fr
@@ -66,6 +66,7 @@ passe
 
  • htpasswd
    • 
 
  • htdbm
    • 
 
    
+
 
    top
    Directive AuthDBMType
    
 
    
     
 
 
 
 
    
@@ -144,7 +145,6 @@ des utilisateurs et de leurs mots de passe
     utilitaire permettant de maintenir les fichiers DBM.
    
-
 
    
 
    Langues Disponibles:  en  |
diff --git a/docs/manual/mod/mod_authn_dbm.html.ja.utf8 b/docs/manual/mod/mod_authn_dbm.html.ja.utf8
index 797ea0ced7..1f2892ab15 100644
--- a/docs/manual/mod/mod_authn_dbm.html.ja.utf8
+++ b/docs/manual/mod/mod_authn_dbm.html.ja.utf8
@@ -68,6 +68,7 @@
   AuthDigestProvider
 
 
    
+
 
    top
    AuthDBMType ディレクティブ
    
 
    
 
 
 
 
    
@@ -131,7 +132,6 @@
     更新したりすることができます。
    
-
 
    
 
    翻訳済み言語:  en  |
diff --git a/docs/manual/mod/mod_authn_dbm.html.ko.euc-kr b/docs/manual/mod/mod_authn_dbm.html.ko.euc-kr
index 3b7cbd0492..82b3e74b4e 100644
--- a/docs/manual/mod/mod_authn_dbm.html.ko.euc-kr
+++ b/docs/manual/mod/mod_authn_dbm.html.ko.euc-kr
@@ -64,6 +64,7 @@
   AuthDigestProvider
 
 
    
+
 
    top
    AuthDBMType Áö½Ã¾î
    
 
    
 
 
 
 
    
@@ -123,7 +124,6 @@
     DBMÇü½Ä ¾ÏÈ£ÆÄÀÏÀ» ¸¸µé°í ¼öÁ¤ÇÑ´Ù.
    
-
 
    
 
    °¡´ÉÇÑ ¾ð¾î:  en  |
diff --git a/docs/manual/mod/mod_authn_file.html.en b/docs/manual/mod/mod_authn_file.html.en
index e9f8a77755..b221c885ba 100644
--- a/docs/manual/mod/mod_authn_file.html.en
+++ b/docs/manual/mod/mod_authn_file.html.en
@@ -62,6 +62,7 @@
 
  • htdigest
    • 
 
  • Password Formats
    • 
 
    
+
 
    top
    AuthUserFile Directive
    
 
    
 
 
 
 
    
@@ -127,7 +128,6 @@ passwords for authentication
-
 
    
 
    Available Languages:  en  |
diff --git a/docs/manual/mod/mod_authn_file.html.fr b/docs/manual/mod/mod_authn_file.html.fr
index 91dd1d299f..2eba3a8034 100644
--- a/docs/manual/mod/mod_authn_file.html.fr
+++ b/docs/manual/mod/mod_authn_file.html.fr
@@ -63,6 +63,7 @@ texte
 
  • Formats de mots de
 passe
    • 
 
    
+
 
    top
    Directive AuthUserFile
    
 
    
     
 
 
 
 
    
@@ -135,7 +136,6 @@ passe
-
 
    
 
    Langues Disponibles:  en  |
diff --git a/docs/manual/mod/mod_authn_file.html.ja.utf8 b/docs/manual/mod/mod_authn_file.html.ja.utf8
index 71dde525f8..30070d0155 100644
--- a/docs/manual/mod/mod_authn_file.html.ja.utf8
+++ b/docs/manual/mod/mod_authn_file.html.ja.utf8
@@ -67,6 +67,7 @@
 
  • htpasswd
    • 
 
  • htdigest
    • 
 
    
+
 
    top
    AuthUserFile ディレクティブ
    
 
    
     
 
 
 
 
    
@@ -138,7 +139,6 @@
     
-
 
    
 
    翻訳済み言語:  en  |
diff --git a/docs/manual/mod/mod_authn_file.html.ko.euc-kr b/docs/manual/mod/mod_authn_file.html.ko.euc-kr
index a0c8410e8c..e4cba5699f 100644
--- a/docs/manual/mod/mod_authn_file.html.ko.euc-kr
+++ b/docs/manual/mod/mod_authn_file.html.ko.euc-kr
@@ -63,6 +63,7 @@
 
  • htpasswd
    • 
 
  • htdigest
    • 
 
    
+
 
    top
    AuthUserFile Áö½Ã¾î
    
 
    
 
 
 
 
    
@@ -121,7 +122,6 @@
     
-
 
    
 
    °¡´ÉÇÑ ¾ð¾î:  en  |
diff --git a/docs/manual/mod/mod_authn_socache.html.en b/docs/manual/mod/mod_authn_socache.html.en
index fb4cd702ce..6a13c31ef0 100644
--- a/docs/manual/mod/mod_authn_socache.html.en
+++ b/docs/manual/mod/mod_authn_socache.html.en
@@ -53,6 +53,61 @@ the load on backends
 
 
    top
    
+
    
+
    Authentication Cacheing
    
+    
    Some users of more heavyweight authentication such as SQL database
+    lookups (mod_authn_dbd) have reported it putting an
+    unacceptable load on their authentication provider.  A typical case
+    in point is where an HTML page contains hundreds of objects
+    (images, scripts, stylesheets, media, etc), and a request to the page
+    generates hundreds of effectively-immediate requests for authenticated
+    additional contents.
    
+    
    mod_authn_socache provides a solution to this problem by
+    maintaining a cache of authentication credentials.
    
+
    top
    
+
    
+
    Usage
    
+    
    The authentication cache should be used where authentication
+    lookups impose a significant load on the server, or a backend or
+    network.  Authentication by file (mod_authn_file)
+    or dbm (mod_authn_dbm) 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).
+    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, mod_authnz_ldap manages its own cache, so only
+    mod_authn_dbd will usually benefit from this cache.
    
+    
    The basic rules to cache for a provider are:
    
+    
    1. Include the provider you're cacheing for in an
+            AuthnCacheProvideFor directive.
      2. 
+        
    2. List socache ahead of the provider you're
+            cacheing for in your AuthBasicProvider or AuthDigestProvider directive.
      3. 
+    
    
+    
    A simple usage example to accelerate mod_authn_dbd
+    using dbm as a cache engine:
    
+    
    #AuthnCacheSOCache is optional.  If specified, it is server-wide
+AuthnCacheSOCache dbm
+<Directory "/usr/www/myhost/private">
+    AuthType Basic
+    AuthName "Cached Authentication Example"
+    AuthBasicProvider socache dbd
+    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
+    AuthnCacheProvideFor dbd
+    Require valid-user
+    #Optional
+    AuthnCacheContext dbd-authn-example
+</Directory>
    
+
+
    top
    
+
    
+
    Cacheing with custom modules
    
+    
    Module developers should note that their modules must be enabled
+    for cacheing with mod_authn_socache.  A single optional API function
+    ap_authn_cache_store is provided to cache credentials
+    a provider has just looked up or generated.  Usage examples are
+    available in r957072, in which three authn providers are enabled for cacheing.
    
+
    
+
    top
    AuthnCacheContext Directive
    
 
    
 
 
 
 
 
    
@@ -167,61 +222,6 @@ Apache HTTP Server 2.4.7 and later
     your timeout.
    
-
    top
    
-
    
-
    Authentication Cacheing
    
-    
    Some users of more heavyweight authentication such as SQL database
-    lookups (mod_authn_dbd) have reported it putting an
-    unacceptable load on their authentication provider.  A typical case
-    in point is where an HTML page contains hundreds of objects
-    (images, scripts, stylesheets, media, etc), and a request to the page
-    generates hundreds of effectively-immediate requests for authenticated
-    additional contents.
    
-    
    mod_authn_socache provides a solution to this problem by
-    maintaining a cache of authentication credentials.
    
-
    top
    
-
    
-
    Usage
    
-    
    The authentication cache should be used where authentication
-    lookups impose a significant load on the server, or a backend or
-    network.  Authentication by file (mod_authn_file)
-    or dbm (mod_authn_dbm) 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).
-    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, mod_authnz_ldap manages its own cache, so only
-    mod_authn_dbd will usually benefit from this cache.
    
-    
    The basic rules to cache for a provider are:
    
-    
    1. Include the provider you're cacheing for in an
-            AuthnCacheProvideFor directive.
      2. 
-        
    2. List socache ahead of the provider you're
-            cacheing for in your AuthBasicProvider or AuthDigestProvider directive.
      3. 
-    
    
-    
    A simple usage example to accelerate mod_authn_dbd
-    using dbm as a cache engine:
    
-    
    #AuthnCacheSOCache is optional.  If specified, it is server-wide
-AuthnCacheSOCache dbm
-<Directory /usr/www/myhost/private>
-    AuthType Basic
-    AuthName "Cached Authentication Example"
-    AuthBasicProvider socache dbd
-    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
-    AuthnCacheProvideFor dbd
-    Require valid-user
-    #Optional
-    AuthnCacheContext dbd-authn-example
-</Directory>
    
-
-
    top
    
-
    
-
    Cacheing with custom modules
    
-    
    Module developers should note that their modules must be enabled
-    for cacheing with mod_authn_socache.  A single optional API function
-    ap_authn_cache_store is provided to cache credentials
-    a provider has just looked up or generated.  Usage examples are
-    available in r957072, in which three authn providers are enabled for cacheing.
    
-
    
 
    Available Languages:  en  |
diff --git a/docs/manual/mod/mod_authn_socache.html.fr b/docs/manual/mod/mod_authn_socache.html.fr
index 8368987404..768b64c341 100644
--- a/docs/manual/mod/mod_authn_socache.html.fr
+++ b/docs/manual/mod/mod_authn_socache.html.fr
@@ -38,7 +38,12 @@ la charge des serveurs d'arri
     
    Maintient un cache des données d'authentification pour limiter
     les sollicitations du serveur d'arrière-plan.
    
 
    
-
+
    top
    
+
    
+
    Mise en cache des données d'authentification
    
+    
    Certains utilisateurs qui mettent oeuvre une authentification
+    lourde s'appuyant par exemple sur des requêtes SQL
+    (mod_authn_dbd) ont signalé une charge induite
+    inacceptable sur leur fournisseur d'authentification. Cela se
+    produit typiquement dans le cas où une page HTML contient des
+    centaines d'objets (images, scripts, pages de styles, media,
+    etc...), et où une requête pour cette page génère des centaines de
+    sous-requêtes à effet immédiat pour des contenus supplémentaires
+    authentifiés.
    
+    
    Pour résoudre ce problème, mod_authn_socache fournit une solution
+    qui permet de maintenir un cache des données d'authentification.
    
+
    top
    
+
    
+
    Utilisation
    
+    
    Le cache d'authentification doit être utilisé lorsque les
+    requêtes d'authentification induisent une charge significative sur le
+    serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache
+    n'apportera probablement aucune amélioration dans le cas d'une
+    authentification à base de fichier (mod_authn_file)
+    ou de base de données dbm (mod_authn_dbm) car ces
+    méthodes sont de par leur conception rapides et légères (la mise en
+    cache peut cependant s'avérer utile dans le cas où le fichier est
+    situé sur un montage réseau). Les fournisseurs d'authentification
+    basés sur SQL ou LDAP ont plus de chances de tirer parti de cette
+    mise en cache, en particulier lorsqu'un problème de performances est
+    détecté. mod_authnz_ldap gérant son propre cache,
+    seul mod_authn_dbd est concerné par notre sujet.
    
+    
    Les principales règles à appliquer pour la mise en cache sont :
    
+    
    1. Inclure le fournisseur pour lequel vous voulez effectuer une
+    mise en cache dans une directive
+    AuthnCacheProvideFor.
      2. 
+        
    2. Mettre socache avant le fournisseur pour lequel
+	vous voulez effectuer une mise en cache dans votre directive
+	AuthBasicProvider
+	ou AuthDigestProvider.
      3. 
+    
    
+    
    Voici un exemple simple permettant d'accélérer
+    mod_authn_dbd et utilisant dbm comme moteur de la
+    mise en cache :
    
+    
        #AuthnCacheSOCache est optionnel. S'il est défini, il l'est pour
+    #l'ensemble du serveur
+AuthnCacheSOCache dbm
+<Directory /usr/www/myhost/private>
+    AuthType Basic
+    AuthName "Cached Authentication Example"
+    AuthBasicProvider socache dbd
+    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
+    AuthnCacheProvideFor dbd
+    Require valid-user
+    #Optionnel
+    AuthnCacheContext dbd-authn-example
+</Directory>
    
+
+
    top
    
+
    
+
    La mise en cache avec les modules tiers
    
+    
    Les développeurs de modules doivent savoir que la mise en cache
+    avec mod_authn_socache doit être activée dans leurs modules. La
+    fonction de l'API ap_authn_cache_store permet de
+    mettre en cache les données d'authentification qu'un fournisseur
+    vient de rechercher ou de générer. Vous trouverez des exemples
+    d'utilisation à r957072, où trois fournisseurs authn sont activés pour la mise
+    en cache.
    
+
    top
    Directive AuthnCacheContext
    
 
    
 
    Description:Specify a context string for use in the cache key
    
 
 
 
 
 
 
    
@@ -184,73 +251,6 @@ utiliser
     définissez la durée de vie.
    
-
    top
    
-
    
-
    Mise en cache des données d'authentification
    
-    
    Certains utilisateurs qui mettent oeuvre une authentification
-    lourde s'appuyant par exemple sur des requêtes SQL
-    (mod_authn_dbd) ont signalé une charge induite
-    inacceptable sur leur fournisseur d'authentification. Cela se
-    produit typiquement dans le cas où une page HTML contient des
-    centaines d'objets (images, scripts, pages de styles, media,
-    etc...), et où une requête pour cette page génère des centaines de
-    sous-requêtes à effet immédiat pour des contenus supplémentaires
-    authentifiés.
    
-    
    Pour résoudre ce problème, mod_authn_socache fournit une solution
-    qui permet de maintenir un cache des données d'authentification.
    
-
    top
    
-
    
-
    Utilisation
    
-    
    Le cache d'authentification doit être utilisé lorsque les
-    requêtes d'authentification induisent une charge significative sur le
-    serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache
-    n'apportera probablement aucune amélioration dans le cas d'une
-    authentification à base de fichier (mod_authn_file)
-    ou de base de données dbm (mod_authn_dbm) car ces
-    méthodes sont de par leur conception rapides et légères (la mise en
-    cache peut cependant s'avérer utile dans le cas où le fichier est
-    situé sur un montage réseau). Les fournisseurs d'authentification
-    basés sur SQL ou LDAP ont plus de chances de tirer parti de cette
-    mise en cache, en particulier lorsqu'un problème de performances est
-    détecté. mod_authnz_ldap gérant son propre cache,
-    seul mod_authn_dbd est concerné par notre sujet.
    
-    
    Les principales règles à appliquer pour la mise en cache sont :
    
-    
    1. Inclure le fournisseur pour lequel vous voulez effectuer une
-    mise en cache dans une directive
-    AuthnCacheProvideFor.
      2. 
-        
    2. Mettre socache avant le fournisseur pour lequel
-	vous voulez effectuer une mise en cache dans votre directive
-	AuthBasicProvider
-	ou AuthDigestProvider.
      3. 
-    
    
-    
    Voici un exemple simple permettant d'accélérer
-    mod_authn_dbd et utilisant dbm comme moteur de la
-    mise en cache :
    
-    
        #AuthnCacheSOCache est optionnel. S'il est défini, il l'est pour
-    #l'ensemble du serveur
-AuthnCacheSOCache dbm
-<Directory /usr/www/myhost/private>
-    AuthType Basic
-    AuthName "Cached Authentication Example"
-    AuthBasicProvider socache dbd
-    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
-    AuthnCacheProvideFor dbd
-    Require valid-user
-    #Optionnel
-    AuthnCacheContext dbd-authn-example
-</Directory>
    
-
-
    top
    
-
    
-
    La mise en cache avec les modules tiers
    
-    
    Les développeurs de modules doivent savoir que la mise en cache
-    avec mod_authn_socache doit être activée dans leurs modules. La
-    fonction de l'API ap_authn_cache_store permet de
-    mettre en cache les données d'authentification qu'un fournisseur
-    vient de rechercher ou de générer. Vous trouverez des exemples
-    d'utilisation à r957072, où trois fournisseurs authn sont activés pour la mise
-    en cache.
    
-
    
 
    Langues Disponibles:  en  |
diff --git a/docs/manual/mod/mod_authn_socache.xml b/docs/manual/mod/mod_authn_socache.xml
index b5d3254f72..e371841388 100644
--- a/docs/manual/mod/mod_authn_socache.xml
+++ b/docs/manual/mod/mod_authn_socache.xml
@@ -72,7 +72,7 @@ the load on backends
     
 #AuthnCacheSOCache is optional.  If specified, it is server-wide
 AuthnCacheSOCache dbm
-<Directory /usr/www/myhost/private>
+<Directory "/usr/www/myhost/private">
     AuthType Basic
     AuthName "Cached Authentication Example"
     AuthBasicProvider socache dbd
diff --git a/docs/manual/mod/mod_authnz_fcgi.html.en b/docs/manual/mod/mod_authnz_fcgi.html.en
index 55e3a674ff..398d8129b8 100644
--- a/docs/manual/mod/mod_authnz_fcgi.html.en
+++ b/docs/manual/mod/mod_authnz_fcgi.html.en
@@ -65,127 +65,6 @@ and Access Control
 
  • mod_proxy_fcgi
    • 
 
    top
    
-
    AuthnzFcgiCheckAuthnProvider Directive
    
-
    
 
 
 
 
 
    
-
-
-
-
-
-
-
    Description:Enables a FastCGI application to handle the check_authn
-authentication hook.
    Syntax:AuthnzFcgiCheckAuthnProvider provider-name|None
-option ...
    Default:none
    Context:directory
    Status:Extension
    Module:mod_authnz_fcgi
    
-    
    This directive is used to enable a FastCGI authorizer to
-    handle a specific processing phase of authentication or
-    authorization.
    
-
-    
    Some capabilities of FastCGI authorizers require enablement
-    using this directive instead of
-    AuthBasicProvider:
    
-
-    
      
-      
    • Non-Basic authentication; generally, determining the user
-      id of the client and returning it from the authorizer; see the
-      UserExpr option below
      • 
-      
    • Selecting a custom response code; for a non-200 response
-      from the authorizer, the code from the authorizer will be the
-      status of the response
      • 
-      
    • Setting the body of a non-200 response; if the authorizer
-      provides a response body with a non-200 response, that body
-      will be returned to the client; up to 8192 bytes of text are
-      supported
      • 
-    
    
-
-    
    
-      
    provider-name
    
-      
    This is the name of a provider defined with 
-      AuthnzFcgiDefineProvider.
    
-
-      
    None
    
-      
    Specify None to disable a provider enabled
-      with this directive in an outer scope, such as in a parent
-      directory.
    
-
-      
    option
    
-      
    The following options are supported:
-      
-      
    
-         
    Authoritative On|Off (default On)
    
-         
    This controls whether or not other modules are allowed
-         to run when this module has a FastCGI authorizer configured
-         and it fails the request.
    
-
-         
    DefaultUser userid
    
-         
    When the authorizer returns success and UserExpr
-         is configured and evaluates to an empty string (e.g., authorizer
-         didn't return a variable), this value will be used as the user
-         id.  This is typically used when the authorizer has a concept of
-         guest, or unauthenticated, users and guest users are mapped to
-         some specific user id for logging and other purposes.
    
-
-         
    RequireBasicAuth On|Off (default Off)
    
-         
    This controls whether or not Basic auth is required
-         before passing the request to the authorizer.  If required,
-         the authorizer won't be invoked without a user id and
-         password; 401 will be returned for a request without that.
    
-
-         
    UserExpr expr (no default)
    
-         
    When Basic authentication isn't provided by the client
-         and the authorizer determines the user, this expression,
-         evaluated after calling the authorizer, determines the
-         user.  The expression follows 
-         ap_expr syntax and must resolve to a string.  A typical
-         use is to reference a Variable-XXX 
-         setting returned by the authorizer using an option like
-         UserExpr "%{reqenv:XXX}".  If
-         this option is specified and the user id can't be retrieved
-         using the expression after a successful authentication, the
-         request will be rejected with a 500 error.
    
-
-       
    
-      
    
-     
    
-
-
    
-
    top
    
-
    AuthnzFcgiDefineProvider Directive
    
-
-
-
-
-
-
-
-
    Description:Defines a FastCGI application as a provider for
-authentication and/or authorization
    Syntax:AuthnzFcgiDefineProvider type provider-name
-backend-address
    Default:none
    Context:server config
    Status:Extension
    Module:mod_authnz_fcgi
    
-    
    This directive is used to define a FastCGI application as
-    a provider for a particular phase of authentication or
-    authorization.
    
-
-    
    
-      
    type
    
-      
    This must be set to authn for authentication,
-      authz for authorization, or authnz for
-      a generic FastCGI authorizer which performs both checks.
    
-
-      
    provider-name
    
-      
    This is used to assign a name to the provider which is
-      used in other directives such as 
-      AuthBasicProvider
-      and 
-      Require.
    
-
-      
    backend-address
    
-      
    This specifies the address of the application, in the form
-      fcgi://hostname:port/.  The application process(es)
-      must be managed independently, such as with
-      fcgistarter.
    
-    
    
-
-
    
-
    top
    
 
    
 
    Invocation modes
    
 
@@ -246,7 +125,7 @@ while (FCGI::accept >= 0) {
 
       Example configuration:
 
    AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10102/
-<Location /protected/>
+<Location "/protected/">
   AuthType Basic
   AuthName "Restricted"
   AuthBasicProvider FooAuthn
@@ -287,7 +166,7 @@ while (FCGI::accept >= 0) {
 
       Example configuration:
 
    AuthnzFcgiDefineProvider authz FooAuthz fcgi://localhost:10103/
-<Location /protected/>
+<Location "/protected/">
   AuthType ...
   AuthName ...
   AuthBasicProvider ...
@@ -338,7 +217,7 @@ while (FCGI::accept >= 0) {
 
       Example configuration:
 
    AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/
-<Location /protected/>
+<Location "/protected/">
   AuthType Basic
   AuthName "Restricted"
   AuthBasicProvider FooAuthnz
@@ -386,7 +265,7 @@ while (FCGI::accept >= 0) {
 
       Example configuration:
 
    AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10103/
-<Location /protected/>
+<Location "/protected/">
   AuthType ...
   AuthName ...
   AuthnzFcgiCheckAuthnProvider FooAuthn \
@@ -527,6 +406,127 @@ Require FooAuthnz
    
 
    LogLevel info authnz_fcgi:trace8
    
 
 
+
    
+
    top
    
+
    AuthnzFcgiCheckAuthnProvider Directive
    
+
+
+
+
+
+
+
+
    Description:Enables a FastCGI application to handle the check_authn
+authentication hook.
    Syntax:AuthnzFcgiCheckAuthnProvider provider-name|None
+option ...
    Default:none
    Context:directory
    Status:Extension
    Module:mod_authnz_fcgi
    
+    
    This directive is used to enable a FastCGI authorizer to
+    handle a specific processing phase of authentication or
+    authorization.
    
+
+    
    Some capabilities of FastCGI authorizers require enablement
+    using this directive instead of
+    AuthBasicProvider:
    
+
+    
      
+      
    • Non-Basic authentication; generally, determining the user
+      id of the client and returning it from the authorizer; see the
+      UserExpr option below
      • 
+      
    • Selecting a custom response code; for a non-200 response
+      from the authorizer, the code from the authorizer will be the
+      status of the response
      • 
+      
    • Setting the body of a non-200 response; if the authorizer
+      provides a response body with a non-200 response, that body
+      will be returned to the client; up to 8192 bytes of text are
+      supported
      • 
+    
    
+
+    
    
+      
    provider-name
    
+      
    This is the name of a provider defined with 
+      AuthnzFcgiDefineProvider.
    
+
+      
    None
    
+      
    Specify None to disable a provider enabled
+      with this directive in an outer scope, such as in a parent
+      directory.
    
+
+      
    option
    
+      
    The following options are supported:
+      
+      
    
+         
    Authoritative On|Off (default On)
    
+         
    This controls whether or not other modules are allowed
+         to run when this module has a FastCGI authorizer configured
+         and it fails the request.
    
+
+         
    DefaultUser userid
    
+         
    When the authorizer returns success and UserExpr
+         is configured and evaluates to an empty string (e.g., authorizer
+         didn't return a variable), this value will be used as the user
+         id.  This is typically used when the authorizer has a concept of
+         guest, or unauthenticated, users and guest users are mapped to
+         some specific user id for logging and other purposes.
    
+
+         
    RequireBasicAuth On|Off (default Off)
    
+         
    This controls whether or not Basic auth is required
+         before passing the request to the authorizer.  If required,
+         the authorizer won't be invoked without a user id and
+         password; 401 will be returned for a request without that.
    
+
+         
    UserExpr expr (no default)
    
+         
    When Basic authentication isn't provided by the client
+         and the authorizer determines the user, this expression,
+         evaluated after calling the authorizer, determines the
+         user.  The expression follows 
+         ap_expr syntax and must resolve to a string.  A typical
+         use is to reference a Variable-XXX 
+         setting returned by the authorizer using an option like
+         UserExpr "%{reqenv:XXX}".  If
+         this option is specified and the user id can't be retrieved
+         using the expression after a successful authentication, the
+         request will be rejected with a 500 error.
    
+
+       
    
+      
    
+     
    
+
+
    
+
    top
    
+
    AuthnzFcgiDefineProvider Directive
    
+
+
+
+
+
+
+
+
    Description:Defines a FastCGI application as a provider for
+authentication and/or authorization
    Syntax:AuthnzFcgiDefineProvider type provider-name
+backend-address
    Default:none
    Context:server config
    Status:Extension
    Module:mod_authnz_fcgi
    
+    
    This directive is used to define a FastCGI application as
+    a provider for a particular phase of authentication or
+    authorization.
    
+
+    
    
+      
    type
    
+      
    This must be set to authn for authentication,
+      authz for authorization, or authnz for
+      a generic FastCGI authorizer which performs both checks.
    
+
+      
    provider-name
    
+      
    This is used to assign a name to the provider which is
+      used in other directives such as 
+      AuthBasicProvider
+      and 
+      Require.
    
+
+      
    backend-address
    
+      
    This specifies the address of the application, in the form
+      fcgi://hostname:port/.  The application process(es)
+      must be managed independently, such as with
+      fcgistarter.
    
+    
    
+
 
    
 
 
    
diff --git a/docs/manual/mod/mod_authnz_fcgi.xml b/docs/manual/mod/mod_authnz_fcgi.xml
index 5cefa686e9..8430e6feb7 100644
--- a/docs/manual/mod/mod_authnz_fcgi.xml
+++ b/docs/manual/mod/mod_authnz_fcgi.xml
@@ -110,7 +110,7 @@ while (FCGI::accept >= 0) {
       Example configuration:
 
 AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10102/
-<Location /protected/>
+<Location "/protected/">
   AuthType Basic
   AuthName "Restricted"
   AuthBasicProvider FooAuthn
@@ -153,7 +153,7 @@ while (FCGI::accept >= 0) {
       Example configuration:
 
 AuthnzFcgiDefineProvider authz FooAuthz fcgi://localhost:10103/
-<Location /protected/>
+<Location "/protected/">
   AuthType ...
   AuthName ...
   AuthBasicProvider ...
@@ -206,7 +206,7 @@ while (FCGI::accept >= 0) {
       Example configuration:
 
 AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/
-<Location /protected/>
+<Location "/protected/">
   AuthType Basic
   AuthName "Restricted"
   AuthBasicProvider FooAuthnz
@@ -257,7 +257,7 @@ while (FCGI::accept >= 0) {
       Example configuration:
 
 AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10103/
-<Location /protected/>
+<Location "/protected/">
   AuthType ...
   AuthName ...
   AuthnzFcgiCheckAuthnProvider FooAuthn \
diff --git a/docs/manual/mod/mod_authnz_ldap.html.en b/docs/manual/mod/mod_authnz_ldap.html.en
index a371fd83ee..465ec9b022 100644
--- a/docs/manual/mod/mod_authnz_ldap.html.en
+++ b/docs/manual/mod/mod_authnz_ldap.html.en
@@ -101,620 +101,6 @@ for HTTP Basic authentication.
    
 
 
 
    
-
-
-
-
-
-
-
-
-
    Description:Specifies the prefix for environment variables set during
-authorization
    Syntax:AuthLDAPAuthorizePrefix prefix
    Default:AuthLDAPAuthorizePrefix AUTHORIZE_
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
-    
    This directive allows you to override the prefix used for environment
-    variables set during LDAP authorization.  If AUTHENTICATE_ is
-    specified, consumers of these environment variables see the same information
-    whether LDAP has performed authentication, authorization, or both.
    
-
-    
    Note
    
-    No authorization variables are set when a user is authorized on the basis of
-    Require valid-user.
-    
    
-
-
    
-
    top
    
-
    AuthLDAPBindAuthoritative Directive
    
-
-
-
-
-
-
-
-
-
    Description:Determines if other authentication providers are used when a user can be mapped to a DN but the server cannot successfully bind with the user's credentials.
    Syntax:AuthLDAPBindAuthoritativeoff|on
    Default:AuthLDAPBindAuthoritative on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    By default, subsequent authentication providers are only queried if a
-    user cannot be mapped to a DN, but not if the user can be mapped to a DN and their
-    password cannot be verified with an LDAP bind.
-    If AuthLDAPBindAuthoritative
-    is set to off, other configured authentication modules will have
-    a chance to validate the user if the LDAP bind (with the current user's credentials)
-    fails for any reason.
    
-    
     This allows users present in both LDAP and
-    AuthUserFile to authenticate
-    when the LDAP server is available but the user's account is locked or password
-    is otherwise unusable.
    
-
-
    See also
    
-
-
    
-
    top
    
-
    AuthLDAPBindDN Directive
    
-
-
-
-
-
-
-
-
    Description:Optional DN to use in binding to the LDAP server
    Syntax:AuthLDAPBindDN distinguished-name
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    An optional DN used to bind to the server when searching for
-    entries. If not provided, mod_authnz_ldap will use
-    an anonymous bind.
    
-
-
    
-
    top
    
-
    AuthLDAPBindPassword Directive
    
-
-
-
-
-
-
-
-
-
    Description:Password used in conjuction with the bind DN
    Syntax:AuthLDAPBindPassword password
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:exec: was added in 2.4.5.
    
-    
    A bind password to use in conjunction with the bind DN. Note
-    that the bind password is probably sensitive data, and should be
-    properly protected. You should only use the AuthLDAPBindDN and AuthLDAPBindPassword if you
-    absolutely need them to search the directory.
    
-
-    
    If the value begins with exec: the resulting command will be
-    executed and the first line returned to standard output by the
-    program will be used as the password.
    
-
    #Password used as-is
-AuthLDAPBindPassword secret
-
-#Run /path/to/program to get my password
-AuthLDAPBindPassword exec:/path/to/program
-
-#Run /path/to/otherProgram and provide arguments
-AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    
-
-
-
-
    
-
    top
    
-
    AuthLDAPCharsetConfig Directive
    
-
-
-
-
-
-
-
    Description:Language to charset conversion configuration file
    Syntax:AuthLDAPCharsetConfig file-path
    Context:server config
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    The AuthLDAPCharsetConfig directive sets the location
-    of the language to charset conversion configuration file. File-path is relative
-    to the ServerRoot. This file specifies
-    the list of language extensions to character sets.
-    Most administrators use the provided charset.conv
-    file, which associates common language extensions to character sets.
    
-
-    
    The file contains lines in the following format:
    
-
-    
    
-      Language-Extension charset [Language-String] ...
-    
    
-
-    
    The case of the extension does not matter. Blank lines, and lines
-    beginning with a hash character (#) are ignored.
    
-
-
    
-
    top
    
-
    AuthLDAPCompareAsUser Directive
    
-
-
-
-
-
-
-
-
-
-
    Description:Use the authenticated user's credentials to perform authorization comparisons
    Syntax:AuthLDAPCompareAsUser on|off
    Default:AuthLDAPCompareAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
-    
    When set, and mod_authnz_ldap has authenticated the
-    user, LDAP comparisons for authorization use the queried distinguished name (DN)
-    and HTTP basic authentication password of the authenticated user instead of
-    the servers configured credentials.
    
-
-    
     The ldap-attribute, ldap-user, and ldap-group (single-level only)
-    authorization checks use comparisons.
    
-
-    
    This directive only has effect on the comparisons performed during
-    nested group processing when 
-    AuthLDAPSearchAsUser is also enabled.
    
-
-    
     This directive should only be used when your LDAP server doesn't
-        accept anonymous comparisons and you cannot use a dedicated
-        AuthLDAPBindDN.
-    
    
-
-
    See also
    
-
-
    
-
    top
    
-
    AuthLDAPCompareDNOnServer Directive
    
-
-
-
-
-
-
-
-
-
    Description:Use the LDAP server to compare the DNs
    Syntax:AuthLDAPCompareDNOnServer on|off
    Default:AuthLDAPCompareDNOnServer on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    When set, mod_authnz_ldap will use the LDAP
-    server to compare the DNs. This is the only foolproof way to
-    compare DNs.  mod_authnz_ldap will search the
-    directory for the DN specified with the Require dn directive, then,
-    retrieve the DN and compare it with the DN retrieved from the user
-    entry. If this directive is not set,
-    mod_authnz_ldap simply does a string comparison. It
-    is possible to get false negatives with this approach, but it is
-    much faster. Note the mod_ldap cache can speed up
-    DN comparison in most situations.
    
-
-
    
-
    top
    
-
    AuthLDAPDereferenceAliases Directive
    
-
-
-
-
-
-
-
-
-
    Description:When will the module de-reference aliases
    Syntax:AuthLDAPDereferenceAliases never|searching|finding|always
    Default:AuthLDAPDereferenceAliases always
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    This directive specifies when mod_authnz_ldap will
-    de-reference aliases during LDAP operations. The default is
-    always.
    
-
-
    
-
    top
    
-
    AuthLDAPGroupAttribute Directive
    
-
-
-
-
-
-
-
-
-
    Description:LDAP attributes used to identify the user members of
-groups.
    Syntax:AuthLDAPGroupAttribute attribute
    Default:AuthLDAPGroupAttribute member uniquemember
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    This directive specifies which LDAP attributes are used to
-    check for user members within groups. Multiple attributes can be used
-    by specifying this directive multiple times. If not specified,
-    then mod_authnz_ldap uses the member and
-    uniquemember attributes.
    
-
-
    
-
    top
    
-
    AuthLDAPGroupAttributeIsDN Directive
    
-
-
-
-
-
-
-
-
-
    Description:Use the DN of the client username when checking for
-group membership
    Syntax:AuthLDAPGroupAttributeIsDN on|off
    Default:AuthLDAPGroupAttributeIsDN on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    When set on, this directive says to use the
-    distinguished name of the client username when checking for group
-    membership.  Otherwise, the username will be used. For example,
-    assume that the client sent the username bjenson,
-    which corresponds to the LDAP DN cn=Babs Jenson,
-    o=Example. If this directive is set,
-    mod_authnz_ldap will check if the group has
-    cn=Babs Jenson, o=Example as a member. If this
-    directive is not set, then mod_authnz_ldap will
-    check if the group has bjenson as a member.
    
-
-
    
-
    top
    
-
    AuthLDAPInitialBindAsUser Directive
    
-
-
-
-
-
-
-
-
-
-
    Description:Determines if the server does the initial DN lookup using the basic authentication users'
-own username, instead of anonymously or with hard-coded credentials for the server
    Syntax:AuthLDAPInitialBindAsUser off|on
    Default:AuthLDAPInitialBindAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
-    
    By default, the server either anonymously, or with a dedicated user and
-     password, converts the basic authentication username into an LDAP
-     distinguished name (DN).  This directive forces the server to use the verbatim username
-     and password provided by the incoming user to perform the initial DN
-     search.
    
-
-     
     If the verbatim username can't directly bind, but needs some
-     cosmetic transformation, see 
-     AuthLDAPInitialBindPattern.
    
-
-     
     This directive should only be used when your LDAP server doesn't
-         accept anonymous searches and you cannot use a dedicated
-         AuthLDAPBindDN.
-     
    
-
-     
    Not available with authorization-only
    
-         This directive can only be used if this module authenticates the user, and
-         has no effect when this module is used exclusively for authorization.
-     
    
-
-
    See also
    
-
-
    
-
    top
    
-
    AuthLDAPInitialBindPattern Directive
    
-
-
-
-
-
-
-
-
-
-
    Description:Specifies the transformation of the basic authentication username to be used when binding to the LDAP server
-to perform a DN lookup
    Syntax:AuthLDAPInitialBindPatternregex substitution
    Default:AuthLDAPInitialBindPattern (.*) $1 (remote username used verbatim)
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
-    
    If AuthLDAPInitialBindAsUser is set to
-       ON, the basic authentication username will be transformed according to the
-       regular expression and substituion arguments.
    
-
-    
     The regular expression argument is compared against the current basic authentication username.
-        The substitution argument may contain backreferences, but has no other variable interpolation.
    
-
-    
     This directive should only be used when your LDAP server doesn't
-        accept anonymous searches and you cannot use a dedicated
-        AuthLDAPBindDN.
-    
    
-
-    
    AuthLDAPInitialBindPattern (.+) $1@example.com
    
-
-    
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    
-
-
-    
    Not available with authorization-only
    
-        This directive can only be used if this module authenticates the user, and
-        has no effect when this module is used exclusively for authorization.
-    
    
-    
    debugging
    
-        The substituted DN is recorded in the environment variable
-        LDAP_BINDASUSER.  If the regular expression does not match the input,
-        the verbatim username is used.
-    
    
-
-
    See also
    
-
-
    
-
    top
    
-
    AuthLDAPMaxSubGroupDepth Directive
    
-
-
-
-
-
-
-
-
-
-
    Description:Specifies the maximum sub-group nesting depth that will be
-evaluated before the user search is discontinued.
    Syntax:AuthLDAPMaxSubGroupDepth Number
    Default:AuthLDAPMaxSubGroupDepth 0
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later, defaulted to 10 in 2.4.x and early 2.5
    
-   
    When this directive is set to a non-zero value X
-   combined with use of the Require ldap-group someGroupDN
-   directive, the provided user credentials will be searched for
-   as a member of the someGroupDN directory object or of
-   any group member of the current group up to the maximum nesting
-   level X specified by this directive.
    
-   
    See the Require ldap-group
-   section for a more detailed example.
    
-
-   
    Nested groups performance
    
-   
     When AuthLDAPSubGroupAttribute overlaps with
-   AuthLDAPGroupAttribute (as it does by default and
-   as required by common LDAP schemas), uncached searching for subgroups in 
-   large groups can be very slow. If you use large, non-nested groups, keep 
-   AuthLDAPMaxSubGroupDepth set to zero.
    
-   
    
-
-
-
    
-
    top
    
-
    AuthLDAPRemoteUserAttribute Directive
    
-
-
-
-
-
-
-
-
-
    Description:Use the value of the attribute returned during the user
-query to set the REMOTE_USER environment variable
    Syntax:AuthLDAPRemoteUserAttribute uid
    Default:none
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    If this directive is set, the value of the
-    REMOTE_USER environment variable will be set to the
-    value of the attribute specified. Make sure that this attribute is
-    included in the list of attributes in the AuthLDAPUrl definition,
-    otherwise this directive will have no effect. This directive, if
-    present, takes precedence over AuthLDAPRemoteUserIsDN. This
-    directive is useful should you want people to log into a website
-    using an email address, but a backend application expects the
-    username as a userid.
    
-    
     This directive only has effect when this module is used for 
-    authentication.
    
-
-
    
-
    top
    
-
    AuthLDAPRemoteUserIsDN Directive
    
-
-
-
-
-
-
-
-
-
    Description:Use the DN of the client username to set the REMOTE_USER
-environment variable
    Syntax:AuthLDAPRemoteUserIsDN on|off
    Default:AuthLDAPRemoteUserIsDN off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    If this directive is set to on, the value of the
-    REMOTE_USER environment variable will be set to the full
-    distinguished name of the authenticated user, rather than just
-    the username that was passed by the client. It is turned off by
-    default.
    
-    
     This directive only has effect when this module is used for
-    authentication.
    
-
-
    
-
    top
    
-
    AuthLDAPSearchAsUser Directive
    
-
-
-
-
-
-
-
-
-
-
    Description:Use the authenticated user's credentials to perform authorization searches
    Syntax:AuthLDAPSearchAsUser on|off
    Default:AuthLDAPSearchAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
-    
    When set, and mod_authnz_ldap has authenticated the
-    user, LDAP searches for authorization use the queried distinguished name (DN)
-    and HTTP basic authentication password of the authenticated user instead of
-    the servers configured credentials.
    
-
-    
     The ldap-filter and ldap-dn authorization
-    checks use searches.
    
-
-    
    This directive only has effect on the comparisons performed during
-    nested group processing when 
-    AuthLDAPCompareAsUser is also enabled.
    
-
-    
     This directive should only be used when your LDAP server doesn't
-        accept anonymous searches and you cannot use a dedicated
-        AuthLDAPBindDN.
-    
    
-
-
    See also
    
-
-
    
-
    top
    
-
    AuthLDAPSubGroupAttribute Directive
    
-
-
-
-
-
-
-
-
-
-
    Description:Specifies the attribute labels, one value per
-directive line, used to distinguish the members of the current group that
-are groups.
    Syntax:AuthLDAPSubGroupAttribute attribute
    Default:AuthLDAPSubgroupAttribute member uniquemember
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    
-    
    An LDAP group object may contain members that are users and
-    members that are groups (called nested or sub groups). The
-    AuthLDAPSubGroupAttribute directive identifies the
-    labels of group members and the AuthLDAPGroupAttribute
-    directive identifies the labels of the user members. Multiple
-    attributes can be used by specifying this directive multiple times.
-    If not specified, then mod_authnz_ldap uses the
-    member and uniqueMember attributes.
    
-
-
    
-
    top
    
-
    AuthLDAPSubGroupClass Directive
    
-
-
-
-
-
-
-
-
-
-
    Description:Specifies which LDAP objectClass values identify directory
-objects that are groups during sub-group processing.
    Syntax:AuthLDAPSubGroupClass LdapObjectClass
    Default:AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    
-    
    An LDAP group object may contain members that are users and
-    members that are groups (called nested or sub groups). The
-    AuthLDAPSubGroupAttribute directive identifies the
-    labels of members that may be sub-groups of the current group
-    (as opposed to user members). The AuthLDAPSubGroupClass
-    directive specifies the LDAP objectClass values used in verifying that
-    these potential sub-groups are in fact group objects. Verified sub-groups
-    can then be searched for more user or sub-group members. Multiple
-    attributes can be used by specifying this directive multiple times.
-    If not specified, then mod_authnz_ldap uses the
-    groupOfNames and groupOfUniqueNames values.
    
-
-
    
-
    top
    
-
    AuthLDAPUrl Directive
    
-
-
-
-
-
-
-
-
    Description:URL specifying the LDAP search parameters
    Syntax:AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
-    
    An RFC 2255 URL which specifies the LDAP search parameters
-    to use. The syntax of the URL is
    
-
    ldap://host:port/basedn?attribute?scope?filter
    
-    
    If you want to specify more than one LDAP URL that Apache should try in turn, the syntax is:
    
-
    AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."
    
-
-
    Caveat: If you specify multiple servers, you need to enclose the entire URL string in quotes;
-otherwise you will get an error: "AuthLDAPURL takes one argument, URL to define LDAP connection.." 
-You can of course use search parameters on each of these.
    
-
-
    
-
    ldap
    
-
-        
    For regular ldap, use the
-        string ldap. For secure LDAP, use ldaps
-        instead. Secure LDAP is only available if Apache was linked
-        to an LDAP library with SSL support.
    
-
-
    host:port
    
-
-        
    
-          
    The name/port of the ldap server (defaults to
-          localhost:389 for ldap, and
-          localhost:636 for ldaps). To
-          specify multiple, redundant LDAP servers, just list all
-          servers, separated by spaces. mod_authnz_ldap
-          will try connecting to each server in turn, until it makes a
-          successful connection. If multiple ldap servers are specified,
-          then entire LDAP URL must be encapsulated in double quotes.
    
-
-          
    Once a connection has been made to a server, that
-          connection remains active for the life of the
-          httpd process, or until the LDAP server goes
-          down.
    
-
-          
    If the LDAP server goes down and breaks an existing
-          connection, mod_authnz_ldap will attempt to
-          re-connect, starting with the primary server, and trying
-          each redundant server in turn. Note that this is different
-          than a true round-robin search.
    
-        
    
-
-
    basedn
    
-
-        
    The DN of the branch of the
-        directory where all searches should start from. At the very
-        least, this must be the top of your directory tree, but
-        could also specify a subtree in the directory.
    
-
-
    attribute
    
-
-        
    The attribute to search for.
-        Although RFC 2255 allows a comma-separated list of
-        attributes, only the first attribute will be used, no
-        matter how many are provided. If no attributes are
-        provided, the default is to use uid. It's a good
-        idea to choose an attribute that will be unique across all
-        entries in the subtree you will be using.  All attributes
-        listed will be put into the environment with an AUTHENTICATE_ prefix
-        for use by other modules.
    
-
-
    scope
    
-
-        
    The scope of the search. Can be either one or
-        sub. Note that a scope of base is
-        also supported by RFC 2255, but is not supported by this
-        module. If the scope is not provided, or if base scope
-        is specified, the default is to use a scope of
-        sub.
    
-
-
    filter
    
-
-        
    A valid LDAP search filter. If
-        not provided, defaults to (objectClass=*), which
-        will search for all objects in the tree. Filters are
-        limited to approximately 8000 characters (the definition of
-        MAX_STRING_LEN in the Apache source code). This
-        should be more than sufficient for any application. The keyword
-        none disables the use of a filter; this is required
-        by some primitive LDAP servers.
    
-
    
-
-    
    When doing searches, the attribute, filter and username passed
-    by the HTTP client are combined to create a search filter that
-    looks like
-    (&(filter)(attribute=username)).
    
-
-    
    For example, consider an URL of
-    ldap://ldap.example.com/o=Example?cn?sub?(posixid=*). When
-    a client attempts to connect using a username of Babs
-    Jenson, the resulting search filter will be
-    (&(posixid=*)(cn=Babs Jenson)).
    
-
-    
    An optional parameter can be added to allow the LDAP Url to override
-    the connection type.  This parameter can be one of the following:
    
-
-
    
-    
    NONE
    
-        
    Establish an unsecure connection on the default LDAP port. This
-        is the same as ldap:// on port 389.
    
-    
    SSL
    
-        
    Establish a secure connection on the default secure LDAP port.
-        This is the same as ldaps://
    
-    
    TLS | STARTTLS
    
-        
    Establish an upgraded secure connection on the default LDAP port.
-        This connection will be initiated on port 389 by default and then
-        upgraded to a secure connection on the same port.
    
-
    
-
-    
    See above for examples of AuthLDAPURL URLs.
    
-
-
    
-
    top
    
 
    
 
    Contents
    
 
@@ -1000,424 +386,1038 @@ Require ldap-user "Joe Manager"
    
     ldap-user line is needed to support all values of the attribute
     in the user's entry.
    
 
-    
    If the uid attribute was used instead of the
-    cn attribute in the URL above, the above three lines
-    could be condensed to
    
-
    Require ldap-user bjenson fuser jmanager
    
+    
    If the uid attribute was used instead of the
+    cn attribute in the URL above, the above three lines
+    could be condensed to
    
+
    Require ldap-user bjenson fuser jmanager
    
+
+
+
+
    Require ldap-group
    
+
+    
    This directive specifies an LDAP group whose members are
+    allowed access. It takes the distinguished name of the LDAP
+    group. Note: Do not surround the group name with quotes.
+    For example, assume that the following entry existed in
+    the LDAP directory:
    
+
    dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
    
+
+    
    The following directive would grant access to both Fred and
+    Barbara:
    
+
    Require ldap-group cn=Administrators, o=Example
    
+
+
+    
    Members can also be found within sub-groups of a specified LDAP group
+    if AuthLDAPMaxSubGroupDepth
+    is set to a value greater than 0. For example, assume the following entries
+    exist in the LDAP directory:
    
+
    dn: cn=Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Managers, o=Example
+uniqueMember: cn=Administrators, o=Example
+uniqueMember: cn=Users, o=Example
+
+dn: cn=Managers, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Bob Ellis, o=Example
+uniqueMember: cn=Tom Jackson, o=Example
+
+dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
+
+dn: cn=Users, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Allan Jefferson, o=Example
+uniqueMember: cn=Paul Tilley, o=Example
+uniqueMember: cn=Temporary Employees, o=Example
+
+dn: cn=Temporary Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Jim Swenson, o=Example
+uniqueMember: cn=Elliot Rhodes, o=Example
    
+
+    
    The following directives would allow access for Bob Ellis, Tom Jackson,
+    Barbara Jenson, Fred User, Allan Jefferson, and Paul Tilley but would not
+    allow access for Jim Swenson, or Elliot Rhodes (since they are at a
+    sub-group depth of 2):
    
+
    Require ldap-group cn=Employees, o=Example
+AuthLDAPMaxSubGroupDepth 1
    
+
+
+    
    Behavior of this directive is modified by the AuthLDAPGroupAttribute, AuthLDAPGroupAttributeIsDN, AuthLDAPMaxSubGroupDepth, AuthLDAPSubGroupAttribute, and AuthLDAPSubGroupClass
+    directives.
    
+
+
+
    Require ldap-dn
    
+
+    
    The Require ldap-dn directive allows the administrator
+    to grant access based on distinguished names. It specifies a DN
+    that must match for access to be granted. If the distinguished
+    name that was retrieved from the directory server matches the
+    distinguished name in the Require ldap-dn, then
+    authorization is granted. Note: do not surround the distinguished
+    name with quotes.
    
+
+    
    The following directive would grant access to a specific
+    DN:
    
+
    Require ldap-dn cn=Barbara Jenson, o=Example
    
+
+
+    
    Behavior of this directive is modified by the AuthLDAPCompareDNOnServer
+    directive.
    
+
+
+
    Require ldap-attribute
    
+
+    
    The Require ldap-attribute directive allows the
+    administrator to grant access based on attributes of the authenticated
+    user in the LDAP directory.  If the attribute in the directory
+    matches the value given in the configuration, access is granted.
    
+
+    
    The following directive would grant access to anyone with
+    the attribute employeeType = active
    
+
+    
    Require ldap-attribute "employeeType=active"
    
+
+
+    
    Multiple attribute/value pairs can be specified on the same line
+    separated by spaces or they can be specified in multiple
+    Require ldap-attribute directives. The effect of listing
+    multiple attribute/values pairs is an OR operation. Access will be
+    granted if any of the listed attribute values match the value of the
+    corresponding attribute in the user object. If the value of the
+    attribute contains a space, only the value must be within double quotes.
    
+
+    
    The following directive would grant access to anyone with
+    the city attribute equal to "San Jose" or status equal to "Active"
    
+
+    
    Require ldap-attribute city="San Jose" "status=active"
    
+
+
+
+
+
    Require ldap-filter
    
+
+    
    The Require ldap-filter directive allows the
+    administrator to grant access based on a complex LDAP search filter.
+    If the dn returned by the filter search matches the authenticated user
+    dn, access is granted.
    
+
+    
    The following directive would grant access to anyone having a cell phone
+    and is in the marketing department
    
+
+    
    Require ldap-filter "&(cell=*)(department=marketing)"
    
+
+
+    
    The difference between the Require ldap-filter directive and the
+    Require ldap-attribute directive is that ldap-filter
+    performs a search operation on the LDAP directory using the specified search
+    filter rather than a simple attribute comparison. If a simple attribute
+    comparison is all that is required, the comparison operation performed by
+    ldap-attribute will be faster than the search operation
+    used by ldap-filter especially within a large directory.
    
+
+    
    When using an expression within the filter, care
+    must be taken to ensure that LDAP filters are escaped correctly to guard against
+    LDAP injection. The ldap function can be used for this purpose.
    
+
+
    <LocationMatch "^/dav/(?<SITENAME>[^/]+)/">
+  Require ldap-filter "(memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)"
+</LocationMatch>
    
+
+
+
+
+
    Require ldap-search
    
+
+    
    The Require ldap-search directive allows the
+    administrator to grant access based on a generic LDAP search filter using an
+    expression. If there is exactly one match to the search filter,
+    regardless of the distinguished name, access is granted.
    
+
+    
    The following directive would grant access to URLs that match the given objects in the
+    LDAP server:
    
+
+
    <LocationMatch "^/dav/(?<SITENAME>[^/]+)/">
+Require ldap-search "(cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}} Website)"
+</LocationMatch>
    
+
+
+    
    Note: care must be taken to ensure that any expressions are properly escaped to guard
+    against LDAP injection. The ldap function can be used as per the example
+    above.
    
+
+
+
+
    top
    
+
    
+
    Examples
    
+
+    
      
+      
    • 
+        Grant access to anyone who exists in the LDAP directory,
+        using their UID for searches.
+
      AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
+Require valid-user
      
+
+      
      • 
+
+      
    • 
+        The next example is the same as above; but with the fields
+        that have useful defaults omitted. Also, note the use of a
+        redundant LDAP server.
+
      AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
+Require valid-user
      
+
+      
      • 
+
+      
    • 
+        The next example is similar to the previous one, but it
+        uses the common name instead of the UID. Note that this
+        could be problematical if multiple people in the directory
+        share the same cn, because a search on cn
+        must return exactly one entry. That's why
+        this approach is not recommended: it's a better idea to
+        choose an attribute that is guaranteed unique in your
+        directory, such as uid.
+
      AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
+Require valid-user
      
+
+      
      • 
+
+      
    • 
+        Grant access to anybody in the Administrators group. The
+        users must authenticate using their UID.
+
      AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=Administrators, o=Example
      
+
+      
      • 
+
+      
    • 
+        Grant access to anybody in the group whose name matches the
+        hostname of the virtual host. In this example an
+        expression is used to build the filter.
+
      AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=%{SERVER_NAME}, o=Example
      
+
+      
      • 
+
+      
    • 
+        The next example assumes that everyone at Example who
+        carries an alphanumeric pager will have an LDAP attribute
+        of qpagePagerID. The example will grant access
+        only to people (authenticated via their UID) who have
+        alphanumeric pagers:
+
      AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
+Require valid-user
      
+
+      
      • 
 
+      
    • 
+        
      The next example demonstrates the power of using filters
+        to accomplish complicated administrative requirements.
+        Without filters, it would have been necessary to create a
+        new LDAP group and ensure that the group's members remain
+        synchronized with the pager users. This becomes trivial
+        with filters. The goal is to grant access to anyone who has
+        a pager, plus grant access to Joe Manager, who doesn't
+        have a pager, but does need to access the same
+        resource:
      
+
      AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
+Require valid-user
      
 
 
-
      Require ldap-group
      
+        
      This last may look confusing at first, so it helps to
+        evaluate what the search filter will look like based on who
+        connects, as shown below.  If
+        Fred User connects as fuser, the filter would look
+        like
      
 
-    
      This directive specifies an LDAP group whose members are
-    allowed access. It takes the distinguished name of the LDAP
-    group. Note: Do not surround the group name with quotes.
-    For example, assume that the following entry existed in
-    the LDAP directory:
      
-
      dn: cn=Administrators, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Barbara Jenson, o=Example
-uniqueMember: cn=Fred User, o=Example
      
+        
      (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))
      
 
-    
      The following directive would grant access to both Fred and
-    Barbara:
      
-
      Require ldap-group cn=Administrators, o=Example
      
+        
      The above search will only succeed if fuser has a
+        pager. When Joe Manager connects as jmanager, the
+        filter looks like
      
 
+        
      (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))
      
 
-    
      Members can also be found within sub-groups of a specified LDAP group
-    if AuthLDAPMaxSubGroupDepth
-    is set to a value greater than 0. For example, assume the following entries
-    exist in the LDAP directory:
      
-
      dn: cn=Employees, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Managers, o=Example
-uniqueMember: cn=Administrators, o=Example
-uniqueMember: cn=Users, o=Example
+        
      The above search will succeed whether jmanager
+        has a pager or not.
      
+      
      • 
+    
    
+
    top
    
+
    
+
    Using TLS
    
 
-dn: cn=Managers, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Bob Ellis, o=Example
-uniqueMember: cn=Tom Jackson, o=Example
+    
    To use TLS, see the mod_ldap directives LDAPTrustedClientCert, LDAPTrustedGlobalCert and LDAPTrustedMode.
    
 
-dn: cn=Administrators, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Barbara Jenson, o=Example
-uniqueMember: cn=Fred User, o=Example
+    
    An optional second parameter can be added to the
+    AuthLDAPURL to override
+    the default connection type set by LDAPTrustedMode.
+    This will allow the connection established by an ldap:// Url
+    to be upgraded to a secure connection on the same port.
    
+
    top
    
+
    
+
    Using SSL
    
 
-dn: cn=Users, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Allan Jefferson, o=Example
-uniqueMember: cn=Paul Tilley, o=Example
-uniqueMember: cn=Temporary Employees, o=Example
+    
    To use SSL, see the mod_ldap directives LDAPTrustedClientCert, LDAPTrustedGlobalCert and LDAPTrustedMode.
    
 
-dn: cn=Temporary Employees, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Jim Swenson, o=Example
-uniqueMember: cn=Elliot Rhodes, o=Example
    
+    
    To specify a secure LDAP server, use ldaps:// in the
+    AuthLDAPURL
+    directive, instead of ldap://.
    
+
    top
    
+
    
+
    Exposing Login Information
    
 
-    
    The following directives would allow access for Bob Ellis, Tom Jackson,
-    Barbara Jenson, Fred User, Allan Jefferson, and Paul Tilley but would not
-    allow access for Jim Swenson, or Elliot Rhodes (since they are at a
-    sub-group depth of 2):
    
-
    Require ldap-group cn=Employees, o=Example
-AuthLDAPMaxSubGroupDepth 1
    
+    
    when this module performs authentication, ldap attributes specified
+    in the authldapurl
+    directive are placed in environment variables with the prefix "AUTHENTICATE_".
    
 
+    
    when this module performs authorization, ldap attributes specified
+    in the authldapurl
+    directive are placed in environment variables with the prefix "AUTHORIZE_".
    
 
-    
    Behavior of this directive is modified by the AuthLDAPGroupAttribute, AuthLDAPGroupAttributeIsDN, AuthLDAPMaxSubGroupDepth, AuthLDAPSubGroupAttribute, and AuthLDAPSubGroupClass
-    directives.
    
+    
    If the attribute field contains the username, common name
+    and telephone number of a user, a CGI program will have access to
+    this information without the need to make a second independent LDAP
+    query to gather this additional information.
    
 
+    
    This has the potential to dramatically simplify the coding and
+    configuration required in some web applications.
    
 
-
    Require ldap-dn
    
+
    top
    
+
    
+
    Using Active Directory
    
 
-    
    The Require ldap-dn directive allows the administrator
-    to grant access based on distinguished names. It specifies a DN
-    that must match for access to be granted. If the distinguished
-    name that was retrieved from the directory server matches the
-    distinguished name in the Require ldap-dn, then
-    authorization is granted. Note: do not surround the distinguished
-    name with quotes.
    
+    
    An Active Directory installation may support multiple domains at the
+    same time. To distinguish users between domains, an identifier called
+    a User Principle Name (UPN) can be added to a user's entry in the
+    directory. This UPN usually takes the form of the user's account
+    name, followed by the domain components of the particular domain,
+    for example somebody@nz.example.com.
    
 
-    
    The following directive would grant access to a specific
-    DN:
    
-
    Require ldap-dn cn=Barbara Jenson, o=Example
    
+    
    You may wish to configure the mod_authnz_ldap
+    module to authenticate users present in any of the domains making up
+    the Active Directory forest. In this way both
+    somebody@nz.example.com and someone@au.example.com
+    can be authenticated using the same query at the same time.
    
 
+    
    To make this practical, Active Directory supports the concept of
+    a Global Catalog. This Global Catalog is a read only copy of selected
+    attributes of all the Active Directory servers within the Active
+    Directory forest. Querying the Global Catalog allows all the domains
+    to be queried in a single query, without the query spanning servers
+    over potentially slow links.
    
 
-    
    Behavior of this directive is modified by the AuthLDAPCompareDNOnServer
-    directive.
    
+    
    If enabled, the Global Catalog is an independent directory server
+    that runs on port 3268 (3269 for SSL). To search for a user, do a
+    subtree search for the attribute userPrincipalName, with
+    an empty search root, like so:
    
 
+
    AuthLDAPBindDN apache@example.com
+AuthLDAPBindPassword password
+AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
    
 
-
    Require ldap-attribute
    
 
-    
    The Require ldap-attribute directive allows the
-    administrator to grant access based on attributes of the authenticated
-    user in the LDAP directory.  If the attribute in the directory
-    matches the value given in the configuration, access is granted.
    
+    
    Users will need to enter their User Principal Name as a login, in
+    the form somebody@nz.example.com.
    
 
-    
    The following directive would grant access to anyone with
-    the attribute employeeType = active
    
+
    top
    
+
    
+
    Using Microsoft
+    FrontPage with mod_authnz_ldap
    
 
-    
    Require ldap-attribute "employeeType=active"
    
+    
    Normally, FrontPage uses FrontPage-web-specific user/group
+    files (i.e., the mod_authn_file and
+    mod_authz_groupfile modules) to handle all
+    authentication. Unfortunately, it is not possible to just
+    change to LDAP authentication by adding the proper directives,
+    because it will break the Permissions forms in
+    the FrontPage client, which attempt to modify the standard
+    text-based authorization files.
    
 
+    
    Once a FrontPage web has been created, adding LDAP
+    authentication to it is a matter of adding the following
+    directives to every .htaccess file
+    that gets created in the web
    
+
    AuthLDAPURL       "the url"
+AuthGroupFile     mygroupfile
+Require group     mygroupfile
    
 
-    
    Multiple attribute/value pairs can be specified on the same line
-    separated by spaces or they can be specified in multiple
-    Require ldap-attribute directives. The effect of listing
-    multiple attribute/values pairs is an OR operation. Access will be
-    granted if any of the listed attribute values match the value of the
-    corresponding attribute in the user object. If the value of the
-    attribute contains a space, only the value must be within double quotes.
    
 
-    
    The following directive would grant access to anyone with
-    the city attribute equal to "San Jose" or status equal to "Active"
    
+
    How It Works
    
 
-    
    Require ldap-attribute city="San Jose" "status=active"
    
+    
    FrontPage restricts access to a web by adding the Require
+    valid-user directive to the .htaccess
+    files. The Require valid-user directive will succeed for
+    any user who is valid as far as LDAP is
+    concerned. This means that anybody who has an entry in
+    the LDAP directory is considered a valid user, whereas FrontPage
+    considers only those people in the local user file to be
+    valid. By substituting the ldap-group with group file authorization,
+    Apache is allowed to consult the local user file (which is managed by
+    FrontPage) - instead of LDAP - when handling authorizing the user.
    
 
+    
    Once directives have been added as specified above,
+    FrontPage users will be able to perform all management
+    operations from the FrontPage client.
    
 
 
+
    Caveats
    
 
-
    Require ldap-filter
    
+    
      
+      
    • When choosing the LDAP URL, the attribute to use for
+      authentication should be something that will also be valid
+      for putting into a mod_authn_file user file.
+      The user ID is ideal for this.
      • 
 
-    
      The Require ldap-filter directive allows the
-    administrator to grant access based on a complex LDAP search filter.
-    If the dn returned by the filter search matches the authenticated user
-    dn, access is granted.
      
+      
    • When adding users via FrontPage, FrontPage administrators
+      should choose usernames that already exist in the LDAP
+      directory (for obvious reasons). Also, the password that the
+      administrator enters into the form is ignored, since Apache
+      will actually be authenticating against the password in the
+      LDAP database, and not against the password in the local user
+      file. This could cause confusion for web administrators.
      • 
 
-    
      The following directive would grant access to anyone having a cell phone
-    and is in the marketing department
      
+      
+      
    • Apache must be compiled with mod_auth_basic,
+      mod_authn_file and
+      mod_authz_groupfile in order to
+      use FrontPage support. This is because Apache will still use
+      the mod_authz_groupfile group file for determine
+      the extent of a user's access to the FrontPage web.
      • 
 
-    
      Require ldap-filter "&(cell=*)(department=marketing)"
      
+      
    • The directives must be put in the .htaccess
+      files. Attempting to put them inside <Location> or <Directory> directives won't work. This
+      is because mod_authnz_ldap has to be able to grab
+      the AuthGroupFile
+      directive that is found in FrontPage .htaccess
+      files so that it knows where to look for the valid user list. If
+      the mod_authnz_ldap directives aren't in the same
+      .htaccess file as the FrontPage directives, then
+      the hack won't work, because mod_authnz_ldap will
+      never get a chance to process the .htaccess file,
+      and won't be able to find the FrontPage-managed user file.
      • 
+    
    
+
+
    
+
    top
    
+
    AuthLDAPAuthorizePrefix Directive
    
+
+
+
+
+
+
+
+
+
+
    Description:Specifies the prefix for environment variables set during
+authorization
    Syntax:AuthLDAPAuthorizePrefix prefix
    Default:AuthLDAPAuthorizePrefix AUTHORIZE_
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
+    
    This directive allows you to override the prefix used for environment
+    variables set during LDAP authorization.  If AUTHENTICATE_ is
+    specified, consumers of these environment variables see the same information
+    whether LDAP has performed authentication, authorization, or both.
    
 
+    
    Note
    
+    No authorization variables are set when a user is authorized on the basis of
+    Require valid-user.
+    
    
 
-    
    The difference between the Require ldap-filter directive and the
-    Require ldap-attribute directive is that ldap-filter
-    performs a search operation on the LDAP directory using the specified search
-    filter rather than a simple attribute comparison. If a simple attribute
-    comparison is all that is required, the comparison operation performed by
-    ldap-attribute will be faster than the search operation
-    used by ldap-filter especially within a large directory.
    
+
    
+
    top
    
+
    AuthLDAPBindAuthoritative Directive
    
+
+
+
+
+
+
+
+
+
    Description:Determines if other authentication providers are used when a user can be mapped to a DN but the server cannot successfully bind with the user's credentials.
    Syntax:AuthLDAPBindAuthoritativeoff|on
    Default:AuthLDAPBindAuthoritative on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    By default, subsequent authentication providers are only queried if a
+    user cannot be mapped to a DN, but not if the user can be mapped to a DN and their
+    password cannot be verified with an LDAP bind.
+    If AuthLDAPBindAuthoritative
+    is set to off, other configured authentication modules will have
+    a chance to validate the user if the LDAP bind (with the current user's credentials)
+    fails for any reason.
    
+    
     This allows users present in both LDAP and
+    AuthUserFile to authenticate
+    when the LDAP server is available but the user's account is locked or password
+    is otherwise unusable.
    
 
-    
    When using an expression within the filter, care
-    must be taken to ensure that LDAP filters are escaped correctly to guard against
-    LDAP injection. The ldap function can be used for this purpose.
    
+
    See also
    
+
+
    
+
    top
    
+
    AuthLDAPBindDN Directive
    
+
+
+
+
+
+
+
+
    Description:Optional DN to use in binding to the LDAP server
    Syntax:AuthLDAPBindDN distinguished-name
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    An optional DN used to bind to the server when searching for
+    entries. If not provided, mod_authnz_ldap will use
+    an anonymous bind.
    
 
-
    <LocationMatch "^/dav/(?<SITENAME>[^/]+)/">
-  Require ldap-filter "(memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)"
-</LocationMatch>
    
+
    
+
    top
    
+
    AuthLDAPBindPassword Directive
    
+
+
+
+
+
+
+
+
+
    Description:Password used in conjuction with the bind DN
    Syntax:AuthLDAPBindPassword password
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:exec: was added in 2.4.5.
    
+    
    A bind password to use in conjunction with the bind DN. Note
+    that the bind password is probably sensitive data, and should be
+    properly protected. You should only use the AuthLDAPBindDN and AuthLDAPBindPassword if you
+    absolutely need them to search the directory.
    
 
+    
    If the value begins with exec: the resulting command will be
+    executed and the first line returned to standard output by the
+    program will be used as the password.
    
+
    #Password used as-is
+AuthLDAPBindPassword secret
 
+#Run /path/to/program to get my password
+AuthLDAPBindPassword exec:/path/to/program
 
+#Run /path/to/otherProgram and provide arguments
+AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    
 
-
    Require ldap-search
    
 
-    
    The Require ldap-search directive allows the
-    administrator to grant access based on a generic LDAP search filter using an
-    expression. If there is exactly one match to the search filter,
-    regardless of the distinguished name, access is granted.
    
 
-    
    The following directive would grant access to URLs that match the given objects in the
-    LDAP server:
    
+
    
+
    top
    
+
    AuthLDAPCharsetConfig Directive
    
+
+
+
+
+
+
+
    Description:Language to charset conversion configuration file
    Syntax:AuthLDAPCharsetConfig file-path
    Context:server config
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    The AuthLDAPCharsetConfig directive sets the location
+    of the language to charset conversion configuration file. File-path is relative
+    to the ServerRoot. This file specifies
+    the list of language extensions to character sets.
+    Most administrators use the provided charset.conv
+    file, which associates common language extensions to character sets.
    
 
-
    <LocationMatch "^/dav/(?<SITENAME>[^/]+)/">
-Require ldap-search "(cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}} Website)"
-</LocationMatch>
    
+    
    The file contains lines in the following format:
    
 
+    
    
+      Language-Extension charset [Language-String] ...
+    
    
 
-    
    Note: care must be taken to ensure that any expressions are properly escaped to guard
-    against LDAP injection. The ldap function can be used as per the example
-    above.
    
+    
    The case of the extension does not matter. Blank lines, and lines
+    beginning with a hash character (#) are ignored.
    
 
+
    
+
    top
    
+
    AuthLDAPCompareAsUser Directive
    
+
+
+
+
+
+
+
+
+
+
    Description:Use the authenticated user's credentials to perform authorization comparisons
    Syntax:AuthLDAPCompareAsUser on|off
    Default:AuthLDAPCompareAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
+    
    When set, and mod_authnz_ldap has authenticated the
+    user, LDAP comparisons for authorization use the queried distinguished name (DN)
+    and HTTP basic authentication password of the authenticated user instead of
+    the servers configured credentials.
    
 
+    
     The ldap-attribute, ldap-user, and ldap-group (single-level only)
+    authorization checks use comparisons.
    
 
-
    top
    
-
    
-
    Examples
    
+    
    This directive only has effect on the comparisons performed during
+    nested group processing when 
+    AuthLDAPSearchAsUser is also enabled.
    
 
-    
      
-      
    • 
-        Grant access to anyone who exists in the LDAP directory,
-        using their UID for searches.
-
      AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
-Require valid-user
      
+    
       This directive should only be used when your LDAP server doesn't
+        accept anonymous comparisons and you cannot use a dedicated
+        AuthLDAPBindDN.
+    
      
 
-      
      • 
+
      See also
      
+
+
    
+
    top
    
+
    AuthLDAPCompareDNOnServer Directive
    
+
+
+
+
+
+
+
+
+
    Description:Use the LDAP server to compare the DNs
    Syntax:AuthLDAPCompareDNOnServer on|off
    Default:AuthLDAPCompareDNOnServer on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    When set, mod_authnz_ldap will use the LDAP
+    server to compare the DNs. This is the only foolproof way to
+    compare DNs.  mod_authnz_ldap will search the
+    directory for the DN specified with the Require dn directive, then,
+    retrieve the DN and compare it with the DN retrieved from the user
+    entry. If this directive is not set,
+    mod_authnz_ldap simply does a string comparison. It
+    is possible to get false negatives with this approach, but it is
+    much faster. Note the mod_ldap cache can speed up
+    DN comparison in most situations.
    
 
-      
  • 
-        The next example is the same as above; but with the fields
-        that have useful defaults omitted. Also, note the use of a
-        redundant LDAP server.
-
    AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
-Require valid-user
    
+
    • 
+
    top
    
+
    AuthLDAPDereferenceAliases Directive
    
+
+
+
+
+
+
+
+
+
    Description:When will the module de-reference aliases
    Syntax:AuthLDAPDereferenceAliases never|searching|finding|always
    Default:AuthLDAPDereferenceAliases always
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    This directive specifies when mod_authnz_ldap will
+    de-reference aliases during LDAP operations. The default is
+    always.
    
 
-      
+
    
+
    top
    
+
    AuthLDAPGroupAttribute Directive
    
+
+
+
+
+
+
+
+
+
    Description:LDAP attributes used to identify the user members of
+groups.
    Syntax:AuthLDAPGroupAttribute attribute
    Default:AuthLDAPGroupAttribute member uniquemember
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    This directive specifies which LDAP attributes are used to
+    check for user members within groups. Multiple attributes can be used
+    by specifying this directive multiple times. If not specified,
+    then mod_authnz_ldap uses the member and
+    uniquemember attributes.
    
 
-      
  • 
-        The next example is similar to the previous one, but it
-        uses the common name instead of the UID. Note that this
-        could be problematical if multiple people in the directory
-        share the same cn, because a search on cn
-        must return exactly one entry. That's why
-        this approach is not recommended: it's a better idea to
-        choose an attribute that is guaranteed unique in your
-        directory, such as uid.
-
    AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
-Require valid-user
    
+
    • 
+
    top
    
+
    AuthLDAPGroupAttributeIsDN Directive
    
+
+
+
+
+
+
+
+
+
    Description:Use the DN of the client username when checking for
+group membership
    Syntax:AuthLDAPGroupAttributeIsDN on|off
    Default:AuthLDAPGroupAttributeIsDN on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    When set on, this directive says to use the
+    distinguished name of the client username when checking for group
+    membership.  Otherwise, the username will be used. For example,
+    assume that the client sent the username bjenson,
+    which corresponds to the LDAP DN cn=Babs Jenson,
+    o=Example. If this directive is set,
+    mod_authnz_ldap will check if the group has
+    cn=Babs Jenson, o=Example as a member. If this
+    directive is not set, then mod_authnz_ldap will
+    check if the group has bjenson as a member.
    
 
-      
+
    
+
    top
    
+
    AuthLDAPInitialBindAsUser Directive
    
+
+
+
+
+
+
+
+
+
+
    Description:Determines if the server does the initial DN lookup using the basic authentication users'
+own username, instead of anonymously or with hard-coded credentials for the server
    Syntax:AuthLDAPInitialBindAsUser off|on
    Default:AuthLDAPInitialBindAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
+    
    By default, the server either anonymously, or with a dedicated user and
+     password, converts the basic authentication username into an LDAP
+     distinguished name (DN).  This directive forces the server to use the verbatim username
+     and password provided by the incoming user to perform the initial DN
+     search.
    
 
-      
  • 
-        Grant access to anybody in the Administrators group. The
-        users must authenticate using their UID.
-
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
-Require ldap-group cn=Administrators, o=Example
    
+     
     If the verbatim username can't directly bind, but needs some
+     cosmetic transformation, see 
+     AuthLDAPInitialBindPattern.
    
 
-      
    • 
+     
     This directive should only be used when your LDAP server doesn't
+         accept anonymous searches and you cannot use a dedicated
+         AuthLDAPBindDN.
+     
    
 
-      
  • 
-        Grant access to anybody in the group whose name matches the
-        hostname of the virtual host. In this example an
-        expression is used to build the filter.
-
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
-Require ldap-group cn=%{SERVER_NAME}, o=Example
    
+     
    Not available with authorization-only
    
+         This directive can only be used if this module authenticates the user, and
+         has no effect when this module is used exclusively for authorization.
+     
    
 
-      
    • 
+
    See also
    
+
+
    
+
    top
    
+
    AuthLDAPInitialBindPattern Directive
    
+
+
+
+
+
+
+
+
+
+
    Description:Specifies the transformation of the basic authentication username to be used when binding to the LDAP server
+to perform a DN lookup
    Syntax:AuthLDAPInitialBindPatternregex substitution
    Default:AuthLDAPInitialBindPattern (.*) $1 (remote username used verbatim)
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
+    
    If AuthLDAPInitialBindAsUser is set to
+       ON, the basic authentication username will be transformed according to the
+       regular expression and substituion arguments.
    
 
-      
  • 
-        The next example assumes that everyone at Example who
-        carries an alphanumeric pager will have an LDAP attribute
-        of qpagePagerID. The example will grant access
-        only to people (authenticated via their UID) who have
-        alphanumeric pagers:
-
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
-Require valid-user
    
+    
     The regular expression argument is compared against the current basic authentication username.
+        The substitution argument may contain backreferences, but has no other variable interpolation.
    
 
-      
    • 
+    
     This directive should only be used when your LDAP server doesn't
+        accept anonymous searches and you cannot use a dedicated
+        AuthLDAPBindDN.
+    
    
 
-      
  • 
-        
    The next example demonstrates the power of using filters
-        to accomplish complicated administrative requirements.
-        Without filters, it would have been necessary to create a
-        new LDAP group and ensure that the group's members remain
-        synchronized with the pager users. This becomes trivial
-        with filters. The goal is to grant access to anyone who has
-        a pager, plus grant access to Joe Manager, who doesn't
-        have a pager, but does need to access the same
-        resource:
    
-
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
-Require valid-user
    
+    
    AuthLDAPInitialBindPattern (.+) $1@example.com
    
 
+    
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    
 
-        
    This last may look confusing at first, so it helps to
-        evaluate what the search filter will look like based on who
-        connects, as shown below.  If
-        Fred User connects as fuser, the filter would look
-        like
    
 
-        
    (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))
    
+    
    Not available with authorization-only
    
+        This directive can only be used if this module authenticates the user, and
+        has no effect when this module is used exclusively for authorization.
+    
    
+    
    debugging
    
+        The substituted DN is recorded in the environment variable
+        LDAP_BINDASUSER.  If the regular expression does not match the input,
+        the verbatim username is used.
+    
    
 
-        
    The above search will only succeed if fuser has a
-        pager. When Joe Manager connects as jmanager, the
-        filter looks like
    
+
    See also
    
+
+
    • 
+
    top
    
+
    AuthLDAPMaxSubGroupDepth Directive
    
+
+
+
+
+
+
+
+
+
+
    Description:Specifies the maximum sub-group nesting depth that will be
+evaluated before the user search is discontinued.
    Syntax:AuthLDAPMaxSubGroupDepth Number
    Default:AuthLDAPMaxSubGroupDepth 0
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later, defaulted to 10 in 2.4.x and early 2.5
    
+   
    When this directive is set to a non-zero value X
+   combined with use of the Require ldap-group someGroupDN
+   directive, the provided user credentials will be searched for
+   as a member of the someGroupDN directory object or of
+   any group member of the current group up to the maximum nesting
+   level X specified by this directive.
    
+   
    See the Require ldap-group
+   section for a more detailed example.
    
 
-        
    (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))
    
+   
    Nested groups performance
    
+   
     When AuthLDAPSubGroupAttribute overlaps with
+   AuthLDAPGroupAttribute (as it does by default and
+   as required by common LDAP schemas), uncached searching for subgroups in 
+   large groups can be very slow. If you use large, non-nested groups, keep 
+   AuthLDAPMaxSubGroupDepth set to zero.
    
+   
    
 
-        
    The above search will succeed whether jmanager
-        has a pager or not.
    
-      
-    
-
    top
    
-
    
-
    Using TLS
    
 
-    
    To use TLS, see the mod_ldap directives LDAPTrustedClientCert, LDAPTrustedGlobalCert and LDAPTrustedMode.
    
+
    
+
    top
    
+
    AuthLDAPRemoteUserAttribute Directive
    
+
+
+
+
+
+
+
+
+
    Description:Use the value of the attribute returned during the user
+query to set the REMOTE_USER environment variable
    Syntax:AuthLDAPRemoteUserAttribute uid
    Default:none
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    If this directive is set, the value of the
+    REMOTE_USER environment variable will be set to the
+    value of the attribute specified. Make sure that this attribute is
+    included in the list of attributes in the AuthLDAPUrl definition,
+    otherwise this directive will have no effect. This directive, if
+    present, takes precedence over AuthLDAPRemoteUserIsDN. This
+    directive is useful should you want people to log into a website
+    using an email address, but a backend application expects the
+    username as a userid.
    
+    
     This directive only has effect when this module is used for 
+    authentication.
    
 
-    
    An optional second parameter can be added to the
-    AuthLDAPURL to override
-    the default connection type set by LDAPTrustedMode.
-    This will allow the connection established by an ldap:// Url
-    to be upgraded to a secure connection on the same port.
    
-
    top
    
-
    
-
    Using SSL
    
+
    
+
    top
    
+
    AuthLDAPRemoteUserIsDN Directive
    
+
+
+
+
+
+
+
+
+
    Description:Use the DN of the client username to set the REMOTE_USER
+environment variable
    Syntax:AuthLDAPRemoteUserIsDN on|off
    Default:AuthLDAPRemoteUserIsDN off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    If this directive is set to on, the value of the
+    REMOTE_USER environment variable will be set to the full
+    distinguished name of the authenticated user, rather than just
+    the username that was passed by the client. It is turned off by
+    default.
    
+    
     This directive only has effect when this module is used for
+    authentication.
    
 
-    
    To use SSL, see the mod_ldap directives LDAPTrustedClientCert, LDAPTrustedGlobalCert and LDAPTrustedMode.
    
+
    
+
    top
    
+
    AuthLDAPSearchAsUser Directive
    
+
+
+
+
+
+
+
+
+
+
    Description:Use the authenticated user's credentials to perform authorization searches
    Syntax:AuthLDAPSearchAsUser on|off
    Default:AuthLDAPSearchAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    
+    
    When set, and mod_authnz_ldap has authenticated the
+    user, LDAP searches for authorization use the queried distinguished name (DN)
+    and HTTP basic authentication password of the authenticated user instead of
+    the servers configured credentials.
    
 
-    
    To specify a secure LDAP server, use ldaps:// in the
-    AuthLDAPURL
-    directive, instead of ldap://.
    
-
    top
    
-
    
-
    Exposing Login Information
    
+    
     The ldap-filter and ldap-dn authorization
+    checks use searches.
    
 
-    
    when this module performs authentication, ldap attributes specified
-    in the authldapurl
-    directive are placed in environment variables with the prefix "AUTHENTICATE_".
    
+    
    This directive only has effect on the comparisons performed during
+    nested group processing when 
+    AuthLDAPCompareAsUser is also enabled.
    
 
-    
    when this module performs authorization, ldap attributes specified
-    in the authldapurl
-    directive are placed in environment variables with the prefix "AUTHORIZE_".
    
+    
     This directive should only be used when your LDAP server doesn't
+        accept anonymous searches and you cannot use a dedicated
+        AuthLDAPBindDN.
+    
    
 
-    
    If the attribute field contains the username, common name
-    and telephone number of a user, a CGI program will have access to
-    this information without the need to make a second independent LDAP
-    query to gather this additional information.
    
+
    See also
    
+
+
    
+
    top
    
+
    AuthLDAPSubGroupAttribute Directive
    
+
+
+
+
+
+
+
+
+
+
    Description:Specifies the attribute labels, one value per
+directive line, used to distinguish the members of the current group that
+are groups.
    Syntax:AuthLDAPSubGroupAttribute attribute
    Default:AuthLDAPSubgroupAttribute member uniquemember
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    
+    
    An LDAP group object may contain members that are users and
+    members that are groups (called nested or sub groups). The
+    AuthLDAPSubGroupAttribute directive identifies the
+    labels of group members and the AuthLDAPGroupAttribute
+    directive identifies the labels of the user members. Multiple
+    attributes can be used by specifying this directive multiple times.
+    If not specified, then mod_authnz_ldap uses the
+    member and uniqueMember attributes.
    
 
-    
    This has the potential to dramatically simplify the coding and
-    configuration required in some web applications.
    
+
    
+
    top
    
+
    AuthLDAPSubGroupClass Directive
    
+
+
+
+
+
+
+
+
+
+
    Description:Specifies which LDAP objectClass values identify directory
+objects that are groups during sub-group processing.
    Syntax:AuthLDAPSubGroupClass LdapObjectClass
    Default:AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    
+    
    An LDAP group object may contain members that are users and
+    members that are groups (called nested or sub groups). The
+    AuthLDAPSubGroupAttribute directive identifies the
+    labels of members that may be sub-groups of the current group
+    (as opposed to user members). The AuthLDAPSubGroupClass
+    directive specifies the LDAP objectClass values used in verifying that
+    these potential sub-groups are in fact group objects. Verified sub-groups
+    can then be searched for more user or sub-group members. Multiple
+    attributes can be used by specifying this directive multiple times.
+    If not specified, then mod_authnz_ldap uses the
+    groupOfNames and groupOfUniqueNames values.
    
 
-
    top
    
-
    
-
    Using Active Directory
    
+
    
+
    top
    
+
    AuthLDAPUrl Directive
    
+
+
+
+
+
+
+
+
    Description:URL specifying the LDAP search parameters
    Syntax:AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    
+    
    An RFC 2255 URL which specifies the LDAP search parameters
+    to use. The syntax of the URL is
    
+
    ldap://host:port/basedn?attribute?scope?filter
    
+    
    If you want to specify more than one LDAP URL that Apache should try in turn, the syntax is:
    
+
    AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."
    
 
-    
    An Active Directory installation may support multiple domains at the
-    same time. To distinguish users between domains, an identifier called
-    a User Principle Name (UPN) can be added to a user's entry in the
-    directory. This UPN usually takes the form of the user's account
-    name, followed by the domain components of the particular domain,
-    for example somebody@nz.example.com.
    
+
    Caveat: If you specify multiple servers, you need to enclose the entire URL string in quotes;
+otherwise you will get an error: "AuthLDAPURL takes one argument, URL to define LDAP connection.." 
+You can of course use search parameters on each of these.
    
 
-    
    You may wish to configure the mod_authnz_ldap
-    module to authenticate users present in any of the domains making up
-    the Active Directory forest. In this way both
-    somebody@nz.example.com and someone@au.example.com
-    can be authenticated using the same query at the same time.
    
+
    
+
    ldap
    
 
-    
    To make this practical, Active Directory supports the concept of
-    a Global Catalog. This Global Catalog is a read only copy of selected
-    attributes of all the Active Directory servers within the Active
-    Directory forest. Querying the Global Catalog allows all the domains
-    to be queried in a single query, without the query spanning servers
-    over potentially slow links.
    
+        
    For regular ldap, use the
+        string ldap. For secure LDAP, use ldaps
+        instead. Secure LDAP is only available if Apache was linked
+        to an LDAP library with SSL support.
    
 
-    
    If enabled, the Global Catalog is an independent directory server
-    that runs on port 3268 (3269 for SSL). To search for a user, do a
-    subtree search for the attribute userPrincipalName, with
-    an empty search root, like so:
    
+
    host:port
    
 
-
    AuthLDAPBindDN apache@example.com
-AuthLDAPBindPassword password
-AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
    
+        
    
+          
    The name/port of the ldap server (defaults to
+          localhost:389 for ldap, and
+          localhost:636 for ldaps). To
+          specify multiple, redundant LDAP servers, just list all
+          servers, separated by spaces. mod_authnz_ldap
+          will try connecting to each server in turn, until it makes a
+          successful connection. If multiple ldap servers are specified,
+          then entire LDAP URL must be encapsulated in double quotes.
    
 
+          
    Once a connection has been made to a server, that
+          connection remains active for the life of the
+          httpd process, or until the LDAP server goes
+          down.
    
 
-    
    Users will need to enter their User Principal Name as a login, in
-    the form somebody@nz.example.com.
    
+          
    If the LDAP server goes down and breaks an existing
+          connection, mod_authnz_ldap will attempt to
+          re-connect, starting with the primary server, and trying
+          each redundant server in turn. Note that this is different
+          than a true round-robin search.
    
+        
    
 
-
    top
    
-
    
-
    Using Microsoft
-    FrontPage with mod_authnz_ldap
    
+
    basedn
    
 
-    
    Normally, FrontPage uses FrontPage-web-specific user/group
-    files (i.e., the mod_authn_file and
-    mod_authz_groupfile modules) to handle all
-    authentication. Unfortunately, it is not possible to just
-    change to LDAP authentication by adding the proper directives,
-    because it will break the Permissions forms in
-    the FrontPage client, which attempt to modify the standard
-    text-based authorization files.
    
+        
    The DN of the branch of the
+        directory where all searches should start from. At the very
+        least, this must be the top of your directory tree, but
+        could also specify a subtree in the directory.
    
 
-    
    Once a FrontPage web has been created, adding LDAP
-    authentication to it is a matter of adding the following
-    directives to every .htaccess file
-    that gets created in the web
    
-
    AuthLDAPURL       "the url"
-AuthGroupFile     mygroupfile
-Require group     mygroupfile
    
+
    attribute
    
 
+        
    The attribute to search for.
+        Although RFC 2255 allows a comma-separated list of
+        attributes, only the first attribute will be used, no
+        matter how many are provided. If no attributes are
+        provided, the default is to use uid. It's a good
+        idea to choose an attribute that will be unique across all
+        entries in the subtree you will be using.  All attributes
+        listed will be put into the environment with an AUTHENTICATE_ prefix
+        for use by other modules.
    
 
-
    How It Works
    
+
    scope
    
 
-    
    FrontPage restricts access to a web by adding the Require
-    valid-user directive to the .htaccess
-    files. The Require valid-user directive will succeed for
-    any user who is valid as far as LDAP is
-    concerned. This means that anybody who has an entry in
-    the LDAP directory is considered a valid user, whereas FrontPage
-    considers only those people in the local user file to be
-    valid. By substituting the ldap-group with group file authorization,
-    Apache is allowed to consult the local user file (which is managed by
-    FrontPage) - instead of LDAP - when handling authorizing the user.
    
+        
    The scope of the search. Can be either one or
+        sub. Note that a scope of base is
+        also supported by RFC 2255, but is not supported by this
+        module. If the scope is not provided, or if base scope
+        is specified, the default is to use a scope of
+        sub.
    
 
-    
    Once directives have been added as specified above,
-    FrontPage users will be able to perform all management
-    operations from the FrontPage client.
    
+
    filter
    
 
+        
    A valid LDAP search filter. If
+        not provided, defaults to (objectClass=*), which
+        will search for all objects in the tree. Filters are
+        limited to approximately 8000 characters (the definition of
+        MAX_STRING_LEN in the Apache source code). This
+        should be more than sufficient for any application. The keyword
+        none disables the use of a filter; this is required
+        by some primitive LDAP servers.
    
+
 
-
    Caveats
    
+    
    When doing searches, the attribute, filter and username passed
+    by the HTTP client are combined to create a search filter that
+    looks like
+    (&(filter)(attribute=username)).
    
 
-    
      
-      
    • When choosing the LDAP URL, the attribute to use for
-      authentication should be something that will also be valid
-      for putting into a mod_authn_file user file.
-      The user ID is ideal for this.
      • 
+    
      For example, consider an URL of
+    ldap://ldap.example.com/o=Example?cn?sub?(posixid=*). When
+    a client attempts to connect using a username of Babs
+    Jenson, the resulting search filter will be
+    (&(posixid=*)(cn=Babs Jenson)).
      
 
-      
    • When adding users via FrontPage, FrontPage administrators
-      should choose usernames that already exist in the LDAP
-      directory (for obvious reasons). Also, the password that the
-      administrator enters into the form is ignored, since Apache
-      will actually be authenticating against the password in the
-      LDAP database, and not against the password in the local user
-      file. This could cause confusion for web administrators.
      • 
+    
      An optional parameter can be added to allow the LDAP Url to override
+    the connection type.  This parameter can be one of the following:
      
 
-      
-      
    • Apache must be compiled with mod_auth_basic,
-      mod_authn_file and
-      mod_authz_groupfile in order to
-      use FrontPage support. This is because Apache will still use
-      the mod_authz_groupfile group file for determine
-      the extent of a user's access to the FrontPage web.
      • 
+
      
+    
      NONE
      
+        
      Establish an unsecure connection on the default LDAP port. This
+        is the same as ldap:// on port 389.
      
+    
      SSL
      
+        
      Establish a secure connection on the default secure LDAP port.
+        This is the same as ldaps://
      
+    
      TLS | STARTTLS
      
+        
      Establish an upgraded secure connection on the default LDAP port.
+        This connection will be initiated on port 389 by default and then
+        upgraded to a secure connection on the same port.
      
+
      
 
-      
    • The directives must be put in the .htaccess
-      files. Attempting to put them inside <Location> or <Directory> directives won't work. This
-      is because mod_authnz_ldap has to be able to grab
-      the AuthGroupFile
-      directive that is found in FrontPage .htaccess
-      files so that it knows where to look for the valid user list. If
-      the mod_authnz_ldap directives aren't in the same
-      .htaccess file as the FrontPage directives, then
-      the hack won't work, because mod_authnz_ldap will
-      never get a chance to process the .htaccess file,
-      and won't be able to find the FrontPage-managed user file.
      • 
-    
    
+    
    See above for examples of AuthLDAPURL URLs.
    
 
 
    
 
diff --git a/docs/manual/mod/mod_authnz_ldap.html.fr b/docs/manual/mod/mod_authnz_ldap.html.fr
index a3f86653b5..c2ee3e0263 100644
--- a/docs/manual/mod/mod_authnz_ldap.html.fr
+++ b/docs/manual/mod/mod_authnz_ldap.html.fr
@@ -63,7 +63,21 @@ HTTP de base.
     invoqué en affectant la valeur ldap à la directive
     AuthBasicProvider.
    
 
-
    Directives
    
+
 
    top
    
-
    Directive AuthLDAPAuthorizePrefix
    
-
-
-
-
-
-
-
-
-
-
    Description:Spécifie le préfixe ajouté aux variables d'environnement
-durant la phase d'autorisation
    Syntaxe:AuthLDAPAuthorizePrefix préfixe
    Défaut:AuthLDAPAuthorizePrefix AUTHORIZE_
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    
-    
    Cette directive permet de spécifier le préfixe ajouté aux
-    variables d'environnement durant la phase d'autorisation. Si la
-    valeur spécifiée est AUTHENTICATE_, les utilisateurs de ces
-    variables d'environnement verront les mêmes informations, que le
-    serveur effectue une authentification, une autorisation, ou les
-    deux.
    
+
    
+
    Sommaire
    
 
-    
    Note
    
-    Aucune variable d'autorisation n'est définie lorsqu'un utilisateur
-    s'est vu autoriser l'accès via la directive Require
-    valid-user.
-    
    
+    
    
-
    top
    
-
    Directive AuthLDAPBindAuthoritative
    
-
-
-
-
-
-
-
-
-
    Description:Détermine si l'on doit utiliser d'autres fournisseurs
-d'authentification lorsque le serveur ne peut pas valider les données
-d'authentification de l'utilisateur, alors que ce dernier possède un
-DN.
    Syntaxe:AuthLDAPBindAuthoritativeoff|on
    Défaut:AuthLDAPBindAuthoritative on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    Par défaut, des fournisseurs d'authentification sont appelés
-    si un utilisateur ne possède pas de DN, mais ne le sont pas si
-    l'utilisateur possède un DN et si son mot de passe ne peut pas être
-    vérifié lors d'une connexion au serveur LDAP. Si la directive
-    AuthLDAPBindAuthoritative est
-    définie à off, d'autres modules d'authentification
-    configurés auront une chance de valider le mot de passe de
-    l'utilisateur si la tentative de connexion au serveur LDAP échoue
-    pour une raison quelconque (avec les données d'authentification
-    fournies).
    
-    
    Ceci permet aux utilisateurs présent à la fois dans l'annuaire
-    LDAP et dans un fichier AuthUserFile de s'authentifier
-    lorsque le serveur LDAP est disponible, alors que le compte de
-    l'utilisateur est verrouillé ou que son mot de passe est
-    inutilisable pour une raison quelconque.
    
+        
    
-
    top
    
-
    Directive AuthLDAPBindDN
    
-
-
-
-
-
-
-
-
    Description:Un DN optionnel pour se connecter au serveur
-LDAP
    Syntaxe:AuthLDAPBindDN dn
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    Cette directive permet de définir un DN optionnel pour se
-    connecter au serveur afin d'y rechercher des entrées. Si aucun DN
-    n'est spécifié, mod_authnz_ldap tentera une
-    connexion anonyme.
    
+          
  • La phase d'autorisation
    • 
+        
+      
 
-
    
-
    top
    
-
    Directive AuthLDAPBindPassword
    
-
-
-
-
-
-
-
-
-
    Description:Mot de passe à utiliser en conjonction avec le DN de
-connexion
    Syntaxe:AuthLDAPBindPassword mot-de-passe
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:exec: est disponible depuis la version 2.4.5 du
-serveur HTTP Apache.
    
-    
    Cette directive permet de spécifier un mot de passe à utiliser en
-    conjonction avec le DN de connexion. Notez que ce mot de passe
-    constitue en général une donnée sensible, et doit donc être protégé
-    de manière appropriée. Vous ne devez utiliser les directives
-    AuthLDAPBindDN et AuthLDAPBindPassword que si
-    vous en avez vraiment besoin pour effectuer une recherche dans
-    l'annuaire.
    
+      
  • 
+        Les directives requises
 
-    
    Si la valeur commence par exec:, la commande résultante sera
-    exécutée, et la première ligne renvoyée sur la sortie standard sera
-    utilisée comme mot de passe.
    
-
    #Mot de passe utilisé tel quel
-AuthLDAPBindPassword secret
+        
+      
    • 
 
-#Exécute /path/to/program pour obtenir le mot de passe
-AuthLDAPBindPassword exec:/path/to/program
+      
  • Exemples
    • 
+      
  • Utilisation de TLS
    • 
+      
  • Utilisation de SSL
    • 
+      
  • Mise à disposition des informations de
+      connexion
    • 
+      
  • Utilisation d'Active Directory
    • 
+      
  • 
+        Utilisation de Microsoft FrontPage avec
+        mod_authnz_ldap
 
-#Exécute /path/to/otherProgram avec un argument pour obtenir le mot de passe
-AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    • 
+        
+      
+    
+
    top
    
+
    
+
    Mode opératoire
    
 
+    
    L'utilisateur se voit accorder l'accès selon un processus en deux
+    phases. La première phase est l'authentification, au cours de
+    laquelle le fournisseur d'authentification
+    mod_authnz_ldap vérifie que les informations de
+    connexion de l'utilisateur sont valides. Elle est aussi connue sous
+    le nom de phase de recherche/connexion (NdT : en anglais ou
+    dans le code source : search/bind). La deuxième
+    phase est l'autorisation, au cours de laquelle
+    mod_authnz_ldap détermine si l'utilisateur
+    authentifié a la permission d'accéder à la ressource considérée.
+    Elle est aussi connue sous le nom de phase de
+    comparaison (compare).
    
 
+    
    mod_authnz_ldap comporte un fournisseur
+    d'authentification authn_ldap et un gestionnaire d'autorisation
+    authz_ldap. Le fournisseur d'authentification authn_ldap peut être
+    invoqué en affectant la valeur ldap à la directive
+    AuthBasicProvider. Le
+    gestionnaire d'autorisation authz_ldap enrichit la liste des types
+    d'autorisations de la directive Require en y ajoutant les
+    valeurs ldap-user, ldap-dn et
+    ldap-group.
    
 
-
    
-
    top
    
-
    Directive AuthLDAPCharsetConfig
    
-
-
-
-
-
-
-
    Description:Chemin du fichier de configuration de la correspondance
-langage/jeu de caractères
    Syntaxe:AuthLDAPCharsetConfig chemin-fichier
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    La directive AuthLDAPCharsetConfig permet
-    de définir le chemin du fichier de configuration de la
-    correspondance langage/jeu de caractères. chemin-fichier
-    est un chemin relatif au répertoire défini par la directive
-    ServerRoot. Ce fichier contient une liste
-    de correspondances extension de langage/jeu de caractères. La
-    plupart des administrateurs utilisent le fichier
-    charset.conv fourni qui associe les extensions de
-    langage courantes à leurs jeux de caractères.
    
+
    La phase d'authentification
    
 
-    
    Le fichier contient des lignes au format suivant :
    
+    
    Au cours de la phase d'authentification,
+    mod_authnz_ldap recherche une entrée de l'annuaire
+    LDAP qui correspond au nom d'utilisateur fourni par le client HTTP.
+    Si une correspondance unique est trouvée,
+    mod_authnz_ldap tente de se connecter au serveur
+    hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot
+    de passe fourni par le client HTTP. Comme ce processus effectue tout
+    d'abord une recherche, puis une connexion, il est aussi connu sous
+    le nom de phase de recherche/connexion. Voici le détail des étapes
+    constituant la phase de recherche/connexion :
    
 
-    
    
-      extension de langage jeu de caractères
-      [Nom du langage] ...
-    
    
+    
      
+      
    1. Confection d'un filtre de recherche en combinant les attribut
+      et filtre définis par la directive AuthLDAPURL avec le nom d'utilisateur et le mot de
+      passe fournis par le client HTTP.
      2. 
 
-    
      L'extension est insensible à la casse. Les lignes vides et les
-    lignes commençant par un dièse (#) sont ignorées.
      
+      
    2. Recherche dans l'annuaire LDAP en utilisant le filtre
+      confectionné précédemment. Si le résultat de la recherche est
+      négatif ou comporte plusieurs entrées, refus ou restriction de
+      l'accès.
      3. 
 
-
    
-
    top
    
-
    Directive AuthLDAPCompareAsUser
    
-
-
-
-
-
-
-
-
-
-
    Description:Utilisation des données d'authentification de l'utilisateur
-pour effectuer les comparaisons pour l'attribution des autorisations
    Syntaxe:AuthLDAPCompareAsUser on|off
    Défaut:AuthLDAPCompareAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version version 2.3.6
    
-    
    Lorsque cette directive est définie, et si
-    mod_authnz_ldap a authentifié l'utilisateur, les
-    recherches LDAP pour les autorisations utilisent le nom distinctif
-    trouvé (DN) et le mot de passe d'authentification basique HTTP de
-    l'utilisateur authentifié au lieu des données d'authentification
-    configurées au niveau du serveur.
    
+      
  • Extraction du DN (distinguished name) de l'entrée issue du
+      résultat de la recherche, et tentative de connexion au serveur
+      LDAP en utilisant ce DN et le mot de passe fournis par le client
+      HTTP. Si la connexion échoue, refus ou restriction de
+      l'accès.
    • 
+    
 
-    
    Les vérifications d'autorisation ldap-attribute,
-    ldap-user, et ldap-group (niveau simple seulement)
-    utilisent des comparaisons.
    
+    
    Les directives utilisées durant la phase de recherche/connexion
+    sont les suivantes :
    
 
-    
    Cette directive n'a d'effet sur les comparaisons effectuées au
-    cours des traitements de groupe imbriqués, et lorsque la directive
-    AuthLDAPSearchAsUser
-    est aussi activée.
    
+    
+      
+      
+        
 
-    
    Cette directive ne doit être utilisée que si votre serveur LDAP
-     n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
-     utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
-     
    
+        
+      
 
-
    Voir aussi
    
-
-
-
    top
    
-
    Directive AuthLDAPCompareDNOnServer
    
-
    AuthLDAPURLSpécifie le serveur LDAP, le DN de base, l'attribut à
+	utiliser pour la recherche, ainsi que les filtres de recherche
+	supplémentaires.
    
-
-
-
-
-
-
-
-
    Description:Utilise le serveur LDAP pour comparer les DNs
    Syntaxe:AuthLDAPCompareDNOnServer on|off
    Défaut:AuthLDAPCompareDNOnServer on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    Lorsque cette directive est définie à on,
-    mod_authnz_ldap utilise le serveur LDAP pour
-    comparer les DNs. Il s'agit de la seule méthode infaillible pour
-    comparer les DNs. mod_authnz_ldap va rechercher
-    dans l'annuaire le DN spécifié par la directive Require dn, puis extraire ce DN et le
-    comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette
-    directive est à off, mod_authnz_ldap effectue une
-    simple comparaison de chaînes. Cette dernière approche peut produire
-    des faux négatifs, mais elle est beaucoup plus rapide. Notez
-    cependant que le cache de mod_ldap peut accélérer
-    la comparaison de DNs dans la plupart des situations.
    
+      
+        AuthLDAPBindDN
 
-
    
-
    top
    
-
    Directive AuthLDAPDereferenceAliases
    
-
-
-
-
-
-
-
-
-
    Description:À quel moment le module va déréférencer les
-alias
    Syntaxe:AuthLDAPDereferenceAliases never|searching|finding|always
    Défaut:AuthLDAPDereferenceAliases always
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    Cette directive permet de spécifier à quel moment
-    mod_authnz_ldap va déréférencer les alias au cours
-    des opérations liées à LDAP. La valeur par défaut est
-    always.
    
+        Un DN optionnel pour se connecter durant la phase de
+	recherche.
+      
 
-
    
-
    top
    
-
    Directive AuthLDAPGroupAttribute
    
-
-
-
-
-
-
-
-
-
    Description:L'attribut LDAP utilisé pour vérifier l'appartenance d'un
-utilisateur à un groupe.
    Syntaxe:AuthLDAPGroupAttribute attribut
    Défaut:AuthLDAPGroupAttribute member uniquemember
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    Cette directive permet de spécifier quel attribut LDAP est
-    utilisé pour vérifier l'appartenance d'un utilisateur à un
-    groupe. On peut spécifier plusieurs attributs en répétant cette
-    directive plusieurs fois. Si la directive n'est pas définie,
-    mod_authnz_ldap utilise les attributs
-    member et uniquemember.
    
+      
+        AuthLDAPBindPassword
 
-
    
-
    top
    
-
    Directive AuthLDAPGroupAttributeIsDN
    
-
-
-
-
-
-
-
-
-
    Description:Utilise le DN de l'utilisateur pour vérifier son
-appartenance à un groupe
    Syntaxe:AuthLDAPGroupAttributeIsDN on|off
    Défaut:AuthLDAPGroupAttributeIsDN on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    Lorsqu'elle est définie à on, cette directive
-    indique que c'est le DN de l'utilisateur qui doit être utilisé pour
-    vérifier son appartenance à un groupe. Dans le cas contraire, c'est
-    le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que
-    le client envoie le nom d'utilisateur bjenson, qui
-    correspond au DN LDAP cn=Babs Jenson,o=Example. Si la
-    directive est à on, mod_authnz_ldap va
-    vérifier si cn=Babs Jenson, o=Example est un membre du
-    groupe. Dans le cas contraire, mod_authnz_ldap
-    vérifiera si bjenson est un membre du groupe.
    
+        Un mot de passe optionnel pour se connecter durant la phase
+	de recherche.
+      
+    
 
-
    
-
    top
    
-
    Directive AuthLDAPInitialBindAsUser
    
-
-
-
-
-
-
-
-
-
-
    Description:Détermine si le serveur effectue la recherche initiale du
-DN en utilisant le nom propre de l'utilisateur pour l'authentification
-de base
-et non de manière anonyme, ou en utilisant des données d'authentification
-codées en dur pour le serveur
    Syntaxe:AuthLDAPInitialBindAsUser off|on
    Défaut:AuthLDAPInitialBindAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    
-    
    Par défaut, le serveur convertit le nom d'utilisateur pour
-    l'authentification de base en nom distinctif LDAP (DN) soit de
-    manière anonyme, soit avec un couple nom/mot de passe dédié. Cette
-    directive permet de forcer le serveur à utiliser les véritables nom
-    d'utilisateur et mot de passe fournis par l'utilisateur pour
-    effectuer la recherche initiale du DN.
    
 
-     
    Si le nom d'utilisateur ne peut pas s'authentifier directement
-     et nécessite de légères modifications, voir la directive AuthLDAPInitialBindPattern.
    
+
    La phase d'autorisation
    
 
-     
    Cette directive ne doit être utilisée que si votre serveur LDAP
-     n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
-     utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
-     
    
+    
    Au cours de la phase d'autorisation,
+    mod_authnz_ldap tente de déterminer si
+    l'utilisateur est autorisé à accéder à la ressource considérée. Une
+    grande partie de cette vérification consiste pour
+    mod_authnz_ldap en des opérations de comparaison au
+    niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue
+    sous le nom de phase de comparaison.
+    mod_authnz_ldap accepte les directives Require suivantes pour
+    déterminer si les informations de connexion permettent d'accorder
+    l'accès à l'utilisateur :
    
 
-     
    Non disponible dans la cas d'une autorisation seule
    
-         On ne peut utiliser cette directive que si ce module
-	 effectue une authentification, et n'a aucun effet si ce module
-	 n'est utilisé que pour les processus d'autorisation.
-     
    
+    
    
-
    top
    
-
    Directive AuthLDAPInitialBindPattern
    
-
-
-
-
-
-
-
-
-
-
    Description:Spécifie la modification a apporter au nom d'utilisateur
-pour l'authentification de base lors de l'authentification auprès du
-serveur LDAP pour effectuer une recherche de DN
    Syntaxe:AuthLDAPInitialBindPatternregex substitution
    Défaut:AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur
-distant utilisé tel quel)
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    
-    
    Si la directive AuthLDAPInitialBindAsUser est
-    définie à ON, le nom utilisateur pour l'authentification de
-    base sera transformé selon l'expression rationnelle
-    regex et l'argument substitution spécifiés.
    
+      
  • Avec la directive Require
+      ldap-dn, l'autorisation d'accès est accordée si le DN
+      spécifié par la directive correspond au DN extrait du résultat de
+      la recherche dans l'annuaire LDAP.
    • 
 
-    
    L'expression rationnelle est comparée au nom d'utilisateur pour
-    l'authentification de base courant. L'argument
-    substitution peut contenir des références arrières, mais
-    n'effectue aucune autre interpolation de variable.
    
+      
  • Avec la directive Require ldap-group,
+      l'autorisation d'accès est accordée si le DN extrait du résultat de
+      la recherche dans l'annuaire LDAP (ou le nom d'utilisateur fourni
+      par le client) appartient au groupe LDAP spécifié par la
+      directive, ou éventuellement à un de ses sous-groupes.
    • 
 
-    
    Cette directive ne doit être utilisée que si votre serveur LDAP
-     n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
-     utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
-     
    
+      
  • Avec la directive 
+      Require ldap-attribute, l'autorisation d'accès
+      est accordée si la valeur de l'attribut extraite de la recherche
+      dans l'annuaire LDAP correspond à la valeur spécifiée par la
+      directive.
    • 
 
-    
    AuthLDAPInitialBindPattern (.+) $1@example.com
    
+      
  • Avec la directive 
+      Require ldap-filter, l'autorisation d'accès
+      est accordée si le filtre de recherche renvoie un objet
+      utilisateur unique qui corresponde au DN de l'utilisateur
+      authentifié.
    • 
 
-    
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    
+      
  • Avec la directive 
+      Require ldap-search, l'autorisation d'accès
+      est accordée si le filtre de recherche renvoie avec succès
+      un seul objet correspondant aux critères avec tout nom distinctif
+      (DN).
    • 
 
+      
  • dans tous les autres cas, refus ou restriction de
+      l'accès.
    • 
+    
 
-    
    Non disponible dans la cas d'une autorisation seule
    
-         On ne peut utiliser cette directive que si ce module
-	 effectue une authentification, et n'a aucun effet si ce module
-	 n'est utilisé que pour les processus d'autorisation.
-     
    
-    
    Débogage
    
-        Le DN de substitution est enregistré dans la variable
-	d'environnement LDAP_BINDASUSER. Si l'expression
-	rationnelle ne convient pas, le nom d'utilisateur est utilisé
-	tel quel.
-    
    
-
-
    Voir aussi
    
-
-
    
-
    top
    
-
    Directive AuthLDAPMaxSubGroupDepth
    
-
-
-
-
-
-
-
-
-
-
    Description:Spécifie la profondeur d'imbrication des sous-groupes
-maximale prise en compte avant l'abandon de la recherche de
-l'utilisateur.
    Syntaxe:AuthLDAPMaxSubGroupDepth Nombre
    Défaut:AuthLDAPMaxSubGroupDepth 0
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP
-Apache ; la valeur par défaut était 10 dans les versions 2.4.x et les
-premières versions 2.5
    
-   
    Lorsque cette directive est définie à une valeur X
-   non nulle, en combinaison avec l'utilisation de la directive
-   Require ldap-group DN-groupe, les données de connexion
-   fournies seront utilisées pour vérifier l'appartenance de
-   l'utilisateur à l'objet de l'annuaire DN-groupe ou à
-   tout sous-groupe du groupe courant en tenant compte de la profondeur
-   d'imbrication maximale X spécifiée par la directive.
    
-   
    Se référer à la section Require
-   ldap-group pour un exemple plus détaillé.
    
-
-   
    Performances dans le cas des groupes imbriqués
    
-   
    Lorsque les directives
-   AuthLDAPSubGroupAttribute et
-   AuthLDAPGroupAttribute se recouvrent (comme
-   c'est le cas par défaut et requis par les schémas LDAP courants), la
-   recherche de sous-groupes au sein de grands groupes peut être très
-   longue. Si vos groupes sont très grands et non imbriqués, définissez
-   la directive AuthLDAPMaxSubGroupDepth à 0.
    
-   
    
-
-
-
    
-
    top
    
-
    Directive AuthLDAPRemoteUserAttribute
    
-
-
-
-
-
-
-
-
-
    Description:Spécifie l'attribut dont la valeur renvoyée au cours de la
-requête de l'utilisateur sera utilisée pour définir la variable
-d'environnement REMOTE_USER
    Syntaxe:AuthLDAPRemoteUserAttribute uid
    Défaut:none
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    Lorsque cette directive est définie, la variable d'environnement
-    REMOTE_USER sera définie à la valeur de l'attribut
-    spécifié. Assurez-vous que cet attribut soit bien inclus dans la
-    liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans
-    le cas contraire, cette directive n'aurait aucun effet. Si elle est
-    présente, cette directive l'emporte sur AuthLDAPRemoteUserIsDN. Elle
-    peut s'avérer utile par exemple, si vous souhaitez que les
-    utilisateurs se connectent à un site web en utilisant leur adresse
-    email, alors qu'une application sous-jacente nécessite un nom
-    d'utilisateur comme identifiant.
    
-    
    Cette directive n'a d'effet que si l'on utilise ce module pour
-    l'authentification.
    
-
-
    
-
    top
    
-
    Directive AuthLDAPRemoteUserIsDN
    
-
-
-
-
-
-
-
-
-
    Description:Utilise le DN de l'utilisateur pour définir la variable
-d'environnement REMOTE_USER
    Syntaxe:AuthLDAPRemoteUserIsDN on|off
    Défaut:AuthLDAPRemoteUserIsDN off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    Lorsque cette directive est à on, la variable d'environnement
-    REMOTE_USER sera définie avec la valeur du DN complet
-    de l'utilisateur authentifié, et non plus avec simplement le nom
-    d'utilisateur fourni par le client. Elle est définie à off par
-    défaut.
    
-    
    Cette directive n'a d'effet que si l'on utilise ce module pour
-    l'authentification.
    
-
-
    
-
    top
    
-
    Directive AuthLDAPSearchAsUser
    
-
-
-
-
-
-
-
-
-
-
    Description:Utilise les données d'authentification de l'utilisateur
-pour la recherche des autorisations
    Syntaxe:AuthLDAPSearchAsUser on|off
    Défaut:AuthLDAPSearchAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    
-    
    Lorsque cette directive est définie, et si
-    mod_authnz_ldap a authentifié l'utilisateur, les
-    recherches LDAP pour définir les autorisations utilisent le nom
-    distinctif (DN) trouvé et le mot de passe pour l'authentification de
-    base HTTP de l'utilisateur authentifié, au lieu des données
-    d'authentification configurées au niveau du serveur.
    
-
-    
    Les vérifications d'autorisation ldap-filter et
-    ldap-dn utilisent des recherches.
    
-
-    
    Cette directive n'a d'effet sur les comparaisons effectuées au
-    cours des traitements de groupe imbriqués, et lorsque la directive
-    AuthLDAPCompareAsUser
-    est aussi activée.
    
-
-     
    Cette directive ne doit être utilisée que si votre serveur LDAP
-     n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
-     utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
-     
    
-
-
-
    Voir aussi
    
-
-
    
-
    top
    
-
    Directive AuthLDAPSubGroupAttribute
    
-
-
-
-
-
-
-
-
-
-
    Description:Spécifie les noms d'attribut, un par directive, utilisés
-pour différencier les membres du groupe courant qui sont eux-mêmes des
-groupes.
    Syntaxe:AuthLDAPSubGroupAttribute attribut
    Défaut:AuthLDAPSubgroupAttribute member uniquemember
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP
-Apache
    
-    
    Un objet groupe LDAP peut contenir des membres qui sont des
-    utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
-    sous-groupes ou groupes imbriqués). La directive
-    AuthLDAPSubGroupAttribute spécifie l'attribut utilisé
-    pour identifier les groupes, alors que la directive
-    AuthLDAPGroupAttribute spécifie l'attribut utilisé
-    pour identifier les utilisateurs. On peut spécifier plusieurs
-    attributs en répétant la directive plusieurs fois. Si elle n'est pas
-    définie, mod_authnz_ldap utilise les attributs
-    member et uniqueMember.
    
-
-
    
-
    top
    
-
    Directive AuthLDAPSubGroupClass
    
-
-
-
-
-
-
-
-
-
-
    Description:Spécifie quelles valeurs d'objectClass LDAP identifient les
-objets de l'annuaire qui sont des groupes au cours du traitement des
-sous-groupes.
    Syntaxe:AuthLDAPSubGroupClass ObjectClass-LDAP
    Défaut:AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP
-Apache
    
-    
    Un objet groupe LDAP peut contenir des membres qui sont des
-    utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
-    sous-groupes ou groupes imbriqués). La directive
-    AuthLDAPSubGroupAttribute permet d'identifier les
-    membres qui sont des sous-groupes du groupe courant (à l'opposé des
-    membres utilisateurs). La directive
-    AuthLDAPSubGroupClass permet de spécifier les valeurs
-    d'objectClass LDAP utilisées pour vérifier que certains membres sont
-    en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent
-    alors faire l'objet d'une recherche d'autres membres utilisateurs ou
-    sous-groupes. On peut spécifier plusieurs attributs en répétant
-    cette directive plusieurs fois. Si cette directive n'est pas
-    définie, mod_authnz_ldap utilise les attributs
-    groupOfNames et groupOfUniqueNames.
    
-
-
    
-
    top
    
-
    Directive AuthLDAPUrl
    
-
-
-
-
-
-
-
-
    Description:L'URL permettant de spécifier les paramètres de la
-recherche LDAP
    Syntaxe:AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
-    
    Une URL conforme à la RFC 2255 qui permet de spécifier les
-    paramètres à utiliser pour la recherche dans l'annuaire LDAP. La
-    syntaxe de l'URL est :
    
-
    ldap://hôte:port/DN-de-base?attribut?portée?filtre
    
-    
    Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs
-    LDAP, la syntaxe sera :
    
-
    AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."
    
-
-
    Mise en garde : Si vous spécifiez plusieurs
-serveurs, vous devez en entourer la liste avec des guillemets ; dans le
-cas contraire, vous générerez une erreur : "AuthLDAPURL takes one
-argument, URL to define LDAP connection..". Vous pouvez bien
-entendu ajouter des paramètres de recherche à chacun des serveurs
-spécifiés.
    
-
-
    
-
    ldap
    
-
-        
    Pour ldap non sécurisé, utilisez la chaîne
-	ldap. Pour ldap sécurisé, utilisez à la place la
-	chaîne ldaps. LDAP sécurisé n'est disponible que si
-	Apache a été lié avec une bibliothèque LDAP supportant SSL.
    
-
-
    hôte:port
    
-
-        
    
-          
    Il s'agit du nom/port du serveur ldap
-	  (dont la valeur par défaut est
-	  localhost:389 pour ldap, et
-	  localhost:636 pour ldaps). Pour
-	  spécifier plusieurs serveurs LDAP redondants, indiquez
-	  simplement leur liste en les séparant par des espaces.
-	  mod_authnz_ldap tentera alors de se connecter
-	  à chacun des serveurs jusqu'à ce qu'il parvienne à se
-	  connecter avec succès. Notez qu'en cas de multiples serveurs
-	  LDAP, l'ensemble de l'URL LDAP doit être entourée de
-	  guillemets.
    
-
-          
    lorsqu'une connection a été établie avec un serveur, elle
-	  reste active pendant toute la durée de vie du processus
-	  httpd, ou jusqu'à ce que le serveur LDAP
-	  cesse de fonctionner.
    
-
-          
    Si le serveur LDAP cesse de fonctionner, et ainsi
-	  interrompt une
-	  connexion existante, mod_authnz_ldap tentera
-	  de se reconnecter en commençant par le premier serveur de la
-	  liste, et ainsi de suite avec les serveurs redondants
-	  suivants. Notez que ce processus n'a rien à voir avec une
-	  véritable recherche de type round-robin.
    
-        
    
-
-
    DN-de-base
    
-        
    Le DN de la branche de l'annuaire à partir de laquelle
-	toutes les recherches seront lancées. Il doit au moins
-	correspondre à la racine de votre annuaire, mais vous pouvez
-	aussi indiquer une branche plus spécifique.
    
-
-
    attribut
    
-
-        
    Il s'agit de l'attribut à utiliser pour la recherche.
-	Bien que la RFC
-	2255 autorise une liste d'attributs séparés par des virgules,
-	seul le premier sera retenu, sans tenir compte des autres
-	attributs fournis. Si aucun attribut n'est fourni, l'attribut
-	par défaut est uid. Il est judicieux de choisir un
-	attribut dont la valeur sera unique parmi toutes les entrées de
-	la branche de l'annuaire que vous aurez définie. Tous les
-	attributs spécifiés seront enregistrés dans des variables
-	d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir
-	être utilisés par d'autres modules.
    
-
-
    portée
    
-
-        
    Il s'agit de la portée de la recherche. Elle peut prendre
-	les valeurs one ou sub. Notez que la
-	RFC 2255 supporte aussi une portée de valeur base,
-	mais cette dernière n'est pas supportée par le module. Si la
-	portée n'est pas définie, ou si elle est définie à
-	base, c'est la valeur de portée par défaut
-	sub qui sera utilisée.
    
-
-
    filtre
    
-
-        
    Il s'agit d'un filtre de recherche LDAP valide. Si aucun
-	filtre n'est spécifié, le filtre par défaut
-	(objectClass=*) sera utilisé, ce qui corrspond à
-	une recherche de tous les types d'objets de l'arborescence. La
-	taille des filtres est limitée à environ 8000 caractères (valeur
-	de la macro MAX_STRING_LEN dans le code source
-	d'Apache), ce qui s'avère plus que suffisant pour la plupart des
-	applications. Le mot-clé none permet de désactiver
-	l'utilisation des filtres, ce qui peut s'avérer nécessaire avec
-	certains serveurs LDAP primitifs.
    
-
    
-
-    
    Pour une recherche, les attribut, filtre et nom d'utilisateur
-    fournis par le client HTTP sont combinés pour créer un filtre de
-    recherche du style :
-    (&(filtre)(attribut
-    =nom-utilisateur)).
    
-
-    
    Par exemple, considérons l'URL
-    ldap://ldap.example.com/o=Example?cn?sub?(posixid=*).
-    Lorsqu'un client tentera de se connecter en utilisant le nom
-    d'utilisateur Babs Jenson, le filtre de recherche sera
-    : (&(posixid=*)(cn=Babs Jenson)).
    
-
-    
    On peut encore ajouter un paramètre optionnel pour permettre à
-    l'URL LDAP de surcharger le type de connexion. Ce paramètre peut
-    prendre l'une des valeurs suivantes :
    
-
-
    
-    
    NONE
    
-        
    Établit une connexion non sécurisée sur le port LDAP par
-	défaut, ce qui est équivalent à ldap:// sur le port
-	389.
    
-    
    SSL
    
-        
    Établit une connexion sécurisée sur le port LDAP sécurisé
-	par défaut, ce qui est équivalent à ldaps://.
    
-    
    TLS | STARTTLS
    
-        
    Établit une connexion sécurisée par élévation de niveau sur
-	le port LDAP par défaut. Cette connexion sera initialisée sur le
-	port 389 par défaut, puis élevée à un niveau de connexion
-	sécurisée sur le même port.
    
-
    
-
-    
    Voir plus haut pour des exemples d'URLs définies par la directive
-    AuthLDAPURL.
    
-
-
    
-
    top
    
-
    
-
    Sommaire
    
-
-    
-
    top
    
-
    
-
    Mode opératoire
    
-
-    
    L'utilisateur se voit accorder l'accès selon un processus en deux
-    phases. La première phase est l'authentification, au cours de
-    laquelle le fournisseur d'authentification
-    mod_authnz_ldap vérifie que les informations de
-    connexion de l'utilisateur sont valides. Elle est aussi connue sous
-    le nom de phase de recherche/connexion (NdT : en anglais ou
-    dans le code source : search/bind). La deuxième
-    phase est l'autorisation, au cours de laquelle
-    mod_authnz_ldap détermine si l'utilisateur
-    authentifié a la permission d'accéder à la ressource considérée.
-    Elle est aussi connue sous le nom de phase de
-    comparaison (compare).
    
-
-    
    mod_authnz_ldap comporte un fournisseur
-    d'authentification authn_ldap et un gestionnaire d'autorisation
-    authz_ldap. Le fournisseur d'authentification authn_ldap peut être
-    invoqué en affectant la valeur ldap à la directive
-    AuthBasicProvider. Le
-    gestionnaire d'autorisation authz_ldap enrichit la liste des types
-    d'autorisations de la directive Require en y ajoutant les
-    valeurs ldap-user, ldap-dn et
-    ldap-group.
    
-
-
    La phase d'authentification
    
-
-    
    Au cours de la phase d'authentification,
-    mod_authnz_ldap recherche une entrée de l'annuaire
-    LDAP qui correspond au nom d'utilisateur fourni par le client HTTP.
-    Si une correspondance unique est trouvée,
-    mod_authnz_ldap tente de se connecter au serveur
-    hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot
-    de passe fourni par le client HTTP. Comme ce processus effectue tout
-    d'abord une recherche, puis une connexion, il est aussi connu sous
-    le nom de phase de recherche/connexion. Voici le détail des étapes
-    constituant la phase de recherche/connexion :
    
-
-    
      
-      
    1. Confection d'un filtre de recherche en combinant les attribut
-      et filtre définis par la directive AuthLDAPURL avec le nom d'utilisateur et le mot de
-      passe fournis par le client HTTP.
      2. 
-
-      
    2. Recherche dans l'annuaire LDAP en utilisant le filtre
-      confectionné précédemment. Si le résultat de la recherche est
-      négatif ou comporte plusieurs entrées, refus ou restriction de
-      l'accès.
      3. 
-
-      
    3. Extraction du DN (distinguished name) de l'entrée issue du
-      résultat de la recherche, et tentative de connexion au serveur
-      LDAP en utilisant ce DN et le mot de passe fournis par le client
-      HTTP. Si la connexion échoue, refus ou restriction de
-      l'accès.
      4. 
-    
    
-
-    
    Les directives utilisées durant la phase de recherche/connexion
-    sont les suivantes :
    
-
-    
-      
-      
-        
-
-        
-      
-
-      
-        
-
-        
-      
-
-      
-        
-
-        
-      
-    
    AuthLDAPURLSpécifie le serveur LDAP, le DN de base, l'attribut à
-	utiliser pour la recherche, ainsi que les filtres de recherche
-	supplémentaires.
    AuthLDAPBindDNUn DN optionnel pour se connecter durant la phase de
-	recherche.
    AuthLDAPBindPasswordUn mot de passe optionnel pour se connecter durant la phase
-	de recherche.
    
-
-
-
    La phase d'autorisation
    
-
-    
    Au cours de la phase d'autorisation,
-    mod_authnz_ldap tente de déterminer si
-    l'utilisateur est autorisé à accéder à la ressource considérée. Une
-    grande partie de cette vérification consiste pour
-    mod_authnz_ldap en des opérations de comparaison au
-    niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue
-    sous le nom de phase de comparaison.
-    mod_authnz_ldap accepte les directives Require suivantes pour
-    déterminer si les informations de connexion permettent d'accorder
-    l'accès à l'utilisateur :
    
-
-    
      
-      
    • Avec la directive Require ldap-user,
-      l'autorisation d'accès est accordée si le nom d'utilisateur
-      spécifié par la directive correspond au nom d'utilisateur fourni
-      par le client.
      • 
-
-      
    • Avec la directive Require
-      ldap-dn, l'autorisation d'accès est accordée si le DN
-      spécifié par la directive correspond au DN extrait du résultat de
-      la recherche dans l'annuaire LDAP.
      • 
-
-      
    • Avec la directive Require ldap-group,
-      l'autorisation d'accès est accordée si le DN extrait du résultat de
-      la recherche dans l'annuaire LDAP (ou le nom d'utilisateur fourni
-      par le client) appartient au groupe LDAP spécifié par la
-      directive, ou éventuellement à un de ses sous-groupes.
      • 
-
-      
    • Avec la directive 
-      Require ldap-attribute, l'autorisation d'accès
-      est accordée si la valeur de l'attribut extraite de la recherche
-      dans l'annuaire LDAP correspond à la valeur spécifiée par la
-      directive.
      • 
-
-      
    • Avec la directive 
-      Require ldap-filter, l'autorisation d'accès
-      est accordée si le filtre de recherche renvoie un objet
-      utilisateur unique qui corresponde au DN de l'utilisateur
-      authentifié.
      • 
-
-      
    • Avec la directive 
-      Require ldap-search, l'autorisation d'accès
-      est accordée si le filtre de recherche renvoie avec succès
-      un seul objet correspondant aux critères avec tout nom distinctif
-      (DN).
      • 
-
-      
    • dans tous les autres cas, refus ou restriction de
-      l'accès.
      • 
-    
    
-
-    
    Sous réserve du chargement de modules d'autorisation
-    supplémentaires, d'autres valeurs de la directive Require peuvent être
-    spécifiées.
    
+    
    Sous réserve du chargement de modules d'autorisation
+    supplémentaires, d'autres valeurs de la directive Require peuvent être
+    spécifiées.
    
 
     
      
         
    • L'accès est accordé à tous les utilisateurs authentifiés si
@@ -1061,526 +364,1223 @@ sp
 	Require ldap-group.
       
 
-      
-        AuthLDAPSubGroupClass
+      
+        AuthLDAPSubGroupClass
+
+        Spécifie les valeurs de classe d'objet LDAP à utiliser pour
+	déterminer si les objets extraits de l'annuaire sont bien des
+	objets de type groupe (et non des objets de type utilisateur),
+	au cours du traitement des sous-groupes initié par la directive
+	Require ldap-group.
+      
+    
+
+
    top
    
+
    
+
    Les directives requises
    
+
+    
    Les directives Require d'Apache sont utilisées
+    au cours de la phase d'autorisation afin de s'assurer que
+    l'utilisateur est autorisé à accéder à une ressource.
+    mod_authnz_ldap enrichit la liste des types d'autorisations avec les
+    valeurs ldap-user, ldap-dn,
+    ldap-group, ldap-attribute et
+    ldap-filter. D'autres types d'autorisations sont
+    disponibles, sous réserve du chargement de modules d'autorisation
+    supplémentaires.
    
+
+    
    A partir de la version 2.4.8, les directives require LDAP
+    supportent les expressions.
    
+
+
    Require ldap-user
    
+
+    
    La directive Require ldap-user permet de spécifier
+    les noms des utilisateurs autorisés à accéder à la ressource.
+    Lorsque mod_authnz_ldap a extrait un DN unique de
+    l'annuaire LDAP, il effectue une opération de comparaison LDAP en
+    utilisant le nom d'utilisateur spécifié par la directive
+    Require ldap-user, pour vérifier si ce nom
+    d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder
+    l'accès à plusieurs utilisateurs en plaçant plusieurs nom
+    d'utilisateurs sur la même ligne séparés par des espaces. Si un nom
+    d'utilisateur contient des espaces, il doit être entouré de
+    guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs
+    en utilisant une directive Require ldap-user par
+    utilisateur. Par exemple, avec la directive AuthLDAPURL définie à
+    ldap://ldap/o=Example?cn (spécifiant donc que l'attribut
+    cn sera utilisé pour les recherches), on pourra
+    utiliser les directives Require suivantes pour restreindre l'accès
+    :
    
+
    Require ldap-user "Barbara Jenson"
+Require ldap-user "Fred User"
+Require ldap-user "Joe Manager"
    
+
+
+    
    De par la manière dont mod_authnz_ldap traite
+    cette directive, Barbara Jenson peut s'authentifier comme
+    Barbara Jenson, Babs Jenson ou tout autre
+    cn sous lequel elle est enregistrée dans l'annuaire
+    LDAP. Une seule ligne Require ldap-user suffit pour
+    toutes les valeurs de l'attribut dans l'entrée LDAP de
+    l'utilisateur.
    
+
+    
    Si l'attribut uid avait été spécifié à la place de
+    l'attribut cn dans l'URL précédente, les trois lignes
+    ci-dessus auraient pû être condensées en une seule ligne :
    
+
    Require ldap-user bjenson fuser jmanager
    
+
+
+
+
    Require ldap-group
    
+
+    
    Cette directive permet de spécifier un groupe LDAP dont les
+    membres auront l'autorisation d'accès. Elle prend comme argument le
+    DN du groupe LDAP. Note : n'entourez pas le nom du groupe avec des
+    guillemets. Par exemple, supposons que l'entrée suivante existe dans
+    l'annuaire LDAP :
    
+
    dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
    
+
+    
    La directive suivante autoriserait alors l'accès à Fred et
+    Barbara :
    
+
    Require ldap-group cn=Administrators, o=Example
    
+
+
+    
    Les membres peuvent aussi se trouver dans les sous-groupes du
+    groupe LDAP spécifié si la directive AuthLDAPMaxSubGroupDepth a été
+    définie à une valeur supérieure à 0. Par exemple, supposons que les
+    entrées suivantes existent dans l'annuaire LDAP :
    
+
    dn: cn=Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Managers, o=Example
+uniqueMember: cn=Administrators, o=Example
+uniqueMember: cn=Users, o=Example
+
+dn: cn=Managers, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Bob Ellis, o=Example
+uniqueMember: cn=Tom Jackson, o=Example
+
+dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
+
+dn: cn=Users, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Allan Jefferson, o=Example
+uniqueMember: cn=Paul Tilley, o=Example
+uniqueMember: cn=Temporary Employees, o=Example
+
+dn: cn=Temporary Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Jim Swenson, o=Example
+uniqueMember: cn=Elliot Rhodes, o=Example
    
+
+    
    Les directives suivantes autoriseraient alors l'accès à Bob
+    Ellis, Tom Jackson, Barbara Jenson, Fred User, Allan Jefferson, et
+    Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes
+    (car ils sont situés dans un sous-groupe de niveau de profondeur 2)
+    :
    
+
    Require ldap-group cn=Employees, o=Example
+AuthLDAPMaxSubGroupDepth 1
    
+
+
+    
    Le comportement de cette directive est modifié par les directives
+    AuthLDAPGroupAttribute,
+    AuthLDAPGroupAttributeIsDN,
+    AuthLDAPMaxSubGroupDepth,
+    AuthLDAPSubGroupAttribute, et
+    AuthLDAPSubGroupClass.
    
+
+
+
    Require ldap-dn
    
+
+    
    La directive Require ldap-dn permet à
+    l'administrateur d'accorder l'utorisation d'accès en fonction du DN.
+    Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si
+    le DN extrait de
+    l'annuaire correspond au DN spécifié par la directive Require
+    ldap-dn, l'autorisation d'accès est accordée. Note :
+    n'entourez pas Le DN de guillemets.
    
+
+    
    La directive suivante accorderait l'accès à un DN spécifique
+    :
    
+
    Require ldap-dn cn=Barbara Jenson, o=Example
    
+
+
+    
    Le comportement ce cette directive est modifié par la directive
+    AuthLDAPCompareDNOnServer.
    
+
+
+
    Require ldap-attribute
    
+
+    
    La directive Require ldap-attribute permet à
+    l'administrateur d'accorder l'autorisation d'accès en fonction des
+    attributs de l'utilisateur authentifié dans l'annuaire LDAP. Si la
+    valeur de l'attribut dans l'annuaire correspond à la valeur
+    spécifiée par la directive, l'autorisation d'accès est accordée.
    
+
+    
    La directive suivante accorderait l'autorisation d'accès à tout
+    utilisateur dont l'attribut employeeType a pour valeur "actif" :
    
+
+    
    Require ldap-attribute employeeType=active
    
+
+
+    
    Plusieurs paires attribut/valeur peuvent être spécifiées par une
+    même directive en les séparant par des espaces, ou en définissant
+    plusieurs directives Require ldap-attribute. La logique
+    sous-jacente à une liste de paires attribut/valeur est une opération
+    OU. L'autorisation d'accès sera accordée si au moins une paire
+    attribut/valeur de la liste spécifiée correspond à la paire
+    attribut/valeur de l'utilisateur authentifié. Si elle contient des
+    espaces, la valeur, et seulement la valeur, doit être entourée de
+    guillemets.
    
+
+    
    La directive suivante accorderait l'autorisation d'accès à tout
+    utilisateur dont l'attribut city aurait pour valeur "San Jose", ou
+    donc l'attribut status aurait pour valeur "actif" :
    
+
+    
    Require ldap-attribute city="San Jose" status=active
    
+
+
+
+
+
    Require ldap-filter
    
+
+    
    La directive Require ldap-filter permet à
+    l'administrateur d'accorder l'autorisation d'accès en fonction d'un
+    filtre de recherche LDAP complexe. L'autorisation d'accès est
+    accordée si le DN renvoyé par le filtre de recherche correspond au
+    DN de l'utilisateur authentifié.
    
+
+    
    La directive suivante accorderait l'autorisation d'accès à tout
+    utilisateur possédant un téléphone cellulaire et faisant partie du
+    département "marketing" :
    
+
+    
    Require ldap-filter &(cell=*)(department=marketing)
    
+
+
+    
    Alors que la directive Require ldap-attribute se
+    contente d'une simple comparaison d'attributs, la directive
+    Require ldap-filter effectue une opération de recherche
+    dans l'annuaire LDAP en utilisant le filtre de recherche spécifié.
+    Si une simple comparaison d'attributs suffit, l'opération de
+    comparaison effectuée par ldap-attribute sera plus
+    rapide que l'opération de recherche effectuée par
+    ldap-filter, en particulier dans le cas d'un annuaire
+    LDAP de grande taille.
    
+
+    
    Lorsqu'on utilise une expression
+    rationnelle au sein d'un filtre, il faut bien s'assurer que les
+    filtres LDAP sont correctement échappés afin de se prémunir contre
+    toute injection LDAP. A cet effet, il est possible d'utiliser la
+    fonction ldap.
    
+
+
    <LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
+  Require ldap-filter (memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)
+</LocationMatch>
    
+
+
+
+
+
    Require ldap-search
    
+
+    
    La directive Require ldap-search permet à
+    l'administrateur d'autoriser l'accès en fonction d'un filtre de
+    recherche LDAP générique contenant une expression rationnelle. Si le filtre de
+    recherche renvoie une et une seule correspondance, l'accès est
+    accordé sans tenir compte du DN.
    
+
+    
    La directive suivante accorderait l'accès aux URLs correspondant
+    aux objets spécifiés dans le serveur LDAP :
    
+
+
    <LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
+Require ldap-search (cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}} Website)
+</LocationMatch>
    
+
+
+    
    Note : il faut bien s'assurer que les
+    expressions sont correctement échappés afin de se prémunir contre
+    toute injection LDAP. A cet effet, il est possible d'utiliser la
+    fonction ldap comme dans l'exemple ci-dessus.
    
+
 
-        Spécifie les valeurs de classe d'objet LDAP à utiliser pour
-	déterminer si les objets extraits de l'annuaire sont bien des
-	objets de type groupe (et non des objets de type utilisateur),
-	au cours du traitement des sous-groupes initié par la directive
-	Require ldap-group.
-      
-    
 
 
    top
    
 
    
-
    Les directives requises
    
+
    Exemples
    
 
-    
    Les directives Require d'Apache sont utilisées
-    au cours de la phase d'autorisation afin de s'assurer que
-    l'utilisateur est autorisé à accéder à une ressource.
-    mod_authnz_ldap enrichit la liste des types d'autorisations avec les
-    valeurs ldap-user, ldap-dn,
-    ldap-group, ldap-attribute et
-    ldap-filter. D'autres types d'autorisations sont
-    disponibles, sous réserve du chargement de modules d'autorisation
-    supplémentaires.
    
+    
      
+      
    • 
+        Accorde l'autorisation d'accès à tout utilisateur présent dans
+	l'annuaire LDAP, en utilisant son UID pour effectuer la
+	recherche :
+
      AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
+Require valid-user
      
 
-    
      A partir de la version 2.4.8, les directives require LDAP
-    supportent les expressions.
      
+      
      • 
 
-
      Require ldap-user
      
+      
    • 
+        L'exemple suivant est similaire au précédent, mais les champs
+	dont les valeurs par défaut conviennent sont omis. Notez aussi
+	la présence d'un annuaire LDAP redondant :
+
      AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
+Require valid-user
      
 
-    
      La directive Require ldap-user permet de spécifier
-    les noms des utilisateurs autorisés à accéder à la ressource.
-    Lorsque mod_authnz_ldap a extrait un DN unique de
-    l'annuaire LDAP, il effectue une opération de comparaison LDAP en
-    utilisant le nom d'utilisateur spécifié par la directive
-    Require ldap-user, pour vérifier si ce nom
-    d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder
-    l'accès à plusieurs utilisateurs en plaçant plusieurs nom
-    d'utilisateurs sur la même ligne séparés par des espaces. Si un nom
-    d'utilisateur contient des espaces, il doit être entouré de
-    guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs
-    en utilisant une directive Require ldap-user par
-    utilisateur. Par exemple, avec la directive AuthLDAPURL définie à
-    ldap://ldap/o=Example?cn (spécifiant donc que l'attribut
-    cn sera utilisé pour les recherches), on pourra
-    utiliser les directives Require suivantes pour restreindre l'accès
-    :
      
-
      Require ldap-user "Barbara Jenson"
-Require ldap-user "Fred User"
-Require ldap-user "Joe Manager"
      
+      
      • 
 
+      
    • 
+        Encore un exemple similaire aux précédents, mais cette fois,
+	c'est l'attribut cn qui est utilisé pour la recherche à la place
+	de l'UID. Notez que ceci peut poser problème si plusieurs
+	utilisateurs de l'annuaire partagent le même cn,
+	car une recherche sur le cn doit
+	retourner une entrée et une seule. C'est pourquoi cette
+	approche n'est pas recommandée : il est préférable de choisir un
+	attribut de votre annuaire dont l'unicité soit garantie, comme
+	uid.
+
      AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
+Require valid-user
      
 
-    
      De par la manière dont mod_authnz_ldap traite
-    cette directive, Barbara Jenson peut s'authentifier comme
-    Barbara Jenson, Babs Jenson ou tout autre
-    cn sous lequel elle est enregistrée dans l'annuaire
-    LDAP. Une seule ligne Require ldap-user suffit pour
-    toutes les valeurs de l'attribut dans l'entrée LDAP de
-    l'utilisateur.
      
+      
      • 
 
-    
      Si l'attribut uid avait été spécifié à la place de
-    l'attribut cn dans l'URL précédente, les trois lignes
-    ci-dessus auraient pû être condensées en une seule ligne :
      
-
      Require ldap-user bjenson fuser jmanager
      
+      
    • 
+        Accorde l'autorisation d'accès à tout utilisateur appartenant au
+	groupe Administrateurs. Les utilisateurs doivent s'authentifier
+	en utilisant leur UID :
+
      AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=Administrators, o=Example
      
 
+      
      • 
 
+      
    • 
+      Accorde l'accès à tout utilisateur appartenant au groupe dont le
+      nom correspond au nom d'hôte du serveur virtuel. Dans cet exemple,
+      on utilise une expression pour
+      construire le filtre.
+
      AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=%{SERVER_NAME}, o=Example
      
 
-
      Require ldap-group
      
+      
      • 
 
-    
      Cette directive permet de spécifier un groupe LDAP dont les
-    membres auront l'autorisation d'accès. Elle prend comme argument le
-    DN du groupe LDAP. Note : n'entourez pas le nom du groupe avec des
-    guillemets. Par exemple, supposons que l'entrée suivante existe dans
-    l'annuaire LDAP :
      
-
      dn: cn=Administrators, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Barbara Jenson, o=Example
-uniqueMember: cn=Fred User, o=Example
      
+      
    • 
+        Pour l'exemple suivant, on suppose que tout utilisateur de chez
+	Example qui dispose d'un bippeur alphanumérique possèdera un
+	attribut LDAP qpagePagerID. Seuls ces utilisateurs
+	(authentifiés via leur UID) se verront accorder l'autorisation
+	d'accès :
+
      AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
+Require valid-user
      
 
-    
      La directive suivante autoriserait alors l'accès à Fred et
-    Barbara :
      
-
      Require ldap-group cn=Administrators, o=Example
      
+      
      • 
+
+      
    • 
+        
      L'exemple suivant illustre la puissance des filtres pour
+	effectuer des requêtes complexes. Sans les filtres, il aurait
+	été nécessaire de créer un nouveau groupe LDAP et de s'assurer
+	de la synchronisation des membres du groupe avec les
+	utilisateurs possédant un bippeur. Tout devient limpide avec les
+	filtres. Nous avons pour but d'accorder l'autorisation d'accès à
+	tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager
+	qui ne possède pas de bippeur, mais doit tout de même pouvoir
+	accéder à la ressource :
      
+
      AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
+Require valid-user
      
 
 
-    
      Les membres peuvent aussi se trouver dans les sous-groupes du
-    groupe LDAP spécifié si la directive AuthLDAPMaxSubGroupDepth a été
-    définie à une valeur supérieure à 0. Par exemple, supposons que les
-    entrées suivantes existent dans l'annuaire LDAP :
      
-
      dn: cn=Employees, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Managers, o=Example
-uniqueMember: cn=Administrators, o=Example
-uniqueMember: cn=Users, o=Example
+        
      Ce dernier exemple peut sembler confus au premier abord ; en
+	fait, il permet de mieux comprendre à quoi doit ressembler le
+	filtre en fonction de l'utilisateur qui se connecte. Si Fred
+	User se connecte en tant que fuser, le filtre devra
+	ressembler à :
      
 
-dn: cn=Managers, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Bob Ellis, o=Example
-uniqueMember: cn=Tom Jackson, o=Example
+        
      (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))
      
 
-dn: cn=Administrators, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Barbara Jenson, o=Example
-uniqueMember: cn=Fred User, o=Example
+        
      Un recherche avec le filtre ci-dessus ne retournera un
+	résultat positif que si fuser dispose d'un bippeur. Si
+	Joe Manager se connecte en tant que jmanager, le filtre
+	devra ressembler à :
      
 
-dn: cn=Users, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Allan Jefferson, o=Example
-uniqueMember: cn=Paul Tilley, o=Example
-uniqueMember: cn=Temporary Employees, o=Example
+        
      (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))
      
 
-dn: cn=Temporary Employees, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Jim Swenson, o=Example
-uniqueMember: cn=Elliot Rhodes, o=Example
      
+        
      Un recherche avec le filtre ci-dessus retournera un
+	résultat positif que jmanager dispose d'un
+	bippeur ou non
      
+      
      • 
+    
    
+
    top
    
+
    
+
    Utilisation de TLS
    
 
-    
    Les directives suivantes autoriseraient alors l'accès à Bob
-    Ellis, Tom Jackson, Barbara Jenson, Fred User, Allan Jefferson, et
-    Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes
-    (car ils sont situés dans un sous-groupe de niveau de profondeur 2)
-    :
    
-
    Require ldap-group cn=Employees, o=Example
-AuthLDAPMaxSubGroupDepth 1
    
+    
    Pour l'utilisation de TLS, voir les directives du module
+    mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.
    
 
+    
    Un second paramètre optionnel peut être ajouté à la directive
+    AuthLDAPURL pour
+    remplacer le type de connexion par défaut défini par la directive
+    LDAPTrustedMode. Ceci
+    permettra de promouvoir la connexion établie via une URL du type
+    ldap:// au statut de connection sécurisée sur le même
+    port.
    
+
    top
    
+
    
+
    Utilisation de SSL
    
 
-    
    Le comportement de cette directive est modifié par les directives
-    AuthLDAPGroupAttribute,
-    AuthLDAPGroupAttributeIsDN,
-    AuthLDAPMaxSubGroupDepth,
-    AuthLDAPSubGroupAttribute, et
-    AuthLDAPSubGroupClass.
    
+    
    Pour l'utilisation de SSL, voir les directives du module
+    mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.
    
 
+    
    Pour spécifier un serveur LDAP sécurisé, utilisez
+    ldaps:// au lieu de
+    ldap:// dans la directive AuthLDAPURL.
    
+
    top
    
+
    
+
    Mise à disposition des informations de
+connexion
    
 
-
    Require ldap-dn
    
+    
    Au cours du processus d'authentification, les attributs LDAP
+    spécifiés par la directive authldapurl sont enregistrés
+    dans des variables d'environnement préfixées par la chaîne
+    "AUTHENTICATE_".
    
 
-    
    La directive Require ldap-dn permet à
-    l'administrateur d'accorder l'utorisation d'accès en fonction du DN.
-    Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si
-    le DN extrait de
-    l'annuaire correspond au DN spécifié par la directive Require
-    ldap-dn, l'autorisation d'accès est accordée. Note :
-    n'entourez pas Le DN de guillemets.
    
+    
    Au cours du processus d'autorisation, les attributs LDAP
+    spécifiés par la directive authldapurl sont enregistrés
+    dans des variables d'environnement préfixées par la chaîne
+    "AUTHORIZE_".
    
+
+    
    Si les champs attribut contiennent le nom, le CN et le numéro de
+    téléphone d'un utilisateur, un programme CGI pourra accéder à ces
+    informations sans devoir effectuer une autre requête LDAP pour
+    les extraire de l'annuaire.
    
+
+    
    Ceci a pour effet de simplifier considérablement le code et la
+    configuration nécessaire de certaines applications web.
    
+
+
    top
    
+
    
+
    Utilisation d'Active
+Directory
    
+
+    
    Active Directory peut supporter plusieurs domaines à la fois.
+    Pour faire la distinction entre les utilisateurs de plusieurs
+    domaines, on peut ajouter à l'entrée de l'utilisateur dans
+    l'annuaire un identifiant appelé Nom
+    Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se
+    compose en général du nom de compte de l'utilisateur, suivi du nom
+    du domaine considéré, par exemple untel@nz.example.com.
    
 
-    
    La directive suivante accorderait l'accès à un DN spécifique
-    :
    
-
    Require ldap-dn cn=Barbara Jenson, o=Example
    
+    
    Vous voudrez probablement configurer le module
+    mod_authnz_ldap afin de pouvoir authentifier les
+    utilisateurs de n'importe quel domaine de la forêt Active Directory.
+    Ainsi, untel@nz.example.com et
+    untel@au.example.com pourront être authentifiés en une
+    seule fois par la même requête.
    
 
+    
    Pour y parvenir, on utilise le concept de Catalogue Global
+    d'Active Directory. Ce Catalogue Global est une copie en lecture
+    seule des attributs sélectionnés de tous les serveurs de la forêt
+    Active Directory. Une requête vers le
+    Catalogue Global permet donc d'atteindre tous les domaines en une
+    seule fois, sans avoir à se connecter aux différents serveurs, via
+    des liaisons dont certaines peuvent être lentes.
    
 
-    
    Le comportement ce cette directive est modifié par la directive
-    AuthLDAPCompareDNOnServer.
    
+    
    Lorsqu'il est activé, la Catalogue Global est un serveur
+    d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL).
+    Pour rechercher un utilisateur, effectuez une recherche sur
+    l'attribut userPrincipalName, avec une base de recherche
+    vide, comme suit :
    
 
+
    AuthLDAPBindDN apache@example.com
+AuthLDAPBindPassword password
+AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
    
 
-
    Require ldap-attribute
    
 
-    
    La directive Require ldap-attribute permet à
-    l'administrateur d'accorder l'autorisation d'accès en fonction des
-    attributs de l'utilisateur authentifié dans l'annuaire LDAP. Si la
-    valeur de l'attribut dans l'annuaire correspond à la valeur
-    spécifiée par la directive, l'autorisation d'accès est accordée.
    
+    
    Les utilisateurs devront s'authentifier en entrant leur UPN, de
+    la formeuntel@nz.example.com.
    
 
-    
    La directive suivante accorderait l'autorisation d'accès à tout
-    utilisateur dont l'attribut employeeType a pour valeur "actif" :
    
+
    top
    
+
    
+
    Utilisation de Microsoft
+    FrontPage avec mod_authnz_ldap
    
 
-    
    Require ldap-attribute employeeType=active
    
+    
    Normalement, FrontPage utilise des fichiers utilisateur/groupe
+    spécifiques à FrontPage-web (c'est à dire les modules
+    mod_authn_file et
+    mod_authz_groupfile) pour effectuer toute
+    l'authentification. Malheureusement, il ne suffit pas de modifier
+    l'authentification LDAP en ajoutant les directives appropriées, car
+    ceci corromprait les formulaires de Permissions dans le
+    client FrontPage, qui sont censés modifier les fichiers
+    d'autorisation standards au format texte.
    
 
+    
    Lorsqu'un site web FrontPage a été créé, lui adjoindre
+    l'authentification LDAP consiste à ajouter les directives suivantes
+    à chaque fichier .htaccess qui sera créé dans
+    le site web :
    
+
    AuthLDAPURL       "the url"
+AuthGroupFile     mygroupfile
+Require group     mygroupfile
    
 
-    
    Plusieurs paires attribut/valeur peuvent être spécifiées par une
-    même directive en les séparant par des espaces, ou en définissant
-    plusieurs directives Require ldap-attribute. La logique
-    sous-jacente à une liste de paires attribut/valeur est une opération
-    OU. L'autorisation d'accès sera accordée si au moins une paire
-    attribut/valeur de la liste spécifiée correspond à la paire
-    attribut/valeur de l'utilisateur authentifié. Si elle contient des
-    espaces, la valeur, et seulement la valeur, doit être entourée de
-    guillemets.
    
 
-    
    La directive suivante accorderait l'autorisation d'accès à tout
-    utilisateur dont l'attribut city aurait pour valeur "San Jose", ou
-    donc l'attribut status aurait pour valeur "actif" :
    
+
    Comment ça marche
    
 
-    
    Require ldap-attribute city="San Jose" status=active
    
+    
    FrontPage restreint l'accès à un site web en ajoutant la
+    directive Require valid-user aux fichiers
+    .htaccess. La directive Require valid-user
+    permettra l'accès à tout utilisateur valide du point de vue
+    LDAP. Cela signifie que tout utilisateur possédant une entrée
+    dans l'annuaire LDAP sera considéré comme valide, alors que
+    FrontPage ne considère comme valides que les utilisateurs
+    enregistrés dans le fichier des utilisateurs local. En remplaçant
+    l'autorisation par groupe LDAP par une autorisation par fichier de
+    groupe, Apache sera en mesure de consulter le fichier des
+    utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP
+    - lors du processus d'autorisation des utilisateurs.
    
 
+    
    Une fois les directives ajoutées selon ce qui précède, les
+    utilisateurs FrontPage pourront effectuer toutes les opérations de
+    gestion à partir du client FrontPage.
    
 
 
+
    Avertissements
    
 
-
    Require ldap-filter
    
+    
      
+      
    • Lors du choix de l'URL LDAP, l'attribut à utiliser pour
+      l'authentification doit aussi être valide pour le fichier des
+      utilisateurs de mod_authn_file. A cette fin,
+      l'UID est idéal.
      • 
 
-    
      La directive Require ldap-filter permet à
-    l'administrateur d'accorder l'autorisation d'accès en fonction d'un
-    filtre de recherche LDAP complexe. L'autorisation d'accès est
-    accordée si le DN renvoyé par le filtre de recherche correspond au
-    DN de l'utilisateur authentifié.
      
+      
    • Lorsqu'ils ajoutent des utilisateurs via FrontPage, les
+      administrateurs de FrontPage doivent choisir des noms
+      d'utilisateurs qui existent déjà dans l'annuaire LDAP (pour des
+      raisons évidentes). De même, le mot de passe que l'administrateur
+      entre dans le formulaire est ignoré, car pour l'authentification,
+      Apache utilise le mot de passe de l'annuaire LDAP, et non le mot
+      de passe enregistré dans le fichier des utilisateurs, ce qui peut
+      semer la confusion parmi les administrateurs web.
      • 
 
-    
      La directive suivante accorderait l'autorisation d'accès à tout
-    utilisateur possédant un téléphone cellulaire et faisant partie du
-    département "marketing" :
      
+      
+      
    • Pour supporter FrontPage, Apache doit être compilé avec
+      mod_auth_basic, mod_authn_file
+      et mod_authz_groupfile. Ceci est dû au fait
+      qu'Apache doit utiliser le fichier de groupes de
+      mod_authz_groupfile pour déterminer le niveau
+      d'accès d'un utilisateur au site web FrontPage.
      • 
 
-    
      Require ldap-filter &(cell=*)(department=marketing)
      
+      
    • Les directives doivent être placées dans les fichiers
+      .htaccess. Elles ne fonctionneront pas si vous les
+      placez dans une section <Location> ou <Directory>. Ceci est dû au fait que pour savoir
+      où se trouve la liste des utilisateurs valides,
+      mod_authnz_ldap doit être en mesure d'atteindre
+      la directive AuthGroupFile qui se trouve
+      dans les fichiers .htaccess de FrontPage. Si les directives
+      de mod_authnz_ldap ne sont pas situées dans le
+      même fichier .htaccess que les directives FrontPage,
+      la configuration ne fonctionnera pas, car
+      mod_authnz_ldap ne sera jamais en mesure de
+      traiter le fichier .htaccess, et par conséquent ne
+      pourra jamais trouver le fichier des utilisateurs géré par
+      FrontPage.
      • 
+    
    
 
+
    
+
    top
    
+
    Directive AuthLDAPAuthorizePrefix
    
+
+
+
+
+
+
+
+
+
+
    Description:Spécifie le préfixe ajouté aux variables d'environnement
+durant la phase d'autorisation
    Syntaxe:AuthLDAPAuthorizePrefix préfixe
    Défaut:AuthLDAPAuthorizePrefix AUTHORIZE_
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    
+    
    Cette directive permet de spécifier le préfixe ajouté aux
+    variables d'environnement durant la phase d'autorisation. Si la
+    valeur spécifiée est AUTHENTICATE_, les utilisateurs de ces
+    variables d'environnement verront les mêmes informations, que le
+    serveur effectue une authentification, une autorisation, ou les
+    deux.
    
 
-    
    Alors que la directive Require ldap-attribute se
-    contente d'une simple comparaison d'attributs, la directive
-    Require ldap-filter effectue une opération de recherche
-    dans l'annuaire LDAP en utilisant le filtre de recherche spécifié.
-    Si une simple comparaison d'attributs suffit, l'opération de
-    comparaison effectuée par ldap-attribute sera plus
-    rapide que l'opération de recherche effectuée par
-    ldap-filter, en particulier dans le cas d'un annuaire
-    LDAP de grande taille.
    
+    
    Note
    
+    Aucune variable d'autorisation n'est définie lorsqu'un utilisateur
+    s'est vu autoriser l'accès via la directive Require
+    valid-user.
+    
    
 
-    
    Lorsqu'on utilise une expression
-    rationnelle au sein d'un filtre, il faut bien s'assurer que les
-    filtres LDAP sont correctement échappés afin de se prémunir contre
-    toute injection LDAP. A cet effet, il est possible d'utiliser la
-    fonction ldap.
    
+
    
+
    top
    
+
    Directive AuthLDAPBindAuthoritative
    
+
+
+
+
+
+
+
+
+
    Description:Détermine si l'on doit utiliser d'autres fournisseurs
+d'authentification lorsque le serveur ne peut pas valider les données
+d'authentification de l'utilisateur, alors que ce dernier possède un
+DN.
    Syntaxe:AuthLDAPBindAuthoritativeoff|on
    Défaut:AuthLDAPBindAuthoritative on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    Par défaut, des fournisseurs d'authentification sont appelés
+    si un utilisateur ne possède pas de DN, mais ne le sont pas si
+    l'utilisateur possède un DN et si son mot de passe ne peut pas être
+    vérifié lors d'une connexion au serveur LDAP. Si la directive
+    AuthLDAPBindAuthoritative est
+    définie à off, d'autres modules d'authentification
+    configurés auront une chance de valider le mot de passe de
+    l'utilisateur si la tentative de connexion au serveur LDAP échoue
+    pour une raison quelconque (avec les données d'authentification
+    fournies).
    
+    
    Ceci permet aux utilisateurs présent à la fois dans l'annuaire
+    LDAP et dans un fichier AuthUserFile de s'authentifier
+    lorsque le serveur LDAP est disponible, alors que le compte de
+    l'utilisateur est verrouillé ou que son mot de passe est
+    inutilisable pour une raison quelconque.
    
 
-
    <LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
-  Require ldap-filter (memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)
-</LocationMatch>
    
+
    Voir aussi
    
+
+
    
+
    top
    
+
    Directive AuthLDAPBindDN
    
+
+
+
+
+
+
+
+
    Description:Un DN optionnel pour se connecter au serveur
+LDAP
    Syntaxe:AuthLDAPBindDN dn
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    Cette directive permet de définir un DN optionnel pour se
+    connecter au serveur afin d'y rechercher des entrées. Si aucun DN
+    n'est spécifié, mod_authnz_ldap tentera une
+    connexion anonyme.
    
 
+
    
+
    top
    
+
    Directive AuthLDAPBindPassword
    
+
+
+
+
+
+
+
+
+
    Description:Mot de passe à utiliser en conjonction avec le DN de
+connexion
    Syntaxe:AuthLDAPBindPassword mot-de-passe
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:exec: est disponible depuis la version 2.4.5 du
+serveur HTTP Apache.
    
+    
    Cette directive permet de spécifier un mot de passe à utiliser en
+    conjonction avec le DN de connexion. Notez que ce mot de passe
+    constitue en général une donnée sensible, et doit donc être protégé
+    de manière appropriée. Vous ne devez utiliser les directives
+    AuthLDAPBindDN et AuthLDAPBindPassword que si
+    vous en avez vraiment besoin pour effectuer une recherche dans
+    l'annuaire.
    
 
+    
    Si la valeur commence par exec:, la commande résultante sera
+    exécutée, et la première ligne renvoyée sur la sortie standard sera
+    utilisée comme mot de passe.
    
+
    #Mot de passe utilisé tel quel
+AuthLDAPBindPassword secret
 
+#Exécute /path/to/program pour obtenir le mot de passe
+AuthLDAPBindPassword exec:/path/to/program
 
-
    Require ldap-search
    
+#Exécute /path/to/otherProgram avec un argument pour obtenir le mot de passe
+AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    
 
-    
    La directive Require ldap-search permet à
-    l'administrateur d'autoriser l'accès en fonction d'un filtre de
-    recherche LDAP générique contenant une expression rationnelle. Si le filtre de
-    recherche renvoie une et une seule correspondance, l'accès est
-    accordé sans tenir compte du DN.
    
 
-    
    La directive suivante accorderait l'accès aux URLs correspondant
-    aux objets spécifiés dans le serveur LDAP :
    
 
-
    <LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
-Require ldap-search (cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}} Website)
-</LocationMatch>
    
+
    
+
    top
    
+
    Directive AuthLDAPCharsetConfig
    
+
+
+
+
+
+
+
    Description:Chemin du fichier de configuration de la correspondance
+langage/jeu de caractères
    Syntaxe:AuthLDAPCharsetConfig chemin-fichier
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    La directive AuthLDAPCharsetConfig permet
+    de définir le chemin du fichier de configuration de la
+    correspondance langage/jeu de caractères. chemin-fichier
+    est un chemin relatif au répertoire défini par la directive
+    ServerRoot. Ce fichier contient une liste
+    de correspondances extension de langage/jeu de caractères. La
+    plupart des administrateurs utilisent le fichier
+    charset.conv fourni qui associe les extensions de
+    langage courantes à leurs jeux de caractères.
    
 
+    
    Le fichier contient des lignes au format suivant :
    
 
-    
    Note : il faut bien s'assurer que les
-    expressions sont correctement échappés afin de se prémunir contre
-    toute injection LDAP. A cet effet, il est possible d'utiliser la
-    fonction ldap comme dans l'exemple ci-dessus.
    
+    
    
+      extension de langage jeu de caractères
+      [Nom du langage] ...
+    
    
 
+    
    L'extension est insensible à la casse. Les lignes vides et les
+    lignes commençant par un dièse (#) sont ignorées.
    
 
+
    
+
    top
    
+
    Directive AuthLDAPCompareAsUser
    
+
+
+
+
+
+
+
+
+
+
    Description:Utilisation des données d'authentification de l'utilisateur
+pour effectuer les comparaisons pour l'attribution des autorisations
    Syntaxe:AuthLDAPCompareAsUser on|off
    Défaut:AuthLDAPCompareAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version version 2.3.6
    
+    
    Lorsque cette directive est définie, et si
+    mod_authnz_ldap a authentifié l'utilisateur, les
+    recherches LDAP pour les autorisations utilisent le nom distinctif
+    trouvé (DN) et le mot de passe d'authentification basique HTTP de
+    l'utilisateur authentifié au lieu des données d'authentification
+    configurées au niveau du serveur.
    
 
-
    top
    
-
    
-
    Exemples
    
+    
    Les vérifications d'autorisation ldap-attribute,
+    ldap-user, et ldap-group (niveau simple seulement)
+    utilisent des comparaisons.
    
 
-    
      
-      
    • 
-        Accorde l'autorisation d'accès à tout utilisateur présent dans
-	l'annuaire LDAP, en utilisant son UID pour effectuer la
-	recherche :
-
      AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
-Require valid-user
      
+    
      Cette directive n'a d'effet sur les comparaisons effectuées au
+    cours des traitements de groupe imbriqués, et lorsque la directive
+    AuthLDAPSearchAsUser
+    est aussi activée.
      
 
-      
      • 
+    
      Cette directive ne doit être utilisée que si votre serveur LDAP
+     n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
+     utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
+     
      
 
-      
    • 
-        L'exemple suivant est similaire au précédent, mais les champs
-	dont les valeurs par défaut conviennent sont omis. Notez aussi
-	la présence d'un annuaire LDAP redondant :
-
      AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
-Require valid-user
      
+
      Voir aussi
      
+
+
    
+
    top
    
+
    Directive AuthLDAPCompareDNOnServer
    
+
+
+
+
+
+
+
+
+
    Description:Utilise le serveur LDAP pour comparer les DNs
    Syntaxe:AuthLDAPCompareDNOnServer on|off
    Défaut:AuthLDAPCompareDNOnServer on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    Lorsque cette directive est définie à on,
+    mod_authnz_ldap utilise le serveur LDAP pour
+    comparer les DNs. Il s'agit de la seule méthode infaillible pour
+    comparer les DNs. mod_authnz_ldap va rechercher
+    dans l'annuaire le DN spécifié par la directive Require dn, puis extraire ce DN et le
+    comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette
+    directive est à off, mod_authnz_ldap effectue une
+    simple comparaison de chaînes. Cette dernière approche peut produire
+    des faux négatifs, mais elle est beaucoup plus rapide. Notez
+    cependant que le cache de mod_ldap peut accélérer
+    la comparaison de DNs dans la plupart des situations.
    
 
-      
+
    
+
    top
    
+
    Directive AuthLDAPDereferenceAliases
    
+
+
+
+
+
+
+
+
+
    Description:À quel moment le module va déréférencer les
+alias
    Syntaxe:AuthLDAPDereferenceAliases never|searching|finding|always
    Défaut:AuthLDAPDereferenceAliases always
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    Cette directive permet de spécifier à quel moment
+    mod_authnz_ldap va déréférencer les alias au cours
+    des opérations liées à LDAP. La valeur par défaut est
+    always.
    
 
-      
  • 
-        Encore un exemple similaire aux précédents, mais cette fois,
-	c'est l'attribut cn qui est utilisé pour la recherche à la place
-	de l'UID. Notez que ceci peut poser problème si plusieurs
-	utilisateurs de l'annuaire partagent le même cn,
-	car une recherche sur le cn doit
-	retourner une entrée et une seule. C'est pourquoi cette
-	approche n'est pas recommandée : il est préférable de choisir un
-	attribut de votre annuaire dont l'unicité soit garantie, comme
-	uid.
-
    AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
-Require valid-user
    
+
    • 
+
    top
    
+
    Directive AuthLDAPGroupAttribute
    
+
+
+
+
+
+
+
+
+
    Description:L'attribut LDAP utilisé pour vérifier l'appartenance d'un
+utilisateur à un groupe.
    Syntaxe:AuthLDAPGroupAttribute attribut
    Défaut:AuthLDAPGroupAttribute member uniquemember
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    Cette directive permet de spécifier quel attribut LDAP est
+    utilisé pour vérifier l'appartenance d'un utilisateur à un
+    groupe. On peut spécifier plusieurs attributs en répétant cette
+    directive plusieurs fois. Si la directive n'est pas définie,
+    mod_authnz_ldap utilise les attributs
+    member et uniquemember.
    
 
-      
+
    
+
    top
    
+
    Directive AuthLDAPGroupAttributeIsDN
    
+
+
+
+
+
+
+
+
+
    Description:Utilise le DN de l'utilisateur pour vérifier son
+appartenance à un groupe
    Syntaxe:AuthLDAPGroupAttributeIsDN on|off
    Défaut:AuthLDAPGroupAttributeIsDN on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    Lorsqu'elle est définie à on, cette directive
+    indique que c'est le DN de l'utilisateur qui doit être utilisé pour
+    vérifier son appartenance à un groupe. Dans le cas contraire, c'est
+    le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que
+    le client envoie le nom d'utilisateur bjenson, qui
+    correspond au DN LDAP cn=Babs Jenson,o=Example. Si la
+    directive est à on, mod_authnz_ldap va
+    vérifier si cn=Babs Jenson, o=Example est un membre du
+    groupe. Dans le cas contraire, mod_authnz_ldap
+    vérifiera si bjenson est un membre du groupe.
    
 
-      
  • 
-        Accorde l'autorisation d'accès à tout utilisateur appartenant au
-	groupe Administrateurs. Les utilisateurs doivent s'authentifier
-	en utilisant leur UID :
-
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
-Require ldap-group cn=Administrators, o=Example
    
+
    • 
+
    top
    
+
    Directive AuthLDAPInitialBindAsUser
    
+
+
+
+
+
+
+
+
+
+
    Description:Détermine si le serveur effectue la recherche initiale du
+DN en utilisant le nom propre de l'utilisateur pour l'authentification
+de base
+et non de manière anonyme, ou en utilisant des données d'authentification
+codées en dur pour le serveur
    Syntaxe:AuthLDAPInitialBindAsUser off|on
    Défaut:AuthLDAPInitialBindAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    
+    
    Par défaut, le serveur convertit le nom d'utilisateur pour
+    l'authentification de base en nom distinctif LDAP (DN) soit de
+    manière anonyme, soit avec un couple nom/mot de passe dédié. Cette
+    directive permet de forcer le serveur à utiliser les véritables nom
+    d'utilisateur et mot de passe fournis par l'utilisateur pour
+    effectuer la recherche initiale du DN.
    
 
-      
+     
    Si le nom d'utilisateur ne peut pas s'authentifier directement
+     et nécessite de légères modifications, voir la directive AuthLDAPInitialBindPattern.
    
 
-      
  • 
-      Accorde l'accès à tout utilisateur appartenant au groupe dont le
-      nom correspond au nom d'hôte du serveur virtuel. Dans cet exemple,
-      on utilise une expression pour
-      construire le filtre.
-
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
-Require ldap-group cn=%{SERVER_NAME}, o=Example
    
+     
    Cette directive ne doit être utilisée que si votre serveur LDAP
+     n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
+     utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
+     
    
 
-      
    • 
+     
    Non disponible dans la cas d'une autorisation seule
    
+         On ne peut utiliser cette directive que si ce module
+	 effectue une authentification, et n'a aucun effet si ce module
+	 n'est utilisé que pour les processus d'autorisation.
+     
    
 
-      
  • 
-        Pour l'exemple suivant, on suppose que tout utilisateur de chez
-	Example qui dispose d'un bippeur alphanumérique possèdera un
-	attribut LDAP qpagePagerID. Seuls ces utilisateurs
-	(authentifiés via leur UID) se verront accorder l'autorisation
-	d'accès :
-
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
-Require valid-user
    
+
    Voir aussi
    
+
+
    • 
+
    top
    
+
    Directive AuthLDAPInitialBindPattern
    
+
+
+
+
+
+
+
+
+
+
    Description:Spécifie la modification a apporter au nom d'utilisateur
+pour l'authentification de base lors de l'authentification auprès du
+serveur LDAP pour effectuer une recherche de DN
    Syntaxe:AuthLDAPInitialBindPatternregex substitution
    Défaut:AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur
+distant utilisé tel quel)
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    
+    
    Si la directive AuthLDAPInitialBindAsUser est
+    définie à ON, le nom utilisateur pour l'authentification de
+    base sera transformé selon l'expression rationnelle
+    regex et l'argument substitution spécifiés.
    
 
-      
+    
    L'expression rationnelle est comparée au nom d'utilisateur pour
+    l'authentification de base courant. L'argument
+    substitution peut contenir des références arrières, mais
+    n'effectue aucune autre interpolation de variable.
    
 
-      
  • 
-        
    L'exemple suivant illustre la puissance des filtres pour
-	effectuer des requêtes complexes. Sans les filtres, il aurait
-	été nécessaire de créer un nouveau groupe LDAP et de s'assurer
-	de la synchronisation des membres du groupe avec les
-	utilisateurs possédant un bippeur. Tout devient limpide avec les
-	filtres. Nous avons pour but d'accorder l'autorisation d'accès à
-	tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager
-	qui ne possède pas de bippeur, mais doit tout de même pouvoir
-	accéder à la ressource :
    
-
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
-Require valid-user
    
+    
    Cette directive ne doit être utilisée que si votre serveur LDAP
+     n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
+     utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
+     
    
 
+    
    AuthLDAPInitialBindPattern (.+) $1@example.com
    
 
-        
    Ce dernier exemple peut sembler confus au premier abord ; en
-	fait, il permet de mieux comprendre à quoi doit ressembler le
-	filtre en fonction de l'utilisateur qui se connecte. Si Fred
-	User se connecte en tant que fuser, le filtre devra
-	ressembler à :
    
+    
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    
 
-        
    (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))
    
 
-        
    Un recherche avec le filtre ci-dessus ne retournera un
-	résultat positif que si fuser dispose d'un bippeur. Si
-	Joe Manager se connecte en tant que jmanager, le filtre
-	devra ressembler à :
    
+    
    Non disponible dans la cas d'une autorisation seule
    
+         On ne peut utiliser cette directive que si ce module
+	 effectue une authentification, et n'a aucun effet si ce module
+	 n'est utilisé que pour les processus d'autorisation.
+     
    
+    
    Débogage
    
+        Le DN de substitution est enregistré dans la variable
+	d'environnement LDAP_BINDASUSER. Si l'expression
+	rationnelle ne convient pas, le nom d'utilisateur est utilisé
+	tel quel.
+    
    
 
-        
    (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))
    
+
    Voir aussi
    
+
+
    • 
+
    top
    
+
    Directive AuthLDAPMaxSubGroupDepth
    
+
+
+
+
+
+
+
+
+
+
    Description:Spécifie la profondeur d'imbrication des sous-groupes
+maximale prise en compte avant l'abandon de la recherche de
+l'utilisateur.
    Syntaxe:AuthLDAPMaxSubGroupDepth Nombre
    Défaut:AuthLDAPMaxSubGroupDepth 0
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP
+Apache ; la valeur par défaut était 10 dans les versions 2.4.x et les
+premières versions 2.5
    
+   
    Lorsque cette directive est définie à une valeur X
+   non nulle, en combinaison avec l'utilisation de la directive
+   Require ldap-group DN-groupe, les données de connexion
+   fournies seront utilisées pour vérifier l'appartenance de
+   l'utilisateur à l'objet de l'annuaire DN-groupe ou à
+   tout sous-groupe du groupe courant en tenant compte de la profondeur
+   d'imbrication maximale X spécifiée par la directive.
    
+   
    Se référer à la section Require
+   ldap-group pour un exemple plus détaillé.
    
 
-        
    Un recherche avec le filtre ci-dessus retournera un
-	résultat positif que jmanager dispose d'un
-	bippeur ou non
    
-      
-    
-
    top
    
-
    
-
    Utilisation de TLS
    
+   
    Performances dans le cas des groupes imbriqués
    
+   
    Lorsque les directives
+   AuthLDAPSubGroupAttribute et
+   AuthLDAPGroupAttribute se recouvrent (comme
+   c'est le cas par défaut et requis par les schémas LDAP courants), la
+   recherche de sous-groupes au sein de grands groupes peut être très
+   longue. Si vos groupes sont très grands et non imbriqués, définissez
+   la directive AuthLDAPMaxSubGroupDepth à 0.
    
+   
    
 
-    
    Pour l'utilisation de TLS, voir les directives du module
-    mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.
    
 
-    
    Un second paramètre optionnel peut être ajouté à la directive
-    AuthLDAPURL pour
-    remplacer le type de connexion par défaut défini par la directive
-    LDAPTrustedMode. Ceci
-    permettra de promouvoir la connexion établie via une URL du type
-    ldap:// au statut de connection sécurisée sur le même
-    port.
    
-
    top
    
-
    
-
    Utilisation de SSL
    
+
    
+
    top
    
+
    Directive AuthLDAPRemoteUserAttribute
    
+
+
+
+
+
+
+
+
+
    Description:Spécifie l'attribut dont la valeur renvoyée au cours de la
+requête de l'utilisateur sera utilisée pour définir la variable
+d'environnement REMOTE_USER
    Syntaxe:AuthLDAPRemoteUserAttribute uid
    Défaut:none
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    Lorsque cette directive est définie, la variable d'environnement
+    REMOTE_USER sera définie à la valeur de l'attribut
+    spécifié. Assurez-vous que cet attribut soit bien inclus dans la
+    liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans
+    le cas contraire, cette directive n'aurait aucun effet. Si elle est
+    présente, cette directive l'emporte sur AuthLDAPRemoteUserIsDN. Elle
+    peut s'avérer utile par exemple, si vous souhaitez que les
+    utilisateurs se connectent à un site web en utilisant leur adresse
+    email, alors qu'une application sous-jacente nécessite un nom
+    d'utilisateur comme identifiant.
    
+    
    Cette directive n'a d'effet que si l'on utilise ce module pour
+    l'authentification.
    
 
-    
    Pour l'utilisation de SSL, voir les directives du module
-    mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.
    
+
    
+
    top
    
+
    Directive AuthLDAPRemoteUserIsDN
    
+
+
+
+
+
+
+
+
+
    Description:Utilise le DN de l'utilisateur pour définir la variable
+d'environnement REMOTE_USER
    Syntaxe:AuthLDAPRemoteUserIsDN on|off
    Défaut:AuthLDAPRemoteUserIsDN off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    Lorsque cette directive est à on, la variable d'environnement
+    REMOTE_USER sera définie avec la valeur du DN complet
+    de l'utilisateur authentifié, et non plus avec simplement le nom
+    d'utilisateur fourni par le client. Elle est définie à off par
+    défaut.
    
+    
    Cette directive n'a d'effet que si l'on utilise ce module pour
+    l'authentification.
    
 
-    
    Pour spécifier un serveur LDAP sécurisé, utilisez
-    ldaps:// au lieu de
-    ldap:// dans la directive AuthLDAPURL.
    
-
    top
    
-
    
-
    Mise à disposition des informations de
-connexion
    
+
    
+
    top
    
+
    Directive AuthLDAPSearchAsUser
    
+
+
+
+
+
+
+
+
+
+
    Description:Utilise les données d'authentification de l'utilisateur
+pour la recherche des autorisations
    Syntaxe:AuthLDAPSearchAsUser on|off
    Défaut:AuthLDAPSearchAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    
+    
    Lorsque cette directive est définie, et si
+    mod_authnz_ldap a authentifié l'utilisateur, les
+    recherches LDAP pour définir les autorisations utilisent le nom
+    distinctif (DN) trouvé et le mot de passe pour l'authentification de
+    base HTTP de l'utilisateur authentifié, au lieu des données
+    d'authentification configurées au niveau du serveur.
    
 
-    
    Au cours du processus d'authentification, les attributs LDAP
-    spécifiés par la directive authldapurl sont enregistrés
-    dans des variables d'environnement préfixées par la chaîne
-    "AUTHENTICATE_".
    
+    
    Les vérifications d'autorisation ldap-filter et
+    ldap-dn utilisent des recherches.
    
 
-    
    Au cours du processus d'autorisation, les attributs LDAP
-    spécifiés par la directive authldapurl sont enregistrés
-    dans des variables d'environnement préfixées par la chaîne
-    "AUTHORIZE_".
    
+    
    Cette directive n'a d'effet sur les comparaisons effectuées au
+    cours des traitements de groupe imbriqués, et lorsque la directive
+    AuthLDAPCompareAsUser
+    est aussi activée.
    
 
-    
    Si les champs attribut contiennent le nom, le CN et le numéro de
-    téléphone d'un utilisateur, un programme CGI pourra accéder à ces
-    informations sans devoir effectuer une autre requête LDAP pour
-    les extraire de l'annuaire.
    
+     
    Cette directive ne doit être utilisée que si votre serveur LDAP
+     n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
+     utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
+     
    
 
-    
    Ceci a pour effet de simplifier considérablement le code et la
-    configuration nécessaire de certaines applications web.
    
 
-
    top
    
-
    
-
    Utilisation d'Active
-Directory
    
+
    Voir aussi
    
+
+
    
+
    top
    
+
    Directive AuthLDAPSubGroupAttribute
    
+
+
+
+
+
+
+
+
+
+
    Description:Spécifie les noms d'attribut, un par directive, utilisés
+pour différencier les membres du groupe courant qui sont eux-mêmes des
+groupes.
    Syntaxe:AuthLDAPSubGroupAttribute attribut
    Défaut:AuthLDAPSubgroupAttribute member uniquemember
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP
+Apache
    
+    
    Un objet groupe LDAP peut contenir des membres qui sont des
+    utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
+    sous-groupes ou groupes imbriqués). La directive
+    AuthLDAPSubGroupAttribute spécifie l'attribut utilisé
+    pour identifier les groupes, alors que la directive
+    AuthLDAPGroupAttribute spécifie l'attribut utilisé
+    pour identifier les utilisateurs. On peut spécifier plusieurs
+    attributs en répétant la directive plusieurs fois. Si elle n'est pas
+    définie, mod_authnz_ldap utilise les attributs
+    member et uniqueMember.
    
 
-    
    Active Directory peut supporter plusieurs domaines à la fois.
-    Pour faire la distinction entre les utilisateurs de plusieurs
-    domaines, on peut ajouter à l'entrée de l'utilisateur dans
-    l'annuaire un identifiant appelé Nom
-    Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se
-    compose en général du nom de compte de l'utilisateur, suivi du nom
-    du domaine considéré, par exemple untel@nz.example.com.
    
+
    
+
    top
    
+
    Directive AuthLDAPSubGroupClass
    
+
+
+
+
+
+
+
+
+
+
    Description:Spécifie quelles valeurs d'objectClass LDAP identifient les
+objets de l'annuaire qui sont des groupes au cours du traitement des
+sous-groupes.
    Syntaxe:AuthLDAPSubGroupClass ObjectClass-LDAP
    Défaut:AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP
+Apache
    
+    
    Un objet groupe LDAP peut contenir des membres qui sont des
+    utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
+    sous-groupes ou groupes imbriqués). La directive
+    AuthLDAPSubGroupAttribute permet d'identifier les
+    membres qui sont des sous-groupes du groupe courant (à l'opposé des
+    membres utilisateurs). La directive
+    AuthLDAPSubGroupClass permet de spécifier les valeurs
+    d'objectClass LDAP utilisées pour vérifier que certains membres sont
+    en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent
+    alors faire l'objet d'une recherche d'autres membres utilisateurs ou
+    sous-groupes. On peut spécifier plusieurs attributs en répétant
+    cette directive plusieurs fois. Si cette directive n'est pas
+    définie, mod_authnz_ldap utilise les attributs
+    groupOfNames et groupOfUniqueNames.
    
 
-    
    Vous voudrez probablement configurer le module
-    mod_authnz_ldap afin de pouvoir authentifier les
-    utilisateurs de n'importe quel domaine de la forêt Active Directory.
-    Ainsi, untel@nz.example.com et
-    untel@au.example.com pourront être authentifiés en une
-    seule fois par la même requête.
    
+
    
+
    top
    
+
    Directive AuthLDAPUrl
    
+
+
+
+
+
+
+
+
    Description:L'URL permettant de spécifier les paramètres de la
+recherche LDAP
    Syntaxe:AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    
+    
    Une URL conforme à la RFC 2255 qui permet de spécifier les
+    paramètres à utiliser pour la recherche dans l'annuaire LDAP. La
+    syntaxe de l'URL est :
    
+
    ldap://hôte:port/DN-de-base?attribut?portée?filtre
    
+    
    Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs
+    LDAP, la syntaxe sera :
    
+
    AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."
    
 
-    
    Pour y parvenir, on utilise le concept de Catalogue Global
-    d'Active Directory. Ce Catalogue Global est une copie en lecture
-    seule des attributs sélectionnés de tous les serveurs de la forêt
-    Active Directory. Une requête vers le
-    Catalogue Global permet donc d'atteindre tous les domaines en une
-    seule fois, sans avoir à se connecter aux différents serveurs, via
-    des liaisons dont certaines peuvent être lentes.
    
+
    Mise en garde : Si vous spécifiez plusieurs
+serveurs, vous devez en entourer la liste avec des guillemets ; dans le
+cas contraire, vous générerez une erreur : "AuthLDAPURL takes one
+argument, URL to define LDAP connection..". Vous pouvez bien
+entendu ajouter des paramètres de recherche à chacun des serveurs
+spécifiés.
    
 
-    
    Lorsqu'il est activé, la Catalogue Global est un serveur
-    d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL).
-    Pour rechercher un utilisateur, effectuez une recherche sur
-    l'attribut userPrincipalName, avec une base de recherche
-    vide, comme suit :
    
+
    
+
    ldap
    
 
-
    AuthLDAPBindDN apache@example.com
-AuthLDAPBindPassword password
-AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
    
+        
    Pour ldap non sécurisé, utilisez la chaîne
+	ldap. Pour ldap sécurisé, utilisez à la place la
+	chaîne ldaps. LDAP sécurisé n'est disponible que si
+	Apache a été lié avec une bibliothèque LDAP supportant SSL.
    
 
+
    hôte:port
    
 
-    
    Les utilisateurs devront s'authentifier en entrant leur UPN, de
-    la formeuntel@nz.example.com.
    
+        
    
+          
    Il s'agit du nom/port du serveur ldap
+	  (dont la valeur par défaut est
+	  localhost:389 pour ldap, et
+	  localhost:636 pour ldaps). Pour
+	  spécifier plusieurs serveurs LDAP redondants, indiquez
+	  simplement leur liste en les séparant par des espaces.
+	  mod_authnz_ldap tentera alors de se connecter
+	  à chacun des serveurs jusqu'à ce qu'il parvienne à se
+	  connecter avec succès. Notez qu'en cas de multiples serveurs
+	  LDAP, l'ensemble de l'URL LDAP doit être entourée de
+	  guillemets.
    
 
-
    top
    
-
    
-
    Utilisation de Microsoft
-    FrontPage avec mod_authnz_ldap
    
+          
    lorsqu'une connection a été établie avec un serveur, elle
+	  reste active pendant toute la durée de vie du processus
+	  httpd, ou jusqu'à ce que le serveur LDAP
+	  cesse de fonctionner.
    
 
-    
    Normalement, FrontPage utilise des fichiers utilisateur/groupe
-    spécifiques à FrontPage-web (c'est à dire les modules
-    mod_authn_file et
-    mod_authz_groupfile) pour effectuer toute
-    l'authentification. Malheureusement, il ne suffit pas de modifier
-    l'authentification LDAP en ajoutant les directives appropriées, car
-    ceci corromprait les formulaires de Permissions dans le
-    client FrontPage, qui sont censés modifier les fichiers
-    d'autorisation standards au format texte.
    
+          
    Si le serveur LDAP cesse de fonctionner, et ainsi
+	  interrompt une
+	  connexion existante, mod_authnz_ldap tentera
+	  de se reconnecter en commençant par le premier serveur de la
+	  liste, et ainsi de suite avec les serveurs redondants
+	  suivants. Notez que ce processus n'a rien à voir avec une
+	  véritable recherche de type round-robin.
    
+        
 
-    
    Lorsqu'un site web FrontPage a été créé, lui adjoindre
-    l'authentification LDAP consiste à ajouter les directives suivantes
-    à chaque fichier .htaccess qui sera créé dans
-    le site web :
    
-
    AuthLDAPURL       "the url"
-AuthGroupFile     mygroupfile
-Require group     mygroupfile
    
+
    DN-de-base
    
+        
    Le DN de la branche de l'annuaire à partir de laquelle
+	toutes les recherches seront lancées. Il doit au moins
+	correspondre à la racine de votre annuaire, mais vous pouvez
+	aussi indiquer une branche plus spécifique.
    
 
+
    attribut
    
 
-
    Comment ça marche
    
+        
    Il s'agit de l'attribut à utiliser pour la recherche.
+	Bien que la RFC
+	2255 autorise une liste d'attributs séparés par des virgules,
+	seul le premier sera retenu, sans tenir compte des autres
+	attributs fournis. Si aucun attribut n'est fourni, l'attribut
+	par défaut est uid. Il est judicieux de choisir un
+	attribut dont la valeur sera unique parmi toutes les entrées de
+	la branche de l'annuaire que vous aurez définie. Tous les
+	attributs spécifiés seront enregistrés dans des variables
+	d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir
+	être utilisés par d'autres modules.
    
 
-    
    FrontPage restreint l'accès à un site web en ajoutant la
-    directive Require valid-user aux fichiers
-    .htaccess. La directive Require valid-user
-    permettra l'accès à tout utilisateur valide du point de vue
-    LDAP. Cela signifie que tout utilisateur possédant une entrée
-    dans l'annuaire LDAP sera considéré comme valide, alors que
-    FrontPage ne considère comme valides que les utilisateurs
-    enregistrés dans le fichier des utilisateurs local. En remplaçant
-    l'autorisation par groupe LDAP par une autorisation par fichier de
-    groupe, Apache sera en mesure de consulter le fichier des
-    utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP
-    - lors du processus d'autorisation des utilisateurs.
    
+
    portée
    
 
-    
    Une fois les directives ajoutées selon ce qui précède, les
-    utilisateurs FrontPage pourront effectuer toutes les opérations de
-    gestion à partir du client FrontPage.
    
+        
    Il s'agit de la portée de la recherche. Elle peut prendre
+	les valeurs one ou sub. Notez que la
+	RFC 2255 supporte aussi une portée de valeur base,
+	mais cette dernière n'est pas supportée par le module. Si la
+	portée n'est pas définie, ou si elle est définie à
+	base, c'est la valeur de portée par défaut
+	sub qui sera utilisée.
    
 
+
    filtre
    
 
-
    Avertissements
    
+        
    Il s'agit d'un filtre de recherche LDAP valide. Si aucun
+	filtre n'est spécifié, le filtre par défaut
+	(objectClass=*) sera utilisé, ce qui corrspond à
+	une recherche de tous les types d'objets de l'arborescence. La
+	taille des filtres est limitée à environ 8000 caractères (valeur
+	de la macro MAX_STRING_LEN dans le code source
+	d'Apache), ce qui s'avère plus que suffisant pour la plupart des
+	applications. Le mot-clé none permet de désactiver
+	l'utilisation des filtres, ce qui peut s'avérer nécessaire avec
+	certains serveurs LDAP primitifs.
    
+
 
-    
      
-      
    • Lors du choix de l'URL LDAP, l'attribut à utiliser pour
-      l'authentification doit aussi être valide pour le fichier des
-      utilisateurs de mod_authn_file. A cette fin,
-      l'UID est idéal.
      • 
+    
      Pour une recherche, les attribut, filtre et nom d'utilisateur
+    fournis par le client HTTP sont combinés pour créer un filtre de
+    recherche du style :
+    (&(filtre)(attribut
+    =nom-utilisateur)).
      
 
-      
    • Lorsqu'ils ajoutent des utilisateurs via FrontPage, les
-      administrateurs de FrontPage doivent choisir des noms
-      d'utilisateurs qui existent déjà dans l'annuaire LDAP (pour des
-      raisons évidentes). De même, le mot de passe que l'administrateur
-      entre dans le formulaire est ignoré, car pour l'authentification,
-      Apache utilise le mot de passe de l'annuaire LDAP, et non le mot
-      de passe enregistré dans le fichier des utilisateurs, ce qui peut
-      semer la confusion parmi les administrateurs web.
      • 
+    
      Par exemple, considérons l'URL
+    ldap://ldap.example.com/o=Example?cn?sub?(posixid=*).
+    Lorsqu'un client tentera de se connecter en utilisant le nom
+    d'utilisateur Babs Jenson, le filtre de recherche sera
+    : (&(posixid=*)(cn=Babs Jenson)).
      
 
-      
-      
    • Pour supporter FrontPage, Apache doit être compilé avec
-      mod_auth_basic, mod_authn_file
-      et mod_authz_groupfile. Ceci est dû au fait
-      qu'Apache doit utiliser le fichier de groupes de
-      mod_authz_groupfile pour déterminer le niveau
-      d'accès d'un utilisateur au site web FrontPage.
      • 
+    
      On peut encore ajouter un paramètre optionnel pour permettre à
+    l'URL LDAP de surcharger le type de connexion. Ce paramètre peut
+    prendre l'une des valeurs suivantes :
      
 
-      
    • Les directives doivent être placées dans les fichiers
-      .htaccess. Elles ne fonctionneront pas si vous les
-      placez dans une section <Location> ou <Directory>. Ceci est dû au fait que pour savoir
-      où se trouve la liste des utilisateurs valides,
-      mod_authnz_ldap doit être en mesure d'atteindre
-      la directive AuthGroupFile qui se trouve
-      dans les fichiers .htaccess de FrontPage. Si les directives
-      de mod_authnz_ldap ne sont pas situées dans le
-      même fichier .htaccess que les directives FrontPage,
-      la configuration ne fonctionnera pas, car
-      mod_authnz_ldap ne sera jamais en mesure de
-      traiter le fichier .htaccess, et par conséquent ne
-      pourra jamais trouver le fichier des utilisateurs géré par
-      FrontPage.
      • 
-    
    
+
    
+    
    NONE
    
+        
    Établit une connexion non sécurisée sur le port LDAP par
+	défaut, ce qui est équivalent à ldap:// sur le port
+	389.
    
+    
    SSL
    
+        
    Établit une connexion sécurisée sur le port LDAP sécurisé
+	par défaut, ce qui est équivalent à ldaps://.
    
+    
    TLS | STARTTLS
    
+        
    Établit une connexion sécurisée par élévation de niveau sur
+	le port LDAP par défaut. Cette connexion sera initialisée sur le
+	port 389 par défaut, puis élevée à un niveau de connexion
+	sécurisée sur le même port.
    
+
    
+
+    
    Voir plus haut pour des exemples d'URLs définies par la directive
+    AuthLDAPURL.
    
 
 
    
 
diff --git a/docs/manual/mod/mod_authz_core.html.en b/docs/manual/mod/mod_authz_core.html.en
index 490563ef39..a9eb23b231 100644
--- a/docs/manual/mod/mod_authz_core.html.en
+++ b/docs/manual/mod/mod_authz_core.html.en
@@ -61,6 +61,210 @@
 
 
 
    top
    
+
    
+
    Authorization Containers
    
+
+    
    The authorization container directives
+    <RequireAll>,
+    <RequireAny>
+    and
+    <RequireNone>
+    may be combined with each other and with the
+    Require
+    directive to express complex authorization logic.
    
+
+    
    The example below expresses the following authorization logic.
+    In order to access the resource, the user must either be the
+    superadmin user, or belong to both the
+    admins group and the Administrators LDAP
+    group and either belong to the sales group or
+    have the LDAP dept attribute sales.
+    Furthermore, in order to access the resource, the user must
+    not belong to either the temps group or the
+    LDAP group Temporary Employees.
    
+
+    
    <Directory "/www/mydocs">
+    <RequireAll>
+        <RequireAny>
+            Require user superadmin
+            <RequireAll>
+                Require group admins
+                Require ldap-group "cn=Administrators,o=Airius"
+                <RequireAny>
+                    Require group sales
+                    Require ldap-attribute dept="sales"
+                </RequireAny>
+            </RequireAll>
+        </RequireAny>
+        <RequireNone>
+            Require group temps
+            Require ldap-group "cn=Temporary Employees,o=Airius"
+        </RequireNone>
+    </RequireAll>
+</Directory>
    
+
+
    top
    
+
    
+
    The Require Directives
    
+
+  
    mod_authz_core provides some generic authorization
+  providers which can be used with the
+  Require directive.
    
+
+  
    Require env
    
+
+    
    The env provider allows access to the server
+    to be controlled based on the existence of an environment variable. When Require
+    env env-variable is specified, then the request is
+    allowed access if the environment variable env-variable
+    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
+    mod_setenvif. Therefore, this directive can be
+    used to allow access based on such factors as the clients
+    User-Agent (browser type), Referer, or
+    other HTTP request header fields.
    
+
+    
    SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in
+<Directory "/docroot">
+    Require env let_me_in
+</Directory>
    
+
+
+    
    In this case, browsers with a user-agent string beginning
+    with KnockKnock/2.0 will be allowed access, and all
+    others will be denied.
    
+
+    
    When the server looks up a path via an internal 
+    subrequest such as looking 
+    for a DirectoryIndex 
+    or generating a directory listing with mod_autoindex,
+    per-request environment variables are not inherited in the 
+    subrequest. Additionally, 
+    SetEnvIf directives
+    are not separately evaluated in the subrequest due to the API phases
+    mod_setenvif takes action in.
    
+
+  
+
+  
    Require all
    
+
+    
    The all provider mimics the functionality that
+    was previously provided by the 'Allow from all' and 'Deny from all'
+    directives.  This provider can take one of two arguments which are
+    'granted' or 'denied'.  The following examples will grant or deny
+    access to all requests.
    
+
+    
    Require all granted
    
+
+
+    
    Require all denied
    
+
+
+  
+
+  
    Require method
    
+
+    
    The method provider allows using the HTTP method in
+    authorization decisions. The GET and HEAD methods are treated as
+    equivalent. The TRACE method is not available to this provider,
+    use TraceEnable instead.
    
+
+    
    The following example will only allow GET, HEAD, POST, and OPTIONS
+    requests:
    
+
+    
    Require method GET POST OPTIONS
    
+
+
+    
    The following example will allow GET, HEAD, POST, and OPTIONS
+    requests without authentication, and require a valid user for all other
+    methods:
    
+
+    
    <RequireAny>
+     Require method GET POST OPTIONS
+     Require valid-user
+</RequireAny>
    
+
+
+  
+
+  
    Require expr
    
+
+  
    The expr provider allows basing authorization
+  decisions on arbitrary expressions.
    
+
+    
    Require expr %{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17
    
+
+
+    
    <RequireAll>
+    Require expr "!(%{QUERY_STRING} =~ /secret/)"
+    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
+</RequireAll>
    
+
+
+    
    Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
    
+
+
+  
    The syntax is described in the ap_expr
+  documentation.
    
+
+  
    Normally, the expression is evaluated before authentication. However, if
+  the expression returns false and references the variable
+  %{REMOTE_USER}, authentication will be performed and
+  the expression will be re-evaluated.
    
+
+  
+
+
+
    top
    
+
    
+
    Creating Authorization Provider Aliases
    
+
+    
    Extended authorization providers can be created within the configuration
+    file and assigned an alias name.  The alias providers can then be referenced
+    through the Require directive
+    in the same way as a base authorization provider.  Besides the ability to
+    create and alias an extended provider, it also allows the same extended
+    authorization provider to be referenced by multiple locations.
+    
    
+
+    
    Example
    
+        
    The example below creates two different ldap authorization provider
+        aliases based on the ldap-group authorization provider.  This example
+        allows a single authorization location to check group membership within
+        multiple ldap hosts:
+        
    
+
+        
    <AuthzProviderAlias ldap-group ldap-group-alias1 "cn=my-group,o=ctx">
+    AuthLDAPBindDN "cn=youruser,o=ctx"
+    AuthLDAPBindPassword yourpassword
+    AuthLDAPURL "ldap://ldap.host/o=ctx"
+</AuthzProviderAlias>
+
+<AuthzProviderAlias ldap-group ldap-group-alias2 "cn=my-other-group,o=dev">
+    AuthLDAPBindDN "cn=yourotheruser,o=dev"
+    AuthLDAPBindPassword yourotherpassword
+    AuthLDAPURL "ldap://other.ldap.host/o=dev?cn"
+</AuthzProviderAlias>
+
+Alias "/secure" "/webpages/secure"
+<Directory "/webpages/secure">
+    Require all granted
+
+    AuthBasicProvider file
+
+    AuthType Basic
+    AuthName LDAP_Protected_Place
+
+    #implied OR operation
+    Require ldap-group-alias1
+    Require ldap-group-alias2
+</Directory>
    
+
+    
+
+
    
+
    top
    
 
    AuthMerging Directive
    
 
  • Authentication, Authorization,
     and Access Control
    • 
-
-
    top
    
-
    
-
    Authorization Containers
    
-
-    
    The authorization container directives
-    <RequireAll>,
-    <RequireAny>
-    and
-    <RequireNone>
-    may be combined with each other and with the
-    Require
-    directive to express complex authorization logic.
    
-
-    
    The example below expresses the following authorization logic.
-    In order to access the resource, the user must either be the
-    superadmin user, or belong to both the
-    admins group and the Administrators LDAP
-    group and either belong to the sales group or
-    have the LDAP dept attribute sales.
-    Furthermore, in order to access the resource, the user must
-    not belong to either the temps group or the
-    LDAP group Temporary Employees.
    
-
-    
    <Directory "/www/mydocs">
-    <RequireAll>
-        <RequireAny>
-            Require user superadmin
-            <RequireAll>
-                Require group admins
-                Require ldap-group "cn=Administrators,o=Airius"
-                <RequireAny>
-                    Require group sales
-                    Require ldap-attribute dept="sales"
-                </RequireAny>
-            </RequireAll>
-        </RequireAny>
-        <RequireNone>
-            Require group temps
-            Require ldap-group "cn=Temporary Employees,o=Airius"
-        </RequireNone>
-    </RequireAll>
-</Directory>
    
-
-
    top
    
-
    
-
    The Require Directives
    
-
-  
    mod_authz_core provides some generic authorization
-  providers which can be used with the
-  Require directive.
    
-
-  
    Require env
    
-
-    
    The env provider allows access to the server
-    to be controlled based on the existence of an environment variable. When Require
-    env env-variable is specified, then the request is
-    allowed access if the environment variable env-variable
-    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
-    mod_setenvif. Therefore, this directive can be
-    used to allow access based on such factors as the clients
-    User-Agent (browser type), Referer, or
-    other HTTP request header fields.
    
-
-    
    SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in
-<Directory "/docroot">
-    Require env let_me_in
-</Directory>
    
-
-
-    
    In this case, browsers with a user-agent string beginning
-    with KnockKnock/2.0 will be allowed access, and all
-    others will be denied.
    
-
-    
    When the server looks up a path via an internal 
-    subrequest such as looking 
-    for a DirectoryIndex 
-    or generating a directory listing with mod_autoindex,
-    per-request environment variables are not inherited in the 
-    subrequest. Additionally, 
-    SetEnvIf directives
-    are not separately evaluated in the subrequest due to the API phases
-    mod_setenvif takes action in.
    
-
-  
-
-  
    Require all
    
-
-    
    The all provider mimics the functionality that
-    was previously provided by the 'Allow from all' and 'Deny from all'
-    directives.  This provider can take one of two arguments which are
-    'granted' or 'denied'.  The following examples will grant or deny
-    access to all requests.
    
-
-    
    Require all granted
    
-
-
-    
    Require all denied
    
-
-
-  
-
-  
    Require method
    
-
-    
    The method provider allows using the HTTP method in
-    authorization decisions. The GET and HEAD methods are treated as
-    equivalent. The TRACE method is not available to this provider,
-    use TraceEnable instead.
    
-
-    
    The following example will only allow GET, HEAD, POST, and OPTIONS
-    requests:
    
-
-    
    Require method GET POST OPTIONS
    
-
-
-    
    The following example will allow GET, HEAD, POST, and OPTIONS
-    requests without authentication, and require a valid user for all other
-    methods:
    
-
-    
    <RequireAny>
-     Require method GET POST OPTIONS
-     Require valid-user
-</RequireAny>
    
-
-
-  
-
-  
    Require expr
    
-
-  
    The expr provider allows basing authorization
-  decisions on arbitrary expressions.
    
-
-    
    Require expr %{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17
    
-
-
-    
    <RequireAll>
-    Require expr "!(%{QUERY_STRING} =~ /secret/)"
-    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
-</RequireAll>
    
-
-
-    
    Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
    
-
-
-  
    The syntax is described in the ap_expr
-  documentation.
    
-
-  
    Normally, the expression is evaluated before authentication. However, if
-  the expression returns false and references the variable
-  %{REMOTE_USER}, authentication will be performed and
-  the expression will be re-evaluated.
    
-
-  
-
-
-
    top
    
-
    
-
    Creating Authorization Provider Aliases
    
-
-    
    Extended authorization providers can be created within the configuration
-    file and assigned an alias name.  The alias providers can then be referenced
-    through the Require directive
-    in the same way as a base authorization provider.  Besides the ability to
-    create and alias an extended provider, it also allows the same extended
-    authorization provider to be referenced by multiple locations.
-    
    
-
-    
    Example
    
-        
    The example below creates two different ldap authorization provider
-        aliases based on the ldap-group authorization provider.  This example
-        allows a single authorization location to check group membership within
-        multiple ldap hosts:
-        
    
-
-        
    <AuthzProviderAlias ldap-group ldap-group-alias1 "cn=my-group,o=ctx">
-    AuthLDAPBindDN "cn=youruser,o=ctx"
-    AuthLDAPBindPassword yourpassword
-    AuthLDAPURL "ldap://ldap.host/o=ctx"
-</AuthzProviderAlias>
-
-<AuthzProviderAlias ldap-group ldap-group-alias2 "cn=my-other-group,o=dev">
-    AuthLDAPBindDN "cn=yourotheruser,o=dev"
-    AuthLDAPBindPassword yourotherpassword
-    AuthLDAPURL "ldap://other.ldap.host/o=dev?cn"
-</AuthzProviderAlias>
-
-Alias "/secure" "/webpages/secure"
-<Directory "/webpages/secure">
-    Require all granted
-
-    AuthBasicProvider file
-
-    AuthType Basic
-    AuthName LDAP_Protected_Place
-
-    #implied OR operation
-    Require ldap-group-alias1
-    Require ldap-group-alias2
-</Directory>
    
-
-    
-
 
    
diff --git a/docs/manual/mod/mod_authz_core.html.fr b/docs/manual/mod/mod_authz_core.html.fr
index 0374e8c3cc..c51e596dc3 100644
--- a/docs/manual/mod/mod_authz_core.html.fr
+++ b/docs/manual/mod/mod_authz_core.html.fr
@@ -47,7 +47,13 @@ d'Apache HTTPD
    
 
    Description:Controls the manner in which each configuration section's
@@ -427,210 +631,6 @@ must succeed for the enclosing directive to not fail.
    
 
 
 
 
    
     permet aussi l'application d'une logique élaborée au déroulement du
     processus d'autorisation.
    
 
    
-
+
    top
    
+
    
+
    Conteneurs d'autorisation
    
+
+    
    Les directives de conteneur d'autorisation <RequireAll>,
+    <RequireAny> et <RequireNone>
+    peuvent être combinées entre elles et avec la directive Require pour construire une
+    logique d'autorisation complexe.
    
+
+    
    L'exemple ci-dessous illustre la logique d'autorisation suivante.
+    Pour pouvoir accéder à la ressource, l'utilisateur doit être
+    l'utilisateur superadmin, ou appartenir aux deux
+    groupes LDAP admins et Administrateurs et
+    soit appartenir au groupe ventes, soit avoir
+    ventes comme valeur de l'attribut LDAP
+    dept. De plus, pour pouvoir accéder à la ressource,
+    l'utilisateur ne doit appartenir ni au groupe temps, ni
+    au groupe LDAP Employés temporaires.
    
+
+    
    <Directory /www/mydocs>
+    <RequireAll>
+        <RequireAny>
+            Require user superadmin
+            <RequireAll>
+            Require group admins
+            Require ldap-group cn=Administrateurs,o=Airius
+                <RequireAny>
+                Require group ventes
+                Require ldap-attribute dept="ventes"
+                </RequireAny>
+            </RequireAll>
+        </RequireAny>
+        <RequireNone>
+            Require group temps
+            Require ldap-group cn=Employés temporaires,o=Airius
+        </RequireNone>
+    </RequireAll>
+</Directory>
    
+
+
    top
    
+
    
+
    Les directives Require
    
+
+  
    Le module mod_authz_core met à disposition des
+  fournisseurs d'autorisation génériques utilisables avec la directive
+  Require.
    
+
+  
    Require env
    
+
+    
    Le fournisseur env permet de contrôler l'accès au
+    serveur en fonction de l'existence d'une variable d'environnement. Lorsque Require
+    env env-variable est spécifié, la requête se voit
+    autoriser l'accès si la variable d'environnement
+    env-variable existe. Le serveur permet de définir
+    facilement des variables d'environnement en fonction des
+    caractéristiques de la requête du client via les directives fournies
+    par le module mod_setenvif. Cette directive Require
+    env permet donc de contrôler l'accès en fonction des
+    valeurs des en-têtes de la requête HTTP tels que
+    User-Agent (type de navigateur), Referer,
+    entre autres.
    
+
+    
    SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
+<Directory /docroot>
+    Require env let_me_in
+</Directory>
    
+
+
+    
    Avec cet exemple, les navigateurs dont la chaîne user-agent
+    commence par KnockKnock/2.0 se verront autoriser
+    l'accès, alors que tous les autres seront rejetés.
    
+
+    
    Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la
+   recherche d'un DirectoryIndex), ou lorsqu'il génère un
+   listing du contenu d'un répertoire via le module
+   mod_autoindex, la sous-requête n'hérite pas des
+   variables d'environnement spécifiques à la requête. En outre, à cause
+   des phases de l'API auxquelles mod_setenvif prend
+   part, les directives SetEnvIf ne sont pas évaluées
+   séparément dans la sous-requête.
    
+
+  
+
+  
    Require all
    
+
+    
    Le fournisseur all reproduit la fonctionnalité
+    précédemment fournie par les directives 'Allow from all' et 'Deny
+    from all'. Il accepte un argument dont les deux valeurs possibles
+    sont : 'granted' ou 'denied'. Les exemples suivants autorisent ou
+    interdisent l'accès à toutes les requêtes.
    
+
+    
    Require all granted
    
+
+
+    
    Require all denied
    
+
+
+  
+
+  
    Require method
    
+
+    
    Le fournisseur method permet d'utiliser la méthode
+    HTTP dans le processus d'autorisation. Les méthodes GET et HEAD sont
+    ici considérées comme équivalentes. La méthode TRACE n'est pas
+    supportée par ce fournisseur ; utilisez à la place la directive
+    TraceEnable.
    
+
+    
    Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et
+    OPTIONS sont autorisées :
    
+
+    
    Require method GET POST OPTIONS
    
+
+
+    
    Dans l'exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS
+    sont autorisées sans authentification, alors que toutes les autres
+    méthodes nécessitent un utilisateur valide :
    
+
+    
    <RequireAny>
+     Require method GET POST OPTIONS
+     Require valid-user
+</RequireAny>
    
+
+
+  
+  
    Require expr
    
+
+  
    Le fournisseur expr permet d'accorder l'autorisation
+  d'accès en fonction d'expressions arbitraires.
    
+
+    
    Require expr %{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17
    
+
+
+    
    <RequireAll>
+    Require expr "!(%{QUERY_STRING} =~ /secret/)"
+    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
+</RequireAll>
    
+
+
+    
    Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
    
+
+
+    
    La syntaxe de l'expression est décrite dans la documentation de ap_expr.
    
+
+    
    Normalement, l'expression est évaluée avant l'authentification.
+    Cependant, si l'expression renvoie false et se réfère à la variable
+    %{REMOTE_USER}, le processus d'authentification sera
+    engagé et l'expression réévaluée.
    
+
+  
+
+
    top
    
+
    
+
    Création des alias du fournisseur
+d'autorisation
    
+
+    
    Il est possible de créer des fournisseurs d'autorisation étendus
+    dans le fichier de configuration et de leur assigner un nom d'alias.
+    On peut ensuite utiliser ces fournisseurs aliasés dans une
+    directive Require de
+    la même manière qu'on le ferait pour des fournisseurs d'autorisation
+    de base. En plus de la possibilité de créer et d'aliaser un
+    fournisseur étendu, le même fournisseur d'autorisation étendu peut
+    être référencé par diverses localisations.
+    
    
+
+    
    Exemple
    
+        
    Dans l'exemple suivant, on crée deux alias de fournisseur
+	d'autorisation ldap différents basés sur le fournisseur
+	d'autorisation ldap-group. Il est ainsi possible pour un seul
+	répertoire de vérifier l'appartenance à un groupe dans plusieurs
+	serveurs ldap :
+        
    
+
+        
    <AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx>
+    AuthLDAPBindDN cn=youruser,o=ctx
+    AuthLDAPBindPassword yourpassword
+    AuthLDAPURL ldap://ldap.host/o=ctx
+</AuthzProviderAlias>
+
+<AuthzProviderAlias ldap-group ldap-group-alias2 cn=my-other-group,o=dev>
+    AuthLDAPBindDN cn=yourotheruser,o=dev
+    AuthLDAPBindPassword yourotherpassword
+    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
+</AuthzProviderAlias>
+
+Alias /secure /webpages/secure
+<Directory /webpages/secure>
+    Require all granted
+
+    AuthBasicProvider file
+
+    AuthType Basic
+    AuthName LDAP_Protected_Place
+
+    #Opération logique implicite : OU inclusif
+    Require ldap-group-alias1
+    Require ldap-group-alias2
+</Directory>
    
+
+    
+
+
    
 
    top
    
 
    Directive AuthMerging
    
 
@@ -438,208 +640,6 @@ pas.
  • Authentification, autorisation et
 contrôle d'accès
    • 
-
-
    top
    
-
    
-
    Conteneurs d'autorisation
    
-
-    
    Les directives de conteneur d'autorisation <RequireAll>,
-    <RequireAny> et <RequireNone>
-    peuvent être combinées entre elles et avec la directive Require pour construire une
-    logique d'autorisation complexe.
    
-
-    
    L'exemple ci-dessous illustre la logique d'autorisation suivante.
-    Pour pouvoir accéder à la ressource, l'utilisateur doit être
-    l'utilisateur superadmin, ou appartenir aux deux
-    groupes LDAP admins et Administrateurs et
-    soit appartenir au groupe ventes, soit avoir
-    ventes comme valeur de l'attribut LDAP
-    dept. De plus, pour pouvoir accéder à la ressource,
-    l'utilisateur ne doit appartenir ni au groupe temps, ni
-    au groupe LDAP Employés temporaires.
    
-
-    
    <Directory /www/mydocs>
-    <RequireAll>
-        <RequireAny>
-            Require user superadmin
-            <RequireAll>
-            Require group admins
-            Require ldap-group cn=Administrateurs,o=Airius
-                <RequireAny>
-                Require group ventes
-                Require ldap-attribute dept="ventes"
-                </RequireAny>
-            </RequireAll>
-        </RequireAny>
-        <RequireNone>
-            Require group temps
-            Require ldap-group cn=Employés temporaires,o=Airius
-        </RequireNone>
-    </RequireAll>
-</Directory>
    
-
-
    top
    
-
    
-
    Les directives Require
    
-
-  
    Le module mod_authz_core met à disposition des
-  fournisseurs d'autorisation génériques utilisables avec la directive
-  Require.
    
-
-  
    Require env
    
-
-    
    Le fournisseur env permet de contrôler l'accès au
-    serveur en fonction de l'existence d'une variable d'environnement. Lorsque Require
-    env env-variable est spécifié, la requête se voit
-    autoriser l'accès si la variable d'environnement
-    env-variable existe. Le serveur permet de définir
-    facilement des variables d'environnement en fonction des
-    caractéristiques de la requête du client via les directives fournies
-    par le module mod_setenvif. Cette directive Require
-    env permet donc de contrôler l'accès en fonction des
-    valeurs des en-têtes de la requête HTTP tels que
-    User-Agent (type de navigateur), Referer,
-    entre autres.
    
-
-    
    SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
-<Directory /docroot>
-    Require env let_me_in
-</Directory>
    
-
-
-    
    Avec cet exemple, les navigateurs dont la chaîne user-agent
-    commence par KnockKnock/2.0 se verront autoriser
-    l'accès, alors que tous les autres seront rejetés.
    
-
-    
    Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la
-   recherche d'un DirectoryIndex), ou lorsqu'il génère un
-   listing du contenu d'un répertoire via le module
-   mod_autoindex, la sous-requête n'hérite pas des
-   variables d'environnement spécifiques à la requête. En outre, à cause
-   des phases de l'API auxquelles mod_setenvif prend
-   part, les directives SetEnvIf ne sont pas évaluées
-   séparément dans la sous-requête.
    
-
-  
-
-  
    Require all
    
-
-    
    Le fournisseur all reproduit la fonctionnalité
-    précédemment fournie par les directives 'Allow from all' et 'Deny
-    from all'. Il accepte un argument dont les deux valeurs possibles
-    sont : 'granted' ou 'denied'. Les exemples suivants autorisent ou
-    interdisent l'accès à toutes les requêtes.
    
-
-    
    Require all granted
    
-
-
-    
    Require all denied
    
-
-
-  
-
-  
    Require method
    
-
-    
    Le fournisseur method permet d'utiliser la méthode
-    HTTP dans le processus d'autorisation. Les méthodes GET et HEAD sont
-    ici considérées comme équivalentes. La méthode TRACE n'est pas
-    supportée par ce fournisseur ; utilisez à la place la directive
-    TraceEnable.
    
-
-    
    Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et
-    OPTIONS sont autorisées :
    
-
-    
    Require method GET POST OPTIONS
    
-
-
-    
    Dans l'exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS
-    sont autorisées sans authentification, alors que toutes les autres
-    méthodes nécessitent un utilisateur valide :
    
-
-    
    <RequireAny>
-     Require method GET POST OPTIONS
-     Require valid-user
-</RequireAny>
    
-
-
-  
-  
    Require expr
    
-
-  
    Le fournisseur expr permet d'accorder l'autorisation
-  d'accès en fonction d'expressions arbitraires.
    
-
-    
    Require expr %{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17
    
-
-
-    
    <RequireAll>
-    Require expr "!(%{QUERY_STRING} =~ /secret/)"
-    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
-</RequireAll>
    
-
-
-    
    Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
    
-
-
-    
    La syntaxe de l'expression est décrite dans la documentation de ap_expr.
    
-
-    
    Normalement, l'expression est évaluée avant l'authentification.
-    Cependant, si l'expression renvoie false et se réfère à la variable
-    %{REMOTE_USER}, le processus d'authentification sera
-    engagé et l'expression réévaluée.
    
-
-  
-
-
    top
    
-
    
-
    Création des alias du fournisseur
-d'autorisation
    
-
-    
    Il est possible de créer des fournisseurs d'autorisation étendus
-    dans le fichier de configuration et de leur assigner un nom d'alias.
-    On peut ensuite utiliser ces fournisseurs aliasés dans une
-    directive Require de
-    la même manière qu'on le ferait pour des fournisseurs d'autorisation
-    de base. En plus de la possibilité de créer et d'aliaser un
-    fournisseur étendu, le même fournisseur d'autorisation étendu peut
-    être référencé par diverses localisations.
-    
    
-
-    
    Exemple
    
-        
    Dans l'exemple suivant, on crée deux alias de fournisseur
-	d'autorisation ldap différents basés sur le fournisseur
-	d'autorisation ldap-group. Il est ainsi possible pour un seul
-	répertoire de vérifier l'appartenance à un groupe dans plusieurs
-	serveurs ldap :
-        
    
-
-        
    <AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx>
-    AuthLDAPBindDN cn=youruser,o=ctx
-    AuthLDAPBindPassword yourpassword
-    AuthLDAPURL ldap://ldap.host/o=ctx
-</AuthzProviderAlias>
-
-<AuthzProviderAlias ldap-group ldap-group-alias2 cn=my-other-group,o=dev>
-    AuthLDAPBindDN cn=yourotheruser,o=dev
-    AuthLDAPBindPassword yourotherpassword
-    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
-</AuthzProviderAlias>
-
-Alias /secure /webpages/secure
-<Directory /webpages/secure>
-    Require all granted
-
-    AuthBasicProvider file
-
-    AuthType Basic
-    AuthName LDAP_Protected_Place
-
-    #Opération logique implicite : OU inclusif
-    Require ldap-group-alias1
-    Require ldap-group-alias2
-</Directory>
    
-
-    
-
 
    
diff --git a/docs/manual/mod/mod_authz_dbd.html.en b/docs/manual/mod/mod_authz_dbd.html.en
index c494f7a0af..157a1fa340 100644
--- a/docs/manual/mod/mod_authz_dbd.html.en
+++ b/docs/manual/mod/mod_authz_dbd.html.en
@@ -71,90 +71,6 @@
 
  • DBDParams
    • 
 
    top
    
-
    AuthzDBDLoginToReferer Directive
    
-
    
 
 
 
 
 
    
-
-
-
-
-
-
-
    Description:Determines whether to redirect the Client to the Referring
-page on successful login or logout if a Referer request
-header is present
    Syntax:AuthzDBDLoginToReferer On|Off
    Default:AuthzDBDLoginToReferer Off
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    
-    
    In conjunction with Require dbd-login or
-    Require dbd-logout, this provides the option to
-    redirect the client back to the Referring page (the URL in
-    the Referer HTTP request header, if present).
-    When there is no Referer header,
-    AuthzDBDLoginToReferer On will be ignored.
    
-
-
    
-
    top
    
-
    AuthzDBDQuery Directive
    
-
-
-
-
-
-
-
    Description:Specify the SQL Query for the required operation
    Syntax:AuthzDBDQuery query
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    
-    
    The AuthzDBDQuery specifies an SQL
-    query to run.  The purpose of the query depends on the
-    Require directive in
-    effect.
    
-    
      
-    
    • When used with a Require dbd-group directive,
-    it specifies a query to look up groups for the current user.  This is
-    the standard functionality of other authorization modules such as
-    mod_authz_groupfile and mod_authz_dbm.
-    The first column value of each row returned by the query statement
-    should be a string containing a group name.  Zero, one, or more rows
-    may be returned.
-    
      Require dbd-group
-AuthzDBDQuery "SELECT group FROM groups WHERE user = %s"
      
-
-    
      • 
-    
    • When used with a Require dbd-login or
-    Require dbd-logout directive, it will never deny access,
-    but will instead execute a SQL statement designed to log the user
-    in or out.  The user must already be authenticated with
-    mod_authn_dbd.
-    
      Require dbd-login
-AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE user = %s"
      
-
-    
      • 
-    
    
-    
    In all cases, the user's ID will be passed as a single string
-    parameter when the SQL query is executed.  It may be referenced within
-    the query statement using a %s format specifier.
    
-
-
    
-
    top
    
-
    AuthzDBDRedirectQuery Directive
    
-
-
-
-
-
-
-
    Description:Specify a query to look up a login page for the user
    Syntax:AuthzDBDRedirectQuery query
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    
-    
    Specifies an optional SQL query to use after successful login
-    (or logout) to redirect the user to a URL, which may be
-    specific to the user.  The user's ID will be passed as a single string
-    parameter when the SQL query is executed.  It may be referenced within
-    the query statement using a %s format specifier.
    
-    
    AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"
    
-
-    
    The first column value of the first row returned by the query
-    statement should be a string containing a URL to which to redirect
-    the client.  Subsequent rows will be ignored.  If no rows are returned,
-    the client will not be redirected.
    
-    
    Note that AuthzDBDLoginToReferer takes
-    precedence if both are set.
    
-
-
    
-
    top
    
 
    
 
    The Require Directives
    
 
@@ -240,7 +156,7 @@ DBDKeep 8
 DBDMax  20
 DBDExptime 300
 
-<Directory /usr/www/my.site/team-private/>
+<Directory "/usr/www/my.site/team-private/">
   # mod_authn_core and mod_auth_basic configuration
   # for mod_authn_dbd
   AuthType Basic
@@ -262,7 +178,7 @@ DBDExptime 300
   # to /team-private/login.html
   ErrorDocument 401 /login-info.html
 
-  <Files login.html>
+  <Files "login.html">
     # don't require user to already be logged in!
     AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
 
@@ -275,7 +191,7 @@ DBDExptime 300
     AuthzDBDLoginToReferer On
   </Files>
 
-  <Files logout.html>
+  <Files "logout.html">
     # dbd-logout action executes a statement to log user out
     Require dbd-logout
     AuthzDBDQuery "UPDATE authn SET login = 'false' WHERE user = %s"
@@ -294,6 +210,90 @@ DBDExptime 300
   
    Please read mod_dbd documentation for more information
   about security on this scope.
    
 
    
+
    top
    
+
    AuthzDBDLoginToReferer Directive
    
+
+
+
+
+
+
+
+
    Description:Determines whether to redirect the Client to the Referring
+page on successful login or logout if a Referer request
+header is present
    Syntax:AuthzDBDLoginToReferer On|Off
    Default:AuthzDBDLoginToReferer Off
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    
+    
    In conjunction with Require dbd-login or
+    Require dbd-logout, this provides the option to
+    redirect the client back to the Referring page (the URL in
+    the Referer HTTP request header, if present).
+    When there is no Referer header,
+    AuthzDBDLoginToReferer On will be ignored.
    
+
+
    
+
    top
    
+
    AuthzDBDQuery Directive
    
+
+
+
+
+
+
+
    Description:Specify the SQL Query for the required operation
    Syntax:AuthzDBDQuery query
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    
+    
    The AuthzDBDQuery specifies an SQL
+    query to run.  The purpose of the query depends on the
+    Require directive in
+    effect.
    
+    
      
+    
    • When used with a Require dbd-group directive,
+    it specifies a query to look up groups for the current user.  This is
+    the standard functionality of other authorization modules such as
+    mod_authz_groupfile and mod_authz_dbm.
+    The first column value of each row returned by the query statement
+    should be a string containing a group name.  Zero, one, or more rows
+    may be returned.
+    
      Require dbd-group
+AuthzDBDQuery "SELECT group FROM groups WHERE user = %s"
      
+
+    
      • 
+    
    • When used with a Require dbd-login or
+    Require dbd-logout directive, it will never deny access,
+    but will instead execute a SQL statement designed to log the user
+    in or out.  The user must already be authenticated with
+    mod_authn_dbd.
+    
      Require dbd-login
+AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE user = %s"
      
+
+    
      • 
+    
    
+    
    In all cases, the user's ID will be passed as a single string
+    parameter when the SQL query is executed.  It may be referenced within
+    the query statement using a %s format specifier.
    
+
+
    
+
    top
    
+
    AuthzDBDRedirectQuery Directive
    
+
+
+
+
+
+
+
    Description:Specify a query to look up a login page for the user
    Syntax:AuthzDBDRedirectQuery query
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    
+    
    Specifies an optional SQL query to use after successful login
+    (or logout) to redirect the user to a URL, which may be
+    specific to the user.  The user's ID will be passed as a single string
+    parameter when the SQL query is executed.  It may be referenced within
+    the query statement using a %s format specifier.
    
+    
    AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"
    
+
+    
    The first column value of the first row returned by the query
+    statement should be a string containing a URL to which to redirect
+    the client.  Subsequent rows will be ignored.  If no rows are returned,
+    the client will not be redirected.
    
+    
    Note that AuthzDBDLoginToReferer takes
+    precedence if both are set.
    
+
+
    
 
 
    
 
    Available Languages:  en  |
diff --git a/docs/manual/mod/mod_authz_dbd.html.fr b/docs/manual/mod/mod_authz_dbd.html.fr
index 2f306d22af..3cb7f82ded 100644
--- a/docs/manual/mod/mod_authz_dbd.html.fr
+++ b/docs/manual/mod/mod_authz_dbd.html.fr
@@ -50,20 +50,20 @@ d'Apache
     pilote de la base de données sous-jacente et les paramètres de
     connexion, et gérer les connexions à la base de données.
    
 
    
-
    Directives
    
-
-
    Sujets
    
+
 
    top
    
-
    Directive AuthzDBDLoginToReferer
    
-
-
-
-
-
-
-
-
    Description:Définit si le client doit être redirigé vers la page
-d'origine en cas de connexion ou de déconnexion réussie si une en-tête
-de requête Referer est présente
    Syntaxe:AuthzDBDLoginToReferer On|Off
    Défaut:AuthzDBDLoginToReferer Off
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    
-    
    Utilisée en conjonction avec Require dbd-login ou
-    Require dbd-logout, cette directive permet de rediriger
-    le client vers la page d'origine (l'URL contenue dans l'en-tête
-    de requête HTTP Referer, s'il est présent). En
-    l'absence d'en-tête Referer, la définition
-    AuthzDBDLoginToReferer On sera ignorée.
    
-
-
    
-
    top
    
-
    Directive AuthzDBDQuery
    
-
-
-
-
-
-
-
    Description:Définit la requête SQL pour l'opération
-requise
    Syntaxe:AuthzDBDQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    
-    
    La directive AuthzDBDQuery permet de
-    spécifier une requête SQL à exécuter. Le but de cette requête dépend
-    de la directive Require en cours de
-    traitement.
    
-    
      
-    
    • Avec la directive Require dbd-group, elle spécifie
-    une requête permettant de rechercher les groupes d'appartenance de
-    l'utilisateur courant. Ceci correspond à la fonctionnalité standard
-    d'autres modules d'autorisation comme
-    mod_authz_groupfile et
-    mod_authz_dbm.
-    La première colonne de chaque enregistrement renvoyé par la requête
-    doit contenir une chaîne de caractères correspondant à un nom de
-    groupe. La requête peut renvoyer zéro, un ou plusieurs
-    enregistrements.
-    
      Require dbd-group
-AuthzDBDQuery "SELECT group FROM groups WHERE user = %s"
      
-
-    
      • 
-    
    • Avec la directive Require dbd-login ou
-    Require dbd-logout, elle ne refusera jamais l'accès,
-    mais au contraire exécutera une requête SQL permettant d'enregistrer
-    la connexion ou la déconnexion de l'utilisateur. Ce dernier doit
-    être déjà authentifié avec mod_authn_dbd.
-    
      Require dbd-login
-AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE user = %s"
      
-
-    
      • 
-    
    
-    
    Dans tous les cas, l'identifiant utilisateur sera transmis comme
-    paramètre sous la forme d'une simple chaîne lorsque la requête SQL
-    sera exécutée. Il y sera fait référence dans la requête en utilisant
-    le spécificateur de format %s.
    
-
-
    
-
    top
    
-
    Directive AuthzDBDRedirectQuery
    
-
-
-
-
-
-
-
    Description:Définit une requête pour rechercher une page vers laquelle
-rediriger l'utilisateur après une connexion réussie
    Syntaxe:AuthzDBDRedirectQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    
-    
    Spécifie une requête SQL optionnelle à utiliser après une
-    connexion (ou une déconnexion) réussie pour rediriger l'utilisateur
-    vers une URL, qui peut être spécifique à l'utilisateur.
-    L'identifiant utilisateur sera transmis comme paramètre sous la
-    forme d'une simple chaîne lorsque la requête SQL sera exécutée. Il y
-    sera fait référence dans la requête en utilisant le spécificateur de
-    format %s.
    
-    
    AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"
    
-
-    
    La première colonne du premier enregistrement renvoyé par la
-    requête doit contenir une chaîne de caractères correspondant à une
-    URL vers laquelle rediriger le client. Les enregistrements suivants
-    sont ignorés. Si aucun enregistrement n'est renvoyé, le client ne
-    sera pas redirigé.
    
-    
    Notez que AuthzDBDLoginToReferer l'emporte
-    sur cette directive si les deux sont définies.
    
-
-
    
-
    top
    
 
    
 
    Les directives Require
    
 
@@ -316,6 +223,99 @@ DBDExptime 300
   mod_dbd pour plus d'informations à propos de la
   sécurité dans ce domaine.
    
 
    
+
    top
    
+
    Directive AuthzDBDLoginToReferer
    
+
+
+
+
+
+
+
+
    Description:Définit si le client doit être redirigé vers la page
+d'origine en cas de connexion ou de déconnexion réussie si une en-tête
+de requête Referer est présente
    Syntaxe:AuthzDBDLoginToReferer On|Off
    Défaut:AuthzDBDLoginToReferer Off
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    
+    
    Utilisée en conjonction avec Require dbd-login ou
+    Require dbd-logout, cette directive permet de rediriger
+    le client vers la page d'origine (l'URL contenue dans l'en-tête
+    de requête HTTP Referer, s'il est présent). En
+    l'absence d'en-tête Referer, la définition
+    AuthzDBDLoginToReferer On sera ignorée.
    
+
+
    
+
    top
    
+
    Directive AuthzDBDQuery
    
+
+
+
+
+
+
+
    Description:Définit la requête SQL pour l'opération
+requise
    Syntaxe:AuthzDBDQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    
+    
    La directive AuthzDBDQuery permet de
+    spécifier une requête SQL à exécuter. Le but de cette requête dépend
+    de la directive Require en cours de
+    traitement.
    
+    
      
+    
    • Avec la directive Require dbd-group, elle spécifie
+    une requête permettant de rechercher les groupes d'appartenance de
+    l'utilisateur courant. Ceci correspond à la fonctionnalité standard
+    d'autres modules d'autorisation comme
+    mod_authz_groupfile et
+    mod_authz_dbm.
+    La première colonne de chaque enregistrement renvoyé par la requête
+    doit contenir une chaîne de caractères correspondant à un nom de
+    groupe. La requête peut renvoyer zéro, un ou plusieurs
+    enregistrements.
+    
      Require dbd-group
+AuthzDBDQuery "SELECT group FROM groups WHERE user = %s"
      
+
+    
      • 
+    
    • Avec la directive Require dbd-login ou
+    Require dbd-logout, elle ne refusera jamais l'accès,
+    mais au contraire exécutera une requête SQL permettant d'enregistrer
+    la connexion ou la déconnexion de l'utilisateur. Ce dernier doit
+    être déjà authentifié avec mod_authn_dbd.
+    
      Require dbd-login
+AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE user = %s"
      
+
+    
      • 
+    
    
+    
    Dans tous les cas, l'identifiant utilisateur sera transmis comme
+    paramètre sous la forme d'une simple chaîne lorsque la requête SQL
+    sera exécutée. Il y sera fait référence dans la requête en utilisant
+    le spécificateur de format %s.
    
+
+
    
+
    top
    
+
    Directive AuthzDBDRedirectQuery
    
+
+
+
+
+
+
+
    Description:Définit une requête pour rechercher une page vers laquelle
+rediriger l'utilisateur après une connexion réussie
    Syntaxe:AuthzDBDRedirectQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    
+    
    Spécifie une requête SQL optionnelle à utiliser après une
+    connexion (ou une déconnexion) réussie pour rediriger l'utilisateur
+    vers une URL, qui peut être spécifique à l'utilisateur.
+    L'identifiant utilisateur sera transmis comme paramètre sous la
+    forme d'une simple chaîne lorsque la requête SQL sera exécutée. Il y
+    sera fait référence dans la requête en utilisant le spécificateur de
+    format %s.
    
+    
    AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"
    
+
+    
    La première colonne du premier enregistrement renvoyé par la
+    requête doit contenir une chaîne de caractères correspondant à une
+    URL vers laquelle rediriger le client. Les enregistrements suivants
+    sont ignorés. Si aucun enregistrement n'est renvoyé, le client ne
+    sera pas redirigé.
    
+    
    Notez que AuthzDBDLoginToReferer l'emporte
+    sur cette directive si les deux sont définies.
    
+
+
    
 
    
 
    
 
    Langues Disponibles:  en  |
diff --git a/docs/manual/mod/mod_authz_dbd.xml b/docs/manual/mod/mod_authz_dbd.xml
index 0f548ea496..0292c86257 100644
--- a/docs/manual/mod/mod_authz_dbd.xml
+++ b/docs/manual/mod/mod_authz_dbd.xml
@@ -140,7 +140,7 @@ DBDKeep 8
 DBDMax  20
 DBDExptime 300
 
-<Directory /usr/www/my.site/team-private/>
+<Directory "/usr/www/my.site/team-private/">
   # mod_authn_core and mod_auth_basic configuration
   # for mod_authn_dbd
   AuthType Basic
@@ -162,7 +162,7 @@ DBDExptime 300
   # to /team-private/login.html
   ErrorDocument 401 /login-info.html
 
-  <Files login.html>
+  <Files "login.html">
     # don't require user to already be logged in!
     AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
 
@@ -175,7 +175,7 @@ DBDExptime 300
     AuthzDBDLoginToReferer On
   </Files>
 
-  <Files logout.html>
+  <Files "logout.html">
     # dbd-logout action executes a statement to log user out
     Require dbd-logout
     AuthzDBDQuery "UPDATE authn SET login = 'false' WHERE user = %s"
diff --git a/docs/manual/mod/mod_authz_dbm.html.en b/docs/manual/mod/mod_authz_dbm.html.en
index 3121966606..b3735797f2 100644
--- a/docs/manual/mod/mod_authz_dbm.html.en
+++ b/docs/manual/mod/mod_authz_dbm.html.en
@@ -53,6 +53,55 @@
 
  • Require
    • 
 
    
 
    top
    
+
    
+
    The Require Directives
    
+
+    
    Apache's Require
+    directives are used during the authorization phase to ensure that
+    a user is allowed to access a resource.  mod_authz_dbm extends the
+    authorization types with dbm-group.
    
+
+    
    Since v2.4.8, expressions are supported
+    within the DBM require directives.
    
+
+
    Require dbm-group
    
+
+    
    This directive specifies group membership that is required for the
+    user to gain access.
    
+
+    
    Require dbm-group admin
    
+
+
+
+
+
    Require dbm-file-group
    
+
+    
    When this directive is specified, the user must be a member of the group
+    assigned to the file being accessed.
    
+
+    
    Require dbm-file-group
    
+
+
+
+
+
    top
    
+
    
+
    Example usage
    
+
+
    Note that using mod_authz_dbm requires you to require dbm-group
+instead of group:
+
    
+
    <Directory "/foo/bar">
+  AuthType Basic
+  AuthName "Secure Area"
+  AuthBasicProvider dbm
+  AuthDBMUserFile "site/data/users"
+  AuthDBMGroupFile "site/data/users"
+  Require dbm-group admin
+</Directory>
    
+
+
    
+
    top
    
 
    AuthDBMGroupFile Directive
    
 
    It is crucial that whatever program you use to create your group
     files is configured to use the same type of database.
    
 
-
-
    top
    
-
    
-
    The Require Directives
    
-
-    
    Apache's Require
-    directives are used during the authorization phase to ensure that
-    a user is allowed to access a resource.  mod_authz_dbm extends the
-    authorization types with dbm-group.
    
-
-    
    Since v2.4.8, expressions are supported
-    within the DBM require directives.
    
-
-
    Require dbm-group
    
-
-    
    This directive specifies group membership that is required for the
-    user to gain access.
    
-
-    
    Require dbm-group admin
    
-
-
-
-
-
    Require dbm-file-group
    
-
-    
    When this directive is specified, the user must be a member of the group
-    assigned to the file being accessed.
    
-
-    
    Require dbm-file-group
    
-
-
-
-
-
    top
    
-
    
-
    Example usage
    
-
-
    Note that using mod_authz_dbm requires you to require dbm-group
-instead of group:
-
    
-
    <Directory "/foo/bar">
-  AuthType Basic
-  AuthName "Secure Area"
-  AuthBasicProvider dbm
-  AuthDBMUserFile "site/data/users"
-  AuthDBMGroupFile "site/data/users"
-  Require dbm-group admin
-</Directory>
    
-
 
    
diff --git a/docs/manual/mod/mod_authz_dbm.html.fr b/docs/manual/mod/mod_authz_dbm.html.fr
index 001b01cdb6..4f9a243c10 100644
--- a/docs/manual/mod/mod_authz_dbm.html.fr
+++ b/docs/manual/mod/mod_authz_dbm.html.fr
@@ -42,20 +42,70 @@
     mod_authz_groupfile fournit une fonctionnalité
     similaire.
    
 
    
-
    Directives
    
+
 
    top
    
+
    
+
    The Require Directives
    
+
+    
    Les directives Require d'Apache permettent,
+    au cours de la phase d'autorisation, de s'assurer qu'un utilisateur
+    est bien autorisé à accéder à une ressource.  mod_authz_dbm ajoute
+    les types d'autorisation dbm-group et dbm-file-group.
    
+
+    
    A partir de la version 2.4.8, les directives require DBM
+    supportent les expressions.
    
+
+
    Require dbm-group
    
+
+    
    Cette directive permet de spécifier à quel groupe un utilisateur
+    doit appartenir pour obtenir l'autorisation d'accès.
    
+
+    
    Require dbm-group admin
    
+
+
+
+
+
    Require dbm-file-group
    
+
+    
    Lorsque cette directive est définie, l'utilisateur doit
+    appartenir au groupe du fichier pour pouvoir y accéder.
    
+
+    
    Require dbm-file-group
    
+
+
+
+
+
    top
    
+
    
+
    Exemple d'utilisation
    
+
+
    Notez que si vous utilisez mod_authz_dbm, le mot-clé pour les
+groupes d'authentification qui était auparavant group est
+maintenant dbm-group :
+
    
+
    <Directory "/foo/bar">
+  AuthType Basic
+  AuthName "Secure Area"
+  AuthBasicProvider dbm
+  AuthDBMUserFile site/data/users
+  AuthDBMGroupFile site/data/users
+  Require dbm-group admin
+</Directory>
    
+
+
    
+
    top
    
 
    Directive AuthDBMGroupFile
    
 
    
 
    Description:Sets the name of the database file containing the list
@@ -130,55 +179,6 @@ store list of user groups
    
     
 
 
    
     fichier de groupes, il est impératif que celui-ci soit configuré
     pour utiliser le même type de base de données.
    
 
-
-
    top
    
-
    
-
    The Require Directives
    
-
-    
    Les directives Require d'Apache permettent,
-    au cours de la phase d'autorisation, de s'assurer qu'un utilisateur
-    est bien autorisé à accéder à une ressource.  mod_authz_dbm ajoute
-    les types d'autorisation dbm-group et dbm-file-group.
    
-
-    
    A partir de la version 2.4.8, les directives require DBM
-    supportent les expressions.
    
-
-
    Require dbm-group
    
-
-    
    Cette directive permet de spécifier à quel groupe un utilisateur
-    doit appartenir pour obtenir l'autorisation d'accès.
    
-
-    
    Require dbm-group admin
    
-
-
-
-
-
    Require dbm-file-group
    
-
-    
    Lorsque cette directive est définie, l'utilisateur doit
-    appartenir au groupe du fichier pour pouvoir y accéder.
    
-
-    
    Require dbm-file-group
    
-
-
-
-
-
    top
    
-
    
-
    Exemple d'utilisation
    
-
-
    Notez que si vous utilisez mod_authz_dbm, le mot-clé pour les
-groupes d'authentification qui était auparavant group est
-maintenant dbm-group :
-
    
-
    <Directory "/foo/bar">
-  AuthType Basic
-  AuthName "Secure Area"
-  AuthBasicProvider dbm
-  AuthDBMUserFile site/data/users
-  AuthDBMGroupFile site/data/users
-  Require dbm-group admin
-</Directory>
    
-
 
    
diff --git a/docs/manual/mod/mod_authz_dbm.html.ko.euc-kr b/docs/manual/mod/mod_authz_dbm.html.ko.euc-kr
index 43511705c6..6cf0d2201b 100644
--- a/docs/manual/mod/mod_authz_dbm.html.ko.euc-kr
+++ b/docs/manual/mod/mod_authz_dbm.html.ko.euc-kr
@@ -51,6 +51,7 @@
 
  • Require
    • 
 
  • Satisfy
    • 
 
    
+
 
    top
    AuthDBMGroupFile Áö½Ã¾î
    
 
    
 
    Description:Définit le nom du fichier de base de données qui liste
@@ -137,56 +187,6 @@ la liste des groupes d'utilisateurs
    
 
 
 
    
@@ -121,7 +122,6 @@
     »ç¿ëÇϵµ·Ï ¼³Á¤ÇØ¾ß ÇÑ´Ù.
    
-
 
    
 
    °¡´ÉÇÑ ¾ð¾î:  en  |
diff --git a/docs/manual/mod/mod_authz_groupfile.html.en b/docs/manual/mod/mod_authz_groupfile.html.en
index 883304b283..81b141abc2 100644
--- a/docs/manual/mod/mod_authz_groupfile.html.en
+++ b/docs/manual/mod/mod_authz_groupfile.html.en
@@ -52,40 +52,6 @@
 
  • Require
    • 
 
    top
    
-
    AuthGroupFile Directive
    
-
    
 
 
 
 
    
-
-
-
-
-
-
-
    Description:Sets the name of a text file containing the list
-of user groups for authorization
    Syntax:AuthGroupFile file-path
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Base
    Module:mod_authz_groupfile
    
-    
    The AuthGroupFile directive sets the
-    name of a textual file containing the list of user groups for user
-    authorization. File-path is the path to the group
-    file. If it is not absolute, it is treated as relative to the ServerRoot.
    
-
-    
    Each line of the group file contains a groupname followed by a
-    colon, followed by the member usernames separated by spaces.
    
-
-    
    Example:
    
-      mygroup: bob joe anne
-    
    
-
-    
    Note that searching large text files is very
-    inefficient; AuthDBMGroupFile provides a much better performance.
    
-
-    
    Security
    
-      
    Make sure that the AuthGroupFile is
-      stored outside the document tree of the web-server; do not
-      put it in the directory that it protects. Otherwise, clients may
-      be able to download the AuthGroupFile.
    
-    
    
-
-
    
-
    top
    
 
    
 
    The Require Directives
    
 
@@ -118,6 +84,40 @@ of user groups for authorization
 
 
 
+
    
+
    top
    
+
    AuthGroupFile Directive
    
+
+
+
+
+
+
+
+
    Description:Sets the name of a text file containing the list
+of user groups for authorization
    Syntax:AuthGroupFile file-path
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Base
    Module:mod_authz_groupfile
    
+    
    The AuthGroupFile directive sets the
+    name of a textual file containing the list of user groups for user
+    authorization. File-path is the path to the group
+    file. If it is not absolute, it is treated as relative to the ServerRoot.
    
+
+    
    Each line of the group file contains a groupname followed by a
+    colon, followed by the member usernames separated by spaces.
    
+
+    
    Example:
    
+      mygroup: bob joe anne
+    
    
+
+    
    Note that searching large text files is very
+    inefficient; AuthDBMGroupFile provides a much better performance.
    
+
+    
    Security
    
+      
    Make sure that the AuthGroupFile is
+      stored outside the document tree of the web-server; do not
+      put it in the directory that it protects. Otherwise, clients may
+      be able to download the AuthGroupFile.
    
+    
    
+
 
    
 
 
    
diff --git a/docs/manual/mod/mod_authz_groupfile.html.fr b/docs/manual/mod/mod_authz_groupfile.html.fr
index f05ebbb4ba..fc90ef6e2a 100644
--- a/docs/manual/mod/mod_authz_groupfile.html.fr
+++ b/docs/manual/mod/mod_authz_groupfile.html.fr
@@ -41,18 +41,52 @@ certaines zones du site web aux utilisateurs authentifi
 fonction de leur appartenance à un groupe spécifié. Le module
 mod_authz_dbm fournit une fonctionnalité similaire.
    
 
    
-
    Directives
    
+
    Sujets
    
+
    Directives
    
 
-
    Sujets
    
-
    Voir aussi
    
+
    Voir aussi
    
 
    
 
    top
    
+
    
+
    The Require Directives
    
+
+    
    Les directives Require d'Apache permettent,
+    au cours de la phase d'autorisation, de s'assurer qu'un utilisateur
+    est bien autorisé à accéder à une ressource. mod_authz_groupfile ajoute
+    les types d'autorisation group et file-group.
+    
    
+
+    
    A partir de la version 2.4.8, les directives require groupfile
+    supportent les expressions.
    
+
+
    Require group
    
+
+    
    Cette directive permet de spécifier à quel groupe un utilisateur
+    doit appartenir pour obtenir l'autorisation d'accès.
    
+
+    
    Require group admin
    
+
+
+
+
+
    Require file-group
    
+
+    
    Lorsque cette directive est définie, l'utilisateur doit
+    appartenir au groupe du fichier pour pouvoir y accéder.
    
+
+    
    Require file-group
    
+
+
+
+
+
    
+
    top
    
 
    Directive AuthGroupFile
    
 
       multiples" (MultiViews) d'un contenu négocié.
    
-
    Directives
    
-
    Ce module ne fournit aucune directive.
    
-
    Sujets
    
+
    Sujets
    
 
    Voir aussi
    
+
    Directives
    
+
    Ce module ne fournit aucune directive.
    
+
    Voir aussi
    
 
    
diff --git a/docs/manual/mod/mod_authz_owner.html.ja.utf8 b/docs/manual/mod/mod_authz_owner.html.ja.utf8
index 1af36918a9..37a5a81217 100644
--- a/docs/manual/mod/mod_authz_owner.html.ja.utf8
+++ b/docs/manual/mod/mod_authz_owner.html.ja.utf8
@@ -79,12 +79,12 @@
       決して承認しません。
    
     
    
-
    ディレクティブ
    
-
    このモジュールにディレクティブはありません。
    
-
    トピック
    
+
    トピック
    
 
    参照
    
+
    ディレクティブ
    
+
    このモジュールにディレクティブはありません。
    
+
    参照
    
 
    
diff --git a/docs/manual/mod/mod_authz_owner.html.ko.euc-kr b/docs/manual/mod/mod_authz_owner.html.ko.euc-kr
index b5b9d4c549..9ad039b31e 100644
--- a/docs/manual/mod/mod_authz_owner.html.ko.euc-kr
+++ b/docs/manual/mod/mod_authz_owner.html.ko.euc-kr
@@ -73,12 +73,12 @@
       "MultiViews" ÀÚ¿øÀ» ±ÇÇѺο©ÇÏÁö ¾Ê´Â´Ù.
    
     
    
-
    Áö½Ã¾îµé
    
-
    ÀÌ ¸ðµâ¿¡´Â Áö½Ã¾î°¡ ¾ø½À´Ï´Ù.
    
-
    ÁÖÁ¦
    
+
    ÁÖÁ¦
    
 
    Âü°í
    
+
    Áö½Ã¾îµé
    
+
    ÀÌ ¸ðµâ¿¡´Â Áö½Ã¾î°¡ ¾ø½À´Ï´Ù.
    
+
    Âü°í
    
 
      
 
    • Require
      • 
 
    • Satisfy
      • 
diff --git a/docs/manual/mod/mod_authz_user.html.fr b/docs/manual/mod/mod_authz_user.html.fr
index ca1c355356..9145abf9a7 100644
--- a/docs/manual/mod/mod_authz_user.html.fr
+++ b/docs/manual/mod/mod_authz_user.html.fr
@@ -43,12 +43,12 @@
     Require valid-user pour accorder l'accès à tous les
     utilisateurs qui ont été authentifiés avec succès.
      
 
    
-
    Directives
    
-
    Ce module ne fournit aucune directive.
    
-
    Sujets
    
+
    Sujets
    
 
    Voir aussi
    
+
    Directives
    
+
    Ce module ne fournit aucune directive.
    
+
    Voir aussi
    
 
    
diff --git a/docs/manual/mod/mod_autoindex.html.en b/docs/manual/mod/mod_autoindex.html.en
index f97dfbfd58..4e649e2165 100644
--- a/docs/manual/mod/mod_autoindex.html.en
+++ b/docs/manual/mod/mod_autoindex.html.en
@@ -104,6 +104,108 @@
 
 
    
 
    top
    
+
    
+
    Autoindex Request Query Arguments
    
+    
+
+    
    Various query string arguments are available to give the client
+    some control over the ordering of the directory listing, as well as
+    what files are listed. If you do not wish to give the client this
+    control, the IndexOptions
+    IgnoreClient option disables that functionality.
    
+
+    
    The column sorting headers themselves are self-referencing
+    hyperlinks that add the sort query options shown below. Any
+    option below may be added to any request for the directory
+    resource.
    
+
+    
      
+      
    • C=N sorts the directory by file name
      • 
+
+      
    • C=M sorts the directory by last-modified
+      date, then file name
      • 
+
+      
    • C=S sorts the directory by size, then file
+      name
      • 
+
+      
    • C=D sorts the directory by description, then
+      file name
      • 
+
+      
    • O=A sorts the listing in Ascending
+      Order
      • 
+
+      
    • O=D sorts the listing in Descending
+      Order
      • 
+
+      
    • F=0 formats the listing as a simple list
+      (not FancyIndexed)
      • 
+
+      
    • F=1 formats the listing as a FancyIndexed
+      list
      • 
+
+      
    • F=2 formats the listing as an
+      HTMLTable FancyIndexed list
      • 
+
+      
    • V=0 disables version sorting
      • 
+
+      
    • V=1 enables version sorting
      • 
+
+      
    • P=pattern lists only files matching
+      the given pattern
      • 
+    
    
+
+    
    Note that the 'P'attern query argument is tested
+    after the usual IndexIgnore directives are processed,
+    and all file names are still subjected to the same criteria as
+    any other autoindex listing. The Query Arguments parser in
+    mod_autoindex will stop abruptly when an unrecognized
+    option is encountered. The Query Arguments must be well formed,
+    according to the table above.
    
+
+    
    The simple example below, which can be clipped and saved in
+    a header.html file, illustrates these query options. Note that
+    the unknown "X" argument, for the submit button, is listed last
+    to assure the arguments are all parsed before mod_autoindex
+    encounters the X=Go input.
    
+
+    
    
+      <form action="" method="get">
    
+      
+        Show me a <select name="F">
    
+        
+          <option value="0"> Plain list</option>
    
+          <option value="1" selected="selected"> Fancy list</option>
    
+          <option value="2"> Table list</option>
    
+            
+        </select>
    
+        Sorted by <select name="C">
    
+        
+          <option value="N" selected="selected"> Name</option>
    
+          <option value="M"> Date Modified</option>
    
+          <option value="S"> Size</option>
    
+          <option value="D"> Description</option>
    
+            
+        </select>
    
+        <select name="O">
    
+        
+          <option value="A" selected="selected"> Ascending</option>
    
+          <option value="D"> Descending</option>
    
+            
+        </select>
    
+        <select name="V">
    
+        
+          <option value="0" selected="selected"> in Normal order</option>
    
+          <option value="1"> in Version order</option>
    
+            
+        </select>
    
+        Matching <input type="text" name="P" value="*" />
    
+        <input type="submit" name="X" value="Go" />
    
+          
+      </form>
+    
    
+
+
    
+
    top
    
 
    AddAlt Directive
    
 
    
 
    Description:Définit le nom d'un fichier texte contenant la liste des
@@ -90,40 +124,6 @@ s
 clients pourraient le télécharger.
    
     
 
-
-
    top
    
-
    
-
    The Require Directives
    
-
-    
    Les directives Require d'Apache permettent,
-    au cours de la phase d'autorisation, de s'assurer qu'un utilisateur
-    est bien autorisé à accéder à une ressource. mod_authz_groupfile ajoute
-    les types d'autorisation group et file-group.
-    
    
-
-    
    A partir de la version 2.4.8, les directives require groupfile
-    supportent les expressions.
    
-
-
    Require group
    
-
-    
    Cette directive permet de spécifier à quel groupe un utilisateur
-    doit appartenir pour obtenir l'autorisation d'accès.
    
-
-    
    Require group admin
    
-
-
-
-
-
    Require file-group
    
-
-    
    Lorsque cette directive est définie, l'utilisateur doit
-    appartenir au groupe du fichier pour pouvoir y accéder.
    
-
-    
    Require file-group
    
-
-
-
-
 
    
 
 
    
diff --git a/docs/manual/mod/mod_authz_groupfile.html.ja.utf8 b/docs/manual/mod/mod_authz_groupfile.html.ja.utf8
index 39d9989a66..a58b83c2f9 100644
--- a/docs/manual/mod/mod_authz_groupfile.html.ja.utf8
+++ b/docs/manual/mod/mod_authz_groupfile.html.ja.utf8
@@ -53,6 +53,7 @@
 
    
+
 
    top
    
 
    AuthGroupFile ディレクティブ
    
 
@@ -94,7 +95,6 @@
     
-
 
    
 
    翻訳済み言語:  en  |
diff --git a/docs/manual/mod/mod_authz_groupfile.html.ko.euc-kr b/docs/manual/mod/mod_authz_groupfile.html.ko.euc-kr
index 65d7dfbd8e..eeb65c8fc5 100644
--- a/docs/manual/mod/mod_authz_groupfile.html.ko.euc-kr
+++ b/docs/manual/mod/mod_authz_groupfile.html.ko.euc-kr
@@ -51,6 +51,7 @@
 
  • Require
    • 
 
  • Satisfy
    • 
 
    
+
 
    top
    AuthGroupFile Áö½Ã¾î
    
 
    
 
 
 
 
    
@@ -85,7 +86,6 @@
     
-
 
    
 
    °¡´ÉÇÑ ¾ð¾î:  en  |
diff --git a/docs/manual/mod/mod_authz_host.html.fr b/docs/manual/mod/mod_authz_host.html.fr
index 9de473cdf6..afdbc8db28 100644
--- a/docs/manual/mod/mod_authz_host.html.fr
+++ b/docs/manual/mod/mod_authz_host.html.fr
@@ -52,12 +52,12 @@ d'Apache
    
 
 
 
    
     méthodes sans protection, en plaçant les directives dans une section
     <Limit>.
    
 
    
-
    Directives
    
-
    Ce module ne fournit aucune directive.
    
-
    Sujets
    
+
    Sujets
    
 
    Voir aussi
    
+
    Directives
    
+
    Ce module ne fournit aucune directive.
    
+
    Voir aussi
    
 
      
 
    • Authentification, autorisation et
 contrôle d'accès
      • 
diff --git a/docs/manual/mod/mod_authz_owner.html.fr b/docs/manual/mod/mod_authz_owner.html.fr
index 745d712180..2cb41e8af0 100644
--- a/docs/manual/mod/mod_authz_owner.html.fr
+++ b/docs/manual/mod/mod_authz_owner.html.fr
@@ -81,12 +81,12 @@ fichiers
    
     
 
 
 
    
     any files ignored by IndexIgnore otherwise
     inherited from other configuration sections. 
    
 
-    
    <Directory /var/www>
+    
    <Directory "/var/www">
     IndexIgnore *.bak .??* *~ *# HEADER* README* RCS CVS *,v *,t
 </Directory>
-<Directory /var/www/backups>
+<Directory "/var/www/backups">
     IndexIgnoreReset ON
     IndexIgnore .??* *# HEADER* README* RCS CVS *,v *,t
 </Directory>
    
@@ -800,7 +902,7 @@ indexing
      
  • Multiple IndexOptions directives for a
      single directory are now merged together. The result of:
 
-     
    <Directory /foo>
+     
    <Directory "/foo">
     IndexOptions HTMLTable
     IndexOptions SuppressColumnsorting
 </Directory>
    
@@ -938,108 +1040,6 @@ ReadmeName /include/FOOTER.html
    
     
    See also HeaderName, where this behavior is described in greater
     detail.
    
 
-
-
    top
    
-
    
-
    Autoindex Request Query Arguments
    
-    
-
-    
    Various query string arguments are available to give the client
-    some control over the ordering of the directory listing, as well as
-    what files are listed. If you do not wish to give the client this
-    control, the IndexOptions
-    IgnoreClient option disables that functionality.
    
-
-    
    The column sorting headers themselves are self-referencing
-    hyperlinks that add the sort query options shown below. Any
-    option below may be added to any request for the directory
-    resource.
    
-
-    
      
-      
    • C=N sorts the directory by file name
      • 
-
-      
    • C=M sorts the directory by last-modified
-      date, then file name
      • 
-
-      
    • C=S sorts the directory by size, then file
-      name
      • 
-
-      
    • C=D sorts the directory by description, then
-      file name
      • 
-
-      
    • O=A sorts the listing in Ascending
-      Order
      • 
-
-      
    • O=D sorts the listing in Descending
-      Order
      • 
-
-      
    • F=0 formats the listing as a simple list
-      (not FancyIndexed)
      • 
-
-      
    • F=1 formats the listing as a FancyIndexed
-      list
      • 
-
-      
    • F=2 formats the listing as an
-      HTMLTable FancyIndexed list
      • 
-
-      
    • V=0 disables version sorting
      • 
-
-      
    • V=1 enables version sorting
      • 
-
-      
    • P=pattern lists only files matching
-      the given pattern
      • 
-    
    
-
-    
    Note that the 'P'attern query argument is tested
-    after the usual IndexIgnore directives are processed,
-    and all file names are still subjected to the same criteria as
-    any other autoindex listing. The Query Arguments parser in
-    mod_autoindex will stop abruptly when an unrecognized
-    option is encountered. The Query Arguments must be well formed,
-    according to the table above.
    
-
-    
    The simple example below, which can be clipped and saved in
-    a header.html file, illustrates these query options. Note that
-    the unknown "X" argument, for the submit button, is listed last
-    to assure the arguments are all parsed before mod_autoindex
-    encounters the X=Go input.
    
-
-    
    
-      <form action="" method="get">
    
-      
-        Show me a <select name="F">
    
-        
-          <option value="0"> Plain list</option>
    
-          <option value="1" selected="selected"> Fancy list</option>
    
-          <option value="2"> Table list</option>
    
-            
-        </select>
    
-        Sorted by <select name="C">
    
-        
-          <option value="N" selected="selected"> Name</option>
    
-          <option value="M"> Date Modified</option>
    
-          <option value="S"> Size</option>
    
-          <option value="D"> Description</option>
    
-            
-        </select>
    
-        <select name="O">
    
-        
-          <option value="A" selected="selected"> Ascending</option>
    
-          <option value="D"> Descending</option>
    
-            
-        </select>
    
-        <select name="V">
    
-        
-          <option value="0" selected="selected"> in Normal order</option>
    
-          <option value="1"> in Version order</option>
    
-            
-        </select>
    
-        Matching <input type="text" name="P" value="*" />
    
-        <input type="submit" name="X" value="Go" />
    
-          
-      </form>
-    
    
-
 
    
 
 
    
diff --git a/docs/manual/mod/mod_autoindex.html.fr b/docs/manual/mod/mod_autoindex.html.fr
index 03008e29d0..000277a41d 100644
--- a/docs/manual/mod/mod_autoindex.html.fr
+++ b/docs/manual/mod/mod_autoindex.html.fr
@@ -30,6 +30,8 @@
  ko  |
  tr 
    
 
    
+
    Cette traduction peut être périmée. Vérifiez la version
+            anglaise pour les changements récents.
    
 
    • 
 
    Description:Alternate text to display for a file, instead of an
@@ -463,10 +565,10 @@ a directory
    
@@ -77,7 +79,10 @@ shell Win32 dir
     affiché avant un fichier de 1011 octets (en ordre croissant), même
     si la taille affichée des deux fichiers est "1K".
    
-
+
    top
    
+
    
+
    Arguments de la requête d'autoindexation
    
+    
+
+    
    La chaîne de paramètres de la requête peut contenir de nombreux
+    arguments permettant dans une certaine mesure au client de contrôler
+    l'ordre de l'index du répertoire, ainsi que la liste des fichiers à
+    afficher. Si vous souhaitez désactiver cette fonctionnalité,
+    utilisez l'option IndexOptions
+    IgnoreClient.
    
+
+    
    Les en-têtes de tri des colonnes eux-mêmes sont des hyper-liens
+    auto-référant qui ajoutent les options de tri à la requête énumérées
+    ci-dessous qui peuvent être ajoutées à toute requête concernant la
+    ressource répertoire.
    
+
+    
      
+      
    • C=N trie l'affichage en fonction du nom de
+      fichier
      • 
+
+      
    • C=M trie l'affichage en fonction de la date de
+      dernière modification, puis du nom de fichier
      • 
+
+      
    • C=S trie l'affichage en fonction de la taille,
+      puis du nom de fichier
      • 
+
+      
    • C=D trie l'affichage en fonction
+      de la description, puis du nom de fichier
      • 
+
+      
    • O=A trie l'affichage selon l'ordre croissant
      • 
+
+      
    • O=D trie l'affichage selon
+      l'ordre décroissant
      • 
+
+      
    • F=0 affiche le listing sous la forme d'une simple
+      liste (sans FancyIndex)
      • 
+
+      
    • F=1 affiche le listing avec en-têtes de colonnes
+      sous forme de liens hyper-textes (FancyIndexed)
      • 
+
+      
    • F=2 affiche le listing sous
+      forme de table HTML avec en-têtes de colonnes contenant des liens
+      hyper-textes (FancyIndexed)
      • 
+
+      
    • V=0 désactive le tri en fonction de la
+      version
      • 
+
+      
    • V=1 active le tri en fonction de
+      la version
      • 
+
+      
    • P=modèle n'affiche que les fichiers
+      correspondant au modèle spécifié
      • 
+    
    
+
+    
    Notez que l'argument 'P' (pour Pattern) n'est testé
+    qu'après que les directives habituelles IndexIgnore ont été traitées,
+    et que tous les noms de fichiers sont encore assujettis aux mêmes
+    critères que pour tout autre listing auto-indexé. L'interpréteur
+    d'arguments de requête de mod_autoindex s'arrête
+    immédiatement s'il rencontre une option non reconnue. Les arguments
+    de requête doivent être bien formés, selon la table ci-dessus.
    
+
+    
    Les options de requêtes sont illustrées par l'exemple ci-dessous,
+    qui peut être copié et collé dans un fichier header.html. Notez que
+    l'argument inconnu "X", pour le bouton submit, est introduit en
+    dernier afin de s'assurer que tous les arguments ont été
+    interprétés avant que mod_autoindex ne rencontre l'entrée X=Go.
    
+
+    
    
+      <form action="" method="get">
    
+      
+        Montre moi une <select name="F">
    
+        
+          <option value="0"> liste simple</option>
    
+          <option value="1" selected="selected"> liste avec
+	  en-têtes</option>
    
+          <option value="2"> liste avec en-tête sous forme de
+	  table</option>
    
+            
+        </select>
    
+        triée par <select name="C">
    
+        
+          <option value="N" selected="selected"> nom</option>
    
+          <option value="M"> date de modification</option>
    
+          <option value="S"> taille</option>
    
+          <option value="D"> description</option>
    
+            
+        </select>
    
+        <select name="O">
    
+        
+          <option value="A" selected="selected"> croissant</option>
    
+          <option value="D"> décroissant</option>
    
+            
+        </select>
    
+        <select name="V">
    
+        
+          <option value="0" selected="selected"> dans l'ordre
+	  normal</option>
    
+          <option value="1"> en fonction de la version</option>
    
+            
+        </select>
    
+        correspondant à <input type="text" name="P" value="*" />
    
+        <input type="submit" name="X" value="Go" />
    
+          
+      </form>
+    
    
+
+
    top
    Directive AddAlt
    
 
    Description:Génère automatiquement des index de répertoires d'une
 manière similaire à la commande Unix ls, ou à la commande
 shell Win32 dir
    
 
 
 
    
@@ -988,115 +1099,6 @@ ReadmeName /include/FOOTER.html
    Voir aussi la directive HeaderName, où cette fonctionnalité est décrite plus en
     détails.
    
 
-
-
    top
    
-
    
-
    Arguments de la requête d'autoindexation
    
-    
-
-    
    La chaîne de paramètres de la requête peut contenir de nombreux
-    arguments permettant dans une certaine mesure au client de contrôler
-    l'ordre de l'index du répertoire, ainsi que la liste des fichiers à
-    afficher. Si vous souhaitez désactiver cette fonctionnalité,
-    utilisez l'option IndexOptions
-    IgnoreClient.
    
-
-    
    Les en-têtes de tri des colonnes eux-mêmes sont des hyper-liens
-    auto-référant qui ajoutent les options de tri à la requête énumérées
-    ci-dessous qui peuvent être ajoutées à toute requête concernant la
-    ressource répertoire.
    
-
-    
      
-      
    • C=N trie l'affichage en fonction du nom de
-      fichier
      • 
-
-      
    • C=M trie l'affichage en fonction de la date de
-      dernière modification, puis du nom de fichier
      • 
-
-      
    • C=S trie l'affichage en fonction de la taille,
-      puis du nom de fichier
      • 
-
-      
    • C=D trie l'affichage en fonction
-      de la description, puis du nom de fichier
      • 
-
-      
    • O=A trie l'affichage selon l'ordre croissant
      • 
-
-      
    • O=D trie l'affichage selon
-      l'ordre décroissant
      • 
-
-      
    • F=0 affiche le listing sous la forme d'une simple
-      liste (sans FancyIndex)
      • 
-
-      
    • F=1 affiche le listing avec en-têtes de colonnes
-      sous forme de liens hyper-textes (FancyIndexed)
      • 
-
-      
    • F=2 affiche le listing sous
-      forme de table HTML avec en-têtes de colonnes contenant des liens
-      hyper-textes (FancyIndexed)
      • 
-
-      
    • V=0 désactive le tri en fonction de la
-      version
      • 
-
-      
    • V=1 active le tri en fonction de
-      la version
      • 
-
-      
    • P=modèle n'affiche que les fichiers
-      correspondant au modèle spécifié
      • 
-    
    
-
-    
    Notez que l'argument 'P' (pour Pattern) n'est testé
-    qu'après que les directives habituelles IndexIgnore ont été traitées,
-    et que tous les noms de fichiers sont encore assujettis aux mêmes
-    critères que pour tout autre listing auto-indexé. L'interpréteur
-    d'arguments de requête de mod_autoindex s'arrête
-    immédiatement s'il rencontre une option non reconnue. Les arguments
-    de requête doivent être bien formés, selon la table ci-dessus.
    
-
-    
    Les options de requêtes sont illustrées par l'exemple ci-dessous,
-    qui peut être copié et collé dans un fichier header.html. Notez que
-    l'argument inconnu "X", pour le bouton submit, est introduit en
-    dernier afin de s'assurer que tous les arguments ont été
-    interprétés avant que mod_autoindex ne rencontre l'entrée X=Go.
    
-
-    
    
-      <form action="" method="get">
    
-      
-        Montre moi une <select name="F">
    
-        
-          <option value="0"> liste simple</option>
    
-          <option value="1" selected="selected"> liste avec
-	  en-têtes</option>
    
-          <option value="2"> liste avec en-tête sous forme de
-	  table</option>
    
-            
-        </select>
    
-        triée par <select name="C">
    
-        
-          <option value="N" selected="selected"> nom</option>
    
-          <option value="M"> date de modification</option>
    
-          <option value="S"> taille</option>
    
-          <option value="D"> description</option>
    
-            
-        </select>
    
-        <select name="O">
    
-        
-          <option value="A" selected="selected"> croissant</option>
    
-          <option value="D"> décroissant</option>
    
-            
-        </select>
    
-        <select name="V">
    
-        
-          <option value="0" selected="selected"> dans l'ordre
-	  normal</option>
    
-          <option value="1"> en fonction de la version</option>
    
-            
-        </select>
    
-        correspondant à <input type="text" name="P" value="*" />
    
-        <input type="submit" name="X" value="Go" />
    
-          
-      </form>
-    
    
-
 
    
diff --git a/docs/manual/mod/mod_autoindex.html.ja.utf8 b/docs/manual/mod/mod_autoindex.html.ja.utf8
index b5d266829c..52f802b7ab 100644
--- a/docs/manual/mod/mod_autoindex.html.ja.utf8
+++ b/docs/manual/mod/mod_autoindex.html.ja.utf8
@@ -89,7 +89,10 @@
     1010 バイトのファイルは必ず 1011
     バイトのファイルよりも前 (昇順の場合) に表示されます。
    
 
    
-
    ディレクティブ
    
+
+
    
+
    top
    
+
    
+
    Autoindex リクエストクエリー引数
    
+    
+
+    
    Apache 2.0.23 で、
+    コラムソートのためにクエリー引数を再編成して、
+    新しいクエリーオプションのグループを導入しました。
+    出力に対するクライアントのすべての制御を効率的に抹消
+    できるように、
+    IndexOptions
+    IgnoreClient が導入されました。
    
+
+    
    コラムソートのヘッダそれ自体が、
+    下記のソートクエリーオプションを付加する
+    自分自身を参照するリンクです。
+    下記のオプションのどれでも、
+    ディレクトリリソースへのリクエストに加えることができます。
    
+
+    
      
+      
    • C=N は、ファイル名でソートします。
      • 
+
+      
    • C=M は、更新日時、
+      ディレクトリ、ファイル名の順でソートします。
      • 
+
+      
    • C=S は、サイズ、
+      ディレクトリ、ファイル名の順でソートします。
      • 
+
+      
    • C=D は、説明、
+      ディレクトリ、ファイル名の順でソートします。
      • 
+
+      
    • O=A は、昇順で表をソートします。
      • 
+
+      
    • O=D は、降順で表をソートします。
      • 
+
+      
    • F=0 は、単純な表の書式にします。
+      (FancyIndex ではありません。)
      • 
+
+      
    • F=1 は、FancyIndex 
+      表示の表の書式にします。
      • 
+
+      
    • F=2 は、表を HTML 
+      のテーブルを使った FancyIndex の書式にします。
      • 
+
+      
    • V=0 
+      は、バージョンによるソートを無効にします。
      • 
+
+      
    • V=1 
+      は、バージョンによるソートを有効にします。
      • 
+
+      
    • P=pattern 
+      は、与えられた pattern
+      に適合したファイルのみを表示します。
      • 
+    
    
+
+    
    "P (パターンの P)" クエリー引数は、
+    通常の IndexIgnore
+    ディレクティブが処理された後に検査され、
+    ファイル名全てが、他の autoindex
+    リスト処理と同様の判定基準下に置かれ続ける
+    ことに注意してください。
+    mod_autoindex のクエリー引数パーサ (解析) は、
+    認識不能なオプションにぶつかると即座に停止します。
+    クエリー引数は上の表に従って
+    正しい形式になっていなければなりません。
    
+
+    
    下の単純な例は、これらのクエリーオプションを
+    表します。これをそのまま切り取って HEADER.html 
+    ファイルに保存することもできます。
+    mod_autoindex が X=Go 入力にぶつかる前に
+    引数が全て解釈されるように、
+    未知の引数 "X" はリストの最後に置かれています。
    
+
+    
    
+      <form action="" method="get">
    
+      
+        Show me a <select name="F">
    
+        
+          <option value="0"> Plain list</option>
    
+          <option value="1" selected="selected"> Fancy list</option>
    
+          <option value="2"> Table list</option>
    
+            
+        </select>
    
+        Sorted by <select name="C">
    
+        
+          <option value="N" selected="selected"> Name</option>
    
+          <option value="M"> Date Modified</option>
    
+          <option value="S"> Size</option>
    
+          <option value="D"> Description</option>
    
+            
+        </select>
    
+        <select name="O">
    
+        
+          <option value="A" selected="selected"> Ascending</option>
    
+          <option value="D"> Descending</option>
    
+            
+        </select>
    
+        <select name="V">
    
+        
+          <option value="0" selected="selected"> in Normal order</option>
    
+          <option value="1"> in Version order</option>
    
+            
+        </select>
    
+        Matching <input type="text" name="P" value="*" />
    
+        <input type="submit" name="X" value="Go" />
    
+          
+      </form>
+    
    
+
+
    top
    AddAlt ディレクティブ
    
 
    
     
 
 
 
 
    
@@ -932,116 +1042,6 @@ Name|Date|Size|Description
    より詳細にまでこの挙動について記述している HeaderName
     もご覧下さい。
    
 
-
-
    top
    
-
    
-
    Autoindex リクエストクエリー引数
    
-    
-
-    
    Apache 2.0.23 で、
-    コラムソートのためにクエリー引数を再編成して、
-    新しいクエリーオプションのグループを導入しました。
-    出力に対するクライアントのすべての制御を効率的に抹消
-    できるように、
-    IndexOptions
-    IgnoreClient が導入されました。
    
-
-    
    コラムソートのヘッダそれ自体が、
-    下記のソートクエリーオプションを付加する
-    自分自身を参照するリンクです。
-    下記のオプションのどれでも、
-    ディレクトリリソースへのリクエストに加えることができます。
    
-
-    
      
-      
    • C=N は、ファイル名でソートします。
      • 
-
-      
    • C=M は、更新日時、
-      ディレクトリ、ファイル名の順でソートします。
      • 
-
-      
    • C=S は、サイズ、
-      ディレクトリ、ファイル名の順でソートします。
      • 
-
-      
    • C=D は、説明、
-      ディレクトリ、ファイル名の順でソートします。
      • 
-
-      
    • O=A は、昇順で表をソートします。
      • 
-
-      
    • O=D は、降順で表をソートします。
      • 
-
-      
    • F=0 は、単純な表の書式にします。
-      (FancyIndex ではありません。)
      • 
-
-      
    • F=1 は、FancyIndex 
-      表示の表の書式にします。
      • 
-
-      
    • F=2 は、表を HTML 
-      のテーブルを使った FancyIndex の書式にします。
      • 
-
-      
    • V=0 
-      は、バージョンによるソートを無効にします。
      • 
-
-      
    • V=1 
-      は、バージョンによるソートを有効にします。
      • 
-
-      
    • P=pattern 
-      は、与えられた pattern
-      に適合したファイルのみを表示します。
      • 
-    
    
-
-    
    "P (パターンの P)" クエリー引数は、
-    通常の IndexIgnore
-    ディレクティブが処理された後に検査され、
-    ファイル名全てが、他の autoindex
-    リスト処理と同様の判定基準下に置かれ続ける
-    ことに注意してください。
-    mod_autoindex のクエリー引数パーサ (解析) は、
-    認識不能なオプションにぶつかると即座に停止します。
-    クエリー引数は上の表に従って
-    正しい形式になっていなければなりません。
    
-
-    
    下の単純な例は、これらのクエリーオプションを
-    表します。これをそのまま切り取って HEADER.html 
-    ファイルに保存することもできます。
-    mod_autoindex が X=Go 入力にぶつかる前に
-    引数が全て解釈されるように、
-    未知の引数 "X" はリストの最後に置かれています。
    
-
-    
    
-      <form action="" method="get">
    
-      
-        Show me a <select name="F">
    
-        
-          <option value="0"> Plain list</option>
    
-          <option value="1" selected="selected"> Fancy list</option>
    
-          <option value="2"> Table list</option>
    
-            
-        </select>
    
-        Sorted by <select name="C">
    
-        
-          <option value="N" selected="selected"> Name</option>
    
-          <option value="M"> Date Modified</option>
    
-          <option value="S"> Size</option>
    
-          <option value="D"> Description</option>
    
-            
-        </select>
    
-        <select name="O">
    
-        
-          <option value="A" selected="selected"> Ascending</option>
    
-          <option value="D"> Descending</option>
    
-            
-        </select>
    
-        <select name="V">
    
-        
-          <option value="0" selected="selected"> in Normal order</option>
    
-          <option value="1"> in Version order</option>
    
-            
-        </select>
    
-        Matching <input type="text" name="P" value="*" />
    
-        <input type="submit" name="X" value="Go" />
    
-          
-      </form>
-    
    
-
 
    
diff --git a/docs/manual/mod/mod_autoindex.html.ko.euc-kr b/docs/manual/mod/mod_autoindex.html.ko.euc-kr
index 052bec6450..218a2e4d7d 100644
--- a/docs/manual/mod/mod_autoindex.html.ko.euc-kr
+++ b/docs/manual/mod/mod_autoindex.html.ko.euc-kr
@@ -73,7 +73,10 @@
     ¹ÙÀÌÆ® ÆÄÀÏÀº µÑ´Ù "1K"·Î º¸ÀÌ´õ¶óµµ Ç×»ó 1010 ¹ÙÀÌÆ® ÆÄÀÏÀÌ
     ¾Õ¿¡ ³ª¿Â´Ù.
    
 
    
-
    Áö½Ã¾îµé
    
+
+
    
+
    top
    
+
    
+
    Autoindex ¿äû ¾Æ±Ô¸ÕÆ®
    
+    
+
+    
    ¾ÆÆÄÄ¡ 2.0.23´Â ¿­¼ø¼­¿¡ ´ëÇÑ ¿äû ¾Æ±Ô¸ÕÆ®¸¦ Á¤¸®ÇÏ°í,
+    »õ·Î¿î ¿É¼ÇµéÀ» Ãß°¡Çß´Ù. Ãâ·ÂÀ» Ŭ¶óÀ̾ðÆ®°¡ Á¶ÀýÇÒ ¼ö
+    ¾øµµ·Ï ¸¸µå´Â IndexOptions
+    IgnoreClient ¿É¼ÇÀÌ Ãß°¡µÇ¾ú´Ù.
    
+
+    
    ¿­¼ø¼­ À̸§Àº ¾Æ·¡ ³ª¿Â ¼ø¼­ ¿äû ¿É¼ÇÀ» ´õÇÑ ÀÚ±âÂüÁ¶
+    ¸µÅ©´Ù. ¾Æ·¡ ¿É¼ÇÀº µð·ºÅ丮 ÀÚ¿ø¿¡ ´ëÇÑ ¾î¶² ¿äû¿¡µµ
+    »ç¿ëÇÒ ¼ö ÀÖ´Ù.
    
+
+    
      
+      
    • C=NÀº ÆÄÀÏ¸í ¼øÀÌ´Ù
      • 
+
+      
    • C=MÀº ÃÖ±Ù ¼öÁ¤ÀÏ ¼ø, ±×¸®°í ÆÄÀÏ¸í ¼øÀÌ´Ù
      • 
+
+      
    • C=S´Â Å©±â ¼ø, ±×¸®°í ÆÄÀÏ¸í ¼øÀÌ´Ù
      • 
+
+      
    • C=D´Â ¼³¸í ¼ø, ±×¸®°í ÆÄÀϸí
+      ¼øÀÌ´Ù
      • 
+
+      
    • O=A´Â ¿À¸§Â÷¼øÀ¸·Î ¸ñ·ÏÀ» Á¤·ÄÇÑ´Ù
      • 
+
+      
    • O=D´Â ³»¸²Â÷¼øÀ¸·Î ¸ñ·ÏÀ» Á¤·ÄÇÑ´Ù
      • 
+
+      
    • F=0Àº (FancyIndexed°¡ ¾Æ´Ñ) °£´ÜÇÑ ¸ñ·Ï Çü½ÄÀÌ´Ù
      • 
+
+      
    • F=1Àº FancyIndexed ¸ñ·Ï Çü½ÄÀÌ´Ù
      • 
+
+      
    • F=2´Â HTMLTable FancyIndexed ¸ñ·Ï
+      Çü½ÄÀÌ´Ù
      • 
+
+      
    • V=0Àº ¹öÀü ¼øÀ¸·Î Á¤·ÄÇÏÁö ¾Ê´Â´Ù
      • 
+
+      
    • V=1Àº ¹öÀü ¼øÀ¸·Î Á¤·ÄÇÑ´Ù
      • 
+
+      
    • P=patternÀº ÁÖ¾îÁø pattern¿¡
+      ÇØ´çÇÏ´Â ÆÄÀϸ¸À» ¸ñ·ÏÀ¸·Î ¸¸µç´Ù
      • 
+    
    
+
+    
    'P'attern ¾Æ±Ô¸ÕÆ®´Â ÀϹÝÀûÀÎ IndexIgnore Áö½Ã¾î¸¦ ó¸®ÇÑ ÈÄ¿¡
+    °Ë»çÇϱ⶧¹®¿¡, ¸ñ·ÏÀº ´Ù¸¥ autoindex Á¶°ÇÀ» µû¸§À» ÁÖÀÇÇ϶ó.
+    mod_autoindexÀÇ ¿äû ¾Æ±Ô¸ÕÆ®¸¦ ÀоîµéÀ϶§
+    ¾Ë ¼ö ¾ø´Â ¿É¼ÇÀ» ¹ß°ßÇÏ¸é ´õ ÀÌ»ó ÀÐÁö¾Ê´Â´Ù. ¿äû ¾Æ±Ô¸ÕÆ®´Â
+    À§ÀÇ Ç¥¿¡ µû¶ó ¸¸µé¾î¾ß ÇÑ´Ù.
    
+
+    
    header.html ÆÄÀÏ¿¡ »ç¿ëÇÒ ¼ö ÀÖ´Â ¾Æ·¡ °£´ÜÇÑ ¿¹Á¦´Â
+    ÀÌ ¿É¼ÇµéÀ» ¼³¸íÇÑ´Ù. submit ¹öÅÏÀÇ ¾Ë ¼ö ¾ø´Â "X" ¾Æ±Ô¸ÕÆ®´Â
+    mod_autoindex°¡ X=Go Àü±îÁö ¸ðµç ¾Æ±Ô¸ÕÆ®¸¦ ÀоîµéÀÓÀ»
+    È®ÀÎÇϱâÀ§ÇØ ¸¶Áö¸·¿¡ »ç¿ëÇß´Ù.
    
+
+    
    
+      <form action="" method="get">
    
+      
+        Show me a <select name="F">
    
+        
+          <option value="0"> Plain list</option>
    
+          <option value="1" selected="selected"> Fancy list</option>
    
+          <option value="2"> Table list</option>
    
+            
+        </select>
    
+        Sorted by <select name="C">
    
+        
+          <option value="N" selected="selected"> Name</option>
    
+          <option value="M"> Date Modified</option>
    
+          <option value="S"> Size</option>
    
+          <option value="D"> Description</option>
    
+            
+        </select>
    
+        <select name="O">
    
+        
+          <option value="A" selected="selected"> Ascending</option>
    
+          <option value="D"> Descending</option>
    
+            
+        </select>
    
+        <select name="V">
    
+        
+          <option value="0" selected="selected"> in Normal order</option>
    
+          <option value="1"> in Version order</option>
    
+            
+        </select>
    
+        Matching <input type="text" name="P" value="*" />
    
+        <input type="submit" name="X" value="Go" />
    
+          
+      </form>
+    
    
+
+
    top
    AddAlt Áö½Ã¾î
    
 
    
     
 
 
 
 
    
@@ -763,97 +854,6 @@ Name|Date|Size|Description
    ÀÌ µ¿ÀÛÀ» ÀÚ¼¼È÷ ¼³¸íÇÑ HeaderNameµµ Âü°íÇ϶ó.
    
 
-
-
    top
    
-
    
-
    Autoindex ¿äû ¾Æ±Ô¸ÕÆ®
    
-    
-
-    
    ¾ÆÆÄÄ¡ 2.0.23´Â ¿­¼ø¼­¿¡ ´ëÇÑ ¿äû ¾Æ±Ô¸ÕÆ®¸¦ Á¤¸®ÇÏ°í,
-    »õ·Î¿î ¿É¼ÇµéÀ» Ãß°¡Çß´Ù. Ãâ·ÂÀ» Ŭ¶óÀ̾ðÆ®°¡ Á¶ÀýÇÒ ¼ö
-    ¾øµµ·Ï ¸¸µå´Â IndexOptions
-    IgnoreClient ¿É¼ÇÀÌ Ãß°¡µÇ¾ú´Ù.
    
-
-    
    ¿­¼ø¼­ À̸§Àº ¾Æ·¡ ³ª¿Â ¼ø¼­ ¿äû ¿É¼ÇÀ» ´õÇÑ ÀÚ±âÂüÁ¶
-    ¸µÅ©´Ù. ¾Æ·¡ ¿É¼ÇÀº µð·ºÅ丮 ÀÚ¿ø¿¡ ´ëÇÑ ¾î¶² ¿äû¿¡µµ
-    »ç¿ëÇÒ ¼ö ÀÖ´Ù.
    
-
-    
      
-      
    • C=NÀº ÆÄÀÏ¸í ¼øÀÌ´Ù
      • 
-
-      
    • C=MÀº ÃÖ±Ù ¼öÁ¤ÀÏ ¼ø, ±×¸®°í ÆÄÀÏ¸í ¼øÀÌ´Ù
      • 
-
-      
    • C=S´Â Å©±â ¼ø, ±×¸®°í ÆÄÀÏ¸í ¼øÀÌ´Ù
      • 
-
-      
    • C=D´Â ¼³¸í ¼ø, ±×¸®°í ÆÄÀϸí
-      ¼øÀÌ´Ù
      • 
-
-      
    • O=A´Â ¿À¸§Â÷¼øÀ¸·Î ¸ñ·ÏÀ» Á¤·ÄÇÑ´Ù
      • 
-
-      
    • O=D´Â ³»¸²Â÷¼øÀ¸·Î ¸ñ·ÏÀ» Á¤·ÄÇÑ´Ù
      • 
-
-      
    • F=0Àº (FancyIndexed°¡ ¾Æ´Ñ) °£´ÜÇÑ ¸ñ·Ï Çü½ÄÀÌ´Ù
      • 
-
-      
    • F=1Àº FancyIndexed ¸ñ·Ï Çü½ÄÀÌ´Ù
      • 
-
-      
    • F=2´Â HTMLTable FancyIndexed ¸ñ·Ï
-      Çü½ÄÀÌ´Ù
      • 
-
-      
    • V=0Àº ¹öÀü ¼øÀ¸·Î Á¤·ÄÇÏÁö ¾Ê´Â´Ù
      • 
-
-      
    • V=1Àº ¹öÀü ¼øÀ¸·Î Á¤·ÄÇÑ´Ù
      • 
-
-      
    • P=patternÀº ÁÖ¾îÁø pattern¿¡
-      ÇØ´çÇÏ´Â ÆÄÀϸ¸À» ¸ñ·ÏÀ¸·Î ¸¸µç´Ù
      • 
-    
    
-
-    
    'P'attern ¾Æ±Ô¸ÕÆ®´Â ÀϹÝÀûÀÎ IndexIgnore Áö½Ã¾î¸¦ ó¸®ÇÑ ÈÄ¿¡
-    °Ë»çÇϱ⶧¹®¿¡, ¸ñ·ÏÀº ´Ù¸¥ autoindex Á¶°ÇÀ» µû¸§À» ÁÖÀÇÇ϶ó.
-    mod_autoindexÀÇ ¿äû ¾Æ±Ô¸ÕÆ®¸¦ ÀоîµéÀ϶§
-    ¾Ë ¼ö ¾ø´Â ¿É¼ÇÀ» ¹ß°ßÇÏ¸é ´õ ÀÌ»ó ÀÐÁö¾Ê´Â´Ù. ¿äû ¾Æ±Ô¸ÕÆ®´Â
-    À§ÀÇ Ç¥¿¡ µû¶ó ¸¸µé¾î¾ß ÇÑ´Ù.
    
-
-    
    header.html ÆÄÀÏ¿¡ »ç¿ëÇÒ ¼ö ÀÖ´Â ¾Æ·¡ °£´ÜÇÑ ¿¹Á¦´Â
-    ÀÌ ¿É¼ÇµéÀ» ¼³¸íÇÑ´Ù. submit ¹öÅÏÀÇ ¾Ë ¼ö ¾ø´Â "X" ¾Æ±Ô¸ÕÆ®´Â
-    mod_autoindex°¡ X=Go Àü±îÁö ¸ðµç ¾Æ±Ô¸ÕÆ®¸¦ ÀоîµéÀÓÀ»
-    È®ÀÎÇϱâÀ§ÇØ ¸¶Áö¸·¿¡ »ç¿ëÇß´Ù.
    
-
-    
    
-      <form action="" method="get">
    
-      
-        Show me a <select name="F">
    
-        
-          <option value="0"> Plain list</option>
    
-          <option value="1" selected="selected"> Fancy list</option>
    
-          <option value="2"> Table list</option>
    
-            
-        </select>
    
-        Sorted by <select name="C">
    
-        
-          <option value="N" selected="selected"> Name</option>
    
-          <option value="M"> Date Modified</option>
    
-          <option value="S"> Size</option>
    
-          <option value="D"> Description</option>
    
-            
-        </select>
    
-        <select name="O">
    
-        
-          <option value="A" selected="selected"> Ascending</option>
    
-          <option value="D"> Descending</option>
    
-            
-        </select>
    
-        <select name="V">
    
-        
-          <option value="0" selected="selected"> in Normal order</option>
    
-          <option value="1"> in Version order</option>
    
-            
-        </select>
    
-        Matching <input type="text" name="P" value="*" />
    
-        <input type="submit" name="X" value="Go" />
    
-          
-      </form>
-    
    
-
 
    
diff --git a/docs/manual/mod/mod_autoindex.html.tr.utf8 b/docs/manual/mod/mod_autoindex.html.tr.utf8
index cdc4875038..09f85d3cc2 100644
--- a/docs/manual/mod/mod_autoindex.html.tr.utf8
+++ b/docs/manual/mod/mod_autoindex.html.tr.utf8
@@ -73,7 +73,10 @@ yaptığı gibi dizin içeriğini listeler.
       olanı küçükten büyüğe sıralamada 1011 baytlıktan önce
       gösterilecektir.
    
 
    
-
    Yönergeler
    
+
    Konular
    
+
    Yönergeler
    
 
-
    Konular
    
-
    
+
    
+
    top
    
+
    
+
    Sütun Sıralamada Sorgu Seçenekleri
    
+    
+
+    
    İstemciye, dizin içeriğini listelerken neleri hangi sırada
+      listeleyeceğini belirleyebilmesi için içerik üzerinde biraz denetim
+      sağlayabileceği çeşitli sorgu dizgesi bileşenleri sağlanmıştır.
+      Çıktı üzerinde kullanıcı denetimini tamamen ortadan kaldırmak için
+      IndexOptions yönergesinin
+      IgnoreClient
+      seçeneği kullanılabilir.
    
+
+    
    Sütun sıralama başlıklarının her biri hedefi kendisi olan birer hiper
+      bağ olup aşağıda sıralanan sorgu seçeneklerini kullanırlar. Bu
+      seçeneklerin her biri her dizin içerik listesi isteğine eklenebilir.
    
+
+    
      
+      
    • C=N dizini dosya adına göre sıralar
      • 
+
+      
    • C=M dizini son değişiklik zamanına ve ardından dosya
+        ismine göre sıralar.
      • 
+
+      
    • C=S dizini boyuta ve ardından dosya adına göre
+        sıralar
      • 
+
+      
    • C=D dizini açıklamaya ve ardından
+        dosya adına göre sıralar.
      • 
+
+      
    • O=A artan sıralama uygulanır.
      • 
+
+      
    • O=D  azalan sıralama uygulanır.
      • 
+
+      
    • F=0 listeleme basit listeleme biçiminde yapılır
+        (FancyIndexing seçeneği ile etkinleştirilen biçimde
+        değil)
      • 
+
+      
    • F=1 listeleme FancyIndexing seçeneği ile
+        etkinleştirilen biçimde yapılır
      • 
+
+      
    • F=2 listeleme FancyIndexing ve
+        HTMLTable seçeneği
+        ile etkinleştirilen biçimde yapılır.
      • 
+
+      
    • V=0 sürüme göre sıralama iptal edilir.
      • 
+
+      
    • V=1 sürüme göre sıralama etkin
+        kılınır.
      • 
+
+      
    • P=kalıp sadece belirtilen
+        kalıp ile eşleşen dosyalar istelenir.
      • 
+    
    
+
+    
    P=kalıp sorgu seçeneğinin normalde IndexIgnore yönergesi işleme
+      sokulduktan sonra değerlendirildiğine ve dosya isimlerinin diğer
+      kendiliğinden içerik listeleme koşullarının konusu olmaya devam ettiğine
+      dikkat ediniz. mod_autoindex modülündeki Sorgu
+      Seçenekleri çözümleyicisi tanımadığı bir seçeneğe rastlar rastlamaz
+      işlemi durdurur. Sorgu Seçenekleri yukarıda belirtilene uygun olarak iyi
+      biçimli olmak zorundadır.
    
+
+    
    Aşağıdaki basit örnekte sorgu seçeneklerinin kullanımı gösterilmiştir.
+      Son satırda bulunan "submit" düğmesindeki tanınmayan "X" girdisine
+      dikkat ediniz. "X=Göster" girdisi tüm seçenekler işlendikten sonra
+      mod_autoindex tarafından son argüman olarak ele
+      alınacak ve çözümleme işlemi o noktada duracaktır.
    
+
+    
    <form action="" method="get">
+  <input type="text" name="P" value="*" /> ile eşleşen
+  <select name="C">
+    <option value="N" selected="selected">isme</option>
+    <option value="M"> değişiklik tarihine</option>
+    <option value="S"> boyuta</option>
+    <option value="D"> açıklamaya</option>
+  </select> göre
+  <select name="O">
+    <option value="A" selected="selected"> artan</option>
+    <option value="D"> azalan</option>
+  </select>
+  <select name="V">
+    <option value="0" selected="selected">normal</option>
+    <option value="1"> sürümlü</option>
+  </select> sıralamayla bir
+  <select name="F">
+    <option value="0"> basit liste</option>
+    <option value="1" selected="selected"> süslü liste</option>
+    <option value="2"> tablolu liste</option>
+  </select>
+  <input type="submit" name="X" value="Göster" />
+</form>
    
+
+
    top
    AddAlt Yönergesi
    
 
    
 
     
 
 
 
 
    
@@ -944,98 +1036,6 @@ belirler.
    Ayrıca bu davranışın daha ayrıntılı ele alındığı HeaderName yönergesine de
       bakınız.
    
 
-
-
    top
    
-
    
-
    Sütun Sıralamada Sorgu Seçenekleri
    
-    
-
-    
    İstemciye, dizin içeriğini listelerken neleri hangi sırada
-      listeleyeceğini belirleyebilmesi için içerik üzerinde biraz denetim
-      sağlayabileceği çeşitli sorgu dizgesi bileşenleri sağlanmıştır.
-      Çıktı üzerinde kullanıcı denetimini tamamen ortadan kaldırmak için
-      IndexOptions yönergesinin
-      IgnoreClient
-      seçeneği kullanılabilir.
    
-
-    
    Sütun sıralama başlıklarının her biri hedefi kendisi olan birer hiper
-      bağ olup aşağıda sıralanan sorgu seçeneklerini kullanırlar. Bu
-      seçeneklerin her biri her dizin içerik listesi isteğine eklenebilir.
    
-
-    
      
-      
    • C=N dizini dosya adına göre sıralar
      • 
-
-      
    • C=M dizini son değişiklik zamanına ve ardından dosya
-        ismine göre sıralar.
      • 
-
-      
    • C=S dizini boyuta ve ardından dosya adına göre
-        sıralar
      • 
-
-      
    • C=D dizini açıklamaya ve ardından
-        dosya adına göre sıralar.
      • 
-
-      
    • O=A artan sıralama uygulanır.
      • 
-
-      
    • O=D  azalan sıralama uygulanır.
      • 
-
-      
    • F=0 listeleme basit listeleme biçiminde yapılır
-        (FancyIndexing seçeneği ile etkinleştirilen biçimde
-        değil)
      • 
-
-      
    • F=1 listeleme FancyIndexing seçeneği ile
-        etkinleştirilen biçimde yapılır
      • 
-
-      
    • F=2 listeleme FancyIndexing ve
-        HTMLTable seçeneği
-        ile etkinleştirilen biçimde yapılır.
      • 
-
-      
    • V=0 sürüme göre sıralama iptal edilir.
      • 
-
-      
    • V=1 sürüme göre sıralama etkin
-        kılınır.
      • 
-
-      
    • P=kalıp sadece belirtilen
-        kalıp ile eşleşen dosyalar istelenir.
      • 
-    
    
-
-    
    P=kalıp sorgu seçeneğinin normalde IndexIgnore yönergesi işleme
-      sokulduktan sonra değerlendirildiğine ve dosya isimlerinin diğer
-      kendiliğinden içerik listeleme koşullarının konusu olmaya devam ettiğine
-      dikkat ediniz. mod_autoindex modülündeki Sorgu
-      Seçenekleri çözümleyicisi tanımadığı bir seçeneğe rastlar rastlamaz
-      işlemi durdurur. Sorgu Seçenekleri yukarıda belirtilene uygun olarak iyi
-      biçimli olmak zorundadır.
    
-
-    
    Aşağıdaki basit örnekte sorgu seçeneklerinin kullanımı gösterilmiştir.
-      Son satırda bulunan "submit" düğmesindeki tanınmayan "X" girdisine
-      dikkat ediniz. "X=Göster" girdisi tüm seçenekler işlendikten sonra
-      mod_autoindex tarafından son argüman olarak ele
-      alınacak ve çözümleme işlemi o noktada duracaktır.
    
-
-    
    <form action="" method="get">
-  <input type="text" name="P" value="*" /> ile eşleşen
-  <select name="C">
-    <option value="N" selected="selected">isme</option>
-    <option value="M"> değişiklik tarihine</option>
-    <option value="S"> boyuta</option>
-    <option value="D"> açıklamaya</option>
-  </select> göre
-  <select name="O">
-    <option value="A" selected="selected"> artan</option>
-    <option value="D"> azalan</option>
-  </select>
-  <select name="V">
-    <option value="0" selected="selected">normal</option>
-    <option value="1"> sürümlü</option>
-  </select> sıralamayla bir
-  <select name="F">
-    <option value="0"> basit liste</option>
-    <option value="1" selected="selected"> süslü liste</option>
-    <option value="2"> tablolu liste</option>
-  </select>
-  <input type="submit" name="X" value="Göster" />
-</form>
    
-
 
    
diff --git a/docs/manual/mod/mod_autoindex.xml b/docs/manual/mod/mod_autoindex.xml
index 503a08f518..9898bc8722 100644
--- a/docs/manual/mod/mod_autoindex.xml
+++ b/docs/manual/mod/mod_autoindex.xml
@@ -563,10 +563,10 @@ a directory
     inherited from other configuration sections. 
    
 
     
-<Directory /var/www>
+<Directory "/var/www">
     IndexIgnore *.bak .??* *~ *# HEADER* README* RCS CVS *,v *,t
 </Directory>
-<Directory /var/www/backups>
+<Directory "/var/www/backups">
     IndexIgnoreReset ON
     IndexIgnore .??* *# HEADER* README* RCS CVS *,v *,t
 </Directory>
@@ -955,7 +955,7 @@ indexing
      single directory are now merged together. The result of:
 
      
-<Directory /foo>
+<Directory "/foo">
     IndexOptions HTMLTable
     IndexOptions SuppressColumnsorting
 </Directory>
diff --git a/docs/manual/mod/mod_autoindex.xml.fr b/docs/manual/mod/mod_autoindex.xml.fr
index 432b783fe8..9b12837a85 100644
--- a/docs/manual/mod/mod_autoindex.xml.fr
+++ b/docs/manual/mod/mod_autoindex.xml.fr
@@ -1,7 +1,7 @@
 
 
 
-
+
 
 
 
diff --git a/docs/manual/mod/mod_autoindex.xml.ja b/docs/manual/mod/mod_autoindex.xml.ja
index 255cdec477..e0ac8ff3b5 100644
--- a/docs/manual/mod/mod_autoindex.xml.ja
+++ b/docs/manual/mod/mod_autoindex.xml.ja
@@ -1,7 +1,7 @@
 
 
 
-
+
 
 
+
 
 
+