[APACHE DOCUMENTATION]

Apache HTTP Server Version 1.3


Module mod_rewrite
URL Rewriting Engine

モジュールは Apache 1.2 以降のmod_rewrite.c ファイルに収容されています。これは、リクエストされた作業中の URL を書き換えるための、ルールベースの書き換えエンジンです。デフォルトではコンパイルされていません。mod_rewrite を使用する為にはサーバ構築の Configuration ファイルにある、以下の行を有効にしなければなりません: 
    AddModule  modules/standard/mod_rewrite.o


概要

``mod_rewrite の良い所は Sendmail のように設定できて、柔軟性に富んでいることだ。mod_rewrite の悪い所は Sendmail のように設定できて、柔軟性に富んでいることだ。''
-- Brian Behlendorf
Apache Group
`` 膨大なサンプルとドキュメントにも関わらず、mod_rewrite は呪術だ。イカれたクールな呪術だけど、呪術であることに変わりはない。''
-- Brian Moore
bem@news.cmc.net
mod_rewrite へようこそ。これは URL を巧みに操る、スイス製のアーミー・ナイフです！

このモジュールは、リクエストされた作業中の URL を書き換えるための、ルールベースの書き換えエンジン(正規表現の解析に基づいた)です。真に柔軟性に富んだ、パワフルな URL 操作を行う、無制限な数のルールと、そのルールに添付される無制限な数の条件をサポートします。URL 操作は様々なテストで、インスタンス変数、環境変数、HTTP ヘッダ、タイムスタンプ、様々なフォーマットでルックアップする外部データベースが本当の granular URL 一致するように使われることでさえ、変わってきます。

このモジュールはサーバ毎のコンテクスト (httpd.conf) と ディレクトリ毎のコンテクスト (.htaccess) にある、完全な URL (パス情報の部分を含む)を操作して、結果としてクエリー文字列部分を生じます。書き換えられた結果、内部のサブ・プロセスになり、外部リクエストの書き換えか、内部プロキシーになります。

しかし、全ての機能性と柔軟性は不利な点を持っています: 複雑さです。このモジュール全体をたった一日で理解するのは無理でしょう。

このモジュールは April 1996 に開発されたものです。
そして、July 1997 に Apache Group に贈られました。

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

目次

内部処理

設定 Directive

その他

内部処理

このモジュールの内部処理はとても複雑ですが、ありがちなミスを避けるために一般的なユーザにも説明が必要です。 あなたがその機能性をフルに活用するためにもです。

API フェーズ

まず、Apache は HTTP リクエストを処理するときに同期を取ることを理解しなければなりません。それぞれのフェーズのフックは Apache API によるものです。Mod_rewrite は二つのフックを使います: 一つは HTTP リクエストが読み込まれた後と、なんらかの承諾が始まる前に使われる URL-to-filename の変換フックです。もう一つは承諾フェーズの後と、コンテントハンドラーがアクティブになる前に読み込まれたディレクトリ毎の設定ファイル (.htaccess) の後に引き起こされる Fixup フックです。

