From: Noirin Plunkett Date: Wed, 25 Jan 2006 09:47:31 +0000 (+0000) Subject: More backporting of various language issues X-Git-Tag: 2.0.56~73 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=dabe1b3e641731d595d04264bc484c8f091d0b6f;p=thirdparty%2Fapache%2Fhttpd.git More backporting of various language issues git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x@372173 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_rewrite.xml b/docs/manual/mod/mod_rewrite.xml index b8bc81cfba4..59181c199fb 100644 --- a/docs/manual/mod/mod_rewrite.xml +++ b/docs/manual/mod/mod_rewrite.xml @@ -33,193 +33,121 @@ URLs on the fly Available in Apache 1.3 and later -
-

``The great thing about mod_rewrite is it gives you - all the configurability and flexibility of Sendmail. - The downside to mod_rewrite is that it gives you all - the configurability and flexibility of Sendmail.''

- -

-- Brian Behlendorf
- Apache Group

- -
- -
-

`` Despite the tons of examples and docs, - mod_rewrite is voodoo. Damned cool voodoo, but still - voodoo. ''

- -

-- Brian Moore
- bem@news.cmc.net

- -
- - -

Welcome to mod_rewrite, the Swiss Army Knife of URL - manipulation!

-

This module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an - unlimited number of attached rule conditions for each rule to + unlimited number of attached rule conditions for each rule, to provide a really flexible and powerful URL manipulation mechanism. The URL manipulations can depend on various tests, - for instance server variables, environment variables, HTTP - headers, time stamps and even external database lookups in - various formats can be used to achieve a really granular URL + of server variables, environment variables, HTTP + headers, or time stamps. Even external database lookups in + various formats can be used to achieve highly granular URL matching.

This module operates on the full URLs (including the path-info part) both in per-server context (httpd.conf) and per-directory context - (.htaccess) and can even generate query-string + (.htaccess) and can generate query-string parts on result. The rewritten result can lead to internal sub-processing, external request redirection or even to an internal proxy throughput.

-

But all this functionality and flexibility has its - drawback: complexity. So don't expect to understand this - entire module in just one day.

- -

This module was invented and originally written in April - 1996 and gifted exclusively to the The Apache Group in July 1997 - by

- -

- Ralf S. - Engelschall
- rse@engelschall.com
- www.engelschall.com -

+

Further details, discussion, and examples, are provided in the + detailed mod_rewrite documentation.

 -
Internal Processing - -

The internal processing of this module is very complex but - needs to be explained once even to the average user to avoid - common mistakes and to let you exploit its full - functionality.

-
API Phases -

First you have to understand that when Apache processes a - HTTP request it does this in phases. A hook for each of these - phases is provided by the Apache API. Mod_rewrite uses two of - these hooks: the URL-to-filename translation hook which is - used after the HTTP request has been read but before any - authorization starts and the Fixup hook which is triggered - after the authorization phases and after the per-directory +

Apache processes a HTTP request in several phases. + A hook for each of these + phases is provided by the Apache API. mod_rewrite uses two of + these hooks: the URL-to-filename translation hook + (used after the HTTP request has been read, but before any + authorization starts) and the Fixup hook (triggered + after the authorization phases, and after the per-directory config files (.htaccess) have been read, but - before the content handler is activated.

- -

So, after a request comes in and Apache has determined the - corresponding server (or virtual server) the rewriting engine - starts processing of all mod_rewrite directives from the - per-server configuration in the URL-to-filename phase. A few - steps later when the final data directories are found, the + before the content handler is activated).

+ +

Once a request comes in, and Apache has determined the + appropriate server (or virtual server), the rewrite engine + starts the URL-to-filename translation, + processing the mod_rewrite directives from the + per-server configuration. A few + steps later, when the final data directories are found, the per-directory configuration directives of mod_rewrite are - triggered in the Fixup phase. In both situations mod_rewrite - rewrites URLs either to new URLs or to filenames, although - there is no obvious distinction between them. This is a usage - of the API which was not intended to be this way when the API - was designed, but as of Apache 1.x this is the only way - mod_rewrite can operate. To make this point more clear - remember the following two points:

- -
    -
  1. Although mod_rewrite rewrites URLs to URLs, URLs to - filenames and even filenames to filenames, the API - currently provides only a URL-to-filename hook. In Apache - 2.0 the two missing hooks will be added to make the - processing more clear. But this point has no drawbacks for - the user, it is just a fact which should be remembered: - Apache does more in the URL-to-filename hook than the API - intends for it.
    2. - -
  2. - Unbelievably mod_rewrite provides URL manipulations in - per-directory context, i.e., within - .htaccess files, although these are reached - a very long time after the URLs have been translated to - filenames. It has to be this way because - .htaccess files live in the filesystem, so - processing has already reached this stage. In other - words: According to the API phases at this time it is too - late for any URL manipulations. To overcome this chicken - and egg problem mod_rewrite uses a trick: When you - manipulate a URL/filename in per-directory context - mod_rewrite first rewrites the filename back to its - corresponding URL (which is usually impossible, but see - the RewriteBase directive below for the - trick to achieve this) and then initiates a new internal - sub-request with the new URL. This restarts processing of - the API phases. - -

    Again mod_rewrite tries hard to make this complicated - step totally transparent to the user, but you should - remember here: While URL manipulations in per-server - context are really fast and efficient, per-directory - rewrites are slow and inefficient due to this chicken and - egg problem. But on the other hand this is the only way - mod_rewrite can provide (locally restricted) URL - manipulations to the average user.

    -
    3. -
+ triggered in the Fixup phase.

-

Don't forget these two points!

Ruleset Processing -

Now when mod_rewrite is triggered in these two API phases, it - reads the configured rulesets from its configuration - structure (which itself was either created on startup for - per-server context or during the directory walk of the Apache - kernel for per-directory context). Then the URL rewriting - engine is started with the contained ruleset (one or more - rules together with their conditions). The operation of the - URL rewriting engine itself is exactly the same for both +

When mod_rewrite is triggered during these two API phases, it + reads the relevant rulesets from its configuration + structure (which was either created on startup, for + per-server context, or during the directory traversal + for per-directory context). The URL rewriting + engine is started with the appropriate ruleset (one or more + rules together with their conditions), and its operation + is exactly the same for both configuration contexts. Only the final result processing is different.

