Return-Path: 
 <cvs-return-36842-apmail-httpd-cvs-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-cvs-archive@www.apache.org
Received: (qmail 9052 invoked from network); 2 Nov 2010 13:41:18 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 2 Nov 2010 13:41:18 -0000
Received: (qmail 71181 invoked by uid 500); 2 Nov 2010 13:41:50 -0000
Delivered-To: apmail-httpd-cvs-archive@httpd.apache.org
Received: (qmail 70957 invoked by uid 500); 2 Nov 2010 13:41:47 -0000
Mailing-List: contact cvs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:cvs-help@httpd.apache.org>
list-unsubscribe: <mailto:cvs-unsubscribe@httpd.apache.org>
List-Post: <mailto:cvs@httpd.apache.org>
List-Id: <cvs.httpd.apache.org>
Delivered-To: mailing list cvs@httpd.apache.org
Received: (qmail 70950 invoked by uid 99); 2 Nov 2010 13:41:46 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Nov 2010 13:41:46 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Nov 2010 13:41:43 +0000
Received: by eris.apache.org (Postfix, from userid 65534)
	id E173E23888FD; Tue,  2 Nov 2010 13:40:28 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: svn commit: r1030041 - in /httpd/httpd/trunk/docs/manual/howto:
 htaccess.html.en htaccess.xml
Date: Tue, 02 Nov 2010 13:40:28 -0000
To: cvs@httpd.apache.org
From: gryzor@apache.org
X-Mailer: svnmailer-1.0.8
Message-Id: <20101102134028.E173E23888FD@eris.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

Author: gryzor
Date: Tue Nov  2 13:40:27 2010
New Revision: 1030041

URL: http://svn.apache.org/viewvc?rev=1030041&view=rev
Log:
Porting previous commit on 2.2 doc, with a not about why .htaccess is bad when you have access to main server config.

Modified:
    httpd/httpd/trunk/docs/manual/howto/htaccess.html.en
    httpd/httpd/trunk/docs/manual/howto/htaccess.xml

Modified: httpd/httpd/trunk/docs/manual/howto/htaccess.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/howto/htaccess.html.en?rev=1030041&r1=1030040&r2=1030041&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/howto/htaccess.html.en (original)
+++ httpd/httpd/trunk/docs/manual/howto/htaccess.html.en Tue Nov  2 13:40:27 2010
@@ -40,6 +40,9 @@ changes on a per-directory basis.</p>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
 <h2><a name="related" id="related">.htaccess files</a></h2>
+    <div class="note">You should avoid using <code>.htaccess</code> files completely if you have access to
+    httpd main server config file. Using <code>.htaccess</code> files slows down your Apache server.
+    Any directive that you can include in a <code>.htaccess</code> file is better set in a <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> block, as it will have the same effect with better performance.</div>
     <table class="related"><tr><th>Related Modules</th><th>Related Directives</th></tr><tr><td><ul><li><code class="module"><a href="../mod/core.html">core</a></code></li><li><code class="module"><a href="../mod/mod_authn_file.html">mod_authn_file</a></code></li><li><code class="module"><a href="../mod/mod_authz_groupfile.html">mod_authz_groupfile</a></code></li><li><code class="module"><a href="../mod/mod_cgi.html">mod_cgi</a></code></li><li><code class="module"><a href="../mod/mod_include.html">mod_include</a></code></li><li><code class="module"><a href="../mod/mod_mime.html">mod_mime</a></code></li></ul></td><td><ul><li><code class="directive"><a href="../mod/core.html#accessfilename">AccessFileName</a></code></li><li><code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code></li><li><code class="directive"><a href="../mod/core.html#options">Options</a></code></li><li><code class="directive"><a href="../mod/mod_mime.html#addhandler">AddHandl
 er</a></code></li><li><code class="directive"><a href="../mod/core.html#sethandler">SetHandler</a></code></li><li><code class="directive"><a href="../mod/mod_authn_core.html#authtype">AuthType</a></code></li><li><code class="directive"><a href="../mod/mod_authn_core.html#authname">AuthName</a></code></li><li><code class="directive"><a href="../mod/mod_authn_file.html#authuserfile">AuthUserFile</a></code></li><li><code class="directive"><a href="../mod/mod_authz_groupfile.html#authgroupfile">AuthGroupFile</a></code></li><li><code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code></li></ul></td></tr></table>
 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