リクエストが来て、Apache は URL-to-filename 変換のサーバ毎の設定から全ての mod_rewrite directive の処理を開始する、対応サーバ(あるいは virtual server)の rewrite エンジンを決定します。最後のデータディレクトリが見つかって、２、３段階後、mod_rewrite のディレクトリ毎の設定 directive は Fixup フェーズで引き起こされます。URL を新しい URL か、ファイル名に置き換える mod_rewrite で、明確な区別はありません。これは API が設計されたとき、このやり方を意図しない API の用法ですが、Apache 1.x 現在では、mod_rewrite を操る唯一の方法です。この点を明確にするために、以下の二点を覚えておいてください:

  1. API は現在、URL-to-filename のフックだけです。ですが mod_rewrite は、URL を URL、URL をファイル名、ファイル名をファイル名に書き換えます。Apache 2.0 では二つの欠けているフックが、処理をより明確にするために追加されます。これがユーザにとって障害となることはありませんが、ちょっと知っておくべきことです: Apache は URL-to-filename フックで多くを行い、そのとき API がそうするようにします。

  2. たとえ URL がファイル名に変換された後、長い時間たっても mod_rewrite はディレクトリ毎のコンテクスト、つまり、.htaccess ファイルで信じられないような URL 操作をします(こうなるのは、.htaccess ファイルがファイルシステムにあって、処理がこの処理の段階に既に達しているからです)。言い換えれば: この時の API フェーズによっては URL 操作に間に合いません。この「卵が先か、ニワトリが先か」という問題を克服するために、mod_rewrite はトリックを使います: ディレクトリ毎のコンテクストで URL/filename を操作するとき、mod_rewrite はまず始めに、もとの対応する URL へファイル名を書き換えます(普通は不可能ですが、これを実行するトリックについては RewriteBase directive を見てください)。そしてそれから新しい URL で新しい内部サブリクエストを起動します。これは始まりから API フェーズの新しい処理につながります。

    再び mod_rewrite はこの複雑なステップをユーザから見えないようにしますが、ここで覚えておいてください: サーバ毎のコンテクストにある URL 操作は本当に速くて効果的な一方、ディレクトリ毎の書き換えはこの「卵が先か、ニワトリが先か」という問題のせいで、遅くて非効率的です。しかし一方、これは mod_rewrite が一般ユーザに対して(ローカルに限定された) URL 操作を行う唯一の方法です。

この二点を忘れないでください！

ルールセットの処理

mod_rewrite は二つの API フェーズで引き起こされて、その設定構造(それ自身がサーバ毎コンテクストのスタートアップを作るか、ディレクトリ毎のコンテクストをApache のカーネルが歩きまわるか)から設定されたルールセットを読みます。それから URL の rewrite エンジンはルールセットを伴って起動します(条件によって、一つかそれ以上のルールが一緒になります)。URL の rewrite エンジン自身の操作は、両方の設定コンテクストとまったく同じです。最後に生じる処理は異なっています。

ルールセットのルールの順番は重要です。なぜなら、rewrite エンジンは特別な順番でそれを処理するからです。この順番は、はっきりしていません。ルールは: rewrite エンジンはルールによるルールセットのルール(RewriteRule directive!)でループして、特定のルールが一致したときに、対応する条件(RewriteCond directive)で任意にループします。史的な理由から、条件が最初に与えられて、制御フローがちょっとだけ曲げられます。詳しくは Figure 1 を見てください。

[Needs graphics capability to display]
Figure 1: rewrite ルールセットを通じた制御フロー

見てきたように、最初の URL はそれぞれのルールの Pattern に対して一致します。失敗すると mod_rewrite はこのルールの処理を直ちに停止して、次のルールに移ります。もし Pattern が一致すれば、mod_rewrite は対応するルール条件を見ます。もし存在しなければ、Substitution 文字列から作られる新しい値で URL を代用して、その rule-looping を継続します。しかし条件が存在すれば、表示される順番で処理を行う内部ループを開始します。条件によってロジックは異なります: 現在の URL に対してパターンは一致しません。代わりに back-references、map lookups、その他の拡張変数によって TestString 文字列を作成します。そしてそれから、それに対して CondPattern を一致させようとします。もしパターンが一致しなければ、条件と対応するルールの完全なセットは失敗します。パターンが一致すると、有効な条件がなくなるまで次の条件が処理されます。もし全ての条件が一致すれば、Substitution の URL の代用を続けます。

Regex Back-Reference Availability

一つ大事なことがあります: Pattern や、CondPattern back-reference の一つで挿入語句を使いたいときはいつでも、$N と %N の文字列を使って内部的に作られます(以下参照)。これらは Substitution と TestCond 文字列を作るために利用できます。Figure 2 は拡張のために転送される back-reference を割り振る場所を示しています。

