RewriteCond命令はルール条件を定義しています。RewriteRule命令の一つかそれ以上前にRewriteCond命令がなければなりません。もしそのパターンが現在の URL の状態と合致していて、そしてこれらの追加条件も適用されるなら、以下の書き換えルールは使われるだけです。

TestStringはサーバの多様なフォームを含むストリングです。

%{ NAME_OF_VARIABLE }

HTTP headers: HTTP_USER_AGENT HTTP_REFERER HTTP_COOKIE HTTP_FORWARDED HTTP_HOST HTTP_PROXY_CONNECTION HTTP_ACCEPT	connection & request: REMOTE_ADDR REMOTE_HOST REMOTE_USER REMOTE_IDENT REQUEST_METHOD SCRIPT_FILENAME PATH_INFO QUERY_STRING AUTH_TYPE
server internals: DOCUMENT_ROOT SERVER_ADMIN SERVER_NAME SERVER_PORT SERVER_PROTOCOL SERVER_SOFTWARE SERVER_VERSION	system stuff: TIME_YEAR TIME_MON TIME_DAY TIME_HOUR TIME_MIN TIME_SEC TIME_WDAY	specials: API_VERSION THE_REQUEST REQUEST_URI REQUEST_FILENAME

これらの全ての変数は、類似の指名された HTTP MIME-headers、アパッチサーバのＣ変数や、UNIX システムのstruct tmフィールドと一致します。

注意:

1. 変数 SCRIPT_FILENAME と REQUEST_FILENAME は同じ値、すなわちアパッチサーバの内部のrequest_rec構造filenameの領域を含んでいます。前者は一般的な CGI 変数名として知られているが、後者は REQUEST_URI に一貫して対応しています（request_recのuri領域の値を含んでいる）。

2. 追加のフォーマットがあります：%{ENV:variable}がvariableであればどんな Unix の環境変数でも有り得ます。これはアパッチのサーバ処理からgetenv()によって検索されます。

3. もう一つ追加のフォーマットがあります：%{HTTP:header}はheaderであればどんな HTTP MIME-header 名でも有り得ます。これは HTTP のリクエストによって検索されます。例：%{HTTP:Proxy-Connection}は HTTPヘッダーの``Proxy-Connection:''の値です。

CondPatternは状態パターン、すなわちTestStringの現在の事例に当てはまる通常表記であり、TestStringは評価されて、その時CondPatternに対して対抗させられます。

注: CondPatternは多少の追記のある標準的なExtended Regular Expressionです：

1. 合致しないパターンを指定するために'!'文字（感嘆マーク）をパターンストリングの先に付けることができます。

2. CondPatternsにはいくつかの特別形があります。本当の通常表記ストリングの代わりに、以下のうちの一つを使うこともできます:
   • '-d' (is directory)
     パス名としてTestStringを扱い、それが存在して、そしてディレクトリであるかどうかをテストします。

   • '-f' (is regular file)
     パス名としてTestStringを扱い、それが存在して、そして標準ファイルであるかどうかをテストします。

   • '-s' (is regular file with size)
     パス名としてTestStringを扱い、それが存在して、そして０より大きい標準ファイルであるかどうかをテストします。

   • '-l' (is symbolic link)
     パス名としてTestStringを扱い、それが存在して、そしてシンボリックリンクであるかどうかをテストします。

   注: これらの全てのテストは、それらを無効にするための('!')ではない文字によって先に付けられます。

さらに、付加することによって３番目のRewriteCond命令に対するアーギュメントとしてCondPatternのために特別なフラッグをセットすることができます。

[flags]

• 'nocase|NC' (no case)
  これは状態テストを鈍感にする、すなわち拡張されたTestStringとCondPatternの 'A-Z' と 'a-z' の違いがないことです。

• 'ornext|OR' (or next condition)
  絶対的な AND の代わりに、ローカルな OR でルール条件を結合させるためにこれを使います。典型的な例：

  RewriteCond %{REMOTE_HOST}  ^host1.*  [OR]
  RewriteCond %{REMOTE_HOST}  ^host2.*  [OR]
  RewriteCond %{REMOTE_HOST}  ^host3.*  
  RewriteRule ...some special stuff for any of these hosts...
  

  このフラッグなしで、３回 cond/rule に書き込まねばなりません。

例:

リクエストの``User-Agent:''というヘッダーによってサイトのホームページを書き換えるために、以下のものを使うことが出来ます：

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]

解説: もしブラウザとして（それ自身が'Mozilla'と認識する）ネットスケープナビゲータを使っているなら、フレーム等を含む最大限のホームページを入手します。もし（ターミナルベースである）Lynx ブラウザを使っているなら、イメージや表等を含まない最小限のホームページを入手します。もしそれ以外のブラウザを使っているなら、標準的なホームページを入手します。

RewriteRule

RewriteRule命令は本当の書き換えを行なうのに有効です。この命令は、一度よりも多く実行することができます。それから、それぞれの命令が一つの書き換えルールを定義します。これらのルールの定義状態は重要です。なぜなら作動中にルールを割り当てる時、この状態が使われるからです。

