|
Apache HTTP Server Version 1.3Module mod_rewrite
This module is contained in the |
Figure 1: The control flow through the rewriting 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 matched, 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 exists, it starts an inner loop for processing them in order 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 condition is available. If all conditions matched processing is continued with the substitution of the URL with Substitution.
$N
and %N
(see below). And these
are available for creating the strings Substitution and
TestCond. Figure 2 shows at which locations the back-references are
transfered to for expansion.
Figure 2: The back-reference flow through a rule |
We know, this was a crash course of mod_rewrite's internal processing. But you will benefit from this knowledge when reading the following documentation of the available directives.
RewriteEngine
{on,off
}RewriteEngine off
The RewriteEngine
directive enables or disables the runtime
rewriting engine. If it is set to off
this module does no runtime
processing at all. It does not even update the SCRIPT_URx
environment variables.
Use this directive to disable the module instead of commenting out
all RewriteRule
directives!
Note that, by default, rewrite configurations are not inherited.
This means that you need to have a RewriteEngine on
directive for each virtual host you wish to use it in.
RewriteOptions
Option
The RewriteOptions
directive sets some special options for the
current per-server or per-directory configuration. The Option
strings can be one of the following:
inherit
'.htaccess
configuration gets inherited.
RewriteLog
Filename
The RewriteLog
directive sets the name of the file to which the
server logs any rewriting actions it performs. If the name does not begin
with a slash ('/
') then it is assumed to be relative to the
Server Root. The directive should occur only once per server
config.
Notice: To disable the logging of rewriting actions it is
not recommended to set Filename
to /dev/null , because although the rewriting engine does
not create output to a logfile it still creates the logfile
output internally. This will slow down the server with no advantage
to the administrator!
To disable logging either remove or comment out the
RewriteLog directive or use RewriteLogLevel 0 !
|
Security: See the Apache Security Tips document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server. |
Example:
RewriteLog "/usr/local/var/apache/logs/rewrite.log"
RewriteLogLevel
LevelRewriteLogLevel 0
The RewriteLogLevel
directive set the verbosity level of the
rewriting
logfile. The default level 0 means no logging, while 9 or more means
that practically all actions are logged.
To disable the logging of rewriting actions simply set Level to 0. This disables all rewrite action logs.
Notice: Using a high value for Level will slow down your Apache server dramatically! Use the rewriting logfile only for debugging or at least at Level not greater than 2! |
Example:
RewriteLogLevel 3
RewriteLock
FilenameThis directive sets the filename for a synchronization lockfile which mod_rewrite needs to communicate with RewriteMap programs. Set this lockfile to a local path (not on a NFS-mounted device) when you want to use a rewriting map-program. It is not required for all other types of rewriting maps.
RewriteMap
MapName
MapType:
MapSource
The RewriteMap
directive defines a Rewriting Map
which can be used inside rule substitution strings by the mapping-functions
to insert/substitute fields through a key lookup. The source of this
lookup can be of various types.
The MapName is the name of the map and will be used to specify a mapping-function for the substitution strings of a rewriting rule via one of the following constructs:
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 substituted by DefaultValue or the empty string if no DefaultValue was specified.${
MapName:
LookupKey}
${
MapName:
LookupKey|
DefaultValue}
The following combinations for MapType and MapSource can be used:
txt
, MapSource: Unix filesystem path to valid regular
file
This is the standard rewriting map feature where the MapSource is a plain ASCII file containing either blank lines, comment lines (starting with a '#' character) or pairs like the following - one per line.
MatchingKey SubstValue
Example:
## ## map.txt -- rewriting map ## Ralf.S.Engelschall rse # Bastard Operator From Hell Mr.Joe.Average joe # Mr. Average |
RewriteMap real-to-user txt:/path/to/file/map.txt |
rnd
, MapSource: Unix filesystem path to valid regular
file
This is identical to the Standard Plain Text variant above but with a
special
post-processing feature: After looking up a value it is parsed according
to contained ``|
'' characters which have the meaning of
``or''. Or
in other words: they indicate a set of alternatives from which the actual
returned value is chosen randomly. Although this sounds crazy and useless,
it
was actually designed for load balancing in a reverse proxy situation where
the looked up values are server names.
Example:
## ## map.txt -- rewriting map ## static www1|www2|www3|www4 dynamic www5|www6 |
RewriteMap servers rnd:/path/to/file/map.txt |
dbm
, MapSource: Unix filesystem path to valid
regular file
Here the source is a binary NDBM format file containing the same contents as a Plain Text format file, but in a special representation which is optimized for really fast lookups. You can create such a file with any NDBM tool or with the following Perl script:
#!/path/to/bin/perl ## ## txt2dbm -- convert txt map to dbm format ## ($txtmap, $dbmmap) = @ARGV; open(TXT, "<$txtmap"); dbmopen(%DB, $dbmmap, 0644); while (<TXT>) { next if (m|^s*#.*| or m|^s*$|); $DB{$1} = $2 if (m|^\s*(\S+)\s+(\S+)$|); } dbmclose(%DB); close(TXT) |
$ txt2dbm map.txt map.db |
int
, MapSource: Internal Apache function
Here the source is an internal Apache function. Currently you cannot create your own, but the following functions already exists:
prg
, MapSource: Unix filesystem path to valid
regular file
Here the source is a Unix program, not a map file. To create it you can use
the language of your choice, but the result has to be a run-able Unix
executable (i.e., either object-code or a script with the
magic cookie trick '#!/path/to/interpreter
' as the first
line).
This program gets started once at startup of the Apache servers and then
communicates with the rewriting engine over 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 looked-up value as a
newline-terminated string on stdout
or the four-character
string ``NULL
'' if it fails (i.e., there is no
corresponding value
for the given key). A trivial program which will implement a 1:1 map
(i.e., key == value) could be:
#!/usr/bin/perl $| = 1; while (<STDIN>) { # ...here any transformations # or lookups should occur... print $_; } |
But be very careful:
stdout
!
This will cause a deadloop! Hence the ``$|=1
'' in the
above example...
RewriteMap
directive can occur more than once. For each
mapping-function use one RewriteMap
directive to declare its
rewriting mapfile. While you cannot declare a map in
per-directory context it is of course possible to use
this map in per-directory context.
Notice: For plain text and DBM format files the looked-up
keys are cached in-core
until the mtime of the mapfile changes or the server does a
restart. This way you can have map-functions in rules which are used
for every request. This is no problem, because the
external lookup only happens once!
|
RewriteBase
BaseURL
The RewriteBase
directive explicitly 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.
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 directly related to physical filename paths, so this
assumption will be usually be wrong! There you have to use the
RewriteBase
directive to specify the correct URL-prefix.
Notice: If your webserver's URLs are not
directly related to physical file paths, you have to use
RewriteBase in every
.htaccess files where you want to use RewriteRule
directives.
|
Example:
Assume the following per-directory config file:
# # /abc/def/.htaccess -- per-dir config file for directory /abc/def # Remember: /abc/def is the physical path of /xyz, i.e., the server # has a 'Alias /xyz /abc/def' directive e.g. # RewriteEngine On # let the server know that we are reached via /xyz and not # via the physical path prefix /abc/def RewriteBase /xyz # now the rewriting rules RewriteRule ^oldstuff\.html$ newstuff.htmlIn the above example, a request to
/xyz/oldstuff.html
gets correctly rewritten to the physical file/abc/def/newstuff.html
.
Notice - For the Apache hackers:
The following list gives detailed information about the internal processing steps:
Request: /xyz/oldstuff.html Internal Processing: /xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server Alias) /abc/def/oldstuff.html -> /abc/def/newstuff.html (per-dir RewriteRule) /abc/def/newstuff.html -> /xyz/newstuff.html (per-dir RewriteBase) /xyz/newstuff.html -> /abc/def/newstuff.html (per-server Alias) Result: /abc/def/newstuff.htmlThis 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 internal 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.
RewriteCond
TestString
CondPattern
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 following expanded constructs in addition to plain text:
$N
(1 <= 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).
%N
(1 <= N <= 9) which provide access to the grouped parts (parenthesis!) of
the pattern from the last matched RewriteCond
directive in the
current bunch of conditions.
where NAME_OF_VARIABLE can be a string of the following list:%{
NAME_OF_VARIABLE}
HTTP headers:
HTTP_USER_AGENT |
connection & request:
REMOTE_ADDR |
|
server internals:
DOCUMENT_ROOT |
system stuff:
TIME_YEAR |
specials:
API_VERSION |
Notice: These variables all correspond to the similar named
HTTP MIME-headers, C variables of the Apache server or struct tm
fields of the Unix system.
|
Special Notes:
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 REQUEST_URI (which contains the value of the uri
field of request_rec
).
%{ENV:variable}
where
variable can be any environment variable. This is looked-up via
internal Apache structures and (if not found there) via getenv()
from the Apache server process.
%{HTTP:header}
where
header can be any HTTP MIME-header name. This is looked-up
from the HTTP request. Example: %{HTTP:Proxy-Connection}
is the value of the HTTP header ``Proxy-Connection:
''.
%{LA-U:variable}
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 actually is 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
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 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.
%{LA-F:variable}
which perform an
internal (filename-based) sub-request to determine the final value of
variable. This is the most of the time the same as LA-U above.
CondPattern is the condition pattern, i.e., a regular expression which gets applied to the current instance of the TestString, i.e., TestString gets evaluated and then matched against CondPattern.
Remember: CondPattern is a standard Extended Regular Expression with some additions:
!
' character
(exclamation mark) to specify a non-matching pattern.
Notice: All of these tests can also be prefixed by a not ('!') character to negate their meaning. |
Additionally you can set special flags for CondPattern by appending
as the third argument to the[
flags]
RewriteCond
directive. Flags
is a comma-separated list of the following flags:
nocase|NC
' (no case)
ornext|OR
' (or next condition)
RewriteCond %{REMOTE_HOST} ^host1.* [OR] RewriteCond %{REMOTE_HOST} ^host2.* [OR] RewriteCond %{REMOTE_HOST} ^host3.* RewriteRule ...some special stuff for any of these hosts...Without this flag you had to write down the cond/rule three times.
Example:
To rewrite the Homepage of a site according to the ``User-Agent:
'' header of the request, you can use the following:RewriteCond %{HTTP_USER_AGENT} ^Mozilla.* RewriteRule ^/$ /homepage.max.html [L] RewriteCond %{HTTP_USER_AGENT} ^Lynx.* RewriteRule ^/$ /homepage.min.html [L] 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.
RewriteRule
Pattern Substitution
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.
Pattern can be (for Apache 1.1.x a System V8 and for Apache 1.2.x a POSIX) regular expression which gets applied to the current URL. Here ``current'' means the value of the URL when this rule gets applied. This may not be the original requested URL, because there could be any number of rules before which already matched and made alterations to it.
Some hints about the syntax of regular expressions:
Text: |
For more information about regular expressions either have a look at your
local regex(3) manpage or its src/regex/regex.3
copy in the
Apache 1.3 distribution. When you are interested in more detailed and deeper
information about regular expressions and its variants (POSIX regex, Perl
regex, etc.) have a look at the following dedicated book on this topic:
Mastering Regular Expressions
Jeffrey E.F. Friedl
Nutshell Handbook Series
O'Reilly & Associates, Inc. 1997
ISBN 1-56592-257-3
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: ``if the current URL does NOT match to this
pattern''. This can be used for special cases where it is better 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!
|
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
$N
to the RewriteRule pattern
%N
to the last matched RewriteCond pattern
%{VARNAME}
)
${mapname:key|default}
)
$
N (N=1..9) identifiers 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.
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 replaced by the Substitution and the
rewriting process goes on until there are no more rules (unless 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.
One more note: You can even 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.
Notice: 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
as the third argument to the[
flags]
RewriteRule
directive. Flags is a
comma-separated list of the following flags:
redirect|R
[=code]' (force redirect)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 or use
one of the following symbolic names: temp
(default), permanent
,
seeother
.
Use it for rules which should
canonicalize the URL and gives it back to the client, e.g., translate
``/~
'' into ``/u/
'' or always append a slash to
/u/
user, etc.
Notice: 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]/
, but rewriting goes on.
Usually you also want to stop and do the redirection immediately. To stop
the rewriting you also have to provide the 'L' flag.
forbidden|F
' (force URL to be forbidden)
gone|G
' (force URL to be gone)
proxy|P
' (force proxy)http://
hostname) which can be handled by the
Apache proxy module. If not you 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.
last|L
' (last rule)last
command or the break
command from the C
language. Use this flag to prevent the currently rewritten URL from being
rewritten further by following rules which may be wrong. For
example, use it to rewrite the root-path URL ('/
') to a real
one, e.g., '/e/www/
'.
next|N
' (next round)next
command or the continue
command from the C
language. Use this flag to restart the rewriting process, i.e., to
immediately go to the top of the loop.
chain|C
' (chained with next rule).www
'' part inside a per-directory rule set when you let an
external redirect happen (where the ``.www
'' part should not to
occur!).
type|T
=MIME-type' (force MIME type)mod_alias
directive ScriptAlias
which internally forces all files inside
the mapped directory to have a MIME type of
``application/x-httpd-cgi
''.
nosubreq|NS
' (used only if no internal sub-request)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 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.
nocase|NC
' (no case)
qsappend|QSA
' (query string
append)
passthrough|PT
' (pass through to next handler)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
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
:
RewriteRule ^/abc(.*) /def$1 [PT] Alias /def /ghiIf you omit the
PT
flag then mod_rewrite
will do its job fine, i.e., it rewrites 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.
Notice: You have to use this flag if you want to intermix directives
of different modules which contain URL-to-filename translators. The
typical example is the use of mod_alias
and
mod_rewrite
..
Notice - For the Apache hackers: If the current Apache API had a filename-to-filename hook additionally to the URI-to-filename hook then we wouldn't need this flag! But without such a hook this flag is the only solution. The Apache Group has discussed this problem and will add such hooks into Apache version 2.0. |
skip|S
=num' (skip next rule(s))skip=N
where N is the number of rules in the else-clause.
(This is not the same as the 'chain|C' flag!)
env|E=
VAR:VAL' (set environment variable)$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 at a lot of situations, but the usual location will be from
within XSSI (via <!--#echo var="VAR"-->
) or CGI (e.g.
$ENV{'VAR'}
). But additionally you can also dereference it in a
following RewriteCond pattern via %{ENV:VAR}
. Use this to strip
but remember information from URLs.
Notice: Never forget that Pattern gets applied to a complete URL
in per-server configuration files. But in per-directory configuration
files, the per-directory prefix (which always is the same for a specific
directory!) gets 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 directory which is not always possible.
There is one exception: If a substitution string starts with
`` |
Notice: To enable the rewriting engine for per-directory configuration files
you need to set ``RewriteEngine On '' in these files and
``Option FollowSymLinks '' 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.
|
Here are all possible substitution combinations and their meanings:
Inside per-server configuration (httpd.conf
)
for request ``GET /somepath/pathinfo
'':
Given Rule Resulting Substitution ---------------------------------------------- ---------------------------------- ^/somepath(.*) otherpath$1 not supported, because invalid! ^/somepath(.*) otherpath$1 [R] not supported, because invalid! ^/somepath(.*) otherpath$1 [P] not supported, because invalid! ---------------------------------------------- ---------------------------------- ^/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(.*) 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://otherhost/otherpath$1 http://otherhost/otherpath/pathinfo via external redirection ^/somepath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo via external redirection (the [R] flag is redundant) ^/somepath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo via internal proxy |
Inside per-directory configuration for /somepath
(i.e., file .htaccess
in dir /physical/path/to/somepath
containing
RewriteBase /somepath
)
for
request ``GET /somepath/localpath/pathinfo
'':
Given Rule Resulting Substitution ---------------------------------------------- ---------------------------------- ^localpath(.*) otherpath$1 /somepath/otherpath/pathinfo ^localpath(.*) otherpath$1 [R] http://thishost/somepath/otherpath/pathinfo via external redirection ^localpath(.*) otherpath$1 [P] not supported, because silly! ---------------------------------------------- ---------------------------------- ^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(.*) 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://otherhost/otherpath$1 http://otherhost/otherpath/pathinfo via external redirection ^localpath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo via external redirection (the [R] flag is redundant) ^localpath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo via internal proxy |
Example:
We want to rewrite URLs of the forminto/
Language/~
Realname/.../
File/u/
Username/.../
File.
LanguageWe 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
SCRIPT_URL
and SCRIPT_URI
. These contain
the logical Web-view to the current resource, while the standard CGI/SSI
variables SCRIPT_NAME
and SCRIPT_FILENAME
contain the
physical System-view.
Notice: These variables hold the URI/URL as they were initially requested, i.e., in a state before any rewriting. This is important because the rewriting process is primarily used to rewrite logical URLs to physical pathnames.
Example:
SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html SCRIPT_FILENAME=/u/rse/.www/index.html SCRIPT_URL=/u/rse/ SCRIPT_URI=http://en1.engelschall.com/u/rse/
Apache URL Rewriting Guide
http://www.engelschall.com/pw/apache/rewriteguide/