[Needs graphics capability to display]
Figure 2: ルールを通じた back-reference フロー

以上、mod_rewrite 内部処理の短期集中講座でした。しかし、以下に続く directive のドキュメントを読む時にこの知識は役に立つでしょう。

設定 directive

RewriteEngine

Syntax: RewriteEngine {on,off}
Default: RewriteEngine off
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2

RewriteEngine directive はランタイム rewrite エンジンを使用可能、不可能にします。off に設定すると、このモジュールはランタイムの処理を全く行いません。SCRIPT_URx 環境変数の更新さえ行いません。

全ての RewriteRule directive をコメントアウトしないで、モジュールを使用不可能にする、この directive を使ってください！

デフォルトでは、rewrite の設定が引き継がれないことに注意してください。これは、使いたいそれぞれの virtual host に対して RewriteEngine on directive が必要だということです。

RewriteOptions

Syntax: RewriteOptions Option
Default: None
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2

RewriteOptions directive は現在のサーバ毎かディレクトリ毎の設定に専用のオプションを設定します。Option 文字列は以下のうちの一つです:

RewriteLog

Syntax: RewriteLog Filename
Default: None
Context: server config, virtual host
Override: Not applicable
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2

RewriteLog directive は、実行したなんらかの rewrite をサーバがログするファイル名を設定します。もし名前がスラッシュ('/')で始まっていなければ Server Root の相対パスになります。directive はサーバ設定毎に一度だけ生じます。

注: rewrite 機能のログを不可能にするためには、/dev/null に対して Filename を設定することは薦められません。なぜなら、rewrite エンジンはログファイルへの出力がなくても、内部的なログファイルの出力があるからです。 これは管理者になんの利点もなくサーバを遅くするだけです！ ログを不可能にするには RewriteLog directive を外すかコメントアウト、あるいは RewriteLogLevel 0 を使ってください！

セキュリティ: ログファイルが蓄積されているディレクトリが、サーバを起動するユーザと異なる者の書き込みを許可していると、なぜセキュリティが甘くなるのかについて、詳しくは Apache セキュリティ集 を見てください。

例: 

RewriteLog "/usr/local/var/apache/logs/rewrite.log"

RewriteLogLevel

Syntax: RewriteLogLevel Level
Default: RewriteLogLevel 0
Context: server config, virtual host
Override: Not applicable
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2

RewriteLogLevel directive は rewrite ログファイルのログレベルを設定します。デフォルトの level 0 はログを行いませんが、9 やその他の数字は実質的には全ての挙動をログします。

rewrite の挙動のログを不可能にするためには、単に Level を 0 にするだけです。これは全ての rewrite の挙動のログを不可能にします。

注: Level に高い値を使うと Apache サーバは非常に遅くなります！デバッグのときだけ rewrite ログファイルを使うか、少なくとも Level を 2 より大きくしないでください！

例: 

RewriteLogLevel 3

RewriteLock

Syntax: RewriteLock Filename
Default: None
Context: server config, virtual host
Override: Not applicable
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.3

この directive は、mod_rewrite が RewriteMap プログラムと連絡を取る必要のある、同期している lockfile のファイル名を設定します。rewrite map-program を使いたいときには、この lockfile をローカルパス(NFS-mounted device ではなく)に設定してください。SAMP に他の全てタイプの rewrite map を使うことを要求しません。

RewriteMap

Syntax: RewriteMap MapName MapType:MapSource
Default: not used per default
Context: server config, virtual host
Override: Not applicable
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2 (partially), Apache 1.3

RewriteMap directive は、キー・ルックアップを通じた挿入/代用フィールドに対する、マップ機能によってルール代用文字列内部で使われる Rewriting Map を定義します。このルックアップのソースは様々なタイプになります。

MapName は map の名前で、以下の構成の一つを通して rewrite ルールの代用文字列に対してマッピング機能を指定するために使われます:

