| <?xml version='1.0' encoding='UTF-8' ?> |
| <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> |
| <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?> |
| <!-- $LastChangedRevision$ --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <manualpage metafile="htaccess.xml.meta"> |
| <parentdocument href="./">How-To / Tutorials</parentdocument> |
| |
| <title>Apache HTTP Server Tutorial: .htaccess files</title> |
| |
| <summary> |
| <p><code>.htaccess</code> files provide a way to make configuration |
| changes on a per-directory basis.</p> |
| </summary> |
| |
| <section id="related"><title>.htaccess files</title> |
| <related> |
| <modulelist> |
| <module>core</module> |
| <module>mod_authn_file</module> |
| <module>mod_authz_groupfile</module> |
| <module>mod_cgi</module> |
| <module>mod_include</module> |
| <module>mod_mime</module> |
| </modulelist> |
| |
| <directivelist> |
| <directive module="core">AccessFileName</directive> |
| <directive module="core">AllowOverride</directive> |
| <directive module="core">Options</directive> |
| <directive module="mod_mime">AddHandler</directive> |
| <directive module="core">SetHandler</directive> |
| <directive module="mod_authn_core">AuthType</directive> |
| <directive module="mod_authn_core">AuthName</directive> |
| <directive module="mod_authn_file">AuthUserFile</directive> |
| <directive module="mod_authz_groupfile">AuthGroupFile</directive> |
| <directive module="mod_authz_core">Require</directive> |
| </directivelist> |
| |
| </related> |
| |
| <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 http 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> |
| </section> |
| |
| <section id="what"> |
| <title>What they are/How to use them</title> |
| |
| <p><code>.htaccess</code> files (or "distributed configuration files") |
| provide a way to make configuration changes on a per-directory basis. A |
| file, containing one or more configuration directives, is placed in a |
| particular document directory, and the directives apply to that |
| directory, and all subdirectories thereof.</p> |
| |
| <note><title>Note:</title> |
| <p>If you want to call your <code>.htaccess</code> file something |
| else, you can change the name of the file using the <directive |
| module="core">AccessFileName</directive> directive. For example, |
| if you would rather call the file <code>.config</code> then you |
| can put the following in your server configuration file:</p> |
| |
| <highlight language="config"> |
| AccessFileName ".config" |
| </highlight> |
| </note> |
| |
| <p>In general, <code>.htaccess</code> files use the same syntax as |
| the <a href="../configuring.html#syntax">main configuration |
| files</a>. What you can put in these files is determined by the |
| <directive module="core">AllowOverride</directive> directive. This |
| directive specifies, in categories, what directives will be |
| honored if they are found in a <code>.htaccess</code> file. If a |
| directive is permitted in a <code>.htaccess</code> file, the |
| documentation for that directive will contain an Override section, |
| specifying what value must be in <directive |
| module="core">AllowOverride</directive> in order for that |
| directive to be permitted.</p> |
| |
| <p>For example, if you look at the documentation for the <directive |
| module="core">AddDefaultCharset</directive> |
| directive, you will find that it is permitted in <code>.htaccess</code> |
| files. (See the Context line in the directive summary.) The <a |
| href="../mod/directive-dict.html#Context">Override</a> line reads |
| <code>FileInfo</code>. Thus, you must have at least |
| <code>AllowOverride FileInfo</code> in order for this directive to be |
| honored in <code>.htaccess</code> files.</p> |
| |
| <example><title>Example:</title> |
| <table> |
| <tr> |
| <td><a |
| href="../mod/directive-dict.html#Context">Context:</a></td> |
| <td>server config, virtual host, directory, .htaccess</td> |
| </tr> |
| |
| <tr> |
| <td><a |
| href="../mod/directive-dict.html#Override">Override:</a></td> |
| <td>FileInfo</td> |
| </tr> |
| </table> |
| </example> |
| |
| <p>If you are unsure whether a particular directive is permitted in a |
| <code>.htaccess</code> file, look at the documentation for that |
| directive, and check the Context line for ".htaccess".</p> |
| </section> |
| |
| <section id="when"><title>When (not) to use .htaccess files</title> |
| |
| <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, |
| another misconception 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. 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 |
| per-directory basis, but do not have root access on the server system. |
| In the event that the server administrator is not willing to make |
| frequent configuration changes, it might be desirable to permit |
| individual users to make these changes in <code>.htaccess</code> files |
| for themselves. This is particularly true, for example, in cases where |
| ISPs are hosting multiple user sites on a single machine, and want |
| their users to be able to alter their configuration.</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 <directive module="core" |
| 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 |
| module="core">AllowOverride</directive> |
| is set to allow the use of <code>.htaccess</code> files, httpd will |
| look in every directory for <code>.htaccess</code> files. Thus, |
| permitting <code>.htaccess</code> files causes a performance hit, |
| whether or not you actually even use them! Also, the |
| <code>.htaccess</code> file is loaded every time a document is |
| requested.</p> |
| |
| <p>Further note that httpd must look for <code>.htaccess</code> files |
| in all higher-level directories, in order to have a full complement of |
| directives that it must apply. (See section on <a href="#how">how |
| directives are applied</a>.) Thus, if a file is requested out of a |
| directory <code>/www/htdocs/example</code>, httpd must look for the |
| following files:</p> |
| |
| <example> |
| /.htaccess<br /> |
| /www/.htaccess<br /> |
| /www/htdocs/.htaccess<br /> |
| /www/htdocs/example/.htaccess |
| </example> |
| |
| <p>And so, for each file access out of that directory, there are 4 |
| additional file-system accesses, even if none of those files are |
| present. (Note that this would only be the case if |
| <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 |
| your users this privilege. Note also that giving users less |
| privileges than they need will lead to additional technical support |
| requests. Make sure you clearly tell your users what level of |
| privileges you have given them. Specifying exactly what you have set |
| <directive module="core">AllowOverride</directive> to, and pointing them |
| to the relevant documentation, will save yourself a lot of confusion |
| later.</p> |
| |
| <p>Note that it is completely equivalent to put a <code>.htaccess</code> |
| file in a directory <code>/www/htdocs/example</code> containing a |
| directive, and to put that same directive in a Directory section |
| <code><Directory "/www/htdocs/example"></code> in your main server |
| configuration:</p> |
| |
| <p><code>.htaccess</code> file in <code>/www/htdocs/example</code>:</p> |
| |
| <example><title>Contents of .htaccess file in |
| <code>/www/htdocs/example</code></title> |
| <highlight language="config"> |
| AddType text/example ".exm" |
| </highlight> |
| </example> |
| |
| <example><title>Section from your <code>httpd.conf</code> |
| file</title> |
| <highlight language="config"> |
| <Directory "/www/htdocs/example"> |
| AddType text/example ".exm" |
| </Directory> |
| </highlight> |
| </example> |
| |
| <p>However, putting this configuration in your server configuration |
| file will result in less of a performance hit, as the configuration is |
| loaded once when httpd starts, rather than every time a file is |
| requested.</p> |
| |
| <p>The use of <code>.htaccess</code> files can be disabled completely |
| by setting the <directive module="core">AllowOverride</directive> |
| directive to <code>none</code>:</p> |
| |
| <highlight language="config"> |
| AllowOverride None |
| </highlight> |
| </section> |
| |
| <section id="how"><title>How directives are applied</title> |
| |
| <p>The configuration directives found in a <code>.htaccess</code> file |
| are applied to the directory in which the <code>.htaccess</code> file |
| is found, and to all subdirectories thereof. However, it is important |
| to also remember that there may have been <code>.htaccess</code> files |
| in directories higher up. Directives are applied in the order that they |
| are found. Therefore, a <code>.htaccess</code> file in a particular |
| directory may override directives found in <code>.htaccess</code> files |
| found higher up in the directory tree. And those, in turn, may have |
| overridden directives found yet higher up, or in the main server |
| configuration file itself.</p> |
| |
| <p>Example:</p> |
| |
| <p>In the directory <code>/www/htdocs/example1</code> we have a |
| <code>.htaccess</code> file containing the following:</p> |
| |
| <highlight language="config"> |
| Options +ExecCGI |
| </highlight> |
| |
| <p>(Note: you must have "<code>AllowOverride Options</code>" in effect |
| to permit the use of the "<directive |
| module="core">Options</directive>" directive in |
| <code>.htaccess</code> files.)</p> |
| |
| <p>In the directory <code>/www/htdocs/example1/example2</code> we have |
| a <code>.htaccess</code> file containing:</p> |
| |
| <highlight language="config"> |
| Options Includes |
| </highlight> |
| |
| <p>Because of this second <code>.htaccess</code> file, in the directory |
| <code>/www/htdocs/example1/example2</code>, CGI execution is not |
| permitted, as only <code>Options Includes</code> is in effect, which |
| completely overrides any earlier setting that may have been in |
| place.</p> |
| |
| <section id="merge"><title>Merging of .htaccess with the main |
| configuration files</title> |
| |
| <p>As discussed in the documentation on <a |
| href="../sections.html">Configuration Sections</a>, |
| <code>.htaccess</code> files can override the <directive |
| type="section" module="core">Directory</directive> sections for |
| the corresponding directory, but will be overridden by other types |
| of configuration sections from the main configuration files. This |
| fact can be used to enforce certain configurations, even in the |
| presence of a liberal <directive |
| module="core">AllowOverride</directive> setting. For example, to |
| prevent script execution while allowing anything else to be set in |
| <code>.htaccess</code> you can use:</p> |
| |
| <highlight language="config"> |
| <Directory "/www/htdocs"> |
| AllowOverride All |
| </Directory> |
| |
| <Location "/"> |
| Options +IncludesNoExec -ExecCGI |
| </Location> |
| </highlight> |
| |
| <note>This example assumes that your <directive |
| module="core">DocumentRoot</directive> is <code>/www/htdocs</code>.</note> |
| </section> |
| |
| </section> |
| |
| <section id="auth"><title>Authentication example</title> |
| |
| <p>If you jumped directly to this part of the document to find out how |
| to do authentication, it is important to note one thing. There is a |
| common misconception that you are required to use |
| <code>.htaccess</code> files in order to implement password |
| authentication. This is not the case. Putting authentication directives |
| 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 |
| href="#when">above</a> for a discussion of when you should and should |
| not use <code>.htaccess</code> files.</p> |
| |
| <p>Having said that, if you still think you need to use a |
| <code>.htaccess</code> file, you may find that a configuration such as |
| what follows may work for you.</p> |
| |
| <p><code>.htaccess</code> file contents:</p> |
| |
| <highlight language="config"> |
| AuthType Basic |
| AuthName "Password Required" |
| AuthUserFile "/www/passwords/password.file" |
| AuthGroupFile "/www/passwords/group.file" |
| Require group admins |
| </highlight> |
| |
| <p>Note that <code>AllowOverride AuthConfig</code> must be in effect |
| for these directives to have any effect.</p> |
| |
| <p>Please see the <a href="auth.html">authentication tutorial</a> for a |
| more complete discussion of authentication and authorization.</p> |
| </section> |
| |
| <section id="ssi"><title>Server Side Includes example</title> |
| |
| <p>Another common use of <code>.htaccess</code> files is to enable |
| Server Side Includes for a particular directory. This may be done with |
| the following configuration directives, placed in a |
| <code>.htaccess</code> file in the desired directory:</p> |
| |
| <highlight language="config"> |
| Options +Includes |
| AddType text/html shtml |
| AddHandler server-parsed shtml |
| </highlight> |
| |
| <p>Note that <code>AllowOverride Options</code> and <code>AllowOverride |
| FileInfo</code> must both be in effect for these directives to have any |
| effect.</p> |
| |
| <p>Please see the <a href="ssi.html">SSI tutorial</a> for a more |
| complete discussion of server-side includes.</p> |
| </section> |
| |
| <section id="rewrite"><title>Rewrite Rules in .htaccess files</title> |
| <p>When using <directive module="mod_rewrite">RewriteRule</directive> in |
| <code>.htaccess</code> files, be aware that the per-directory context |
| changes things a bit. In particular, rules are taken to be relative to |
| the current directory, rather than being the original requested URI. |
| Consider the following examples:</p> |
| |
| <highlight language="config"> |
| # In httpd.conf |
| RewriteRule "^/images/(.+)\.jpg" "/images/$1.png" |
| |
| # In .htaccess in root dir |
| RewriteRule "^images/(.+)\.jpg" "images/$1.png" |
| |
| # In .htaccess in images/ |
| RewriteRule "^(.+)\.jpg" "$1.png" |
| </highlight> |
| |
| <p>In a <code>.htaccess</code> in your document directory, the leading |
| slash is removed from the value supplied to <directive |
| module="mod_rewrite">RewriteRule</directive>, and in the |
| <code>images</code> subdirectory, <code>/images/</code> is removed from |
| it. Thus, your regular expression needs to omit that portion as |
| well.</p> |
| |
| <p>Consult the <a href="../rewrite/">mod_rewrite documentation</a> for |
| further details on using <code>mod_rewrite</code>.</p> |
| |
| </section> |
| |
| <section id="cgi"><title>CGI example</title> |
| |
| <p>Finally, you may wish to use a <code>.htaccess</code> file to permit |
| the execution of CGI programs in a particular directory. This may be |
| implemented with the following configuration:</p> |
| |
| <highlight language="config"> |
| Options +ExecCGI |
| AddHandler cgi-script cgi pl |
| </highlight> |
| |
| <p>Alternately, if you wish to have all files in the given directory be |
| considered to be CGI programs, this may be done with the following |
| configuration:</p> |
| |
| <highlight language="config"> |
| Options +ExecCGI |
| SetHandler cgi-script |
| </highlight> |
| |
| <p>Note that <code>AllowOverride Options</code> and <code>AllowOverride |
| FileInfo</code> must both be in effect for these directives to have any |
| effect.</p> |
| |
| <p>Please see the <a href="cgi.html">CGI tutorial</a> for a more |
| complete discussion of CGI programming and configuration.</p> |
| |
| </section> |
| |
| <section id="troubleshoot"><title>Troubleshooting</title> |
| |
| <p>When you put configuration directives in a <code>.htaccess</code> |
| file, and you don't get the desired effect, there are a number of |
| things that may be going wrong.</p> |
| |
| <p>Most commonly, the problem is that <directive |
| module="core">AllowOverride</directive> is not |
| set such that your configuration directives are being honored. Make |
| sure that you don't have a <code>AllowOverride None</code> in effect |
| for the file scope in question. A good test for this is to put garbage |
| in your <code>.htaccess</code> file and reload the page. If a server error is |
| not generated, then you almost certainly have <code>AllowOverride |
| None</code> in effect.</p> |
| |
| <p>If, on the other hand, you are getting server errors when trying to |
| access documents, check your httpd error log. It will likely tell you |
| that the directive used in your <code>.htaccess</code> file is not |
| permitted.</p> |
| |
| <example> |
| [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here |
| </example> |
| |
| <p>This will indicate either that you've used a directive that is |
| never permitted in <code>.htaccess</code> files, or that you simply |
| don't have <directive module="core">AllowOverride</directive> set to |
| 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> |
| |
| <example> |
| [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters |
| </example> |
| |
| <p>In this case, the error message should be specific to the |
| particular syntax error that you have committed.</p> |
| |
| </section> |
| |
| </manualpage> |