リアルタイムで書き換えるための、ルールベースの書き換えエンジンを提供します。すばらしいところは、Sendmailのような設定性と柔軟性を与えてくれるところだろう。よくないところは、Sendmailのような設定性と柔軟性を与えてくれるところだろう。イケてるっぽい黒魔術だが、やっぱり所詮は黒魔術である。操作メカニズムを提供します。操作に先立ち、次のようにいろいろな評価を行なうことができます。マッチングを実現できます。対する操作を行いますが、さらに結果としてクエリー文字列部分を生成することもできます。出力された結果を内部のサブプロセスや外部リクエストのリダイレクション、さらには内部のプロキシ処理ルーチンに渡すこともできます。これらすべての機能や柔軟性が、欠点や複雑さの元にもなっています。このモジュール全体を一日程度で覚えようなどとは思わないほうがいいでしょう。対して独占的に贈呈されました。このモジュールの内部処理はとても複雑ですが、ありがちなミスを避け、また全機能を活用できるように、平均的ユーザに対しても一度は説明しておく必要があります。リクエストを処理する際に、このモジュールがこのフェーズで行なうことを理解しておかなければなりません。APIでは、これらの各フェーズに対するフックが提供されています。ディレクティブの処理を開始します。フェーズで起動されます。ファイル名に書き換えます。動ける唯一の方法でした。フックのみを提供しています。つのフックが追加され、処理がより明確になりました。意図する以上のことを行ないます。操作を行えるようになっていす。処理の流れはすでにこの段階まで到達しているのです。操作するにもすでに遅きに失しているのです。内部的に新しいサブリクエストを生成しているのです。フェーズ処理が再度起動されます。操作は実際高速でかつ有用であるのに対し、ディレクトリ毎の書き換えは、この鶏と卵の問題のため遅い上に役に立ちません。操作のための唯一の方法なのです。カーネルがディレクトリ毎のコンテキストに従ってディレクトリ間を探索する途中のいずれかに生成される)より構成されたルールセットを読み込みます。書き換えエンジンが開始されます。書き換えエンジン自体は、双方の設定内容と全く同じように動作します。最終結果の処理が異なるだけです。ルールセット中のルールの書き順は重要です。これは、書き換えエンジンはそれらを特別な(かつ、あまり分かりやすいとは言えない)順序で処理するからです。ルールは以下のように処理されます:書き換えエンジンはルール(RewriteRuleディレクティブ)を1つずつなめながらルールセット中をループしますが、ある特別なルールがマッチしたら、それに対応する条件(RewriteCondディレクティブ)がある間その中をループします。歴史的な理由によりまず条件が与えられ、その後に制御フローを書くところがちょっとくどいところです。各ルールのパターンに対してマッチングします。このルールの処理を中止して次のルールを見に行きます。それに対応する条件を探します。置換対象文字列から作られた新しい値に置換し、そのルールのループを続けます。内部ループを開始し、それらの条件が列挙されている順に処理を繰り返します。対してパターンのマッチングを行ないません。検索テーブルをマッピングするなどしてテスト文字列を生成し、それに対して条件パターンとのマッチングを行ないます。パターンにマッチしない場合、条件の組合せ全体とそれに対応するルールは成立しないことになります。パターンにマッチした場合、次の条件が評価され、それが条件のある限り繰り返されます。置くことでエスケープ(すなわち、それらの持つ特殊な意味を打ち消して、通常の文字として扱うこと)できます。いう文字列を使って本来のドル記号を入れることができるわけです。それを後方参照として扱おうとするのを防いでいます。使える後方参照が内部的に生成されます(後述)。文字列やテスト文字列を生成するのに使えます。この後方参照が転送されて展開される場所について解説します。内部処理に関する短期集中コースでした。ここからは使用可能なディレクティブに関することがかかれています。これを読めば役立つ知識になってゆくはずです。Apache1.2RewriteEngineディレクティブを使うと、実行時の書き換えエンジンを有効にしたり無効にしたりできます。これがoffに設定されていると、このモジュールは実行時の処理を一切行ないません。SCRIPT_URx環境変数の更新さえもしなくなります。RewriteRuleを全部コメントアウトしたりしないで、このディレクティブを使ってくださいね。設定は継承されないので注意してください。onディレクティブを書かなければいけないということです。Apache1.2RewriteOptionsディレクティブは、現在のサーバ単位もしくはディレクトリ単位の設定で使用する、特別なオプションをセットします。オプション文字列は以下のいずれかです:'inherit'これは、現在の設定値を親の設定値から強制的に継承させます。これにより、仮想サーバ単位のコンテキストにおいて、メインサーバのマップ、条件、ルールが継承されることになります。ディレクトリ単位のコンテキストでは、親ディレクトリの.htaccess設定に記述されている条件やルールが継承されることになります。Apache1.2RewriteLogディレクティブは、すべての書き換え動作に関してサーバがログを書き込むためのファイルの名前をセットします。Rootから相対であると見なされます。このディレクティブはサーバ単位の設定の中で一度だけ記述されるべきものです。書き換え動作のロギングを抑制するためにファイル名を/dev/nullにするのはお勧めできません。これは、書き換えエンジンは実際にはログファイルへの出力を行わないのに、未だ内部的にはログファイルへの出力を生成しているからです。管理者にとってよいことはありません。SecurityTipsドキュメントをご覧ください。Apache1.2RewriteLogLevelディレクティブでは、書き換え動作時のログファイルの冗長レベルを指定します。これは一切ログを書かないことを意味します。それ以上を指定すると、ほとんどすべての動作についてログが書かれます。これで書き換え動作に関するすべてのログが無効となります。RewriteMapプログラムと通信するのに必要な、同期用ロックファイルの名前をセットします。マウントされたデバイスではなく)ローカルパスをセットします。それ以外のタイプの書き換えマップを使う場合には、セットする必要はありません。1.3RewriteMapディレクティブでは、マッピング関数を使ってルール置換文字列の内部で使える書き換えマップを定義します。これにより、キーを検索する際に、フィールドを挿入したり置換したりできます。検索対象には各種のタイプが使えます。MapNameはマップの名前です。以下の書き方のいずれかを通して、書き換えルールの置換文字列におけるマッピング関数を特定するのに使われます。DefaultValue}このような書式が現れると、MapNameマップが評価されてキーLookupKeyが検索されます。キーが見つかれば、置換される代わりにSubstValueによりマップ関数が呼ばれます。キーが見つからない場合、DefaultValueがあればそれで置換され、DefaultValue指定されていなければ空文字列に置換されます。ファイルである場合の、標準の書き換えマップ機能です。文字にしたがってパースされます。これらは変換候補とみなされ、実際に返される値はこれらの中からランダムに選ばれます。これは一見妙な感じがして意味がなさそうに思えますが、これは実際にリバースプロキシにおける負荷分散用として設計されており、検索した値がサーバ名として使われます。フォーマットファイルというものがあり、これをソースとして使うこともできます。スクリプトを使って作ることができます。関数というものもあります。今現在はエンドユーザが自分用に独自のものを作ることはできませんが、以下のものが用意されています。toupper:見つかったキーをすべて大文字に変換する。tolower:見つかったキーをすべて小文字に変換する。進エンコーディングに変換する。進エンコーディングを特殊文字に戻す。ファイルシステムのパスソースにはマップファイル以外にプログラムを使うこともできます。ようなマジッククッキートリックの入ったスクリプト)でなければなりません。ファイルハンドルを通して、書き換えエンジンとのやりとりを行ないます。stdinから受け取ります。返されなければなりません。サーバ自体がハングしてしまいます。当該プログラムへの通信において同期合わせができるようにしてください。デフォルトではそのような同期合わせは行なわれません。ディレクティブは何度でも書くことができます。RewriteMapを使い、その書き換え用マップファイルを宣言します。ディレクトリ毎のコンテキスト内部でマップを宣言することはできませんが、ディレクトリ毎のコンテキストでこのマップを使うことはもちろん可能です。変更されるかまたはサーバが再起動されるまで、検索されたキーはメモリ内にキャッシュされます。それにもかかわらず、毎回のリクエストで使われるマップ関数をルール内に書くことができます。外部検索は一度しか行なわれないので、これでも大丈夫なのです。明示的に指定するものです。以下で示すように、RewriteRuleはディレクトリ毎の設定ファイル(.htaccess)で使えます。そこでは、これはローカルに振舞います。この処理段階ではローカルディレクトリの接頭辞が取り除かれ、その残りの部分に対してのみ書き換えルールが適用されます。書き換え後、取り除かれた部分が再度自動的にパスに付加されます。URLをサーバ処理に再投入しなければなりません。ベースが何なのかを知る必要があります。デフォルトではこのプリフィックスはファイルパスそのものに対応しています。一般的にこの仮定は間違っていることになります。プリフィックスを指定してやらなければならないのです。物理的なファイルパスを直接指しているのでなければ、RewriteRuleディレクティブを使おうとしているところすべてについて、各.htaccessファイルでRewriteBaseディレクティブを使わなければなりません。いったディレクティブの設定がある。アクセスしていることをサーバに知らせる。正しい書き換え操作が行なわれます。内部処理に関する正しい動きです。ディレクトリ単位の書き換え操作は処理の中において来るのが遅すぎるのです。実際には大した事はありません。内部におけるその他の多くの動作中にも同様のことが起こっているからです。その設計と実装は正しいのだと確信して構わないのです。1.3RewriteCondディレクティブはルール条件を定義します。以上のRewriteCondディレクティブを置くことができます。状態とマッチし、かつこれらの追加条件が適用される場合にのみ使われます。後方参照:この書式で、後方参照を表します。これは、対応するRewriteRuleディレクティブ(現在のRewriteCondディレクティブのブロックの最後にあるもの)からのパターンを、(括弧で!)グループ化したものへのアクセスを提供します。この書式で、後方参照を表します。これは、現在の条件ブロックの中で最後にマッチしたRewriteCondディレクティブからのパターンを、(括弧で!)グループ化したものへのアクセスを提供します。この書式で、拡張を表します。ドキュメントを参照のこと。以下は変数を表します。フィールドに対応します。仕様のどこかに説明があります。解決する必要があるモジュールは、サブリクエストを生成する場合があります。19990320:10)に対応しますが、これは主にモジュールの作者が関心を持つものです。HTTP/1.1")。これには、ブラウザから送られた追加ヘッダは一切含みません。完全なローカルファイルシステムのパス。フィールドの値が入っています。ここで変数は任意の環境変数です。