${ MapName : LookupKey }
${ MapName : LookupKey | DefaultValue }
そのような構成が map を生じるときに、MapName が参考にされて、キーの LookupKey がルックアップされます。 もしキーが見つかると、マップ機能の構成は SubstValue によって代用されます。キーが見つからなければ、DefaultValue によって代用されるか、DefaultValue が指定されていなければ空の文字列になります。

以下の MapType と MapSource の組み合わせが使われます:

RewriteMap directive は２回以上発生します。それぞれのマップ機能のために、rewrite マップファイルを宣言する、一つの RewriteMap directive を使います。ディレクトリ毎のコンテクストでマップを宣言できない一方、もちろんディレクトリ毎のコンテクストにあるこのマップを使うことは可能です。

注: プレインテキストと DBM フォーマットファイルのために、ルックアップキーはマップファイルの mtime が変わるか、サーバが再起動するまでコアにキャッシュされます。この方法で、あらゆるリクエストのために使われるルールの中でマップ機能を持つことができます。これで問題がないのは、外部ルックアップが起こるのが一度だけだからです！

RewriteBase

Syntax: RewriteBase BaseURL
Default: default is the physical directory path
Context: directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2

RewriteBase directive はディレクトリ毎の rewrite の基になる URL を設定します。以下にあるように、RewriteRule はディレクトリ毎の設定ファイル(.htaccess)で使われます。そこではローカルとして動きます、すなわち、ローカルディレクトリの prefix はこの処理をする段階で取り除かれ、rewrite ルール が残りに作用します。最後は自動的に追加されます。

代用が新しい URL に対して生じると、このモジュールはサーバ処理に URL を再び差し挟みます。これを可能にするためには、一致する URL-prefix か URL-base が何であるかを知る必要があります。デフォルトで、この prefix はそれ自身が一致するファイルパスです。 しかし、ほとんどのウェブサイトの URL は物理的なファイル名パスと関連するディレクトリではありません。ですので、この前提は間違っています！ 正確な URL-prefix を指定するためには RewriteBase directive を使わなければなりません。

注: ウェブサーバの URL が物理的なファイル名パスと関連するディレクトリではないと、RewriteRule directive を使いたいあらゆる .htaccess ファイルにある RewriteBase を使わなければなりません。

例:

以下のディレクトリ毎の設定ファイルを前提とします: 

#
#  /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.html

上の例では、/xyz/oldstuff.html に対するリクエストが、物理的なファイル /abc/def/newstuff.html に正確に rewrite されています。

注 - Apache ハッカー達へ:
以下の表は詳細な内部処理のステップについての情報です: 

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.html
これはとても複雑に見えますが、正しい Apache の内部処理です。なぜならディレクトリ毎の rewrite は途中で遅くなるからです。それで、rewrite が生じたときに、リクエストは Apache カーネルへ再投入されます！ しかし: これは深刻なオーバーヘッドのようですが、そうではありません。なぜならこの再投入は完全に Apache サーバに対して内部的に生じ、同じ処理が Apache 内部の、多くの他の操作によって使われるからです。計画を確かめて、実装は正確に。

RewriteCond

Syntax: RewriteCond TestString CondPattern
Default: None
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2 (partially), Apache 1.3

RewriteCond directive はルール条件を定義します。 一つかそれ以上の RewriteCond directive よりも RewriteRule directive は優先します。以下の rewrite ルールは、パターンが URL の現在の状態と一致して、これらの追加条件も割り当てられていれば、使われます。

TestString は、プレインテキストとは別に、次の拡張構成を含む文字列です:

特記:

  1. 変数 SCRIPT_FILENAME と REQUEST_FILENAME は同じ値を持っています。つまり、Apache サーバの内部 request_rec 構造の filename 領域の値です。最初の名前は一般的には知られた CGI 変数ですが、二番目のものは REQUEST_URI(request_rec の uri 領域の値があります)と似たもので、両立します

  2. 特殊なフォーマット:variable が環境変数になることができる %{ENV:variable}。これは内部的な Apache 構造経由と、(もし見つからなければ)Apache サーバ処理からの getenv() 経由のルックアップです。

  3. 特殊なフォーマット:header が HTTP MIME ヘッダー名になる %{HTTP:header}。これは HTTP リクエストからのルックアップです。例: %{HTTP:Proxy-Connection} は HTTP ヘッダ``Proxy-Connection:''の値です。

  4. variable の最後の値を決定するために、内部的に (URL-based) sub-request を実行するルック・アヘッドのための、特殊なフォーマット %{LA-U:variable} があります。実際に API フェーズで設定されるのは後になる rewrite の変数を使いたいときに、これを使ってください。従って、カレントの段階では利用できません。使いたい時というのは、例えば、%{LA-U:REMOTE_USER} を使わなければならないサーバ毎のコンテクスト(httpd.conf)内部からの REMOTE_USER 変数による rewrite をしたいときです。この変数は mod_rewrite が操作する URL 変換フェーズの後に生じる認証フェーズによって設定されるからです。同時に、API の Fixup フェーズ経由で mod_rewrite はディレクトリ毎のコンテクスト(.htaccess)を実行して、このフェーズの前に、承諾フェーズが生じるので、そこで %{REMOTE_USER} を使うことができます。

  5. 特殊なフォーマットがあります: variable の最後の値を決定するための内部的な(ファイル名ベースの)サブリクエストを実行する %{LA-F:variable} です。これはだいたいの場合、LA-U と同じです。

CondPattern は条件パターンです。すなわち、TestString のカレント・インスタンスに割り当てられる正規表現、言い換えれば、TestString は評価されて、CondPattern に一致します。

忘れないでください: CondPattern はいくつか追加がある、標準の Extended Regular Expression です:

  1. 一致するパターンがないという指定をするためには、'!'文字をパターン文字列の前に付けます。

  2. CondPatterns には、いくつかの特別な変数があります。本当の正規表現の代わりに、以下を使うこともできます:

    • '<CondPattern' (辞書ソートがより小さい)
      もし TestString が CondPattern よりも辞書ソートが低ければ、プレイン文字列として CondPattern を扱い、それを TestString に対する辞書ソートと比較して、正規表現になります。

    • '>CondPattern' (辞書ソートがより大きい)
      もし TestString が CondPattern よりも辞書ソートが大きければ、CondPattern をプレイン文字列として扱い、それを TestString に対する辞書ソートと比較して、正規表現になります。

    • '=CondPattern' (辞書ソートが同じ)
      もし TestString が CondPattern と辞書ソートが同じ、すなわち二つの文字列が全く同じなら(文字単位で)、プレイン文字列として CondPattern を扱い、それを TestString に対する辞書ソートと比較して、正規表現になります。もし CondPattern がちょうど "" なら(二つの引用記号)、これは空の文字列に対して TestString を比較します。

    • '-d' (is directory)
      パス名として TestString を扱い、それが存在していて、ディレクトリかどうかをテストします。

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

    • '-s' (is regular file with size)
      パス名として TestString を扱い、それが存在していて、サイズが 0 以上の正規ファイルかどうかをテストします。

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

    • '-F' (is existing file via subrequest)
      TestString が正規ファイルで、そのパスに対して、サーバで現在設定された全てのアクセス制御を経由してアクセスが可能かどうかをチェックします。これはチェックを決定するために内部サブリクエストを使い、サーバのパフォーマンスを低下させるので注意して使います！

    • '-U' (is existing URL via subrequest)
      TestString が正当な URL で、そのパスに対して、サーバで現在設定された全てのアクセス制御を経由してアクセスが可能かどうかをチェックします。これはチェックを決定するために内部サブリクエストを使い、サーバのパフォーマンスを低下させるので注意して使います！

    注: これらのテストの全ては、意味を消すための ('!') 文字ではないプレフィックスを付けることができます。