Patternは現在の URL に対して割り当てられた通常表記 (for Apache 1.1.x a System V8 and for Apache 1.2.x a POSIX) であり得ます。ここでこのルールが割り当てられた時、``current''は URL の値を意味します。これはオリジナルのリクエストされた URL ではないかもしれません。なぜなら、その前にルールのいくつかの数が合致していて、それに変更を加えることが有り得るからです。

通常表記のsyntaxについてのいくつかのヒント：

^ Start of line $ End of line . Any single character [chars] One of chars [^chars] None of chars ? 0 or 1 of the preceding char * 0 or N of the preceding char + 1 or N of the preceding char \char escape that specific char (e.g. for specifying the chars ".[]()" etc.) (string) Grouping of chars (the Nth group can be used on the RHS with $N)

更に、NOT 文字('!')は可能なパターン接頭句である。これはパターンを無効にして、言う効力を与えます。例えば：``if the current URL does NOT match to this pattern''.これは、ネガティブなパターンと合致するのがより良い、特別な場合か、または最新のデフォルトルールとして使われることができます。

注意! パターンを無効にする NOT 文字を使う時、パターンにグループ化されたワイルドカードを用いることは出来ません。これが不可能なのは、グループのためにパターンが合致しなくて、中身がないからです。その結果、もし無効なパターンが使われたら、代用ストリングの$Nを使うことはできません！

書き換えルールのSubstitutionは、Patternが合致したオリジナルの URL に代用（置き換え）られるストリングです。使用できるプレインテキストの横に

1. pattern-group back-references ($N)
2. server-variables as in rule condition test-strings (%{VARNAME})
3. mapping-function calls (${mapname:key|default})

既に上で書かれたように、全ての書き換えルールはSubstitutionに割り当てられます（コンフィグファイルの定義状態で）。URL はSubstitutionによって完全に置き換えられ、書き換え処理はルールがなくなるまで続きます（Lフラッグによる明白な終端がない限りー以下参照）

'-'という特別な代用ストリングは：「代用がない！」ことを示す。愚かに聞こえるでしょうか？いいえ、いくつかの URLs にだけ合致して、代用を行なわない書き換えルールを提供する有効なものです。例えば、 代用が実行するよりも前に、割り当てられた１つより多くのパターンを持つことが可能なC(chain) フラッグと関連してです。

注: 特別な特徴があります。http://thishost[:thisport] という代用フィールドが接頭句である時、mod_rewriteは自動的にそれを外します。この絶対的な外部方向転換の URLs の自動削除は、有効なものであり、ホストネームの部分が生じるマッピング機能と結合して使われる重要な特徴です。これを理解するには、以下の例のセクションの最初の例を見てください。 確認: 所有するサーバに対する無条件の外部方向転換が、http://thishostという接頭句では働かないのは、この特徴のせいです。そのような自己方向転換を完了するためには、Rフラッグを使わなければなりません。

さらに、追記することによってSubstitutionのための特別なフラッグをセットすることができます。

[flags]

• 'redirect|R' (force redirect)
  外部方向転換に働くより前にhttp://thishost/（新しい URL a URI を作る）というSubstitutionを置きます。URL を canonicalize してそれをクライアントに返さなければならないルール、すなわち``/~''を``/u/''に置き換えたり、/u/userにスラッシュを付けたりするために、これを使います。
  注: このフラッグを使う時、代用領域が有効なURLであることを確実にします！もしそうでなければ、無効なロケーションに方向転換しています。

• 'proxy|P' (force proxy)
  このフラッグは代用部分にプロキシーのリクエストとして内部的に働くようにして、直ちに（例えば、書き換えルール処理がここで終了する）プロキシーモジュールを実行する。代用ストリングがアパッチプロキシーモジュールによってハンドルされることができる有効な URI（すなわち、典型的な http://）であることを確信するに違いないでしょう。もしそうでなければ、プロキシーモジュールからエラーが出ます。このフラッグはより強力なmod_proxy命令のProxyPassの実行を行なうためと、いくつかのリモートスタッフをローカルサーバの name-space にマップするために使ってください。

• 'last|L' (last rule)
  ここで書き換え処理を終了して、これ以上の書き換えルールを追加しません。これはパールのlastコマンドやＣ言語のbreakコマンドと一致します。このフラッグは、悪化するかもしれない以下のルールによって更に書き換えが行われることから、現在の書き換えられた URL を防ぐために使われます。例えば、ルートパスの URL('/')を実在するものに書き換えるために使います。すなわち、'/e/www/'です。

• 'next|N' (next round)
  書き換え処理を再実行します（最初の書き換えルールを再び始めます）。ここで一致するための URL はオリジナルの URL に対してではなく、最新の書き換えルールからの URL です。これはパールのnextコマンドやＣ言語のcontinueコマンドと一致します。このフラッグは書き換え処理を再実行するため、すなわち直ちにループのトップへ移動するために使います。
  デッドループを作らないように気を付けて下さい！

