Apache HTTP サーバ バージョン 2.5

このドキュメントでは、RewriteRule
ディレクティブで使用可能なフラグについて、詳細な説明と例を提供します。
はじめに
B (バックリファレンスのエスケープ)
BNP|backrefnoplus (スペースを + にエスケープしない)
BCTLS
BNE
C|chain
CO|cookie
DPI|discardpath
E|env
END
F|forbidden
G|gone
H|handler
L|last
N|next
NC|nocase
NE|noescape
NS|nosubreq
P|proxy
PT|passthrough
QSA|qsappend
QSD|qsdiscard
QSL|qslast
R|redirect
S|skip
T|type
UnsafeAllow3F
UnsafePrefixStat
UNCRewriteRule は、
1 つ以上のフラグによって動作を変更できます。フラグはルールの末尾の
角括弧内に含まれ、複数のフラグはカンマで区切られます。
RewriteRule pattern target [Flag1,Flag2,Flag3]
各フラグ (いくつかの例外を除き) には CO のような短い形式と、
cookie のような長い形式があります。短い形式を使用するのが
最も一般的ですが、各フラグの機能を覚えるために長い形式に慣れることを
お勧めします。一部のフラグは 1 つ以上の引数を取ります。フラグは
大文字小文字を区別しません。
メタデータを変更するフラグ (T=、H=、E=) は、ディレクトリ単位および htaccess コンテキストで、同じ書き換え処理ラウンド中に ('-' 以外の) 置換が行われる場合、効果がありません。
ここでは、各フラグと使用例を紹介します。
[B] フラグは、変換を適用する前に非英数字文字をエスケープするよう
RewriteRule に指示します。
mod_rewrite はマッピング前に URL をアンエスケープする
必要があるため、バックリファレンスは適用時にアンエスケープされています。
B フラグを使用すると、バックリファレンス内の非英数字文字がエスケープ
されます。例えば、以下のルールを考えてみてください:
サーバ変数の同様のエスケープについては、"escape" マッピング関数を参照してください
RewriteRule "^search/(.*)$" "/search.php?term=$1"
検索語が 'x & y/z' の場合、ブラウザはこれを
'x%20%26%20y%2Fz' としてエンコードし、リクエストは 'search/x%20%26%20y%2Fz'
になります。B フラグがない場合、この書き換えルールは 'search.php?term=x & y/z'
にマッピングされますが、これは有効な URL ではないため、
search.php?term=x%20&y%2Fz= としてエンコードされ、
意図した結果になりません。
同じルールに B フラグを設定すると、パラメータは出力 URL に渡される前に
再エンコードされ、正しいマッピング
/search.php?term=x%20%26%20y%2Fz になります。
RewriteRule "^search/(.*)$" "/search.php?term=$1" [B,PT]
この特定の例を動作させるには、AllowEncodedSlashes を On に
設定する必要がある場合があることに注意してください。httpd は URL 内の
エンコードされたスラッシュを許可せず、見つけた場合は 404 を返します。
このエスケープは特にプロキシの状況で必要です。バックエンドが アンエスケープされた URL を受け取ると壊れる可能性があるためです。
このフラグの代替として、RewriteCond を使用して %{THE_REQUEST} に対してキャプチャする
方法があります。これはエンコードされた形式の文字列をキャプチャします。
2.4.26 以降では、エスケープする文字を特定の文字に限定できます:
[B=#?;]。注: スペース文字はエスケープする文字リストに
含めることができますが、RewriteRule
の 3 番目の引数全体を引用符で囲む必要があり、スペースはリストの
最後の文字にしてはいけません。
# スペースと疑問符をエスケープ。最後の引数の引用符は # スペースが含まれる場合に必要です。 RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]"
この方法でエスケープされる文字を制限するには、#flag_bne および #flag_bctls を参照してください
[BNP] フラグは、バックリファレンス内のスペース文字を '+' ではなく
%20 にエスケープするよう RewriteRule に指示します。
バックリファレンスがクエリ文字列ではなくパスコンポーネントで使用される
場合に便利です。
# クエリ文字列経由のフォーム送信で使用される + ではなく、 # パス内のスペースを %20 にエスケープ RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]"
このフラグはバージョン 2.4.26 以降で使用可能です。
[BCTLS] フラグは [B] フラグに似ていますが、制御文字とスペース文字のみを エスケープします。これは、エンコードされずにクエリ文字列にコピーされた 場合に拒否される文字セットと同じです。
# 制御文字とスペースをエスケープ RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]"
このフラグはバージョン 2.5.1 以降で使用可能です。
[BNE=...] 内の文字リストは、[B] または [BCTLS] フラグの文字に対する 除外として扱われます。リストされた文字はエスケープされません。
# デフォルトの文字をエスケープするが、/ は除外 RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]"
このフラグはバージョン 2.5.1 以降で使用可能です。
[C] または [chain] フラグは、RewriteRule が次のルールに
チェーンされることを示します。つまり、ルールがマッチすると通常通り
処理され、制御は次のルールに移ります。しかし、マッチしない場合は、
次のルールおよびチェーンされたその他のルールがスキップされます。
[CO] または [cookie] フラグは、特定の
RewriteRule がマッチした場合に
cookie を設定できるようにします。引数は 3 つの必須フィールドと
5 つのオプションフィールドで構成されます。
フラグの完全な構文 (すべての属性を含む) は以下の通りです:
[CO=NAME:VALUE:DOMAIN:lifetime:path:secure:httponly:samesite]
cookie フィールドのいずれかにリテラルの ':' 文字が必要な場合、 代替構文が利用可能です。代替構文にオプトインするには、cookie の "Name" の前に ';' 文字を付け、フィールドセパレータを ';' として 指定してください。
[CO=;NAME;VALUE:MOREVALUE;DOMAIN;lifetime;path;secure;httponly;samesite]
cookie が設定されるためには、名前、値、およびドメインを宣言する 必要があります。
www.example.com のような
ホスト名か、.example.com のようなドメインです。
ドットで区切られた少なくとも 2 つのパートが必要です。つまり、
単に .com や .net にはできません。
そのような cookie は cookie セキュリティモデルで禁止されています。オプションで以下の値も設定できます:
/customers/ や /files/download/ などです。/ (ウェブサイト全体) に設定されます。secure、true、または 1 に
設定すると、cookie はセキュアな (https) 接続経由でのみ送信が許可されます。HttpOnly、true、または 1 に
設定すると、cookie に HttpOnly フラグが設定され、
この機能をサポートするブラウザでは JavaScript コードから cookie に
アクセスできなくなります。false または 0 以外の値に設定すると、
SameSite 属性が指定された値に設定されます。典型的な値は
None、Lax、Strict です。
2.5.1 以降で使用可能です。以下の例を考えてみましょう:
RewriteEngine On RewriteRule "^/index\.html" "-" [CO=frontdoor:yes:.example.com:1440:/]
この例では、ルールはリクエストを書き換えません。
書き換えターゲットの "-" は mod_rewrite にリクエストを
変更せずに通過させることを意味します。代わりに、'frontdoor' という名前で
値 'yes' の cookie を設定します。cookie は .example.com
ドメイン内のすべてのホストに対して有効です。有効期限は 1440 分
(24 時間) で、すべての URI に対して返されます。
DPI フラグは、書き換えた URI の PATH_INFO 部分を破棄します。
このフラグはバージョン 2.2.12 以降で使用可能です。
ディレクトリ単位のコンテキストでは、各
RewriteRule が比較する URI は、URI と PATH_INFO の
現在の値を連結したものです。
現在の URI は、クライアントが要求した初期 URI、
mod_rewrite の前のラウンドの処理結果、または現在のラウンドの
mod_rewrite 処理の前のルールの結果である可能性があります。
一方、各ルールの前に URI に追加される PATH_INFO は、この
mod_rewrite 処理ラウンド前の PATH_INFO の値のみを
反映します。その結果、URI の大部分が複数の
RewriteRule ディレクティブで置換にマッチおよび
コピーされ、URI のどの部分が現在の PATH_INFO から来たかを考慮しない場合、
最終的な URI に PATH_INFO の複数のコピーが追加される可能性があります。
前のマッピングの結果としてのこのリクエストの PATH_INFO が不要な
置換にはこのフラグを使用してください。このフラグは、この
mod_rewrite 処理ラウンドの開始前に確立された PATH_INFO を
永続的に破棄します。PATH_INFO は、現在の mod_rewrite
処理ラウンドが完了するまで再計算されません。このラウンド中の
後続のルールは、PATH_INFO が追加されていない置換の直接の結果のみを
参照します。
[E] または [env] フラグを使用すると、環境変数の値を設定できます。 一部の環境変数はルールの実行後に設定される可能性があり、設定した値が 上書きされることがあることに注意してください。環境変数の動作の詳細は 環境変数ドキュメントを参照してください。
このフラグの完全な構文は以下の通りです:
[E=VAR:VAL] [E=!VAR]
VAL には展開されるバックリファレンス ($N や
%N) を含めることができます。
短い形式
[E=VAR]
を使用すると、VAR という名前の環境変数を空の値に
設定できます。
以下の形式
[E=!VAR]
で、以前に設定された VAR という名前の環境変数を
削除できます。
環境変数は CGI プログラム、他の RewriteRule ディレクティブ、 CustomLog ディレクティブなど、さまざまなコンテキストで使用できます。
以下の例は、リクエストされた URI が画像ファイルの場合、'image' という 環境変数を値 '1' に設定します。その後、その環境変数を使用して、 それらのリクエストをアクセスログから除外します。
RewriteRule "\.(png|gif|jpg)$" "-" [E=image:1] CustomLog "logs/access_log" combined env=!image
この効果は SetEnvIf を
使用しても得られることに注意してください。このテクニックは推奨としてではなく、
例として提供されています。
[END] フラグを使用すると、([L] のように) 現在の書き換え処理ラウンドを 終了するだけでなく、ディレクトリ単位 (htaccess) コンテキストでの 以降の書き換え処理も防止します。
これは外部リダイレクトによる新しいリクエストには適用されません。
[F] フラグを使用すると、サーバはクライアントに 403 Forbidden
ステータスコードを返します。同じ動作は
Deny ディレクティブでも
実現できますが、このフラグの方が Forbidden ステータスの割り当てに
柔軟性があります。
以下のルールは、サーバから .exe ファイルのダウンロードを
禁止します。
RewriteRule "\.exe" "-" [F]
この例は書き換えターゲットに "-" 構文を使用しており、リクエスト URI は 変更されません。リクエストを禁止するのであれば、別の URI に書き換える 理由はありません。
[F] を使用すると [L] が暗黙的に含まれます - つまり、レスポンスが 直ちに返され、後続のルールは評価されません。
[G] フラグは、サーバにレスポンスとして 410 Gone ステータスを 返すよう強制します。これは、リソースがかつて利用可能であったが、 もはや利用できないことを示します。
[F] フラグと同様に、[G] フラグを使用する場合は通常書き換えターゲットに "-" 構文を使用します:
RewriteRule "oldproduct" "-" [G,NC]
[G] を使用すると [L] が暗黙的に含まれます - つまり、レスポンスが 直ちに返され、後続のルールは評価されません。
結果のリクエストを指定されたハンドラで処理するよう強制します。 例えば、ファイル拡張子のないすべてのファイルを php ハンドラで 解析させるために使用できます:
RewriteRule "!\." "-" [H=application/x-httpd-php]
上記の正規表現 - !\. - は、リテラルの .
文字を含まないすべてのリクエストにマッチします。
これは条件に基づいてハンドラを強制するためにも使用できます。
例えば、以下のスニペットをサーバ単位のコンテキストで使用すると、
.php ファイルが .phps 拡張子でリクエスト
された場合に mod_php によって表示されます:
RewriteRule "^(/source/.+\.php)s$" "$1" [H=application/x-httpd-php-source]
上記の正規表現 - ^(/source/.+\.php)s$ - は
/source/ で始まり、1 文字以上の任意の文字が続き、
リテラルの .phps で終わるリクエストにマッチします。
バックリファレンス $1 は正規表現の括弧内のキャプチャされたマッチを
参照します。
[L] フラグは mod_rewrite にルールセットの処理を
停止させます。ほとんどのコンテキストで、ルールがマッチした場合、
以降のルールは処理されなくなります。これは Perl の last
コマンドや C の break コマンドに相当します。
このフラグは、後続のルールを考慮せずに現在のルールを直ちに適用
すべきことを示すために使用します。
.htaccess ファイルまたは
<Directory>
セクションで RewriteRule
を使用している場合、ルールがどのように処理されるかについてある程度の
理解が重要です。簡略化すると、ルールが処理された後、書き換えられた
リクエストは URL 解析エンジンに渡されます。書き換えられたリクエストが
処理される際に、.htaccess ファイルまたは
<Directory> セクションが
再び検出され、ルールセットが最初から再実行される可能性があります。
これは最も一般的に、ルールの 1 つが (内部または外部の) リダイレクトを
引き起こし、リクエスト処理が最初からやり直される場合に発生します。
したがって、これらのコンテキストで RewriteRule ディレクティブを使用する場合、
ルールのループを避けるための明示的な対策を取り、一連のルールの実行
終了を [L] フラグだけに頼らないことが重要です。以下に示す通りです。
代替フラグ [END] は、現在の書き換え処理ラウンドを終了するだけでなく、 ディレクトリ単位 (htaccess) コンテキストでの以降の書き換え処理も 防止するために使用できます。これは外部リダイレクトによる新しい リクエストには適用されません。
ここに示す例は、すべてのリクエストを index.php に
書き換え、元のリクエストを index.php へのクエリ文字列
引数として渡しますが、RewriteCond
により、リクエストが既に index.php に対するものである場合は
RewriteRule がスキップされます。
RewriteBase "/"
RewriteCond "%{REQUEST_URI}" !=/index.php
RewriteRule "^(.*)" "/index.php?req=$1" [L,PT]
[N] フラグは、それまでのルールセットの結果を出発点として、ルールセットを 最初からやり直します。ループを引き起こす可能性があるため、 極めて慎重に使用してください。
[Next] フラグは、例えばリクエスト内の特定の文字列や文字を繰り返し 置換したい場合に使用できます。ここに示す例は、リクエスト内のすべての A を B に置換し、置換すべき A がなくなるまで続けます。
RewriteRule "(.*)A(.*)" "$1B$2" [N]
これは while ループと考えることができます: このパターンが
まだマッチする間 (つまり、URI にまだ A が含まれている間)、
この置換を実行します (つまり、A を B に
置換します)。
2.5.0 以降では、意図しないループを防ぐため、10,000 回の反復後に エラーを返します。N フラグに追加することで、代替の最大反復回数を 指定できます。
# ループの各パスで 1 文字を置換 RewriteRule "(.+)[><;]$" "$1" [N=32000] # ... または、10 ループ後に諦める RewriteRule "(.+)[><;]$" "$1" [N=10]
[NC] フラグを使用すると、RewriteRule は大文字小文字を
区別せずにマッチします。つまり、マッチする URI で文字が大文字か
小文字かを気にしません。
以下の例では、画像ファイルのリクエストは専用の画像サーバに
プロキシされます。マッチは大文字小文字を区別しないため、例えば
.jpg と .JPG ファイルの両方が受け入れられます。
RewriteRule "(.*\.(jpg|gif|png))$" "http://images.example.com$1" [P,NC]
デフォルトでは、RewriteRule
が外部リダイレクトをもたらす場合、出力内の以下の安全なセット以外の文字は
16 進コード (パーセントエンコード) に変換されます:
A-Z、a-z、
0-9$-_.+!*'(),:;@&=/~例えば、# は %23 に、? は
%3F に変換されます。% 文字もエスケープされ
(%25 に)、これにより置換に既に存在するパーセントエンコーディングが
二重エンコードされることを意味します。
[NE] フラグを使用すると、このエスケープが防止され、# や
? などの文字がそのままリダイレクト URL に渡されます。
RewriteRule "^/anchor/(.+)" "/bigpage.html#$1" [NE,R]
上記の例は /anchor/xyz を /bigpage.html#xyz に
リダイレクトします。[NE] を省略すると、# が 16 進コード相当の
%23 に変換され、404 Not Found エラーが発生します。
[NS] フラグを使用すると、サブリクエストでのルールの使用が
防止されます。例えば、SSI (Server Side Include) を使用して
インクルードされたページはサブリクエストであり、それらのサブリクエストで
書き換えが行われないようにしたい場合があります。また、
mod_dir がディレクトリのデフォルトファイル
(index.html ファイルなど) の情報を調べようとする場合も
内部サブリクエストであり、そのようなサブリクエストでの書き換えを
避けたい場合が多くあります。サブリクエストでは、ルールの完全なセットが
適用されると有用でない場合やエラーを引き起こす場合があります。
問題のあるルールを除外するためにこのフラグを使用してください。
このルールを使用するかどうかを決定するには: CGI スクリプトで URL をプレフィックスし、CGI スクリプトで処理させるようにしている場合、 サブリクエストで問題 (または大きなオーバーヘッド) が発生する 可能性があります。そのような場合はこのフラグを使用してください。
HTML ページの一部として読み込まれる画像、JavaScript ファイル、 CSS ファイルはサブリクエストではありません - ブラウザがそれらを 別の HTTP リクエストとしてリクエストします。
[P] フラグを使用すると、リクエストは mod_proxy によって
処理され、プロキシリクエストとして扱われます。例えば、すべての画像
リクエストをバックエンド画像サーバで処理したい場合、以下のようにします:
RewriteRule "/(.*)\.(jpg|gif|png)$" "http://images.example.com/$1.$2" [P]
[P] フラグの使用は [L] を暗黙的に含みます - つまり、リクエストは 直ちにプロキシに送られ、後続のルールは考慮されません。
置換文字列が mod_proxy で処理できる有効な URI
(通常 http://hostname で始まる) であることを
確認する必要があります。そうでない場合、プロキシモジュールからエラーが
発生します。このフラグは、ProxyPass
ディレクティブのより強力な実装を実現し、リモートコンテンツをローカル
サーバのネームスペースにマッピングするために使用します。
ルールのターゲット URL を構築する際には、サーバがプロキシとして 動作する URL のセットに対するクライアントの影響のセキュリティ上の 影響を考慮してください。URL のスキームとホスト名の部分が固定されているか、 クライアントに過度の影響を与えないことを確認してください。
このフラグを使用すると、デフォルトワーカーが使用されるため、
永続的な接続が処理されない mod_proxy の使用がトリガー
されます。接続プーリング/再利用が処理されません。
永続的な接続を使用するには、少なくともターゲット URL のスキームと
ホスト部分に対する Proxy
ブロックを設定し、例えばタイムアウトを設定する
ProxySet ディレクティブを
含めてください。
ProxyPass または
ProxyPassMatch で設定すると、
永続的な接続が自動的に使用されます。
注: このフラグを使用するには mod_proxy が
有効になっている必要があります。
RewriteRule のターゲット (置換文字列) はデフォルトではファイルパスと
想定されます。[PT] フラグを使用すると、代わりに URI として扱われます。
つまり、[PT] フラグを使用すると、RewriteRule の結果が URL マッピングに
戻され、Alias、Redirect、ScriptAlias などの場所ベースのマッピングが
効果を発揮する機会が与えられます。
例えば、/icons に対する Alias があり、
そこを指す RewriteRule がある
場合、Alias が評価されるように
[PT] フラグを使用する必要があります。
Alias "/icons" "/usr/local/apache/icons" RewriteRule "/pics/(.+)\.jpg$" "/icons/$1.gif" [PT]
この場合に [PT] フラグを省略すると、Alias が無視され、 'File not found' エラーが返されます。
PT フラグは L フラグを暗黙的に含みます:
リクエストを処理の次のフェーズに渡すために書き換えが停止されます。
PT フラグは、
<Directory> セクションや
.htaccess ファイルなどのディレクトリ単位のコンテキストでは
暗黙的に含まれることに注意してください。これを回避する唯一の方法は、
- に書き換えることです。
置換 URI にクエリ文字列が含まれる場合、
RewriteRule のデフォルト動作は
既存のクエリ文字列を破棄し、新しく生成されたもので置き換えることです。
[QSA] フラグを使用すると、クエリ文字列が結合されます。
以下のルールを考えてみましょう:
RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]
[QSA] フラグがある場合、/pages/123?one=two へのリクエストは
/page.php?page=123&one=two にマッピングされます。
[QSA] フラグがない場合、同じリクエストは /page.php?page=123
にマッピングされます - つまり、既存のクエリ文字列は破棄されます。
リクエストされた URI にクエリ文字列が含まれ、ターゲット URI に含まれない
場合、RewriteRule のデフォルト
動作はそのクエリ文字列をターゲット URI にコピーすることです。
[QSD] フラグを使用すると、クエリ文字列が破棄されます。
このフラグはバージョン 2.4.0 以降で使用可能です。
[QSD] と [QSA] を一緒に使用すると、[QSD] が優先されます。
ターゲット URI にクエリ文字列がある場合は、デフォルトの動作が
観察されます - つまり、元のクエリ文字列は破棄され、
RewriteRule ターゲット URI のクエリ文字列に
置き換えられます。
デフォルトでは、置換内の最初の (左端の) 疑問符がパスとクエリ文字列を
区切ります。[QSL] フラグを使用すると、代わりに最後の (右端の) 疑問符で
2 つのコンポーネントを分割するよう
RewriteRule に指示します。
これは、ファイル名にリテラルの疑問符が含まれるファイルへのマッピング時に 便利です。置換でクエリ文字列が使用されない場合、このフラグと組み合わせて 疑問符を追加できます。
このフラグはバージョン 2.4.19 以降で使用可能です。
[R] フラグを使用すると、ブラウザに HTTP リダイレクトが発行されます。
完全修飾 URL (つまり http://servername/ を含む) が指定された
場合、その場所へのリダイレクトが発行されます。それ以外の場合は、
現在のプロトコル、サーバ名、ポート番号がリダイレクトで送信される
URL の生成に使用されます。
[R=305] のような構文を使用して、任意の有効な HTTP レスポンスステータス
コードを指定できます。指定されない場合、デフォルトの 302 ステータスコードが
使用されます。指定されたステータスコードは必ずしもリダイレクト (3xx)
ステータスコードである必要はありません。ただし、リダイレクト範囲 (300-399)
外のステータスコードの場合、置換文字列は完全に破棄され、L
が使用されたかのように書き換えが停止されます。
レスポンスステータスコードに加えて、シンボリック名を使用して
リダイレクトステータスを指定することもできます: temp
(デフォルト)、permanent、または seeother。
[R] フラグはほぼ常に [L] と組み合わせて使用します (つまり [R,L])。
[R] フラグ単独では、URI に http://thishost[:thisport] を
前置しますが、これをルールセットの次のルールに渡すため、しばしば
'Invalid URI in request' 警告が発生します。
注: httpd は HTTP 仕様に含まれるステータスコードのみをサポートします。 認識されないステータスコードを使用すると、500 エラーとエラーログ メッセージが発生します。
[S] フラグは、実行したくないルールをスキップするために使用されます。
スキップフラグの構文は [S=N] で、N はスキップする
ルールの数を表します (RewriteRule
と先行する RewriteCond
ディレクティブがマッチする場合)。これは書き換えルールセット内の
goto 文と考えることができます。以下の例では、リクエストされた
URI が実際のファイルに対応しない場合にのみ
RewriteRule を実行したいとします。
# Is the request for a non-existent file?
RewriteCond "%{REQUEST_FILENAME}" !-f
RewriteCond "%{REQUEST_FILENAME}" !-d
# If so, skip these two RewriteRules
RewriteRule ".?" "-" [S=2]
RewriteRule "(.*\.gif)" "images.php?$1"
RewriteRule "(.*\.html)" "docs.php?$1"
このテクニックが有用なのは、RewriteCond は直後の
RewriteRule にのみ適用されるため
です。複数の RewriteRule に RewriteCond を
適用したい場合の一つの方法は、条件を否定して [Skip] フラグ付きの
RewriteRule を追加することです。これを使用して疑似的な
if-then-else 構造を作成できます: then 節の最後のルールが
skip=N となり、N は else 節のルール数です:
# Does the file exist?
RewriteCond "%{REQUEST_FILENAME}" !-f
RewriteCond "%{REQUEST_FILENAME}" !-d
# Create an if-then-else construct by skipping 3 lines if we meant to go to the "else" stanza.
RewriteRule ".?" "-" [S=3]
# IF the file exists, then:
RewriteRule "(.*\.gif)" "images.php?$1"
RewriteRule "(.*\.html)" "docs.php?$1"
# Skip past the "else" stanza.
RewriteRule ".?" "-" [S=1]
# ELSE...
RewriteRule "(.*)" "404.php?file=$1"
# END
この種の設定は、代わりに <If>、
<ElseIf>、<Else> ディレクティブを使用する方が
おそらく簡単でしょう。
結果のレスポンスが送信される MIME タイプを設定します。
これは AddType ディレクティブと
同じ効果を持ちます。
例えば、特定の方法でリクエストされた場合に Perl ソースコードを プレーンテキストとして提供するために、以下のテクニックを使用できます:
# .pl ファイルをプレーンテキストとして提供 RewriteRule "\.pl$" "-" [T=text/plain]
あるいは、ファイル拡張子のない jpeg 画像を生成するカメラがある場合、 ファイル名によって正しい MIME タイプで画像を提供するよう強制できます:
# 名前に 'IMG' を含むファイルは jpg 画像 RewriteRule "IMG" "-" [T=image/jpg]
これは簡単な例であり、代わりに
<FilesMatch> を使用する
方が良いことに注意してください。問題に対する代替の解決策を常に検討して
から書き換えに頼ってください。書き換えは常に代替手段よりも
効率が悪くなります。
ディレクトリ単位のコンテキストで使用する場合は、
mod_rewrite 処理の全ラウンドの置換として
- (ダッシュ) のみを使用してください。そうしないと、
内部的な再処理 (mod_rewrite 処理の後続ラウンドを含む)
により、このフラグで設定された MIME タイプが失われます。
現在の mod_rewrite 処理ラウンドを終了するために
L フラグが有用です。
このフラグを設定すると、書き換え対象の HTTP リクエストに エンコードされた疑問符 '%3f' が含まれ、書き換え結果の置換に '?' がある場合でも書き換えを続行できます。これは、悪意のある URL がエンコードされた疑問符のキャプチャと再置換を利用するのを 防止します。
このフラグを設定すると、サーバスコープの置換が変数や バックリファレンスで始まり、ファイルシステムパスに解決される場合に 必要です。これらの置換にはドキュメントルートがプレフィックスとして 付加されません。これは、悪意のある URL が展開された置換を 予期しないファイルシステムの場所にマッピングさせるのを防止します。
Available in Apache HTTP Server 2.5.1 and later.