さらに、アペンドすることにより CondPattern に特別なフラッグを設定することができます。

[flags]
RewriteCond directive に対する三番目の引数としてです。Flags は以下のフラッグをコンマで区切ったリストです:

例:

リクエストの ``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]
解説: ブラウザに Netscape Navigator を使っているなら('Mozilla' としてそれ自身を認識する)、フレーム等を含む max homepage を得ます。Lynx browser(Terminal-based) なら、画像、テーブル等を含まない min homepage を得ます。その他のブラウザなら standard homepage を得ます。

RewriteRule

Syntax: RewriteRule Pattern Substitution
Default: None
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2 (partially), Apache 1.3

RewriteRule directive は、rewrite 機能の中枢を担っています。directive は何度も生じることができます。これらのルールの定義する順番が重要なのは、ランタイムにルールを割り当てるときにこの順番が使われるからです。

Pattern は(for Apache 1.1.x a System V8 and for Apache 1.2.x a POSIX)現在の URL に割り当てた正規表現になれます。このルールが割り当てられると、ここで``current''は URL の値を示します。これは最初にリクエストされた URL ではないかもしれません。なぜなら、一致して、それに変更する前にいくらでもルールがあるからです。

正規表現の構文についてのヒント: 

Text:
  .           Any single character
  [chars]     Character class: One  of chars
  [^chars]    Character class: None of chars
  text1|text2 Alternative: text1 or text2

Quantifiers:
  ?           0 or 1 of the preceding text
  *           0 or N of the preceding text (N > 1)
  +           1 or N 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)

Anchors:
  ^           Start of line anchor
  $           End   of line anchor

Escaping:
  \char       escape that particular char
              (for instance to specify the chars ".[]()" etc.)

正規表現についての詳しい情報は、Apache 1.3 配布にある regex(3) の man を見るか、その src/regex/regex.3 コピーを見てください。正規表現とその仲間(POSIX regex、Perl regex、等)の詳しい、より深い情報に興味があれば、このトピックにある以下に紹介された本を見てください:

Mastering Regular Expressions
Jeffrey E.F. Friedl
Nutshell Handbook Series
O'Reilly & Associates, Inc. 1997
ISBN 1-56592-257-3

さらに、mod_rewrite には NOT の記号('!')がパターンのプレフィックスとして使えます。これはパターンを打ち消す機能があります: `` もし現在の URL がこのパターンと一致しなければ''拒否するパターンか、最も不適当なデフォルトのルールと一致した方が良い、特別な場合に使われます。

注: パターンを拒否するために NOT 記号を使うときに、パターンにグループ化されたワイルドカードがあってはいけません。なぜなら、パターンが一致しないとき、これは不可能になって、グループのコンテンツがなくなるからです。その結果、否定パターンが使われると、代わりの文字列に $N を使うことはできません！

rewrite ルールの Substitution は Pattern が一致した(あるいは置き換えられた)最初の URL に代用される文字列です。 使用できるプレインテキストは

  1. back-references $N to the RewriteRule pattern
  2. back-references %N to the last matched RewriteCond pattern
  3. server-variables as in rule condition test-strings (%{VARNAME})
  4. mapping-function calls (${mapname:key|default})
Back-references は一致したパターンのN番目のグループのコンテンツによって置き換えられる$N (N=1..9)識別子です。server-variables は RewriteCond directive の TestString と同じものです。mapping-functions は RewriteMap directive によるもので、そこで説明されています。これらの３つのタイプの変数は、上にあるリストの順番で拡張されます。

すでに上で書かれているように、全ての rewrite のルールは Substitution に割り当てられます(設定ファイルに定義してある順番で)。URL は Substitution によって完全に置き換えられて、ルールがなくなるまで rewrite の処理を続けます(L フラッグによって明らかに終わっているのでなければ - 以下参照)。

