<!--#if expr="$FAQMASTER" -->
 <!--#set var="STANDALONE" value="" -->
 <!--#set var="INCLUDED" value="YES" -->
 <!--#if expr="$QUERY_STRING = TOC" -->
  <!--#set var="TOC" value="YES" -->
  <!--#set var="CONTENT" value="" -->
 <!--#else -->
  <!--#set var="TOC" value="" -->
  <!--#set var="CONTENT" value="YES" -->
 <!--#endif -->
<!--#else -->
 <!--#set var="STANDALONE" value="YES" -->
 <!--#set var="INCLUDED" value="" -->
 <!--#set var="TOC" value="" -->
 <!--#set var="CONTENT" value="" -->
<!--#endif -->
<!--#if expr="$STANDALONE" -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
 <HEAD>
  <TITLE>Apache Server Frequently Asked Questions</TITLE>
 </HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  BGCOLOR="#FFFFFF"
  TEXT="#000000"
  LINK="#0000FF"
  VLINK="#000080"
  ALINK="#FF0000"
 >
  <!--#include virtual="header.html" -->
  <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
  <P>
  $Revision: 1.1 $ ($Date: 1999/06/24 15:02:52 $)
  </P>
  <P>
  The latest version of this FAQ is always available from the main
  Apache web site, at
  &lt;<A
       HREF="http://www.apache.org/docs/misc/FAQ.html"
       REL="Help"
      ><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>&gt;.
  </P>
<!-- Notes about changes:                                           -->
<!--  - If adding a relative link to another part of the            -->
<!--    documentation, *do* include the ".html" portion.  There's a -->
<!--    good chance that the user will be reading the documentation -->
<!--    on his own system, which may not be configured for          -->
<!--    multiviews.                                                 -->
<!--  - When adding items, make sure they're put in the right place -->
<!--    - verify that the numbering matches up.                     -->
<!--  - *Don't* use <PRE></PRE> blocks - they don't appear          -->
<!--    correctly in a reliable way when this is converted to text  -->
<!--    with Lynx.  Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL>    -->
<!--    blocks inside a <P></P> instead.  This is necessary to get  -->
<!--    the horizontal and vertical indenting right.                -->
<!--  - Don't forget to include an HR tag after the last /P tag     -->
<!--    but before the /LI in an item.                              -->
  <P>
  If you are reading a text-only version of this FAQ, you may find numbers
  enclosed in brackets (such as &quot;[12]&quot;).  These refer to the list of
  reference URLs to be found at the end of the document.  These references
  do not appear, and are not needed, for the hypertext version.
  </P>
  <H2>The Questions</H2>
<OL TYPE="A">
<!--#endif -->
<!--#if expr="$TOC || $STANDALONE" -->
 <LI VALUE="8"><STRONG>URL Rewriting</STRONG>
  <OL>
   <LI><A HREF="#rewrite-more-config">Where can I find mod_rewrite rulesets
        which already solve particular URL-related problems?</A>
   </LI>
   <LI><A HREF="#rewrite-article">Where can I find any published information
        about URL-manipulations and mod_rewrite?</A>
   </LI>
   <LI><A HREF="#rewrite-complexity">Why is mod_rewrite so difficult to learn
        and seems so complicated?</A>
   </LI>
   <LI><A HREF="#rewrite-dontwork">What can I do if my RewriteRules don't work
        as expected?</A>
   </LI>
   <LI><A HREF="#rewrite-prefixdocroot">Why don't some of my URLs get
        prefixed with DocumentRoot when using mod_rewrite?</A>
   </LI>
   <LI><A HREF="#rewrite-nocase">How can I make all my URLs case-insensitive
        with mod_rewrite?</A>
   </LI>
   <LI><A HREF="#rewrite-virthost">Why are RewriteRules in my VirtualHost
        parts ignored?</A>
   </LI>
   <LI><A HREF="#rewrite-envwhitespace">How can I use strings with whitespaces
        in RewriteRule's ENV flag?</A>
   </LI>
  </OL>
 </LI>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
</OL>

<HR>

  <H2>The Answers</H2>
<!--#endif -->
<!--#if expr="! $TOC" -->

  <H3>H. URL Rewriting</H3>