The order of rules in the ruleset is important because the - rewriting engine processes them in a special (and not very - obvious) order. The rule is this: The rewriting engine loops - through the ruleset rule by rule (RewriteRule directives) and - when a particular rule matches it optionally loops through - existing corresponding conditions (RewriteCond + rewrite engine processes them in a particular (not always + obvious) order, as follows: The rewrite engine loops + through the rulesets (each ruleset being made up of RewriteRule directives, with or without + RewriteConds), rule by rule. + When a particular rule is matched, mod_rewrite + also checks the corresponding conditions (RewriteCond directives). For historical reasons the conditions are given - first, and so the control flow is a little bit long-winded. See + first, making the control flow a little bit long-winded. See Figure 1 for more details.

[Needs graphics capability to display]
- Figure 1:The control flow through the rewriting ruleset + Figure 1:The control flow of the rewrite engine through a + rewrite ruleset

-

As you can see, first the URL is matched against the - Pattern of each rule. When it fails mod_rewrite - immediately stops processing this rule and continues with the - next rule. If the Pattern matches, mod_rewrite looks - for corresponding rule conditions. If none are present, it - just substitutes the URL with a new value which is - constructed from the string Substitution and goes on - with its rule-looping. But if conditions exist, it starts an - inner loop for processing them in the order that they are - listed. For conditions the logic is different: we don't match - a pattern against the current URL. Instead we first create a - string TestString by expanding variables, - back-references, map lookups, etc. and then we try - to match CondPattern against it. If the pattern - doesn't match, the complete set of conditions and the - corresponding rule fails. If the pattern matches, then the - next condition is processed until no more conditions are +

As above, first the URL is matched against the + Pattern of a rule. If it does not match, mod_rewrite immediately stops processing that rule, + and goes on to the next rule. If the Pattern matches, + mod_rewrite checks for rule conditions. + If none are present, the URL will be replaced with a new string, + constructed from the Substitution string, and mod_rewrite goes on to the next rule.

+

If RewriteConds exist, an + inner loop is started, processing them in the order that they are + listed. Conditions are not matched against the current URL directly. + A TestString is constructed by expanding variables, + back-references, map lookups, etc., against which the + CondPattern is matched. If the pattern fails to match one + of the conditions, the complete set of rule and associated conditions + fails. If the pattern matches a given condition, then matching continues + to the next condition, until no more conditions are available. If all conditions match, processing is continued - with the substitution of the URL with - Substitution.

+ with the substitution of the Substitution string for the URL.

+ +
+
Regex Back-Reference Availability + +

Using parentheses in Pattern or in one of the + CondPatterns causes back-references to be internally + created. + These can later be referenced using the strings $N and + %N (see below), for creating + the Substitution and TestString strings. + Figure 2 attempts to show how the back-references are + transferred through the process for later expansion.

+ +

+ [Needs graphics capability to display]
+ Figure 2: The back-reference flow through a rule. +

Quoting Special Characters @@ -234,30 +162,6 @@ URLs on the fly to treat it as a backreference.

-
Regex Back-Reference Availability - -

One important thing here has to be remembered: Whenever you - use parentheses in Pattern or in one of the - CondPattern, back-references are internally created - which can be used with the strings $N and - %N (see below). These are available for creating - the strings Substitution and TestString. - Figure 2 shows to which locations the back-references are - transfered for expansion.

- -

- [Needs graphics capability to display]
- Figure 2: The back-reference flow through a rule. -

-

We know this was a crash course on mod_rewrite's internal - processing. But you will benefit from this knowledge when - reading the following documentation of the available - directives.

- -
-
-
Environment Variables

This module keeps track of two additional (non-standard) @@ -269,8 +173,8 @@ URLs on the fly System-view.

Notice: These variables hold the URI/URL as they were - initially requested, i.e., before any - rewriting. This is important because the rewriting process is + initially requested, that is, before any + rewriting. This is important to note because the rewriting process is primarily used to rewrite logical URLs to physical pathnames.

@@ -285,15 +189,16 @@ SCRIPT_URI=http://en1.engelschall.com/u/rse/
+
Practical Solutions -

We also have an URL - Rewriting Guide available, which provides a collection of - practical solutions for URL-based problems. There you can - find real-life rulesets and additional information about - mod_rewrite.

-
+

For numerous examples of common, and not-so-common, uses for + mod_rewrite, see the Rewrite + Guide, and the Advanced Rewrite + Guide documents.

+ RewriteEngine @@ -393,7 +298,7 @@ processing Security See the Apache Security Tips -document for details on why your security could be compromised if the +document for details on how your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server. @@ -489,7 +394,7 @@ Apache 2.0.41 and later }

-

When such a construct occurs the map MapName is +

When such a construct occurs, the map MapName is consulted and the key LookupKey is looked-up. If the key is found, the map-function construct is substituted by SubstValue. If the key is not found then it is @@ -636,23 +541,23 @@ $ txt2dbm map.txt map.db MapType: int, MapSource: Internal Apache function -

Here the source is an internal Apache function. +

Here, the source is an internal Apache function. Currently you cannot create your own, but the following - functions already exists:

+ functions already exist:

@@ -663,15 +568,15 @@ $ txt2dbm map.txt map.db path to valid regular file