'-'を指定された特殊な代用文字列があり、これは: NO substitutionです！ バカげてますか？いいえ、URL のいくつかに一致するだけで、代用をしない rewrite ルールを行う場合に便利です。すなわち、代用が生じる前、割り当てられるパターンを一つ以上持つことができる C (chain) フラッグと共に。

注: クエリー文字列を含む代用文字列に URL を作ることができます。以下の事項が QUERY_STRING に re-inject されるべきであることを表すためには、代用文字列にクエスチョン・マークを使ってください。存在しているクエリー文字列を消したいときは、クエスチョン・マークで代用文字列を終わらせてください。

注: 特殊な機能があります。代用領域に http://thishost[:thisport] のプレフィックスを付けると、mod_rewrite は自動的に取り除きます。この外部リダイレクト URL の自動的な削除は、便利で、ホスト名部分を生成するマップ機能と組み合わせて使われる重要な機能です。これを理解するには、以下にある例のセクションの最初の例を見てください。

Remember: 自身のサーバに向けた無条件の外部リダイレクトは、この機能のせいで、プレフィックスが http://thishost だと作動しません。自身のリダイレクトを実行するためには、R フラッグを使わなければなりません(以下参照)。

さらに、アペンドすることにより Substitution に特殊なフラッグを設定することができます。

[flags]
RewriteRule directive の３番目の引数としてです。Flags は以下のフラッグの、コンマで区切られたリストです:

注: Pattern は、サーバ毎の設定ファイルで完全な URL に対して割り当てるということを、決して忘れないでください。しかし、ディレクトリ毎の設定ファイルで、ディレクトリ毎のプレフィックス(常に特定のディレクトリと同じ)は、代用が行われた後に自動的にパターンの一致に対して取り外し、自動的に追加します。この機能はたくさんある rewrite のソートの中でも、本質的なものです。

一つ例外があります: 代用文字列が``http://''で始まると、ディレクトリのプレフィックスは追加されず、外部リダイレクトやプロキシーのスループット(P フラッグが使われていれば！)が行われます。

注: ディレクトリ毎の設定ファイルで rewrite エンジンを可能にするためには、これらのファイルで``RewriteEngine On''に設定して、``Option FollowSymLinks''を可能にする必要があります。もし管理者がユーザディレクトリでの FollowSymLinks の無効を不可能にすると、rewrite エンジンを使うことができません。この制限はセキュリティ上必要です。

ここに全ての可能な組み合わせと、その内容があります:

``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

/somepath に対するサーバ毎の設定で
(すなわち、RewriteBase /somepath を持つ /physical/path/to/somepath ディレクトリ にある .htaccess ファイル)
``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

例:

URL の形式を
/ Language /~ Realname /.../ File
これに rewrite したい
/u/ Username /.../ File . Language

上から rewrite mapfile を取って、/path/to/file/map.txt 下にそれを保存します。 それから Apache サーバの設定ファイル以下の行を追加するだけです: 

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、SCRIPT_URI と名付けられた二つの(非標準) CGI/SSI 環境変数を取ります。 これは現在のリソースに対して論理的な Web-view がある一方、標準の CGI/SSI 変数 SCRIPT_NAME と SCRIPT_FILENAME は 物理的な System-view を持っています。

注: これらの変数は最初にリクエストされたもの、すなわち、rewrite される前の状態です。 これが大事なのは rewrite 処理がローカルの URL を物理パスに rewrite するために使われるからです。

例: 

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/

実践ソリューション

mod_rewrite の作者による、URL-based の問題を解決する実践的なソリューション集です。 ここで実際のルールセットと追加情報を捜すことができます。
Apache URL Rewriting Guide
http://www.engelschall.com/pw/apache/rewriteguide/

Apache HTTP Server Version 1.3

Index Home