@@ -103,7 +106,7 @@ changes on a per-directory basis.</p>
     <p>In general, you should only use <code>.htaccess</code> files when
     you don't have access to the main server configuration file. There is,
     for example, a common misconception that user authentication should
-    always be done in <code>.htaccess</code> files, and, in more recent years, 
+    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
@@ -124,7 +127,7 @@ changes on a per-directory basis.</p>
     <p>However, in general, use of <code>.htaccess</code> files should be
     avoided when possible. Any configuration that you would consider
     putting in a <code>.htaccess</code> file, can just as effectively be
-    made in a <code class="directive"><a href="../mod/core.html#directory">&lt;Directory&gt;</a></code> section in your main server 
+    made in a <code class="directive"><a href="../mod/core.html#directory">&lt;Directory&gt;</a></code> section in your main server
     configuration file.</p>
 
     <p>There are two main reasons to avoid the use of
@@ -397,7 +400,7 @@ Options +IncludesNoExec -ExecCGI<br />
     a level sufficient for the directive you've used. Consult the
     documentation for that particular directive to determine which is
     the case.</p>
-    
+
     <p>Alternately, it may tell you that you had a syntax error in your
     usage of the directive itself.</p>
 

Modified: httpd/httpd/trunk/docs/manual/howto/htaccess.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/howto/htaccess.xml?rev=1030041&r1=1030040&r2=1030041&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/howto/htaccess.xml (original)
+++ httpd/httpd/trunk/docs/manual/howto/htaccess.xml Tue Nov  2 13:40:27 2010
@@ -31,6 +31,9 @@ changes on a per-directory basis.</p>
 </summary>
 
 <section id="related"><title>.htaccess files</title>
+    <note>You should avoid using <code>.htaccess</code> files completely if you have access to
+    httpd main server config file. Using <code>.htaccess</code> files slows down your Apache server.
+    Any directive that you can include in a <code>.htaccess</code> file is better set in a <directive module="core">Directory</directive> block, as it will have the same effect with better performance.</note>
     <related>
         <modulelist>
             <module>core</module>
@@ -125,7 +128,7 @@ changes on a per-directory basis.</p>
     <p>In general, you should only use <code>.htaccess</code> files when
     you don't have access to the main server configuration file. There is,
     for example, a common misconception that user authentication should
-    always be done in <code>.htaccess</code> files, and, in more recent years, 
+    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
@@ -147,13 +150,13 @@ changes on a per-directory basis.</p>
     avoided when possible. Any configuration that you would consider
     putting in a <code>.htaccess</code> file, can just as effectively be
     made in a <directive module="core"
-    type="section">Directory</directive> section in your main server 
+    type="section">Directory</directive> section in your main server
     configuration file.</p>
 
     <p>There are two main reasons to avoid the use of
     <code>.htaccess</code> files.</p>
 
-    <p>The first of these is performance. When <directive 
+    <p>The first of these is performance. When <directive
     module="core">AllowOverride</directive>
     is set to allow the use of <code>.htaccess</code> files, Apache will
     look in every directory for <code>.htaccess</code> files. Thus,
@@ -309,7 +312,7 @@ Options +IncludesNoExec -ExecCGI<br />
 &lt;/Location&gt;
     </example>
 
-    <note>This example assumes that your <directive 
+    <note>This example assumes that your <directive
     module="core">DocumentRoot</directive> is <code>/www/htdocs</code>.</note>
 </section>
 
@@ -325,7 +328,7 @@ Options +IncludesNoExec -ExecCGI<br />
     in a <directive module="core" type="section">Directory</directive>
     section, in your main server configuration file, is the preferred way
     to implement this, and <code>.htaccess</code> files should be used only
-    if you don't have access to the main server configuration file. See <a 
+    if you don't have access to the main server configuration file. See <a
     href="#when">above</a> for a discussion of when you should and should
     not use <code>.htaccess</code> files.</p>
 
@@ -430,7 +433,7 @@ Options +IncludesNoExec -ExecCGI<br />
     a level sufficient for the directive you've used. Consult the
     documentation for that particular directive to determine which is
     the case.</p>
-    
+
     <p>Alternately, it may tell you that you had a syntax error in your
     usage of the directive itself.</p>