Poking around the old htaccess howto, looking for ways that we can make

it more relevant. These days, instead of "htaccess files are for auth"
the general belief is "htaccess files are for rewrite".

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

diff --git a/docs/manual/howto/htaccess.html.en b/docs/manual/howto/htaccess.html.en
index 3d671058cd21a0e27d4bfbc5fc6fc8db6669d539..8ac91f42fdcb1b6961c74fe081e7acad55ff412f 100644 (file)
--- a/docs/manual/howto/htaccess.html.en
+++ b/docs/manual/howto/htaccess.html.en
@@ -102,11 +102,14 @@ changes on a per-directory basis.</p>
 
     <p>In general, you should never use <code>.htaccess</code> files unless
     you don't have access to the main server configuration file. There is,
-    for example, a prevailing misconception that user authentication should
-    always be done in <code>.htaccess</code> files. This is simply not the
+    for example, a common misconception that user authentication should
+    always be done in <code>.htaccess</code> files, and, in more recent years, 
+    another miscomception that <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> directives
+    must go in <code>.htaccess</code> files. This is simply not the
     case. You can put user authentication configurations in the main server
     configuration, and this is, in fact, the preferred way to do
-    things.</p>
+    things. Likewise, <code>mod_rewrite</code> directives work better,
+    in many respects, in the main server configuration.</p>
 
     <p><code>.htaccess</code> files should be used in a case where the
     content providers need to make configuration changes to the server on a
@@ -155,6 +158,15 @@ changes on a per-directory basis.</p>
     <code>.htaccess</code> files were enabled for <code>/</code>, which
     is not usually the case.)</p>
 
+    <p>In the case of <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> directives, in
+    <code>.htaccess</code> context these regular expressions must be
+    re-compiled with every request to the directory, whereas in main
+    server configuration context they are compiled once and cached.
+    Additionally, the rules themselves are more complicated, as one must
+    work around the restrictions that come with per-directory context
+    and <code>mod_rewrite</code>. Consult the <a href="../rewrite/intro.html#htaccess">Rewrite Guide</a> for more
+    detail on this subject.</p>
+
     <p>The second consideration is one of security. You are permitting
     users to modify server configuration, which may result in changes over
     which you have no control. Carefully consider whether you want to give

diff --git a/docs/manual/howto/htaccess.xml b/docs/manual/howto/htaccess.xml
index ccddcc8c1fc63c9d45fa692f4eea57fe93f5849c..b560f1df85392eb50b5bd0f0c0b927a85a04e959 100644 (file)
--- a/docs/manual/howto/htaccess.xml
+++ b/docs/manual/howto/htaccess.xml
@@ -124,11 +124,14 @@ changes on a per-directory basis.</p>
 
     <p>In general, you should never use <code>.htaccess</code> files unless
     you don't have access to the main server configuration file. There is,
-    for example, a prevailing misconception that user authentication should
-    always be done in <code>.htaccess</code> files. This is simply not the
+    for example, a common misconception that user authentication should
+    always be done in <code>.htaccess</code> files, and, in more recent years, 
+    another miscomception that <module>mod_rewrite</module> directives
+    must go in <code>.htaccess</code> files. This is simply not the
     case. You can put user authentication configurations in the main server
     configuration, and this is, in fact, the preferred way to do
-    things.</p>
+    things. Likewise, <code>mod_rewrite</code> directives work better,
+    in many respects, in the main server configuration.</p>
 
     <p><code>.htaccess</code> files should be used in a case where the
     content providers need to make configuration changes to the server on a
@@ -179,6 +182,17 @@ changes on a per-directory basis.</p>
     <code>.htaccess</code> files were enabled for <code>/</code>, which
     is not usually the case.)</p>
 
+    <p>In the case of <directive
+    module="mod_rewrite">RewriteRule</directive> directives, in
+    <code>.htaccess</code> context these regular expressions must be
+    re-compiled with every request to the directory, whereas in main
+    server configuration context they are compiled once and cached.
+    Additionally, the rules themselves are more complicated, as one must
+    work around the restrictions that come with per-directory context
+    and <code>mod_rewrite</code>. Consult the <a
+    href="../rewrite/intro.html#htaccess">Rewrite Guide</a> for more
+    detail on this subject.</p>
+
     <p>The second consideration is one of security. You are permitting
     users to modify server configuration, which may result in changes over
     which you have no control. Carefully consider whether you want to give