• 'chain|C' (chained with next rule)
  このルールは次のルール（それ自身もまた以下のルール等とつなぐことができる）と現在のルールをつなぎます。これは以下の効果があります：もしルールが一致していれば、普通に処理を行ない、フラッグは効果を発揮しません。もしルールが一致していなければ、全ての以下につながっているルールはスキップされます。例えば、外部方向転換を起こさせた時（``.www''の部分で起こすべきではない！）、ディレクトリごとのルールセットの中で``.www''部分を外すためにこれを使います。

• 'type|T=mime-type' (force MIME type)
  mime-typeであるターゲットファイルの MIME-type に作用します。例えば、``application/x-httpd-cgi''の MIME type を持つマップされたディレクトリの中にある全てのファイルに内部的に働く古いmod_alias命令であるScriptAliasをシミュレイトするために使うことが出来ます。

• 'nosubreq|NS' (used only if no internal sub-request)
  もし現在のリクエストが内部のサブリクエストであれば、このフラッグは書き換えルールをスキップするために書き換えエンジンに作用します。例えば、mod_includeが実行可能なディレクトリのデフォルトファイル(index.xxx)についての情報を探そうとしている時、サブリクエストはアパッチで内部的に発生します。サブリクエストでは、もし完了したルールのセットを追加されると、有効ではなく、時々失敗の原因となります。いくつかのルールを排除するためにこのフラッグを使います。
  

  あなたの判断で以下のルールを使って下さい： CGI-script によって処理されたものに作用するよりも前に CGI-scripts のいくつかの URLs を置く時はいつでも、サブリクエストの問題にぶつかる可能性は高くなります。これらの場合、このフラッグを使ってください。

• 'passthrough|PT' (pass through to next handler)
  このフラッグはfilename領域の値に対して、内部のrequest_rec構造のuri領域をセットするために書き換えエンジンに作用します。このフラッグはちょうど、Alias, ScriptAlias, Redirect等の他の URI-to-filename 翻訳からの命令によるRewriteRule命令の post-process 出力を可能にするハックです。セマンティクス を示すありふれた例：もし/abcを/defにmod_rewriteの書き換えエンジンによって、その時 /defを/ghiにmod_aliasで書き換えたいのなら：

      RewriteRule ^/abc(.*)  /def$1 [PT]
      Alias       /def       /ghi   
      

  もしmod_rewriteがその作業を無事に行なう時PTフラッグを省略すれば、すなわち翻訳が行なうべきフルの API-compliant の URI-to-filename としてuri=/abc/...をfilename=/def/...に書き換えます。その時mod_aliasは、働かない URI-to-filename 移行を行なおうとします。

  注：もし URL-to-filename 翻訳を含む違ったモジュールの命令を混ぜたいのなら、このフラッグを使わなければなりません。典型的な例はmod_aliasとmod_rewrite..の使用です。

  アパッチハッカーのために： もし現在のアパッチ API が URI-to-filename フックに追加する filename-to-filename フックを持っていれば、その時このフラッグは必要ありません！しかしそのようなフックなしでは、このフラッグはただの解答です。アパッチグループはこの問題を討議し、アパッチversion 2.0 にそのようなフックを追加します。

• 'skip|S=num' (skip next rule(s))
  このフラッグは現在のルールが一致している時、連続の次のnumルールをスキップするように働きます。仮の if-then-else 構造を作るためにこれを使います： then-clause の最新のルールが、N が else-clause のルールの数字であるskip=Nになります（これは'chain|C' フラッグとは違います！）

確認：サーバごとのコンフィグレーションファイルの完了した URL にPatternが追加されたことを決して忘れないで下さい。しかし、ディレクトリごとのコンフィグレーションファイルでは、代用が行われた後、ディレクトリごとの接頭句（いつも特定のディレクトリとっては同じ物！）がパターンの一致で自動的にremovedされ、自動的にaddedされます。この特徴は多くの種類の書き換えの基本になっています。なぜなら、この接頭句を外すことなしでは、常に実行可能とは限らない親ディレクトリと一致しなければならないからです。 一つ例外があります：もし代用ストリングが``http://''で始まっていれば、ディレクトリの接頭句は追加されず、外部方向転換やプロキシーのスループット（もしPフラッグが使われていれば！）が働きます!

注意！ディレクトリごとのコンフィフレーションファイルの書き換えエンジンを可能にするためには、これらのファイルで``RewriteEngine On''と可能になった``Option FollowSymLinks''をセットする必要があります。もし管理者がユーザディレクトリのFollowSymLinksの override を不可能にしていれば、書き換えエンジンを使うことはできません。この制限はセキュリティ上必要です。

ここには全ての可能な代用の組み合わせとその意味が記述してあります:

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 form

/ Language /~ Realname /.../ File

into

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

上記の書き換えマップファイルは/anywhere/map.real-to-userの下に置いてあります。それから、アパッチサーバのコンフィグレーションファイルに以下の行を追加することだけをしなければばりません：

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

このページの情報に関わる、ご質問、お問い合わせは、 japache@infoscience.co.jpまで。