Here the source is a program, not a map file. To - create it you can use the language of your choice, but - the result has to be a executable (i.e., either + create it you can use a language of your choice, but + the result has to be an executable program (either object-code or a script with the magic cookie trick '#!/path/to/interpreter' as the first line).

-

This program is started once at startup of the Apache - servers and then communicates with the rewriting engine - over its stdin and stdout +

This program is started once, when the Apache server + is started, and then communicates with the rewriting engine + via its stdin and stdout file-handles. For each map-function lookup it will receive the key to lookup as a newline-terminated string on stdin. It then has to give back the @@ -696,18 +601,18 @@ while (<STDIN>) {

But be very careful:

    -
  1. ``Keep it simple, stupid'' (KISS), because - if this program hangs it will hang the Apache server - when the rule occurs.
    2. - -
  2. Avoid one common mistake: never do buffered I/O on - stdout! This will cause a deadloop! Hence - the ``$|=1'' in the above example...
    3. - -
  3. Use the RewriteLock directive to - define a lockfile mod_rewrite can use to synchronize the - communication to the program. By default no such +
  4. ``Keep it simple, stupid'' (KISS). + If this program hangs, it will cause Apache to hang + when trying to use the relevant rewrite rule.
    5. + +
  5. A common mistake is to use buffered I/O on + stdout. Avoid this, as it will cause a deadloop! + ``$|=1'' is used above, to prevent this.
    6. + +
  6. The RewriteLock directive can + be used to define a lockfile which mod_rewrite can use to synchronize + communication with the mapping program. By default no such synchronization takes place.
@@ -744,26 +649,26 @@ once! sets the base URL for per-directory rewrites. As you will see below, RewriteRule can be used in per-directory config files - (.htaccess). There it will act locally, - i.e., the local directory prefix is stripped at this - stage of processing and your rewriting rules act only on the - remainder. At the end it is automatically added back to the + (.htaccess). In such a case, it will act locally, + stripping the local directory prefix before processing, and applying + rewrite rules only to the remainder. When processing is complete, the + prefix is automatically added back to the path. The default setting is; RewriteBase physical-directory-path

When a substitution occurs for a new URL, this module has to re-inject the URL into the server processing. To be able to do this it needs to know what the corresponding URL-prefix or URL-base is. By default this prefix is the corresponding - filepath itself. But at most websites URLs are NOT + filepath itself. However, for most websites, URLs are NOT directly related to physical filename paths, so this - assumption will usually be wrong! There you have to + assumption will often be wrong! Therefore, you can use the RewriteBase directive to specify the correct URL-prefix.

If your webserver's URLs are not directly -related to physical file paths, you have to use +related to physical file paths, you will need to use RewriteBase in every .htaccess -files where you want to use RewriteRule directives. @@ -808,17 +713,15 @@ Internal Processing: Result: /abc/def/newstuff.html -

This seems very complicated but is - the correct Apache internal processing, because the - per-directory rewriting comes too late in the - process. So, when it occurs the (rewritten) request - has to be re-injected into the Apache kernel! BUT: - While this seems like a serious overhead, it really - isn't, because this re-injection happens fully - internally to the Apache server and the same - procedure is used by many other operations inside - Apache. So, you can be sure the design and - implementation is correct.

+

This seems very complicated, but is in fact + correct Apache internal processing. Because the + per-directory rewriting comes late in the + process, the rewritten request + has to be re-injected into the Apache kernel. + This is not the serious overhead it may seem to be - + this re-injection is completely internal to the + Apache server (and the same procedure is used by + many other operations within Apache).

@@ -837,63 +740,44 @@ Result:

The RewriteCond directive defines a - rule condition. Precede a RewriteRule directive with one - or more RewriteCond directives. The following - rewriting rule is only used if its pattern matches the current - state of the URI and if these additional - conditions apply too.

- -

TestString is a string which can contains the + rule condition. One or more RewriteCond + can precede a RewriteRule + directive. The following rule is then only used if both + the current state of the URI matches its pattern, and if these conditions are met.

+ +

TestString is a string which can contain the following expanded constructs in addition to plain text:

  • RewriteRule backreferences: These are - backreferences of the form - -

    - $N -

    - (0 <= N <= 9) which provide access to the grouped - parts (parenthesis!) of the pattern from the - corresponding RewriteRule directive (the one - following the current bunch of RewriteCond - directives). + backreferences of the form $N + (0 <= N <= 9), which provide access to the grouped + parts (in parentheses) of the pattern, from the + RewriteRule which is subject to the current + set of RewriteCond conditions..
    • -
  • RewriteCond backreferences: These are - backreferences of the form - -

    - %N -

    - (1 <= N <= 9) which provide access to the grouped - parts (parentheses!) of the pattern from the last matched - RewriteCond directive in the current bunch + backreferences of the form %N + (1 <= N <= 9), which provide access to the grouped + parts (again, in parentheses) of the pattern, from the last matched + RewriteCond in the current set of conditions.
    • -
  • RewriteMap expansions: These are - expansions of the form - -

    - ${mapname:key|default} -

    + expansions of the form ${mapname:key|default}. See the documentation for RewriteMap for more details.
    • -
  • Server-Variables: These are variables of the form - -

    %{ NAME_OF_VARIABLE } -

    where NAME_OF_VARIABLE can be a string taken from the following list: @@ -918,7 +802,8 @@ Result: REMOTE_ADDR
    REMOTE_HOST
    - REMOTE_USER
    + REMOTE_PORT
    + REMOTE_USER
    REMOTE_IDENT
    REQUEST_METHOD
    SCRIPT_FILENAME
    @@ -967,15 +852,14 @@ Result: -

    These variables all correspond to the similarly named HTTP MIME-headers, C variables of the Apache server or struct tm fields of the Unix system. Most are documented elsewhere in the Manual or in the CGI specification. Those that are special to - mod_rewrite include:

    - + mod_rewrite include those below.

    +
    IS_SUBREQ
    @@ -1019,7 +903,7 @@ Result:
    Will contain the text "on" if the connection is using SSL/TLS, or "off" otherwise. (This variable - can be safely used regardless of whether + can be safely used regardless of whether or not mod_ssl is loaded).
    @@ -1027,69 +911,72 @@ Result:
-

Special Notes:

+

Other things you should be aware of:

  1. The variables SCRIPT_FILENAME and REQUEST_FILENAME - contain the same value, i.e., the value of the + contain the same value - the value of the filename field of the internal request_rec structure of the Apache server. - The first name is just the commonly known CGI variable name - while the second is the consistent counterpart to + The first name is the commonly known CGI variable name + while the second is the appropriate counterpart of REQUEST_URI (which contains the value of the uri field of request_rec).
    2. -
  2. There is the special format: - %{ENV:variable} where variable can be - any environment variable. This is looked-up via internal +
  3. + %{ENV:variable}, where variable can be + any environment variable, is also available. + This is looked-up via internal Apache structures and (if not found there) via getenv() from the Apache server process.
    4. -
  4. There is the special format: - %{SSL:variable} where variable is the +
  5. + %{SSL:variable}, where variable is the name of an SSL environment - variable; this can be used whether or not + variable, can be used whether or not mod_ssl is loaded, but will always expand to the empty string if it is not. Example: %{SSL:SSL_CIPHER_USEKEYSIZE} may expand to 128.
    6. -
  6. There is the special format: - %{HTTP:header} where header can be - any HTTP MIME-header name. This is looked-up from the HTTP - request. Example: %{HTTP:Proxy-Connection} is +
  7. + %{HTTP:header}, where header can be + any HTTP MIME-header name, can always be used to obtain the + value of a header sent in the HTTP request. + Example: %{HTTP:Proxy-Connection} is the value of the HTTP header ``Proxy-Connection:''.
    8. -
  8. There is the special format - %{LA-U:variable} for look-aheads which perform +
  9. + %{LA-U:variable} can be used for look-aheads which perform an internal (URL-based) sub-request to determine the final - value of variable. Use this when you want to use a - variable for rewriting which is actually set later in an - API phase and thus is not available at the current stage. - For instance when you want to rewrite according to the + value of variable. This can be used to access + variable for rewriting which is not available at the current + stage, but will be set in a later phase. +

    For instance, to rewrite according to the REMOTE_USER variable from within the - per-server context (httpd.conf file) you have - to use %{LA-U:REMOTE_USER} because this - variable is set by the authorization phases which come - after the URL translation phase where mod_rewrite - operates. On the other hand, because mod_rewrite implements + per-server context (httpd.conf file) you must + use %{LA-U:REMOTE_USER} - this + variable is set by the authorization phases, which come + after the URL translation phase (during which mod_rewrite + operates).

    +

    On the other hand, because mod_rewrite implements its per-directory context (.htaccess file) via the Fixup phase of the API and because the authorization phases come before this phase, you just can use - %{REMOTE_USER} there.

    10. + %{REMOTE_USER} in that context.

    -
  10. There is the special format: - %{LA-F:variable} which performs an internal - (filename-based) sub-request to determine the final value - of variable. Most of the time this is the same as +
  11. + %{LA-F:variable} can be used to perform an internal + (filename-based) sub-request, to determine the final value + of variable. Most of the time, this is the same as LA-U above.

CondPattern is the condition pattern, - i.e., a regular expression which is applied to the - current instance of the TestString, i.e., - TestString is evaluated and then matched against + a regular expression which is applied to the + current instance of the TestString. + TestString is first evaluated, before being matched against CondPattern.

Remember: CondPattern is a @@ -1107,92 +994,88 @@ Result: use one of the following:

    -
  • '<CondPattern' (is lexically - lower)
    - Treats the CondPattern as a plain string and - compares it lexically to TestString. True if - TestString is lexically lower than + +
  • '<CondPattern' (lexicographically + precedes)
    + Treats the CondPattern as a plain string and + compares it lexicographically to TestString. True if + TestString lexicographically precedes CondPattern.
    • -
  • '>CondPattern' (is lexically - greater)
    - Treats the CondPattern as a plain string and - compares it lexically to TestString. True if - TestString is lexically greater than - CondPattern.
    • +
  • '>CondPattern' (lexicographically + follows)
    + Treats the CondPattern as a plain string and + compares it lexicographically to TestString. True if + TestString lexicographically follows + CondPattern.
    • -
  • '=CondPattern' (is lexically +
  • '=CondPattern' (lexicographically equal)
    - Treats the CondPattern as a plain string and - compares it lexically to TestString. True if - TestString is lexically equal to - CondPattern, i.e the two strings are exactly - equal (character by character). If CondPattern - is just "" (two quotation marks) this + Treats the CondPattern as a plain string and + compares it lexicographically to TestString. True if + TestString is lexicographically equal to + CondPattern (the two strings are exactly + equal, character for character). If CondPattern + is "" (two quotation marks) this compares TestString to the empty string.
  • '-d' (is directory)
    Treats the TestString as a pathname and tests - if it exists and is a directory.
    • + whether or not it exists, and is a directory.
  • '-f' (is regular file)
    Treats the TestString as a pathname and tests - if it exists and is a regular file.
    • + whether or not it exists, and is a regular file. -
  • '-s' (is regular file with +
  • '-s' (is regular file, with size)
    - Treats the TestString as a pathname and tests - if it exists and is a regular file with size greater + Treats the TestString as a pathname and tests + whether or not it exists, and is a regular file with size greater than zero.
  • '-l' (is symbolic link)
    - Treats the TestString as a pathname and tests - if it exists and is a symbolic link.
    • + Treats the TestString as a pathname and tests + whether or not it exists, and is a symbolic link. -
  • '-F' (is existing file via +
  • '-F' (is existing file, via subrequest)
    - Checks if TestString is a valid file and + Checks whether or not TestString is a valid file, accessible via all the server's currently-configured access controls for that path. This uses an internal - subrequest to determine the check, so use it with care - because it decreases your servers performance!
    • + subrequest to do the check, so use it with care - + it can impact your server's performance! -
  • '-U' (is existing URL via +
  • '-U' (is existing URL, via subrequest)
    - Checks if TestString is a valid URL and + Checks whether or not TestString is a valid URL, accessible via all the server's currently-configured access controls for that path. This uses an internal - subrequest to determine the check, so use it with care - because it decreases your server's performance!
    • + subrequest to do the check, so use it with care - + it can impact your server's performance!
-Notice +Note All of these tests can also be prefixed by an exclamation mark ('!') to negate their meaning. - - -

Additionally you can set special flags for - CondPattern by appending

-

+

  • You can also set special flags for + CondPattern by appending [flags] -

    - -

    as the third argument to the RewriteCond - directive. Flags is a comma-separated list of the - following flags:

    + as the third argument to the RewriteCond + directive, where flags is a comma-separated list of any of the + following flags:
    • 'nocase|NC' (no case)
      - This makes the test case-insensitive, i.e., there - is no difference between 'A-Z' and 'a-z' both in the + This makes the test case-insensitive - differences + between 'A-Z' and 'a-z' are ignored, both in the expanded TestString and the CondPattern. This flag is effective only for comparisons between TestString and CondPattern. It has no @@ -1201,8 +1084,8 @@ Result:
    • 'ornext|OR' (or next condition)
      - Use this to combine rule conditions with a local OR - instead of the implicit AND. Typical example: + Use this to combine rule conditions with a local OR + instead of the implicit AND. Typical example: 
      @@ -1213,10 +1096,11 @@ RewriteRule ...some special stuff for any of these hosts...
      - Without this flag you would have to write the cond/rule - three times. + Without this flag you would have to write the condition/rule + pair three times.
    +

    Example:

    @@ -1236,13 +1120,16 @@ RewriteRule ^/$ /homepage.std.html [L] -

    Interpretation: If you use Netscape Navigator as your - browser (which identifies itself as 'Mozilla'), then you - get the max homepage, which includes Frames, etc. - If you use the Lynx browser (which is Terminal-based), then - you get the min homepage, which contains no images, no - tables, etc. If you use any other browser you get - the standard homepage.

    +

    Explanation: If you use a browser which identifies itself + as 'Mozilla' (including Netscape Navigator, Mozilla etc), then you + get the max homepage (which could include frames, or other special + features). + If you use the Lynx browser (which is terminal-based), then + you get the min homepage (which could be a version designed for + easy, text-only browsing). + If neither of these conditions apply (you use any other browser, + or your browser identifies itself as something non-standard), you get + the std (standard) homepage.

     @@ -1260,56 +1147,54 @@ RewriteRule ^/$ /homepage.std.html [L]

    The RewriteRule directive is the real - rewriting workhorse. The directive can occur more than once. - Each directive then defines one single rewriting rule. The - definition order of these rules is - important, because this order is used when - applying the rules at run-time.

    + rewriting workhorse. The directive can occur more than once, with + each instance defining a single rewrite rule. The + order in which these rules are defined is important - this is the order + in which they will be applied at run-time.

    Pattern is a perl compatible regular - expression which gets applied to the current URL. Here - ``current'' means the value of the URL when this rule gets + expression, which is applied to the current URL. + ``Current'' means the value of the URL when this rule is applied. This may not be the originally requested URL, - because any number of rules may already have matched and made - alterations to it.

    + which may already have matched a previous rule, and have + been altered.

    -

    Some hints about the syntax of regular expressions:

    +

    Some hints on the syntax of regular expressions:

     Text:
   .           Any single character
-  [chars]     Character class: One  of chars
-  [^chars]    Character class: None of chars
+  [chars]     Character class: Any character of the class ``chars''
+  [^chars]    Character class: Not a character of the class ``chars''
   text1|text2 Alternative: text1 or text2
 
 Quantifiers:
-  ?           0 or 1 of the preceding text
-  *           0 or N of the preceding text (N > 0)
-  +           1 or N of the preceding text (N > 1)
+  ?           0 or 1 occurrences of the preceding text
+  *           0 or N occurrences of the preceding text (N > 0)
+  +           1 or N occurrences of the preceding text (N > 1)
 
 Grouping:
   (text)      Grouping of text
-              (either to set the borders of an alternative or
-              for making backreferences where the Nth group can 
-              be used on the RHS of a RewriteRule with $N)
+              (used either to set the borders of an alternative as above, or
+              to make backreferences, where the Nth group can
+              be referred to on the RHS of a RewriteRule as $N)
 
 Anchors:
-  ^           Start of line anchor
-  $           End   of line anchor
+  ^           Start-of-line anchor
+  $           End-of-line anchor
 
 Escaping:
-  \char       escape that particular char
-              (for instance to specify the chars ".[]()" etc.)
+  \char       escape the given char
+              (for instance, to specify the chars ".[]()" etc.)
    -

    For more information about regular expressions have a look at the +

    For more information about regular expressions, have a look at the perl regular expression manpage ("perldoc perlre"). If you are interested in more detailed information about regular expressions and their variants - (POSIX regex etc.) have a look at the - following dedicated book on this topic:

    + (POSIX regex etc.) the following book is dedicated to this topic:

    Mastering Regular Expressions, 2nd Edition
    @@ -1318,34 +1203,32 @@ RewriteRule ^/$ /homepage.std.html [L] ISBN 0-596-00289-0

    -

    Additionally in mod_rewrite the NOT character - ('!') is a possible pattern prefix. This gives - you the ability to negate a pattern; to say, for instance: +

    In mod_rewrite, the NOT character + ('!') is also available as a possible pattern + prefix. This enables you to negate a pattern; to say, for instance: ``if the current URL does NOT match this pattern''. This can be used for exceptional cases, where it is easier to match the negative pattern, or as a last default rule.

    -Notice -When using the NOT character - to negate a pattern you cannot have grouped wildcard - parts in the pattern. This is impossible because when the - pattern does NOT match, there are no contents for the - groups. In consequence, if negated patterns are used, you - cannot use $N in the substitution - string! +Note +When using the NOT character to negate a pattern, you cannot include +grouped wildcard parts in that pattern. This is because, when the +pattern does NOT match (ie, the negation matches), there are no +contents for the groups. Thus, if negated patterns are used, you +cannot use $N in the substitution string! -

    Substitution of a - rewriting rule is the string which is substituted for (or - replaces) the original URL for which Pattern - matched. Beside plain text you can use

    +

    The substitution of a + rewrite rule is the string which is substituted for (or + replaces) the original URL which Pattern + matched. In addition to plain text, it can include

      -
    1. back-references $N to the RewriteRule +
    2. back-references ($N) to the RewriteRule pattern
      3. -
    3. back-references %N to the last matched +
    4. back-references (%N) to the last matched RewriteCond pattern
    5. server-variables as in rule condition test-strings @@ -1354,74 +1237,39 @@ When using the NOT character
    6. mapping-function calls (${mapname:key|default})
    -

    Back-references are $N - (N=0..9) identifiers which will be replaced + +

    Back-references are identifiers of the form + $N + (N=0..9), which will be replaced by the contents of the Nth group of the matched Pattern. The server-variables are the same as for the TestString of a RewriteCond directive. The mapping-functions come from the RewriteMap directive and are explained there. - These three types of variables are expanded in the order of - the above list.

    + These three types of variables are expanded in the order above.

    -

    As already mentioned above, all the rewriting rules are - applied to the Substitution (in the order of - definition in the config file). The URL is completely +

    As already mentioned, all rewrite rules are + applied to the Substitution (in the order in which + they are defined + in the config file). The URL is completely replaced by the Substitution and the - rewriting process goes on until there are no more rules - unless explicitly terminated by a + rewriting process continues until all rules have been applied, + or it is explicitly terminated by a L flag - see below.

    There is a special substitution string named '-' which means: NO - substitution! Sounds silly? No, it is useful to - provide rewriting rules which only match - some URLs but do no substitution, e.g., in - conjunction with the C (chain) flag to be - able to have more than one pattern to be applied before a - substitution occurs.

    - -Query String -

    The Pattern will not match against the query string. - Instead, you must use a RewriteCond with the - %{QUERY_STRING} variable. You can, however, create - URLs in the substitution string containing a query string - part. Just use a question mark inside the substitution string to - indicate that the following stuff should be re-injected into the - query string. When you want to erase an existing query string, - end the substitution string with just the question mark. To - combine a new query string with an old one, use the - [QSA] flag (see below).

    -     - -Substitution of Absolute URLs -

    There is a special feature: - When you prefix a substitution field with - http://thishost[:thisport] - then mod_rewrite automatically strips it - out. This auto-reduction on implicit external redirect - URLs is a useful and important feature when used in - combination with a mapping-function which generates the - hostname part. Have a look at the first example in the - example section below to understand this.

    - -

    Remember: An unconditional external - redirect to your own server will not work with the prefix - http://thishost because of this feature. To - achieve such a self-redirect, you have to use the - R-flag (see below).

    -     - -

    Additionally you can set special flags for - Substitution by appending

    - -

    - [flags] -

    -

    + substitution! This is useful in providing + rewriting rules which only match + URLs but do not substitute anything for them. It is commonly used + in conjunction with the C (chain) flag, in order + to apply more than one pattern before substitution occurs.

    + +

    Additionally you can set special flags for Substitution by + appending [flags] as the third argument to the RewriteRule - directive. Flags is a comma-separated list of the + directive. Flags is a comma-separated list of any of the following flags:

      @@ -1429,61 +1277,60 @@ When using the NOT character (chained with next rule)
      This flag chains the current rule with the next rule (which itself can be chained with the following rule, - etc.). This has the following effect: if a rule - matches, then processing continues as usual, i.e., + and so on). This has the following effect: if a rule + matches, then processing continues as usual - the flag has no effect. If the rule does not match, then all following chained - rules are skipped. For instance, use it to remove the - ``.www'' part inside a per-directory rule set + rules are skipped. For instance, it can be used to remove the + ``.www'' part, inside a per-directory rule set, when you let an external redirect happen (where the - ``.www'' part should not to occur!). + ``.www'' part should not occur!).
    • 'cookie|CO=NAME:VAL:domain[:lifetime[:path]]' (set cookie)
      - This sets a cookie on the client's browser. The cookie's name + This sets a cookie in the client's browser. The cookie's name is specified by NAME and the value is VAL. The domain field is the domain of the - cookie, such as '.apache.org',the optional lifetime + cookie, such as '.apache.org', the optional lifetime is the lifetime of the cookie in minutes, and the optional path is the path of the cookie
    • 'env|E=VAR:VAL' (set environment variable)
      - This forces an environment variable named VAR to + This forces an environment variable named VAR to be set to the value VAL, where VAL can - contain regexp backreferences $N and - %N which will be expanded. You can use this - flag more than once to set more than one variable. The - variables can be later dereferenced in many situations, but - usually from within XSSI (via <!--#echo - var="VAR"-->) or CGI (e.g. - $ENV{'VAR'}). Additionally you can dereference - it in a following RewriteCond pattern via - %{ENV:VAR}. Use this to strip but remember - information from URLs.
      • + contain regexp backreferences ($N and + %N) which will be expanded. You can use this + flag more than once, to set more than one variable. The + variables can later be dereferenced in many situations, most commonly + from within XSSI (via <!--#echo + var="VAR"-->) or CGI ($ENV{'VAR'}). + You can also dereference the variable in a later RewriteCond pattern, using + %{ENV:VAR}. Use this to strip + information from URLs, while maintaining a record of that information.
    • 'forbidden|F' (force URL to be forbidden)
      - This forces the current URL to be forbidden, - i.e., it immediately sends back a HTTP response of - 403 (FORBIDDEN). Use this flag in conjunction with + This forces the current URL to be forbidden - it immediately + sends back a HTTP response of 403 (FORBIDDEN). + Use this flag in conjunction with appropriate RewriteConds to conditionally block some URLs.
    • 'gone|G' (force URL to be gone)
      - This forces the current URL to be gone, i.e., it + This forces the current URL to be gone - it immediately sends back a HTTP response of 410 (GONE). Use this flag to mark pages which no longer exist as gone.
    • 'last|L' (last rule)
      Stop the rewriting process here and don't apply any more - rewriting rules. This corresponds to the Perl + rewrite rules. This corresponds to the Perl last command or the break command - from the C language. Use this flag to prevent the currently + in C. Use this flag to prevent the currently rewritten URL from being rewritten further by following rules. For example, use it to rewrite the root-path URL ('/') to a real one, e.g., @@ -1491,20 +1338,20 @@ When using the NOT character
    • 'next|N' (next round)
      - Re-run the rewriting process (starting again with the - first rewriting rule). Here the URL to match is again not - the original URL but the URL from the last rewriting rule. + Re-run the rewriting process (starting again with the + first rewriting rule). This time, the URL to match is no longer + the original URL, but rather the URL returned by the last rewriting rule. This corresponds to the Perl next command or - the continue command from the C language. Use - this flag to restart the rewriting process, i.e., + the continue command in C. Use + this flag to restart the rewriting process - to immediately go to the top of the loop.
      - But be careful not to create an infinite + Be careful not to create an infinite loop!
    • 'nocase|NC' (no case)
      - This makes the Pattern case-insensitive, - i.e., there is no difference between 'A-Z' and + This makes the Pattern case-insensitive, + ignoring difference between 'A-Z' and 'a-z' when Pattern is matched against the current URL.
      • @@ -1512,12 +1359,12 @@ When using the NOT character 'noescape|NE' (no URI escaping of output)
      - This flag keeps mod_rewrite from applying the usual URI + This flag prevents mod_rewrite from applying the usual URI escaping rules to the result of a rewrite. Ordinarily, special characters (such as '%', '$', ';', and so on) will be escaped into their hexcode equivalents ('%25', '%24', and '%3B', respectively); this flag prevents this - from being done. This allows percent symbols to appear in + from happening. This allows percent symbols to appear in the output, as in RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE] @@ -1528,134 +1375,123 @@ When using the NOT character
    • - 'nosubreq|NS' (used only if - no internal - sub-request)
      - This flag forces the rewriting engine to skip a - rewriting rule if the current request is an internal + 'nosubreq|NS' ( + not for internal + sub-requests)
      + This flag forces the rewrite engine to skip a + rewrite rule if the current request is an internal sub-request. For instance, sub-requests occur internally - in Apache when mod_include tries to find out + in Apache when mod_include tries to find out information about possible directory default files (index.xxx). On sub-requests it is not - always useful and even sometimes causes a failure to if + always useful, and can even cause errors, if the complete set of rules are applied. Use this flag to exclude some rules.
      - - -

      Use the following rule for your decision: whenever you - prefix some URLs with CGI-scripts to force them to be - processed by the CGI-script, the chance is high that you - will run into problems (or even overhead) on - sub-requests. In these cases, use this flag.

      -
      • + To decide whether or not to use this rule: if you + prefix URLs with CGI-scripts, to force them to be + processed by the CGI-script, it's likely that you + will run into problems (or significant overhead) on + sub-requests. In these cases, use this flag. +
    • 'proxy|P' (force proxy)
      - This flag forces the substitution part to be internally - forced as a proxy request and immediately (i.e., - rewriting rule processing stops here) put through the proxy module. You have to make + This flag forces the substitution part to be internally + sent as a proxy request and immediately (rewrite + processing stops here) put through the proxy module. You must make sure that the substitution string is a valid URI - (e.g., typically starting with + (typically starting with http://hostname) which can be - handled by the Apache proxy module. If not you get an + handled by the Apache proxy module. If not, you will get an error from the proxy module. Use this flag to achieve a more powerful implementation of the ProxyPass directive, - to map some remote stuff into the namespace of the local - server. - -

      Notice: To use this functionality make sure you have - the proxy module compiled into your Apache server - program. If you don't know please check whether - mod_proxy.c is part of the ``httpd - -l'' output. If yes, this functionality is - available to mod_rewrite. If not, then you first have to - rebuild the ``httpd'' program with mod_proxy - enabled.

      + to map remote content into the namespace of the local + server. + +

      Note: mod_proxy must be enabled in order + to use this flag.

    • 'passthrough|PT' (pass through to next handler)
      - This flag forces the rewriting engine to set the + This flag forces the rewrite engine to set the uri field of the internal request_rec structure to the value of the filename field. This flag is just a hack to - be able to post-process the output of - RewriteRule directives by + enable post-processing of the output of + RewriteRule directives, using Alias, ScriptAlias, - Redirect, etc. directives from - other URI-to-filename translators. A trivial example to - show the semantics: If you want to rewrite - /abc to /def via the rewriting - engine of mod_rewrite and then - /def to /ghi with - mod_alias: + Redirect, and other directives from + various URI-to-filename translators. For example, to rewrite + /abc to /def using + mod_rewrite, and then + /def to /ghi using + mod_alias: RewriteRule ^/abc(.*) /def$1 [PT]
      Alias /def /ghi       - If you omit the PT flag then - mod_rewrite will do its job fine, - i.e., it rewrites uri=/abc/... to + If you omit the PT flag, + mod_rewrite will rewrite + uri=/abc/... to filename=/def/... as a full API-compliant URI-to-filename translator should do. Then - mod_alias comes and tries to do a - URI-to-filename transition which will not work. + mod_alias will try to do a + URI-to-filename transition, which will fail. -

      Note: You have to use this flag if you want to - intermix directives of different modules which contain +

      Note: You must use this flag if you want to + mix directives from different modules which allow URL-to-filename translators. The typical example - is the use of mod_alias and - mod_rewrite..

      + is the use of mod_alias and + mod_rewrite.

    • 'qsappend|QSA' (query string append)
      - This flag forces the rewriting engine to append a query - string part in the substitution string to the existing one + This flag forces the rewrite engine to append a query + string part of the substitution string to the existing string, instead of replacing it. Use this when you want to add more data to the query string via a rewrite rule.
    • 'redirect|R [=code]' (force redirect)
      - Prefix Substitution with + Prefix Substitution with http://thishost[:thisport]/ (which makes the new URL a URI) to force a external redirection. If no - code is given a HTTP response of 302 (MOVED - TEMPORARILY) is used. If you want to use other response - codes in the range 300-400 just specify them as a number + code is given, a HTTP response of 302 (MOVED + TEMPORARILY) will be returned. If you want to use other response + codes in the range 300-400, simply specify the appropriate number or use one of the following symbolic names: temp (default), permanent, - seeother. Use it for rules which should - canonicalize the URL and give it back to the client, - e.g., translate ``/~'' into - ``/u/'' or always append a slash to + seeother. Use this for rules to + canonicalize the URL and return it to the client - to + translate ``/~'' into + ``/u/'', or to always append a slash to /u/user, etc.
      - - -

      Note: When you use this flag, make - sure that the substitution field is a valid URL! If not, - you are redirecting to an invalid location! And remember - that this flag itself only prefixes the URL with - http://thishost[:thisport]/, rewriting - continues. Usually you also want to stop and do the - redirection immediately. To stop the rewriting you also - have to provide the 'L' flag.

      + Note: When you use this flag, make + sure that the substitution field is a valid URL! Otherwise, + you will be redirecting to an invalid location. Remember + that this flag on its own will only prepend + http://thishost[:thisport]/ to the URL, and rewriting + will continue. Usually, you will want to stop rewriting at this point, + and redirect immediately. To stop rewriting, you should add + the 'L' flag.
    • 'skip|S=num' (skip next rule(s))
      - This flag forces the rewriting engine to skip the next - num rules in sequence when the current rule + This flag forces the rewriting engine to skip the next + num rules in sequence, if the current rule matches. Use this to make pseudo if-then-else constructs: The last rule of the then-clause becomes - skip=N where N is the number of rules in the + skip=N, where N is the number of rules in the else-clause. (This is not the same as the 'chain|C' flag!)
      • @@ -1663,8 +1499,8 @@ When using the NOT character 'type|T=MIME-type' (force MIME type)
      Force the MIME-type of the target file to be - MIME-type. For instance, this can be used to - setup the content-type based on some conditions. + MIME-type. This can be used to + set up the content-type based on some conditions. For example, the following snippet allows .php files to be displayed by mod_php if they are called with the .phps extension: @@ -1675,33 +1511,65 @@ When using the NOT character
    -Note Never forget that Pattern is +Note: Enabling rewrites in per-directory context + To enable the rewriting engine + for per-directory configuration files, you need to set + ``RewriteEngine On'' in these files + and ``Options + FollowSymLinks'' must be enabled. If your + administrator has disabled override of + FollowSymLinks for a user's directory, then + you cannot use the rewriting engine. This restriction is + needed for security reasons. + + + Note: Pattern matching in per-directory context + Never forget that Pattern is applied to a complete URL in per-server configuration -files. But in per-directory configuration files, the +files. However, in per-directory configuration files, the per-directory prefix (which always is the same for a specific -directory!) is automatically removed for the pattern matching +directory) is automatically removed for the pattern matching and automatically added after the substitution has been -done. This feature is essential for many sorts of rewriting, -because without this prefix stripping you have to match the parent +done. This feature is essential for many sorts of rewriting - +without this, you would always have to match the parent directory which is not always possible.

    There is one exception: If a substitution string - starts with ``http://'' then the directory - prefix will not be added and an + starts with ``http://'', then the directory + prefix will not be added, and an external redirect or proxy throughput (if flag - P is used!) is forced!

    + P is used) is forced!

     -Note - To enable the rewriting engine - for per-directory configuration files you need to set - ``RewriteEngine On'' in these files - and ``Options - FollowSymLinks'' must be enabled. If your - administrator has disabled override of - FollowSymLinks for a user's directory, then - you cannot use the rewriting engine. This restriction is - needed for security reasons. + +Note: Substitution of Absolute URLs +

    When you prefix a substitution field with + http://thishost[:thisport], + mod_rewrite will automatically strip that + out. This auto-reduction on URLs with an implicit external redirect + is most useful in combination with + a mapping-function which generates the + hostname part.

    + +

    Remember: An unconditional external + redirect to your own server will not work with the prefix + http://thishost because of this feature. To + achieve such a self-redirect, you have to use the + R-flag.

    +     + +Note: Query String +

    The Pattern will not be matched against the query string. + Instead, you must use a RewriteCond with the + %{QUERY_STRING} variable. You can, however, create + URLs in the substitution string, containing a query string + part. Simply use a question mark inside the substitution string, to + indicate that the following text should be re-injected into the + query string. When you want to erase an existing query string, + end the substitution string with just a question mark. To + combine a new query string with an old one, use the + [QSA] flag.

    Here are all possible substitution combinations and their @@ -1716,25 +1584,25 @@ directory which is not always possible. 

     Given Rule                                      Resulting Substitution
 ----------------------------------------------  ----------------------------------
-^/somepath(.*) otherpath$1                      not supported, because invalid!
+^/somepath(.*) otherpath$1                      invalid, not supported
 
-^/somepath(.*) otherpath$1  [R]                 not supported, because invalid!
+^/somepath(.*) otherpath$1  [R]                 invalid, not supported
 
-^/somepath(.*) otherpath$1  [P]                 not supported, because invalid!
+^/somepath(.*) otherpath$1  [P]                 invalid, not supported
 ----------------------------------------------  ----------------------------------
 ^/somepath(.*) /otherpath$1                     /otherpath/pathinfo
 
 ^/somepath(.*) /otherpath$1 [R]                 http://thishost/otherpath/pathinfo
                                                 via external redirection
 
-^/somepath(.*) /otherpath$1 [P]                 not supported, because silly!
+^/somepath(.*) /otherpath$1 [P]                 doesn't make sense, not supported
 ----------------------------------------------  ----------------------------------
 ^/somepath(.*) http://thishost/otherpath$1      /otherpath/pathinfo
 
 ^/somepath(.*) http://thishost/otherpath$1 [R]  http://thishost/otherpath/pathinfo
                                                 via external redirection
 
-^/somepath(.*) http://thishost/otherpath$1 [P]  not supported, because silly!
+^/somepath(.*) http://thishost/otherpath$1 [P]  doesn't make sense, not supported
 ----------------------------------------------  ----------------------------------
 ^/somepath(.*) http://otherhost/otherpath$1     http://otherhost/otherpath/pathinfo
                                                 via external redirection
@@ -1749,8 +1617,7 @@ directory which is not always possible.
 
       
    Inside per-directory configuration for
       /somepath
    
-       (i.e., file .htaccess in dir
-      /physical/path/to/somepath containing
+       (/physical/path/to/somepath/.htacccess, with
       RewriteBase /somepath)
    
        for request ``GET
       /somepath/localpath/pathinfo'':
     
@@ -1764,21 +1631,21 @@ directory which is not always possible.
 ^localpath(.*) otherpath$1  [R]                 http://thishost/somepath/otherpath/pathinfo
                                                 via external redirection
 
-^localpath(.*) otherpath$1  [P]                 not supported, because silly!
+^localpath(.*) otherpath$1  [P]                 doesn't make sense, not supported
 ----------------------------------------------  ----------------------------------
 ^localpath(.*) /otherpath$1                     /otherpath/pathinfo
 
 ^localpath(.*) /otherpath$1 [R]                 http://thishost/otherpath/pathinfo
                                                 via external redirection
 
-^localpath(.*) /otherpath$1 [P]                 not supported, because silly!
+^localpath(.*) /otherpath$1 [P]                 doesn't make sense, not supported
 ----------------------------------------------  ----------------------------------
 ^localpath(.*) http://thishost/otherpath$1      /otherpath/pathinfo
 
 ^localpath(.*) http://thishost/otherpath$1 [R]  http://thishost/otherpath/pathinfo
                                                 via external redirection
 
-^localpath(.*) http://thishost/otherpath$1 [P]  not supported, because silly!
+^localpath(.*) http://thishost/otherpath$1 [P]  doesn't make sense, not supported
 ----------------------------------------------  ----------------------------------
 ^localpath(.*) http://otherhost/otherpath$1     http://otherhost/otherpath/pathinfo
                                                 via external redirection
@@ -1790,35 +1657,6 @@ directory which is not always possible.
 ^localpath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
                                                 via internal proxy
    - -

    Example:

    - -

    We want to rewrite URLs of the form

    - -

    - / Language /~ - Realname /.../ File -

    - -

    into

    - -

    - /u/ Username /.../ - File . Language -

    - -

    We take the rewrite mapfile from above and save it under - /path/to/file/map.txt. Then we only have to - add the following lines to the Apache server configuration - file:

    - - -
    -RewriteLog   /path/to/file/rewrite.log
-RewriteMap   real-to-user               txt:/path/to/file/map.txt
-RewriteRule  ^/([^/]+)/~([^/]+)/(.*)$   /u/${real-to-user:$2|nobody}/$3.$1
-
    -