<OL>

 <LI><A NAME="rewrite-more-config">
      <STRONG>Where can I find mod_rewrite rulesets which already solve
      particular URL-related problems?</STRONG>
     </A>
  <P>
  There is a collection of 
  <A HREF="http://www.engelschall.com/pw/apache/rewriteguide/"
  >Practical Solutions for URL-Manipulation</A>
  where you can
  find all typical solutions the author of 
  <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A> 
  currently knows of. If you have more
  interesting rulesets which solve particular problems not currently covered in
  this document, send it to 
  <A HREF="mailto:rse@apache.org">Ralf S. Engelschall</A>
  for inclusion. The
  other webmasters will thank you for avoiding the reinvention of the wheel.
  </P>
  <HR>
 </LI>

 <LI><A NAME="rewrite-article">
      <STRONG>Where can I find any published information about
      URL-manipulations and mod_rewrite?</STRONG>
     </A>
  <P>
  There is an article from 
  <A HREF="mailto:rse@apache.org"
  >Ralf S. Engelschall</A>
  about URL-manipulations based on
  <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A> 
  in the &quot;iX Multiuser Multitasking Magazin&quot; issue #12/96. The
  german (original) version
  can be read online at 
  &lt;<A HREF="http://www.heise.de/ix/artikel/9612149/"
      >http://www.heise.de/ix/artikel/9612149/</A>&gt;,
  the English (translated) version can be found at 
  &lt;<A HREF="http://www.heise.de/ix/artikel/E/9612149/"
      >http://www.heise.de/ix/artikel/E/9612149/</A>&gt;.
  </P>
  <HR>
 </LI>

 <LI><A NAME="rewrite-complexity">
      <STRONG>Why is mod_rewrite so difficult to learn and seems so
      complicated?</STRONG>
     </A>
  <P>
  Hmmm... there are a lot of reasons. First, mod_rewrite itself is a powerful
  module which can help you in really <STRONG>all</STRONG> aspects of URL
  rewriting, so it can be no trivial module per definition. To accomplish
  its hard job it uses software leverage and makes use of a powerful regular
  expression
  library by Henry Spencer which is an integral part of Apache since its
  version 1.2.  And regular expressions itself can be difficult to newbies,
  while providing the most flexible power to the advanced hacker. 
  </P>
  <P>
  On the other hand mod_rewrite has to work inside the Apache API environment
  and needs to do some tricks to fit there. For instance the Apache API as of
  1.x really was not designed for URL rewriting at the <TT>.htaccess</TT>
  level of processing. Or the problem of multiple rewrites in sequence, which
  is also not handled by the API per design. To provide this features
  mod_rewrite has to do some special (but API compliant!) handling which leads
  to difficult processing inside the Apache kernel. While the user usually
  doesn't see anything of this processing, it can be difficult to find
  problems when some of your RewriteRules seem not to work.
  </P>
  <HR>
 </LI>

 <LI><A NAME="rewrite-dontwork">
      <STRONG>What can I do if my RewriteRules don't work as expected?
      </STRONG>
     </A>
  <P>
  Use &quot;<SAMP>RewriteLog somefile</SAMP>&quot; and
  &quot;<SAMP>RewriteLogLevel 9</SAMP>&quot; and have a precise look at the
  steps the rewriting engine performs. This is really the only one and best
  way to debug your rewriting configuration.
  </P>
  <HR>
 </LI>

 <LI><A NAME="rewrite-prefixdocroot"><STRONG>Why don't some of my URLs
      get prefixed with DocumentRoot when using mod_rewrite?</STRONG>
     </A>
  <P>
  If the rule starts with <SAMP>/somedir/...</SAMP> make sure that
  really no <SAMP>/somedir</SAMP> exists on the filesystem if you
  don't want to lead the URL to match this directory, <EM>i.e.</EM>,
  there must be no root directory named <SAMP>somedir</SAMP> on the
  filesystem. Because if there is such a directory, the URL will not
  get prefixed with DocumentRoot. This behaviour looks ugly, but is
  really important for some other aspects of URL rewriting.
  </P>
  <HR>
 </LI>

 <LI><A NAME="rewrite-nocase">
      <STRONG>How can I make all my URLs case-insensitive with mod_rewrite?
      </STRONG>
     </A>
  <P>
  You can't! The reason is: First, case translations for arbitrary
  length URLs cannot be done <EM>via</EM> regex patterns and
  corresponding substitutions.  One need a per-character pattern like
  sed/Perl <SAMP>tr|..|..|</SAMP> feature.  Second, just making URLs
  always upper or lower case will not resolve the complete problem of
  case-INSENSITIVE URLs, because actually the URLs had to be rewritten
  to the correct case-variant residing on the filesystem because in
  later processing Apache needs to access the file.  And Unix
  filesystem is always case-SENSITIVE.
  </P>
  <P>
  But there is a module named <CODE>mod_speling.c</CODE> (yes, it is named
  this way!) out there on the net. Try this one.
  </P>
  <HR>
 </LI>

 <LI><A NAME="rewrite-virthost">
      <STRONG> Why are RewriteRules in my VirtualHost parts ignored?</STRONG>
     </A>
  <P>
  Because you have to enable the engine for every virtual host explicitly due
  to security concerns. Just add a &quot;RewriteEngine on&quot; to your
  virtual host configuration parts.
  </P>
  <HR>
 </LI>

 <LI><A NAME="rewrite-envwhitespace">
      <STRONG> How can I use strings with whitespaces in RewriteRule's ENV
      flag?</STRONG>
     </A>
  <P>
  There is only one ugly solution: You have to surround the complete
  flag argument by quotation marks (<SAMP>"[E=...]"</SAMP>). Notice:
  The argument to quote here is not the argument to the E-flag, it is
  the argument of the Apache config file parser, <EM>i.e.</EM>, the
  third argument of the RewriteRule here.  So you have to write
  <SAMP>"[E=any text with whitespaces]"</SAMP>.
  </P>
  <HR>
 </LI>

</OL>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
  <!-- Don't forget to add HR tags at the end of each list item.. -->

<!--#include virtual="footer.html" -->
</BODY>
</HTML>
<!--#endif -->