Apache HTTP サーバ バージョン 2.0
Apache HTTP サーバ バージョン 2.0
Apache が使用するアドレスとポートの設定をします。
| 関連モジュール | 関連ディレクティブ |
|---|---|
Apache は起動時に、ローカルマシンのあるポートあよびアドレス に対して接続し、リクエストが来るのを待ちます。 デフォルトではマシンのすべてのアドレスに対して listen します。 しかしながら、特定のポートか、特定のアドレスのみか、 またはそれらの組み合わせのいずれかを listen するようにする必要があります。 これは、異なる IP アドレス、ホスト名、ポートに対する Apache の応答方法を決定するバーチャルホスト機能と組み合わせて使われます。
Listen
ディレクティブで、特定のポートやアドレス・ポートの組からのみ入ってくる
リクエストを受け付けるようにできます。
もしポート番号のみが Listen
ディレクティブで指定された場合は、
すべてのインターフェースの与えられたポート番号を
listen します。 IP アドレスがポート番号と同時に与えられた場合は、
サーバは与えられたポートとインターフェースを listen します。
複数の Listen ディレクティブを用いて
いくつかの listen するアドレスとポートを指定できます。
サーバはリストされたアドレスやポートからのすべてのリクエストに
対して応答します。
たとえば、ポート 80 と 8000 の両方に対しての接続を受け付けるには
Listen 80
Listen 8000
とします。 二つの指定されたインタフェースとポート番号に対しての接続を受け付けるには、
Listen 192.170.2.1:80
Listen 192.170.2.5:8000
とします。 IPv6 アドレスは、角括弧で次の例のように囲まなければいけません。
Listen [2001:db8::a00:20ff:fea7:ccea]:80
多くのプラットホームで IPv6 がサポートされてきていて、 APR はこれらのほとんどで IPv6 をサポートしているので、 Apache は IPv6 ソケットを割り当てて IPv6 経由で送られてきたリクエストを扱うことができます。
IPv6 ソケットが IPv4 と IPv6 コネクションの両方を扱うことができるか どうかは、Apache 管理者にとって厄介な問題です。 IPv4 コネクションを IPv6 ソケットで扱う場合は、 IPv4 マップされた IPv6 アドレスを使用していて、 ほとんどのプラットホームではデフォルトで使用可能ですが、 FreeBSD, NetBSD, OpenBSD では、システム全体としてのポリシーとの整合性から、 デフォルトでは使用不可に設定されています。 これらのデフォルトで使用不可のプラットホームであっても、 特別な設定パラメータで Apache の挙動を変化させることができます。
IPv4 と IPv6 のコネクションを最小限のソケットで扱いたいのであれば、
IPv4 マップの IPv6 アドレスを使用する必要があり、
--enable-v4-mapped configure オプションを指定して、単純に
Listen
ディレクティブで次のように設定します。
Listen 80
--enable-v4-mapped では、Apache
の生成するデフォルトの設定ファイル中の
Listen
ディレクティブはこの形式を使用しています。
--enable-v4-mapped は、
FreeBSD, NetBSD, OpenBSD 以外の全てのプラットホームでのデフォルトです。
ですから、おそらくお手元の Apache はこの設定でビルドされているでしょう。
プラットフォームや APR が何をサポートするかに関わらず、
IPv4 コネクションのみを扱うようにしたい場合は、
次の例のように全ての
Listen ディレクティブで
IPv4 アドレスを指定してください。
Listen 0.0.0.0:80
Listen 192.170.2.1:80
IPv4 と IPv6 のコネクションを個別のソケットで扱うようにしたい場合
(つまり IPv4 マップのアドレスを無効にしたい場合)
は、--disable-v4-mapped configure
オプションを指定して、次のように個別指定の
Listen
ディレクティブを使用してください。
Listen [::]:80
Listen 0.0.0.0:80
--disable-v4-mapped では、Apache
の生成するデフォルトの設定ファイル中の
Listen
ディレクティブはこの形式を使用しています。
--disable-v4-mapped は、
FreeBSD, NetBSD, OpenBSD プラットホームでのデフォルトです。
Listen でバーチャルホストが実装されるわけではありません。
Listen は単にメインサーバにどのアドレスとポートを listen すべきかを
教えるだけです。
<VirtualHost>
ディレクティブが使われない場合は、
受け入れたリクエストすべてに対して全く同じ挙動をします。
しかしながら
<VirtualHost>
を使って、
一つ以上のアドレスやポートに対して異なる挙動をするように
指定することができます。
VirtualHost を実装するには、使用するアドレスとポートを
まず初めにサーバに通知しなければなりません。
そして、その指定したアドレスとポートでの
このバーチャルホストの挙動を設定するために、
<VirtualHost>
セクションを作ります。もし
<VirtualHost>
が listen していないアドレスとポートに対して
設定されてしまうと、
それにはアクセスできないということに注意してください。
Apache HTTP サーバ バージョン 2.0
この文書では、Apache HTTP サーバを設定するのに使用するファイルについて 記述しています。
| 関連モジュール | 関連ディレクティブ |
|---|---|
Apache は ディレクティブ を設定ファイルに平文で書くことにより設定します。
メインの設定ファイルは普通は httpd.conf という名前です。
このファイルの位置はコンパイル時に設定されますが、コマンドラインの
-f フラグにより上書きできます。
また、他の設定ファイルを Include
ディレクティブによって追加でき、ワイルドカードを使用して多数の
設定ファイルを追加することができます。
どんなディレクティブも、これらの設定ファイルどれにでも入れることができます。
Apache は起動時か再起動時のみメイン設定ファイルの変更を認識します。
サーバは MIME
ドキュメントタイプを含んでいるファイルも読み込みます。ファイル名は
TypesConfig
で設定され、デフォルトでは mime.types
になっています。
Apache の設定ファイルは 1 行に 1 つのディレクティブからなります。 バックスラッシュ "\" はディレクティブが次の行に継続していることを 示すために行の最後の文字として使われているかもしれません。 行の最後とバックスラッシュの間に他の文字や空白があってはいけません。
設定ファイルのディレクティブは大文字小文字を区別しませんが、 引数にはしばしば区別するものがあります。ハッシュ文字 "#" で始まる行はコメントと見なされて無視されます。 設定ディレクティブの後の行ではコメントが含まれていてはいけません。ディレクティブの前の空行と空白は無視されますので、 わかりやすくするためにディレクティブをインデントしても構いません。
設定ファイルの構文エラーは、
apachectl configtest
かコマンドラインオプション
-t を使って調べられます。
| 関連モジュール | 関連ディレクティブ |
|---|---|
Apache はモジュール化されたサーバです。
コアサーバには最も基本的な機能だけが含まれています。拡張機能は
Apache にロードされるモジュールとして利用可能です。デフォルトでは、コンパイル時にモジュールの
Base セット (基本セット) が
サーバに含まれます。サーバが動的ロードモジュールを使うようにコンパイルされている場合は、
モジュールを別にコンパイルして、いつでも
LoadModule
ディレクティブを使って追加できます。
そうでない場合は、モジュールの追加や削除をするためには Apache
を再コンパイルする必要があります。設定ディレクティブは <IfModule>
ブロックに入れることで特定のモジュールが存在するときだけ
設定ファイルに含まれるようにすることができます。
コマンドラインオプション -l を使って現時点で
どのモジュールがサーバにコンパイルされているかを知ることができます。
| 関連モジュール | 関連ディレクティブ |
|---|---|
メイン設定ファイルにあるディレクティブはサーバ全体に適用されます。
サーバの一部分の設定だけを変更したい場合は <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, <LocationMatch>
セクションの中に置くことで適用範囲を決められます。
これらのセクションはその中にあるディレクティブの適用範囲を
特定のファイルシステムの位置や URL に限定します。
非常に細粒度の設定を可能にするために、
セクションを入れ子にすることもできます。
Apache は同時に多くの違うウェブサイトを扱う能力があります。
これは バーチャルホスト と呼ばれています。
特定のウェブサイトにのみ適用されるようにするために、
ディレクティブは
<VirtualHost>
セクションの中に置くことでも適用範囲を変えることができます。
ほとんどのディレクティブはどのセクションにでも書けますが、 中にはコンテキストによっては意味をなさないものもあります。 例えば、プロセスの作成を制御しているディレクティブはメインサーバの コンテキストにのみ書くことができます。 どのディレクティブをどのセクションに書くことができるかを知るためには ディレクティブの コンテキスト を調べてください。詳しい情報は、 Directory, Location, Files セクションの動作法にあります。
| 関連モジュール | 関連ディレクティブ |
|---|---|
Apache ではウェブツリーの中に置かれた特別なファイルを使って
非中央集権的な設定管理をできます。その特別なファイルは普通は
.htaccess という名前で、
AccessFileName
ディレクティブでどんな名前にでも指定できます。
.htaccess
ファイルに書かれたディレクティブはファイルを置いた
ディレクトリとその全てのサブディレクトリに適用されます。
.htaccess
ファイルはすべてのリクエストで読み込まれるため、
変更はすぐに反映されます。
どのディレクティブが .htaccess
ファイルに書けるかを調べるには、ディレクティブのコンテキスト
を調べてください。サーバ管理者はさらにメイン設定ファイルの
AllowOverride
を設定することでどのディレクティブを .htaccess
ファイルに書けるようにするかを制御することができます。
.htaccess ファイルに関する詳しい情報は
.htaccess チュートリアル
を参照してください。
Apache HTTP サーバ バージョン 2.0
Apache は HTTP/1.1 の規格に記述されているコンテントネゴシエーションを サポートしています。 ブラウザにより提供されたメディアタイプ、 言語、文字セット、エンコーディングの優先傾向に基づいて、 最適なリソースの表現を選択できます。 また、不完全なネゴシエーション情報を送ってくるブラウザからのリクエストを もっと賢く取り扱えるよう、いくつか機能も実装してあります。
コンテントネゴシエーションは
mod_negotiation
モジュールによって提供されていて、デフォルトで組み込まれています。
リソースは、幾つか異なった表現で利用できる場合があります。 例えば、異なる言語や異なるメディアタイプ、 またはそれらの組み合わせで利用できるかも知れません。 もっとも適した選択をする方法の一つには、インデックスページを ユーザに見せて、ユーザに選んでもらう方法があります。 しかし、サーバが自動的に選ぶことができる場合が多くあります。 これは、ブラウザがリクエスト毎に、 どの表現を嗜好するかという情報を送ることで動作しています。 例えばブラウザは、可能ならフランス語で情報を見たい、 不可能ならその代わりに英語でもよいと、 自分の嗜好を知らせることができます。 ブラウザはリクエストのヘッダで自分の優先傾向を知らせます。 フランス語のみの表現を要求する場合は、ブラウザは次を送ります。
Accept-Language: fr
この優先傾向は、選択可能な表現が存在して、 言語によって様々な表現がある場合にのみ適用される ということに注意してください。
もっと複雑なリクエストの例を挙げましょう。 このブラウザはフランス語と英語を受け付ける、しかしフランス語を好む、 そして様々なメディアタイプを受け付けるが、 プレインテキストや他のタイプよりは HTML を好む、 他のメディアタイプよりは GIF や JPEG を好む、しかし最終手段として 他のメディアタイプも受け付ける、と設定されています。
Accept-Language: fr; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
Apache は HTTP/1.1 規格で定義されている 'server
driven' コンテントネゴシエーションをサポートしています。
Accept, Accept-Language,
Accept-Charset, Accept-Encoding
リクエストヘッダを完全にサポートしています。Apache は
'transparent' コンテントネゴシエーションもサポートしていますが、
これは RFC 2295 と RFC 2296 で定義されている試験的な
ネゴシエーションプロトコルです。
これらの RFCで定義されている 'feature negotiation'
はサポートしていません。
リソースとは URI で特定される概念上のもののことです (RFC 2396)。 Apache のような HTTP サーバは、その名前空間の中での リソースの表現へのアクセスを提供します。 それぞれの表現は 定義されたメディアタイプ、文字セット、エンコーディング等の 付属した、バイト列の形式です。 それぞれのリソースはある時点で 0 個、1 個、それ以上の表現と 関連付けられる可能性があります。複数の表現が利用できる場合は、 リソースはネゴシエーション可能であるとされ、 個々の表現は variant と呼ばれます。 ネゴシエーション可能なリソースの variant が異なる、 その状態を指して、 ネゴシエーションの次元と呼びます。
リソースをネゴシエーションするためには、 サーバは variant それぞれについての情報を知っておく必要があります。 これは以下の二つの方法のどちらかで行われます。
*.var ファイル)
を使う方法。 これは variant
を明示的に挙げているファイルを指定します。タイプマップは type-map ハンドラ
(もしくは、古い Apache
の設定と下位互換である MIME タイプ
application/x-type-map)
に関連付けられたドキュメントです。
この機能を使うためには、あるファイルの拡張子を
type-map
として定義するようなハンドラを、
設定ファイル中に置く必要があることに注意してください。
これは
AddHandler type-map .var
をサーバ設定ファイル中に書くことが一番良い方法です。
タイプマップファイルは記述するリソースと同じ名前を持っていて、
利用可能な variant それぞれのエントリを持っている必要があります。
そして、このエントリは連続した HTTP のヘッダ行で構成されます。
異なる variant のためのエントリは空行で区切られています。
エントリ中に空行が複数あってはいけません。
習慣的には、マップファイルは全体を結合したもののエントリから始まります
(しかしこれは必須ではなく、あったとしても無視されるものです)。
次に例を示します。このファイルはリソース foo
を記述しているので、foo.var という名前になります。
URI: foo
URI: foo.en.html
Content-type: text/html
Content-language: en
URI: foo.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de
たとえ MultiViews を使用するようになっていたとしても、 ファイル名の拡張子よりタイプマップの方が優先権を持つということにも 注意してください。 variant の品質が違うときは、この画像のように (JPEG, GIF, ASCII アートがあります) メディアタイプの "qs" パラメータで指定されます。
URI: foo
URI: foo.jpeg
Content-type: image/jpeg; qs=0.8
URI: foo.gif
Content-type: image/gif; qs=0.5
URI: foo.txt
Content-type: text/plain; qs=0.01
qs 値の範囲は 0.000 から 1.000 です。qs 値が 0.000 の variant は決して 選択されないことに注意してください。'qs' 値のない variant は qs 値 1.0 を 与えられます。qs パラメータはクライアントの能力に関係無く、他の variant と 比較したときの variant の相対的な「品質」を示します。 例えば、写真を表現しようとしているときは JPEG ファイルの方が普通は ASCII ファイルよりも高い品質になります。しかし、リソースが元々 ASCII アートで表現されているときは、ASCII ファイルの 方が JPEG ファイルよりも高い品質になります。このように、qs は 表現されるリソースの性質によって variant 毎に特有の値を取ります。
認識されるヘッダの一覧は mod_negotiation ドキュメントにあります。
MultiViews はディレクトリ毎のオプションで、
httpd.confファイルの
<Directory>,
<Location>,
<Files>
セクション中や、(AllowOverride
が適切な値に 設定されていると) .htaccess
ファイルで Options
ディレクティブによって設定することができます。
Options All は
MultiViews
をセットしないことに注意してください。明示的に
その名前を書く必要があります。
MultiViews の効果は以下のようになります:
サーバが /some/dir/foo
へのリクエストを受け取り、/some/dir で
MultiViews が有効であって、
/some/dir/foo が存在しない場合、
サーバはディレクトリを読んで foo.*
にあてはまる全てのファイルを探し、
事実上それらのファイルをマップするタイプマップを作ります。
そのとき、メディアタイプとコンテントエンコーディングは、そのファイル名を
直接指定したときと同じものが割り当てられます。
それからクライアントの要求に一番合うものを選びます。
サーバがディレクトリの索引を作ろうとしている場合、
MultiViews
は DirectoryIndex
ディレクティブで指定されたファイルを探す過程にも
適用されます。設定ファイルに
DirectoryIndex index
が書かれていて、index.html と
index.html3 が
両方存在していると、サーバはその中からどちらかを適当に選びます。
もしその両方が存在せずに index.cgi
が存在していると、 サーバはそれを実行します。
もしディレクトリを読んでいる際に、
文字セット、コンテントタイプ、言語、エンコーディングを
指定するための mod_mime
で認識できる拡張子を持たないファイルが見つかると、結果は
MultiViewsMatch
ディレクティブの設定に依存します。このディレクティブは
ハンドラ、フィルタ、他のファイル拡張子タイプのどれが
MultiViews ネゴシエーションで使用できるかを決定します。
Apache はリソースの variant の一覧を、タイプマップファイルか ディレクトリ内のファイル名からかで取得した後、 「最適な」 variant を決定するために二つの方法の どちらかを起動します。 Apache のコンテントネゴシエーションの機能を使うために、 どのようにしてこの調停が行われるか詳細を知る必要はありません。 しかしながら、この文書の残りでは関心のある人のために、 使用されている方法について説明しています。
ネゴシエーション方法は二つあります。
| 次元 | 説明 |
|---|---|
| メディアタイプ | ブラウザは Accept
ヘッダフィールドで優先傾向を指定します。
アイテムそれぞれは、関連した品質数値を持つことができます。
variant の説明も品質数値を持つことができます
("qs" パラメータをご覧下さい)。 |
| 言語 | ブラウザは Accept-Language
ヘッダフィールドで優先傾向を指定します。
要素それぞれに品質数値を持たせることができます。
variants は 0 か 1 つかそれ以上の言語と
関連づけることができます。 |
| エンコーディング | ブラウザは Accept-Encoding
ヘッダフィールドで優先傾向を指定します。
要素それぞれに品質数値を持たせることができます。 |
| 文字セット | ブラウザは Accept-Charset
ヘッダフィールドで優先傾向を指定します。
要素それぞれに品質数値を持たせることができます。
variant はメディアタイプのパラメータとして文字セットを
指定することもできます。 |
ブラウザに返す「最適な」variant を (もしあれば) 選択するように Apache は次のアルゴリズムを使うことができます。 このアルゴリズムを設定により変更することはできません。 次のように動作します:
Accept
ヘッダの品質数値との積を計算して、最高値の variant
を選びます。Accept-Language ヘッダの言語順か、
(もしあれば)
LanguagePriority
ディレクティブの言語順で最適な言語の variant を選びます。Accept-Charset ヘッダ行で与えられている最高の文字セット
メディアパラメータを持つ variant を選びます。
明示的に除外されていない限り、ISO-8859-1
が許容されるようになっています。
text/* メディアタイプであるけれども
特定の文字セットに明示的に関連づけられているわけではない
variant は ISO-8859-1 であると仮定されます。Vary が設定されます
(リソースのキャッシュをする時に、
ブラウザやキャッシュはこの情報を使うことができます)。
以上で終わり。Vary ヘッダも設定されます。上記の Apache ネゴシエーションアルゴリズムの厳格な解釈で
得られるであろう値から、Apache は品質数値を時々変えます。
これは、このアルゴリズムで完全ではない、あるいは正確でない情報を送る
ブラウザ向けによりよい結果を得るために行われます。
かなりポピュラーなブラウザで、もしないと間違った variant
を選択する結果になってしまうような Accept
ヘッダ情報を送るものもあります。
ブラウザが完全で正しい情報を送っていれば、
この数値変化は適用されません。
Accept: リクエストヘッダはメディアタイプの優先傾向を指定します。
これはまた、"image/*" や "*/*"
といった「ワイルドカード」メディアタイプを含むことができます。
ここで * は任意の文字列にマッチします。
ですから、次の:
Accept: image/*, */*
を含むリクエストは、"image/" ではじまるタイプ全てが許容できる、 そして他のどんなタイプも許容できる (この場合はじめの "image/*" は冗長になります) ことを示します。 扱うことのできる明示的なタイプに加えて、機械的に ワイルドカードを送るブラウザもあります。例えば:
Accept: text/html, text/plain, image/gif, image/jpeg, */*
こうすることの狙いは、明示的にリストしているタイプが優先されるけれども、 異なる表現が利用可能であればそれでも良い、ということです。 しかしながら、上の基本的なアルゴリズムでは、 */* ワイルドカードは他の全てのタイプと全く同等なので優先されません。 ブラウザは */* にもっと低い品質 (優先) 値を付けてリクエストを送るべきなのです。例えば:
Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
明示的なタイプには品質数値が付けられていませんので、 デフォルトの 1.0 (最高値) の優先になります。 ワイルドカード */* は低い優先度 0.01 を与えられているので、 明示的にリストされているタイプに合致する variant がない場合にのみ、 他のタイプが返されます。
もし Accept: ヘッダが q 値を全く含んでいなければ、
望みの挙動をするために、
Apache は "*/*" があれば 0.01 の q 値を設定します。
また、"type/*" の形のワイルドカードには 0.02 の q 値を設定します
(ですからこれらは "*/*" のマッチよりも優先されます)。
もし Accept: ヘッダ中のメディアタイプのどれかが q
値を含んでいれば、これらの特殊な値は適応されず、
正しい情報を送るブラウザからのリクエストは期待通りに
動作するようになります。
Apache 2.0 では新たに、言語ネゴシエーションが適合するものを 見つけるのに失敗した時に、優雅にフォールバックできるような ネゴシエーションアルゴリズムが幾つか追加されました。
サーバのページをクライアントがリクエストしたけれども、
ブラウザの送ってきた Accept-Language に合致するページが一つも
見つからなかった場合に、サーバは "No Acceptable Variant"
か "Multiple Choices" レスポンスをクライアントに返します。
これらのエラーメッセージを返さないように、
このような場合には Apache が Accept-Language を無視して、
クライアントのリクエストに明示的には合致しないドキュメントを
提供するように設定できます。
ForceLanguagePriority
ディレクティブは、これらのエラーの一つか両方をオーバーライドするために
使用できて、
LanguagePriority
ディレクティブの内容を使ってサーバの判断を代行するようにできます。
サーバは他に適合するものが見つからなければ、
言語サブセットで適合するものを試そうともします。
例えばクライアントが英国英語である en-GB 言語で
ドキュメントをリクエストした場合、サーバは HTTP/1.1
規格では、単に en とマークされているドキュメントを
マッチするものとすることは通常は許されていません。
(英国英語は理解できるけど一般的な英語は理解できないという読み手は
考えられないので、Accept-Language ヘッダで en-GB
を含んで en を含まないのはほぼ確実に設定の間違いである、
ということに注意してください。
ですが不幸なことに、多くのクライアントではデフォルトで
このような設定になっています。)
しかしながら、他の言語にはマッチせず、"No Acceptable Variants"
エラーを返したり、
LanguagePriority
にフォールバックしようとしているときは、
サブセット指定を無視して、en-GB を en
にマッチします。
Apache はクライアントの許容言語リストに暗黙に
非常に低い品質値の親言語を加えることになります。
しかし、クライアントが "en-GB; q=0.9, fr; q=0.8" とリクエストして、
サーバが "en" と "fr" と設計されたドキュメントを持っている場合は、
"fr" ドキュメントが返されることに注意してください。
このような処理は、HTTP 1.1 規格との整合性を維持して、
適切に設定されたクライアントともきちんと動作するために
必要です。
より高度なテクニック (Cookie や特殊な URL パス等)
においてもユーザの言語選択をサポートするため、
Apache 2.0.47 からは、mod_negotiation
が環境変数 prefer-language
を認識するようになりました。
この変数が存在して、適切な言語タグが代入されているのであれば、
mod_negotiation は合致する variant
を選択しようとします。合致するものが無ければ、
通常のネゴシエーション手順が適用されます。
SetEnvIf Cookie "language=en" prefer-language=en
SetEnvIf Cookie "language=fr" prefer-language=fr
Apache は transparent content negotiation プロトコル
(RFC 2295) を次のように拡張しています。
特定のコンテントエンコーディングのみが利用可能である variant
に印を付けるために、新たに {encoding ..}
要素を variant リスト中に使っています。
リスト中のエンコードされた variant を認識し、
Accept-Encoding リクエストヘッダに従って許容される
エンコードをもった variant は、どれでも候補 variant
として使用するように、
RVSA/1.0 アルゴリズム (RFC 2296) の実装が拡張されました。
RVSA/1.0 の実装では、最適な variant が見つかるまで、
計算した品質数値は小数点以下 5 桁まで丸めません。
言語ネゴシエーションを使っている場合は、 ファイルが一つ以上の拡張子を持てて、 拡張子の順番は通常は考慮されない (詳細は mod_mime を参照) ので、 幾つかの異なる名前の変換を選べることになります。
典型的なファイルでは、MIME タイプ拡張子 (例えば
html) を持っていて、エンコーディング拡張子
(例えば gz) を持っているかもしれなくて、
このファイルに異なる言語 variant を用意していれば、
もちろん言語拡張子 (例えば en)
を持っているでしょう。
例:
ファイル名と、それに対して使えるリンクと使えないリンクの例です:
| ファイル名 | 使えるリンク | 使えないリンク |
|---|---|---|
| foo.html.en | foo foo.html |
- |
| foo.en.html | foo | foo.html |
| foo.html.en.gz | foo foo.html |
foo.gz foo.html.gz |
| foo.en.html.gz | foo | foo.html foo.html.gz foo.gz |
| foo.gz.html.en | foo foo.gz foo.gz.html |
foo.html |
| foo.html.gz.en | foo foo.html foo.html.gz |
foo.gz |
上の表を見て、拡張子なしのリンク (例えば foo)
がいつでも使えることに気が付くでしょう。
この利点は、ドキュメントとして応答するファイルの
実際のファイルタイプを隠蔽して、リンクの参照を変更することなく
後からファイルを変更できる、
例えば html から shtml
に、あるいは cgi に変更できる点です。
リンクに MIME タイプを使い続けたい (例えば
foo.html)時は、言語拡張子は
(エンコーディング拡張子もあればそれも含めて)
MIME タイプ拡張子の右側になければなりません
(例えば foo.html.en)。
キャッシュが一つの表現を保存しているときは、 リクエスト URL と関連づけられています。 次にその URL がリクエストされた時に、キャッシュは 保存されている表現を使用できます。しかし、 リソースがサーバでネゴシエーション可能であれば、 最初のリクエストでキャッシュされて続くキャッシュヒットでは 間違った応答を返してしまうということになりかねません。 これを防ぐために、Apache はコンテントネゴシエーションの 後に返された応答全てに、HTTP/1.0 クライアントでは キャッシュ不可能の印をつけます。 また、ネゴシエーションされた応答のキャッシュを可能にする HTTP/1.1 プロトコルの機能も Apache はサポートします。
HTTP/1.0 準拠のクライアントからのリクエストに対しては、
(ブラウザであろうとキャッシュであろうと)
ネゴシエーションを受けた応答のキャッシュを許すために、
CacheNegotiatedDocs
ディレクティブを使用できます。
このディレクティブは、サーバ設定ファイルやバーチャルホストに書くことができ、
引数をとりません。
HTTP/1.1 クライアントからのリクエストには効力を持ちません。
コンテントネゴシエーションに関する追加情報は、 Alan J. Flavell さんのLanguage Negotiation Notes をご覧下さい。ですが、 Apache 2.0 での変更点を含むためには更新されていないかもしれない ということに注意してください。
Apache HTTP サーバ バージョン 2.0
ウェブマスターが何らかのエラーや問題に対する Apache の反応を設定できるようにする追加機能を提供します。
サーバがエラーや問題を発見した場合の反応を、 カスタマイズして定義することができます。
スクリプトの実行が失敗して "500 Server Error" を発生させたとします。この場合の反応を、より好ましいテキストや、別の URL (内部及び外部) へのリダイレクションに置き換えることができます。
NCSA httpd 1.3 は、古くて退屈なエラー/問題メッセージを 返していました。それはしばしばユーザには無意味であり、 またそれを発生させた原因を記録する方法も提供していませんでした。
するようにサーバを設定できます。
別の URL にリダイレクトすることは役に立ちますが、 それは説明をしたり、より明確に誤り/問題を記録したりするために 何か情報を伝えられるときに限ります。
これを実現するために、 Apache は新しく CGI のような環境変数を 定義します:
REDIRECT_HTTP_ACCEPT=*/*, image/gif,
image/x-xbitmap, image/jpeg
REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX
A.09.05 9000/712)
REDIRECT_PATH=.:/bin:/usr/local/bin:/etc
REDIRECT_QUERY_STRING=
REDIRECT_REMOTE_ADDR=121.345.78.123
REDIRECT_REMOTE_HOST=ooh.ahhh.com
REDIRECT_SERVER_NAME=crash.bang.edu
REDIRECT_SERVER_PORT=80
REDIRECT_SERVER_SOFTWARE=Apache/0.8.15
REDIRECT_URL=/cgi-bin/buggy.pl
頭に付く REDIRECT_ に注目してください。
少なくとも REDIRECT_URL と
REDIRECT_QUERY_STRING は新しい URL (CGI スクリプトか
CGI インクルードであると仮定されます) に渡されます。
他の変数は、エラーや問題が起きる前に存在した場合にだけ存在します。
もしあなたの設定した ErrorDocument が 外部リダイレクト
(すなわち、http:
のような体系名から始まるすべてのもの。たとえ同じホストを指していても)
ならば、これらはまったく設定されません。
AllowOverride が適切に設定されていれば、
.htaccess ファイルで ErrorDocument
を使用することができます。
ここに、いくつかの例を挙げます。
ErrorDocument 500 /cgi-bin/crash-recover
ErrorDocument 500 "Sorry, our script crashed. Oh dear"
ErrorDocument 500 http://xxx/
ErrorDocument 404 /Lame_excuses/not_found.html
ErrorDocument 401 /Subscription/how_to_subscribe.html
構文
ErrorDocument <3-digit-code> <action>
action (動作) は、
スクリプト/SSI に追加の環境変数が利用可能になるように、 リダイレクトされた URL に対する Apache の動作が変更されました。
リダイレクトされたスクリプトは標準の CGI 環境変数を利用可能でした。しかし、どこからリダイレクト されたかの情報は提供されていませんでした。
リダイレクトされた先のスクリプトが使用可能なように、
新しいたくさんの環境変数が初期化されます。新しい変数は、それぞれ
REDIRECT_ で始まります。
REDIRECT_ で始まる環境変数はリダイレクトされる前に存在していた
CGI 環境変数の頭に REDIRECT_ を付けて作成されます。
すなわち、HTTP_USER_AGENT は
REDIRECT_HTTP_USER_AGENT になります。
これらの新しい変数に加えて、Apache は、
スクリプトがリダイレクト元のトレースを助けるために
REDIRECT_URL と REDIRECT_STATUS
を定義します。アクセスログには元の URL とリダイレクトされた URL
の両方が記録されます。
ErrorDocument が CGI スクリプトへのローカルリダイレクトを
指定している場合は、それを起動することになったエラーの状態を
クライアントまで確実に伝えるために "Status:"
ヘッダを含むべきです。例えば、ErrorDocument 用の Perl
スクリプトは以下のようなものを含むかもしれません。
...
print "Content-type: text/html\n";
printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
...
スクリプトが 404 Not Found のような
特定のエラーコンディションを扱うためだけに使われる場合は、
代わりに特定のコードとエラーテキストを使用することができます。
Apache HTTP Server Version 2.0
This document has not been updated to take into account changes made in the 2.0 version of the Apache HTTP Server. Some of the information may still be relevant, but please use it with care.
These are some notes on the Apache API and the data structures you have to deal with, etc. They are not yet nearly complete, but hopefully, they will help you get your bearings. Keep in mind that the API is still subject to change as we gain experience with it. (See the TODO file for what might be coming). However, it will be easy to adapt modules to any changes that are made. (We have more modules to adapt than you do).
A few notes on general pedagogical style here. In the interest of conciseness, all structure declarations here are incomplete -- the real ones have more slots that I'm not telling you about. For the most part, these are reserved to one component of the server core or another, and should be altered by modules with caution. However, in some cases, they really are things I just haven't gotten around to yet. Welcome to the bleeding edge.
Finally, here's an outline, to give you some bare idea of what's coming up, and in what order:
We begin with an overview of the basic concepts behind the API, and how they are manifested in the code.
Apache breaks down request handling into a series of steps, more or less the same way the Netscape server API does (although this API has a few more stages than NetSite does, as hooks for stuff I thought might be useful in the future). These are:
SetEnv, which don't really fit well elsewhere.These phases are handled by looking at each of a succession of modules, looking to see if each of them has a handler for the phase, and attempting invoking it if so. The handler can typically do one of three things:
OK.DECLINED. In this case, the server behaves in all
respects as if the handler simply hadn't been there.Most phases are terminated by the first module that handles them;
however, for logging, `fixups', and non-access authentication checking,
all handlers always run (barring an error). Also, the response phase is
unique in that modules may declare multiple handlers for it, via a
dispatch table keyed on the MIME type of the requested object. Modules may
declare a response-phase handler which can handle any request,
by giving it the key */* (i.e., a wildcard MIME type
specification). However, wildcard handlers are only invoked if the server
has already tried and failed to find a more specific response handler for
the MIME type of the requested object (either none existed, or they all
declined).
The handlers themselves are functions of one argument (a
request_rec structure. vide infra), which returns an integer,
as above.
At this point, we need to explain the structure of a module. Our
candidate will be one of the messier ones, the CGI module -- this handles
both CGI scripts and the ScriptAlias config file command. It's actually a great deal
more complicated than most modules, but if we're going to have only one
example, it might as well be the one with its fingers in every place.
Let's begin with handlers. In order to handle the CGI scripts, the
module declares a response handler for them. Because of ScriptAlias, it also has handlers for the
name translation phase (to recognize ScriptAliased URIs), the type-checking phase (any
ScriptAliased request is typed
as a CGI script).
The module needs to maintain some per (virtual) server information,
namely, the ScriptAliases in
effect; the module structure therefore contains pointers to a functions
which builds these structures, and to another which combines two of them
(in case the main server and a virtual server both have ScriptAliases declared).
Finally, this module contains code to handle the ScriptAlias command itself. This particular
module only declares one command, but there could be more, so modules have
command tables which declare their commands, and describe where
they are permitted, and how they are to be invoked.
A final note on the declared types of the arguments of some of these
commands: a pool is a pointer to a resource pool
structure; these are used by the server to keep track of the memory which
has been allocated, files opened, etc., either to service a
particular request, or to handle the process of configuring itself. That
way, when the request is over (or, for the configuration pool, when the
server is restarting), the memory can be freed, and the files closed,
en masse, without anyone having to write explicit code to track
them all down and dispose of them. Also, a cmd_parms
structure contains various information about the config file being read,
and other status information, which is sometimes of use to the function
which processes a config-file command (such as ScriptAlias). With no further ado, the
module itself:
/* Declarations of handlers. */
int translate_scriptalias (request_rec *);
int type_scriptalias (request_rec *);
int cgi_handler (request_rec *);
/* Subsidiary dispatch table for response-phase
* handlers, by MIME type */
handler_rec cgi_handlers[] = {
{ "application/x-httpd-cgi", cgi_handler },
{ NULL }
};
/* Declarations of routines to manipulate the
* module's configuration info. Note that these are
* returned, and passed in, as void *'s; the server
* core keeps track of them, but it doesn't, and can't,
* know their internal structure.
*/
void *make_cgi_server_config (pool *);
void *merge_cgi_server_config (pool *, void *, void *);
/* Declarations of routines to handle config-file commands */
extern char *script_alias(cmd_parms *, void *per_dir_config, char *fake,
char *real);
command_rec cgi_cmds[] = {
{ "ScriptAlias", script_alias, NULL, RSRC_CONF, TAKE2,
"a fakename and a realname"},
{ NULL }
};
module cgi_module = {
STANDARD_MODULE_STUFF, NULL, /* initializer */ NULL, /* dir config creator */ NULL, /* dir merger */ make_cgi_server_config, /* server config */ merge_cgi_server_config, /* merge server config */ cgi_cmds, /* command table */ cgi_handlers, /* handlers */ translate_scriptalias, /* filename translation */ NULL, /* check_user_id */ NULL, /* check auth */ NULL, /* check access */ type_scriptalias, /* type_checker */ NULL, /* fixups */ NULL, /* logger */ NULL /* header parser */ };
The sole argument to handlers is a request_rec structure.
This structure describes a particular request which has been made to the
server, on behalf of a client. In most cases, each connection to the
client generates only one request_rec structure.
The request_rec contains pointers to a resource pool
which will be cleared when the server is finished handling the request;
to structures containing per-server and per-connection information, and
most importantly, information on the request itself.
The most important such information is a small set of character strings describing attributes of the object being requested, including its URI, filename, content-type and content-encoding (these being filled in by the translation and type-check handlers which handle the request, respectively).
Other commonly used data items are tables giving the MIME headers on
the client's original request, MIME headers to be sent back with the
response (which modules can add to at will), and environment variables for
any subprocesses which are spawned off in the course of servicing the
request. These tables are manipulated using the ap_table_get
and ap_table_set routines.
Note that the Content-type header value cannot
be set by module content-handlers using the ap_table_*()
routines. Rather, it is set by pointing the content_type
field in the request_rec structure to an appropriate
string. e.g.,
r->content_type = "text/html";
Finally, there are pointers to two data structures which, in turn,
point to per-module configuration structures. Specifically, these hold
pointers to the data structures which the module has built to describe
the way it has been configured to operate in a given directory (via
.htaccess files or <Directory> sections), for private data it has built in the
course of servicing the request (so modules' handlers for one phase can
pass `notes' to their handlers for other phases). There is another such
configuration vector in the server_rec data structure pointed
to by the request_rec, which contains per (virtual) server
configuration data.
Here is an abridged declaration, giving the fields most commonly used:
struct request_rec {
pool *pool;
conn_rec *connection;
server_rec *server;
/* What object is being requested */
char *uri;
char *filename;
char *path_info;
char *args; /* QUERY_ARGS, if any */
struct stat finfo; /* Set by server core;
* st_mode set to zero if no such file */
char *content_type;
char *content_encoding;
/* MIME header environments, in and out. Also,
* an array containing environment variables to
* be passed to subprocesses, so people can write
* modules to add to that environment.
*
* The difference between headers_out and
* err_headers_out is that the latter are printed
* even on error, and persist across internal
* redirects (so the headers printed for
* ErrorDocument handlers will have
them).
*/
table *headers_in;
table *headers_out;
table *err_headers_out;
table *subprocess_env;
/* Info about the request itself... */
int header_only; /* HEAD request, as opposed to GET */ char *protocol; /* Protocol, as given to us, or HTTP/0.9 */ char *method; /* GET, HEAD, POST, etc. */ int method_number; /* M_GET, M_POST, etc. */
/* Info for logging */
char *the_request;
int bytes_sent;
/* A flag which modules can set, to indicate that
* the data being returned is volatile, and clients
* should be told not to cache it.
*/
int no_cache;
/* Various other config info which may change
* with .htaccess files
* These are config vectors, with one void*
* pointer for each module (the thing pointed
* to being the module's business).
*/
void *per_dir_config; /* Options set in config files, etc. */ void *request_config; /* Notes on *this* request */
};
Most request_rec structures are built by reading an HTTP
request from a client, and filling in the fields. However, there are a
few exceptions:
*.var file), or a CGI script which returned a local
`Location:', then the resource which the user requested is going to be
ultimately located by some URI other than what the client originally
supplied. In this case, the server does an internal redirect,
constructing a new request_rec for the new URI, and
processing it almost exactly as if the client had requested the new URI
directly.ErrorDocument
is in scope, the same internal redirect machinery comes into play.Finally, a handler occasionally needs to investigate `what would happen if' some other request were run. For instance, the directory indexing module needs to know what MIME type would be assigned to a request for each directory entry, in order to figure out what icon to use.
Such handlers can construct a sub-request, using the
functions ap_sub_req_lookup_file,
ap_sub_req_lookup_uri, and ap_sub_req_method_uri;
these construct a new request_rec structure and processes it
as you would expect, up to but not including the point of actually sending
a response. (These functions skip over the access checks if the
sub-request is for a file in the same directory as the original
request).
(Server-side includes work by building sub-requests and then actually
invoking the response handler for them, via the function
ap_run_sub_req).
As discussed above, each handler, when invoked to handle a particular
request_rec, has to return an int to indicate
what happened. That can either be
OK -- the request was handled successfully. This may or
may not terminate the phase.DECLINED -- no erroneous condition exists, but the module
declines to handle the phase; the server tries to find another.Note that if the error code returned is REDIRECT, then
the module should put a Location in the request's
headers_out, to indicate where the client should be
redirected to.
Handlers for most phases do their work by simply setting a few fields
in the request_rec structure (or, in the case of access
checkers, simply by returning the correct error code). However, response
handlers have to actually send a request back to the client.
They should begin by sending an HTTP response header, using the
function ap_send_http_header. (You don't have to do anything
special to skip sending the header for HTTP/0.9 requests; the function
figures out on its own that it shouldn't do anything). If the request is
marked header_only, that's all they should do; they should
return after that, without attempting any further output.
Otherwise, they should produce a request body which responds to the
client as appropriate. The primitives for this are ap_rputc
and ap_rprintf, for internally generated output, and
ap_send_fd, to copy the contents of some FILE *
straight to the client.
At this point, you should more or less understand the following piece
of code, which is the handler which handles GET requests
which have no more specific handler; it also shows how conditional
GETs can be handled, if it's desirable to do so in a
particular response handler -- ap_set_last_modified checks
against the If-modified-since value supplied by the client,
if any, and returns an appropriate code (which will, if nonzero, be
USE_LOCAL_COPY). No similar considerations apply for
ap_set_content_length, but it returns an error code for
symmetry.
int default_handler (request_rec *r)
{
int errstatus;
FILE *f;
if (r->method_number != M_GET) return DECLINED;
if (r->finfo.st_mode == 0) return NOT_FOUND;
if ((errstatus = ap_set_content_length (r, r->finfo.st_size))
||
(errstatus = ap_set_last_modified (r, r->finfo.st_mtime)))
return errstatus;
f = fopen (r->filename, "r");
if (f == NULL) {
log_reason("file permissions deny server access", r->filename, r);
return FORBIDDEN;
}
register_timeout ("send", r);
ap_send_http_header (r);
if (!r->header_only) send_fd (f, r);
ap_pfclose (r->pool, f);
return OK;
}
Finally, if all of this is too much of a challenge, there are a few
ways out of it. First off, as shown above, a response handler which has
not yet produced any output can simply return an error code, in which
case the server will automatically produce an error response. Secondly,
it can punt to some other handler by invoking
ap_internal_redirect, which is how the internal redirection
machinery discussed above is invoked. A response handler which has
internally redirected should always return OK.
(Invoking ap_internal_redirect from handlers which are
not response handlers will lead to serious confusion).
Stuff that should be discussed here in detail:
ap_auth_type,
ap_auth_name, and ap_requires.ap_get_basic_auth_pw, which sets the
connection->user structure field
automatically, and ap_note_basic_auth_failure,
which arranges for the proper WWW-Authenticate:
header to be sent back).When a request has internally redirected, there is the question of
what to log. Apache handles this by bundling the entire chain of redirects
into a list of request_rec structures which are threaded
through the r->prev and r->next pointers.
The request_rec which is passed to the logging handlers in
such cases is the one which was originally built for the initial request
from the client; note that the bytes_sent field will only be
correct in the last request in the chain (the one for which a response was
actually sent).
One of the problems of writing and designing a server-pool server is that of preventing leakage, that is, allocating resources (memory, open files, etc.), without subsequently releasing them. The resource pool machinery is designed to make it easy to prevent this from happening, by allowing resource to be allocated in such a way that they are automatically released when the server is done with them.
The way this works is as follows: the memory which is allocated, file opened, etc., to deal with a particular request are tied to a resource pool which is allocated for the request. The pool is a data structure which itself tracks the resources in question.
When the request has been processed, the pool is cleared. At that point, all the memory associated with it is released for reuse, all files associated with it are closed, and any other clean-up functions which are associated with the pool are run. When this is over, we can be confident that all the resource tied to the pool have been released, and that none of them have leaked.
Server restarts, and allocation of memory and resources for per-server configuration, are handled in a similar way. There is a configuration pool, which keeps track of resources which were allocated while reading the server configuration files, and handling the commands therein (for instance, the memory that was allocated for per-server module configuration, log files and other files that were opened, and so forth). When the server restarts, and has to reread the configuration files, the configuration pool is cleared, and so the memory and file descriptors which were taken up by reading them the last time are made available for reuse.
It should be noted that use of the pool machinery isn't generally
obligatory, except for situations like logging handlers, where you really
need to register cleanups to make sure that the log file gets closed when
the server restarts (this is most easily done by using the function ap_pfopen, which also arranges for the
underlying file descriptor to be closed before any child processes, such as
for CGI scripts, are execed), or in case you are using the
timeout machinery (which isn't yet even documented here). However, there are
two benefits to using it: resources allocated to a pool never leak (even if
you allocate a scratch string, and just forget about it); also, for memory
allocation, ap_palloc is generally faster than
malloc.
We begin here by describing how memory is allocated to pools, and then discuss how other resources are tracked by the resource pool machinery.
Memory is allocated to pools by calling the function
ap_palloc, which takes two arguments, one being a pointer to
a resource pool structure, and the other being the amount of memory to
allocate (in chars). Within handlers for handling requests,
the most common way of getting a resource pool structure is by looking at
the pool slot of the relevant request_rec; hence
the repeated appearance of the following idiom in module code:
int my_handler(request_rec *r)
{
struct my_structure *foo;
...
foo = (foo *)ap_palloc (r->pool, sizeof(my_structure));
}
Note that there is no ap_pfree --
ap_palloced memory is freed only when the associated resource
pool is cleared. This means that ap_palloc does not have to
do as much accounting as malloc(); all it does in the typical
case is to round up the size, bump a pointer, and do a range check.
(It also raises the possibility that heavy use of
ap_palloc could cause a server process to grow excessively
large. There are two ways to deal with this, which are dealt with below;
briefly, you can use malloc, and try to be sure that all of
the memory gets explicitly freed, or you can allocate a
sub-pool of the main pool, allocate your memory in the sub-pool, and clear
it out periodically. The latter technique is discussed in the section
on sub-pools below, and is used in the directory-indexing code, in order
to avoid excessive storage allocation when listing directories with
thousands of files).
There are functions which allocate initialized memory, and are
frequently useful. The function ap_pcalloc has the same
interface as ap_palloc, but clears out the memory it
allocates before it returns it. The function ap_pstrdup
takes a resource pool and a char * as arguments, and
allocates memory for a copy of the string the pointer points to, returning
a pointer to the copy. Finally ap_pstrcat is a varargs-style
function, which takes a pointer to a resource pool, and at least two
char * arguments, the last of which must be
NULL. It allocates enough memory to fit copies of each of
the strings, as a unit; for instance:
ap_pstrcat (r->pool, "foo", "/", "bar", NULL);
returns a pointer to 8 bytes worth of memory, initialized to
"foo/bar".
A pool is really defined by its lifetime more than anything else. There are some static pools in http_main which are passed to various non-http_main functions as arguments at opportune times. Here they are:
permanent_poolpconfptemppchildptransr->poolFor almost everything folks do, r->pool is the pool to
use. But you can see how other lifetimes, such as pchild, are useful to
some modules... such as modules that need to open a database connection
once per child, and wish to clean it up when the child dies.
You can also see how some bugs have manifested themself, such as
setting connection->user to a value from
r->pool -- in this case connection exists for the
lifetime of ptrans, which is longer than
r->pool (especially if r->pool is a
subrequest!). So the correct thing to do is to allocate from
connection->pool.
And there was another interesting bug in mod_include
/ mod_cgi. You'll see in those that they do this test
to decide if they should use r->pool or
r->main->pool. In this case the resource that they are
registering for cleanup is a child process. If it were registered in
r->pool, then the code would wait() for the
child when the subrequest finishes. With mod_include this
could be any old #include, and the delay can be up to 3
seconds... and happened quite frequently. Instead the subprocess is
registered in r->main->pool which causes it to be
cleaned up when the entire request is done -- i.e., after the
output has been sent to the client and logging has happened.
As indicated above, resource pools are also used to track other sorts
of resources besides memory. The most common are open files. The routine
which is typically used for this is ap_pfopen, which takes a
resource pool and two strings as arguments; the strings are the same as
the typical arguments to fopen, e.g.,
...
FILE *f = ap_pfopen (r->pool, r->filename, "r");
if (f == NULL) { ... } else { ... }
There is also a ap_popenf routine, which parallels the
lower-level open system call. Both of these routines arrange
for the file to be closed when the resource pool in question is
cleared.
Unlike the case for memory, there are functions to close files
allocated with ap_pfopen, and ap_popenf, namely
ap_pfclose and ap_pclosef. (This is because, on
many systems, the number of files which a single process can have open is
quite limited). It is important to use these functions to close files
allocated with ap_pfopen and ap_popenf, since to
do otherwise could cause fatal errors on systems such as Linux, which
react badly if the same FILE* is closed more than once.
(Using the close functions is not mandatory, since the
file will eventually be closed regardless, but you should consider it in
cases where your module is opening, or could open, a lot of files).
More text goes here. Describe the cleanup primitives in terms of
which the file stuff is implemented; also, spawn_process.
Pool cleanups live until clear_pool() is called:
clear_pool(a) recursively calls destroy_pool()
on all subpools of a; then calls all the cleanups for
a; then releases all the memory for a.
destroy_pool(a) calls clear_pool(a) and then
releases the pool structure itself. i.e.,
clear_pool(a) doesn't delete a, it just frees
up all the resources and you can start using it again immediately.
On rare occasions, too-free use of ap_palloc() and the
associated primitives may result in undesirably profligate resource
allocation. You can deal with such a case by creating a sub-pool,
allocating within the sub-pool rather than the main pool, and clearing or
destroying the sub-pool, which releases the resources which were
associated with it. (This really is a rare situation; the only
case in which it comes up in the standard module set is in case of listing
directories, and then only with very large directories.
Unnecessary use of the primitives discussed here can hair up your code
quite a bit, with very little gain).
The primitive for creating a sub-pool is ap_make_sub_pool,
which takes another pool (the parent pool) as an argument. When the main
pool is cleared, the sub-pool will be destroyed. The sub-pool may also be
cleared or destroyed at any time, by calling the functions
ap_clear_pool and ap_destroy_pool, respectively.
(The difference is that ap_clear_pool frees resources
associated with the pool, while ap_destroy_pool also
deallocates the pool itself. In the former case, you can allocate new
resources within the pool, and clear it again, and so forth; in the
latter case, it is simply gone).
One final note -- sub-requests have their own resource pools, which are
sub-pools of the resource pool for the main request. The polite way to
reclaim the resources associated with a sub request which you have
allocated (using the ap_sub_req_... functions) is
ap_destroy_sub_req, which frees the resource pool. Before
calling this function, be sure to copy anything that you care about which
might be allocated in the sub-request's resource pool into someplace a
little less volatile (for instance, the filename in its
request_rec structure).
(Again, under most circumstances, you shouldn't feel obliged to call
this function; only 2K of memory or so are allocated for a typical sub
request, and it will be freed anyway when the main request pool is
cleared. It is only when you are allocating many, many sub-requests for a
single main request that you should seriously consider the
ap_destroy_... functions).
One of the design goals for this server was to maintain external compatibility with the NCSA 1.3 server --- that is, to read the same configuration files, to process all the directives therein correctly, and in general to be a drop-in replacement for NCSA. On the other hand, another design goal was to move as much of the server's functionality into modules which have as little as possible to do with the monolithic server core. The only way to reconcile these goals is to move the handling of most commands from the central server into the modules.
However, just giving the modules command tables is not enough to divorce
them completely from the server core. The server has to remember the
commands in order to act on them later. That involves maintaining data which
is private to the modules, and which can be either per-server, or
per-directory. Most things are per-directory, including in particular access
control and authorization information, but also information on how to
determine file types from suffixes, which can be modified by
AddType and DefaultType directives, and so forth. In general,
the governing philosophy is that anything which can be made
configurable by directory should be; per-server information is generally
used in the standard set of modules for information like
Aliases and Redirects which come into play before the
request is tied to a particular place in the underlying file system.
Another requirement for emulating the NCSA server is being able to handle
the per-directory configuration files, generally called
.htaccess files, though even in the NCSA server they can
contain directives which have nothing at all to do with access control.
Accordingly, after URI -> filename translation, but before performing any
other phase, the server walks down the directory hierarchy of the underlying
filesystem, following the translated pathname, to read any
.htaccess files which might be present. The information which
is read in then has to be merged with the applicable information
from the server's own config files (either from the <Directory> sections in
access.conf, or from defaults in srm.conf, which
actually behaves for most purposes almost exactly like <Directory
/>).
Finally, after having served a request which involved reading
.htaccess files, we need to discard the storage allocated for
handling them. That is solved the same way it is solved wherever else
similar problems come up, by tying those structures to the per-transaction
resource pool.
Let's look out how all of this plays out in mod_mime.c,
which defines the file typing handler which emulates the NCSA server's
behavior of determining file types from suffixes. What we'll be looking
at, here, is the code which implements the AddType and AddEncoding commands. These commands can appear in
.htaccess files, so they must be handled in the module's
private per-directory data, which in fact, consists of two separate
tables for MIME types and encoding information, and is declared as
follows:
typedef struct {
table *forced_types; /* Additional AddTyped stuff */
table *encoding_types; /* Added with AddEncoding... */
} mime_dir_config;When the server is reading a configuration file, or <Directory> section, which includes
one of the MIME module's commands, it needs to create a
mime_dir_config structure, so those commands have something
to act on. It does this by invoking the function it finds in the module's
`create per-dir config slot', with two arguments: the name of the
directory to which this configuration information applies (or
NULL for srm.conf), and a pointer to a
resource pool in which the allocation should happen.
(If we are reading a .htaccess file, that resource pool
is the per-request resource pool for the request; otherwise it is a
resource pool which is used for configuration data, and cleared on
restarts. Either way, it is important for the structure being created to
vanish when the pool is cleared, by registering a cleanup on the pool if
necessary).
For the MIME module, the per-dir config creation function just
ap_pallocs the structure above, and a creates a couple of
tables to fill it. That looks like this:
void *create_mime_dir_config (pool *p, char *dummy)
{
mime_dir_config *new =
(mime_dir_config *) ap_palloc (p, sizeof(mime_dir_config));
new->forced_types = ap_make_table (p, 4);
new->encoding_types = ap_make_table (p, 4);
return new;
}
Now, suppose we've just read in a .htaccess file. We
already have the per-directory configuration structure for the next
directory up in the hierarchy. If the .htaccess file we just
read in didn't have any AddType
or AddEncoding commands, its
per-directory config structure for the MIME module is still valid, and we
can just use it. Otherwise, we need to merge the two structures
somehow.
To do that, the server invokes the module's per-directory config merge function, if one is present. That function takes three arguments: the two structures being merged, and a resource pool in which to allocate the result. For the MIME module, all that needs to be done is overlay the tables from the new per-directory config structure with those from the parent:
void *merge_mime_dir_configs (pool *p, void *parent_dirv, void *subdirv)
{
mime_dir_config *parent_dir = (mime_dir_config *)parent_dirv;
mime_dir_config *subdir = (mime_dir_config *)subdirv;
mime_dir_config *new =
(mime_dir_config *)ap_palloc (p, sizeof(mime_dir_config));
new->forced_types = ap_overlay_tables (p, subdir->forced_types,
parent_dir->forced_types);
new->encoding_types = ap_overlay_tables (p, subdir->encoding_types,
parent_dir->encoding_types);
return new;
}
As a note -- if there is no per-directory merge function present, the
server will just use the subdirectory's configuration info, and ignore
the parent's. For some modules, that works just fine (e.g., for
the includes module, whose per-directory configuration information
consists solely of the state of the XBITHACK), and for those
modules, you can just not declare one, and leave the corresponding
structure slot in the module itself NULL.
Now that we have these structures, we need to be able to figure out how
to fill them. That involves processing the actual AddType and AddEncoding commands. To find commands, the server looks in
the module's command table. That table contains information on how many
arguments the commands take, and in what formats, where it is permitted,
and so forth. That information is sufficient to allow the server to invoke
most command-handling functions with pre-parsed arguments. Without further
ado, let's look at the AddType
command handler, which looks like this (the AddEncoding command looks basically the same, and won't be
shown here):
char *add_type(cmd_parms *cmd, mime_dir_config *m, char *ct, char *ext)
{
if (*ext == '.') ++ext;
ap_table_set (m->forced_types, ext, ct);
return NULL;
}
This command handler is unusually simple. As you can see, it takes
four arguments, two of which are pre-parsed arguments, the third being the
per-directory configuration structure for the module in question, and the
fourth being a pointer to a cmd_parms structure. That
structure contains a bunch of arguments which are frequently of use to
some, but not all, commands, including a resource pool (from which memory
can be allocated, and to which cleanups should be tied), and the (virtual)
server being configured, from which the module's per-server configuration
data can be obtained if required.
Another way in which this particular command handler is unusually
simple is that there are no error conditions which it can encounter. If
there were, it could return an error message instead of NULL;
this causes an error to be printed out on the server's
stderr, followed by a quick exit, if it is in the main config
files; for a .htaccess file, the syntax error is logged in
the server error log (along with an indication of where it came from), and
the request is bounced with a server error response (HTTP error status,
code 500).
The MIME module's command table has entries for these commands, which look like this:
command_rec mime_cmds[] = {
{ "AddType", add_type, NULL, OR_FILEINFO, TAKE2,
"a mime type followed by a file extension" },
{ "AddEncoding", add_encoding, NULL, OR_FILEINFO, TAKE2,
"an encoding (e.g., gzip), followed by a file extension" },
{ NULL }
};
The entries in these tables are:
(void *) pointer, which is passed in the
cmd_parms structure to the command handler ---
this is useful in case many similar commands are handled by
the same function.AllowOverride option, and an additional mask
bit, RSRC_CONF, indicating that the command may
appear in the server's own config files, but not in
any .htaccess file.TAKE2 indicates two pre-parsed arguments. Other
options are TAKE1, which indicates one
pre-parsed argument, FLAG, which indicates that
the argument should be On or Off,
and is passed in as a boolean flag, RAW_ARGS,
which causes the server to give the command the raw, unparsed
arguments (everything but the command name itself). There is
also ITERATE, which means that the handler looks
the same as TAKE1, but that if multiple
arguments are present, it should be called multiple times,
and finally ITERATE2, which indicates that the
command handler looks like a TAKE2, but if more
arguments are present, then it should be called multiple
times, holding the first argument constant.NULL).Finally, having set this all up, we have to use it. This is ultimately
done in the module's handlers, specifically for its file-typing handler,
which looks more or less like this; note that the per-directory
configuration structure is extracted from the request_rec's
per-directory configuration vector by using the
ap_get_module_config function.
int find_ct(request_rec *r)
{
int i;
char *fn = ap_pstrdup (r->pool, r->filename);
mime_dir_config *conf = (mime_dir_config *)
ap_get_module_config(r->per_dir_config, &mime_module);
char *type;
if (S_ISDIR(r->finfo.st_mode)) {
r->content_type = DIR_MAGIC_TYPE;
return OK;
}
if((i=ap_rind(fn,'.')) < 0) return DECLINED;
++i;
if ((type = ap_table_get (conf->encoding_types, &fn[i])))
{
r->content_encoding = type;
/* go back to previous extension to try to use it as a type */
fn[i-1] = '\0';
if((i=ap_rind(fn,'.')) < 0) return OK;
++i;
}
if ((type = ap_table_get (conf->forced_types, &fn[i])))
{
r->content_type = type;
}
return OK;
}
The basic ideas behind per-server module configuration are basically the same as those for per-directory configuration; there is a creation function and a merge function, the latter being invoked where a virtual server has partially overridden the base server configuration, and a combined structure must be computed. (As with per-directory configuration, the default if no merge function is specified, and a module is configured in some virtual server, is that the base configuration is simply ignored).
The only substantial difference is that when a command needs to
configure the per-server private module data, it needs to go to the
cmd_parms data to get at it. Here's an example, from the
alias module, which also indicates how a syntax error can be returned
(note that the per-directory configuration argument to the command
handler is declared as a dummy, since the module doesn't actually have
per-directory config data):
char *add_redirect(cmd_parms *cmd, void *dummy, char *f, char *url)
{
server_rec *s = cmd->server;
alias_server_conf *conf = (alias_server_conf *)
ap_get_module_config(s->module_config,&alias_module);
alias_entry *new = ap_push_array (conf->redirects);
if (!ap_is_url (url)) return "Redirect to non-URL";
new->fake = f; new->real = url;
return NULL;
}
Apache HTTP Server Version 2.0
The allocation mechanism's within APR have a number of debugging modes that can be used to assist in finding memory problems. This document describes the modes available and gives instructions on activating them.
free()d memory and other such
nonsense.The theory is simple. The FILL_BYTE (0xa5)
is written over all malloc'd memory as we receive it, and
is written over everything that we free up during a
clear_pool. We check that blocks on the free list always
have the FILL_BYTE in them, and we check during
palloc() that the bytes still have FILL_BYTE
in them. If you ever see garbage URLs or whatnot containing lots
of 0xa5s then you know something used data that's been
freed or uninitialized.
malloc() and free()d appropriately at the
end.This is intended to be used with something like Electric
Fence or Purify to help detect memory problems. Note that if
you're using efence then you should also add in ALLOC_DEBUG.
But don't add in ALLOC_DEBUG if you're using Purify because
ALLOC_DEBUG would hide all the uninitialized read errors
that Purify can diagnose.
In particular, it causes the table_{set,add,merge}n
routines to check that their arguments are safe for the
apr_table_t they're being placed in. It currently only works
with the unix multiprocess model, but could be extended to others.
This requires a recent gcc which supports
__builtin_return_address(). The error_log output will be a
message such as:
table_push: apr_table_t created by 0x804d874 hit limit of 10
Use l *0x804d874 to find the
source that corresponds to. It indicates that a apr_table_t
allocated by a call at that address has possibly too small an
initial apr_table_t size guess.
This requires a bit of an understanding of how alloc.c works.
Not all the options outlined above can be activated at the same time. the following table gives more information.
| ALLOC DEBUG | ALLOC USE MALLOC | POOL DEBUG | MAKE TABLE PROFILE | ALLOC STATS | |
|---|---|---|---|---|---|
| ALLOC DEBUG | - | No | Yes | Yes | Yes |
| ALLOC USE MALLOC | No | - | No | No | No |
| POOL DEBUG | Yes | No | - | Yes | Yes |
| MAKE TABLE PROFILE | Yes | No | Yes | - | Yes |
| ALLOC STATS | Yes | No | Yes | Yes | - |
Additionally the debugging options are not suitable for multi-threaded versions of the server. When trying to debug with these options the server should be started in single process mode.
The various options for debugging memory are now enabled in
the apr_general.h header file in APR. The various options are
enabled by uncommenting the define for the option you wish to
use. The section of the code currently looks like this
(contained in srclib/apr/include/apr_pools.h)
/*
#define ALLOC_DEBUG
#define POOL_DEBUG
#define ALLOC_USE_MALLOC
#define MAKE_TABLE_PROFILE
#define ALLOC_STATS
*/
typedef struct ap_pool_t {
union block_hdr *first;
union block_hdr *last;
struct cleanup *cleanups;
struct process_chain *subprocesses;
struct ap_pool_t *sub_pools;
struct ap_pool_t *sub_next;
struct ap_pool_t *sub_prev;
struct ap_pool_t *parent;
char *free_first_avail;
#ifdef ALLOC_USE_MALLOC
void *allocation_list;
#endif
#ifdef POOL_DEBUG
struct ap_pool_t *joined;
#endif
int (*apr_abort)(int retcode);
struct datastruct *prog_data;
} ap_pool_t;
To enable allocation debugging simply move the #define
ALLOC_DEBUG above the start of the comments block and rebuild
the server.
In order to use the various options the server must be rebuilt after editing the header file.
Apache HTTP Server Version 2.0
Apache 2.0 uses Doxygen to document the APIs and global variables in the code. This will explain the basics of how to document using Doxygen.
To start a documentation block, use /**
To end a documentation block, use */
In the middle of the block, there are multiple tags we can use:
Description of this functions purpose
@param parameter_name description
@return description
@deffunc signature of the function
The deffunc is not always necessary. DoxyGen does not
have a full parser in it, so any prototype that use a macro in the
return type declaration is too complex for scandoc. Those functions
require a deffunc. An example (using > rather
than >):
/**
* return the final element of the pathname
* @param pathname The path to get the final element of
* @return the final element of the path
* @tip Examples:
* <pre>
* "/foo/bar/gum" -> "gum"
* "/foo/bar/gum/" -> ""
* "gum" -> "gum"
* "wi\\n32\\stuff" -> "stuff"
* </pre>
* @deffunc const char * ap_filename_of_pathname(const char *pathname)
*/
At the top of the header file, always include:
/**
* @package Name of library header
*/
Doxygen uses a new HTML file for each package. The HTML files are named {Name_of_library_header}.html, so try to be concise with your names.
For a further discussion of the possibilities please refer to the Doxygen site.
Apache HTTP Server Version 2.0
This is a cut 'n paste job from an email (<022501c1c529$f63a9550$7f00000a@KOJ>) and only reformatted for better readability. It's not up to date but may be a good start for further research.
There are three basic filter types (each of these is actually broken down into two categories, but that comes later).
CONNECTIONAP_FTYPE_CONNECTION, AP_FTYPE_NETWORK)PROTOCOLAP_FTYPE_PROTOCOL,
AP_FTYPE_TRANSCODE)RESOURCEPROTOCOL, but internal redirects and sub-requests can change
the content without ending the request. (AP_FTYPE_RESOURCE,
AP_FTYPE_CONTENT_SET)It is important to make the distinction between a protocol and a resource filter. A resource filter is tied to a specific resource, it may also be tied to header information, but the main binding is to a resource. If you are writing a filter and you want to know if it is resource or protocol, the correct question to ask is: "Can this filter be removed if the request is redirected to a different resource?" If the answer is yes, then it is a resource filter. If it is no, then it is most likely a protocol or connection filter. I won't go into connection filters, because they seem to be well understood. With this definition, a few examples might help:
The further breakdown of each category into two more filter types is
strictly for ordering. We could remove it, and only allow for one
filter type, but the order would tend to be wrong, and we would need to
hack things to make it work. Currently, the RESOURCE filters
only have one filter type, but that should change.
This is actually rather simple in theory, but the code is
complex. First of all, it is important that everybody realize that
there are three filter lists for each request, but they are all
concatenated together. So, the first list is
r->output_filters, then r->proto_output_filters,
and finally r->connection->output_filters. These correspond
to the RESOURCE, PROTOCOL, and
CONNECTION filters respectively. The problem previously, was
that we used a singly linked list to create the filter stack, and we
started from the "correct" location. This means that if I had a
RESOURCE filter on the stack, and I added a
CONNECTION filter, the CONNECTION filter would
be ignored. This should make sense, because we would insert the connection
filter at the top of the c->output_filters list, but the end
of r->output_filters pointed to the filter that used to be
at the front of c->output_filters. This is obviously wrong.
The new insertion code uses a doubly linked list. This has the advantage
that we never lose a filter that has been inserted. Unfortunately, it comes
with a separate set of headaches.
The problem is that we have two different cases were we use subrequests. The first is to insert more data into a response. The second is to replace the existing response with an internal redirect. These are two different cases and need to be treated as such.
In the first case, we are creating the subrequest from within a handler
or filter. This means that the next filter should be passed to
make_sub_request function, and the last resource filter in the
sub-request will point to the next filter in the main request. This
makes sense, because the sub-request's data needs to flow through the
same set of filters as the main request. A graphical representation
might help:
Default_handler --> includes_filter --> byterange --> ...
If the includes filter creates a sub request, then we don't want the data from that sub-request to go through the includes filter, because it might not be SSI data. So, the subrequest adds the following:
Default_handler --> includes_filter -/-> byterange --> ...
/
Default_handler --> sub_request_core
What happens if the subrequest is SSI data? Well, that's easy, the
includes_filter is a resource filter, so it will be added to
the sub request in between the Default_handler and the
sub_request_core filter.
The second case for sub-requests is when one sub-request is going to
become the real request. This happens whenever a sub-request is created
outside of a handler or filter, and NULL is passed as the next filter to
the make_sub_request function.
In this case, the resource filters no longer make sense for the new request, because the resource has changed. So, instead of starting from scratch, we simply point the front of the resource filters for the sub-request to the front of the protocol filters for the old request. This means that we won't lose any of the protocol filters, neither will we try to send this data through a filter that shouldn't see it.
The problem is that we are using a doubly-linked list for our filter stacks now. But, you should notice that it is possible for two lists to intersect in this model. So, you do you handle the previous pointer? This is a very difficult question to answer, because there is no "right" answer, either method is equally valid. I looked at why we use the previous pointer. The only reason for it is to allow for easier addition of new servers. With that being said, the solution I chose was to make the previous pointer always stay on the original request.
This causes some more complex logic, but it works for all cases. My concern in having it move to the sub-request, is that for the more common case (where a sub-request is used to add data to a response), the main filter chain would be wrong. That didn't seem like a good idea to me.
The final topic. :-) Mod_Asis is a bit of a hack, but the
handler needs to remove all filters except for connection filters, and
send the data. If you are using mod_asis, all other
bets are off.
The absolutely last point is that the reason this code was so hard to
get right, was because we had hacked so much to force it to work. I
wrote most of the hacks originally, so I am very much to blame.
However, now that the code is right, I have started to remove some
hacks. Most people should have seen that the reset_filters
and add_required_filters functions are gone. Those inserted
protocol level filters for error conditions, in fact, both functions did
the same thing, one after the other, it was really strange. Because we
don't lose protocol filters for error cases any more, those hacks went away.
The HTTP_HEADER, Content-length, and
Byterange filters are all added in the
insert_filters phase, because if they were added earlier, we
had some interesting interactions. Now, those could all be moved to be
inserted with the HTTP_IN, CORE, and
CORE_IN filters. That would make the code easier to
follow.
Apache HTTP Server Version 2.0
This document is still in development and may be partially out of date.
In general, a hook function is one that Apache will call at some point during the processing of a request. Modules can provide functions that are called, and specify when they get called in comparison to other modules.
In order to create a new hook, four things need to be done:
Use the AP_DECLARE_HOOK macro, which needs to be given
the return type of the hook function, the name of the hook, and the
arguments. For example, if the hook returns an int and
takes a request_rec * and an int and is
called do_something, then declare it like this:
AP_DECLARE_HOOK(int, do_something, (request_rec *r, int n))
This should go in a header which modules will include if they want to use the hook.
Each source file that exports a hook has a private structure which is used to record the module functions that use the hook. This is declared as follows:
APR_HOOK_STRUCT(
APR_HOOK_LINK(do_something)
...
)
The source file that exports the hook has to implement a
function that will call the hook. There are currently three
possible ways to do this. In all cases, the calling function is
called ap_run_hookname().
If the return value of a hook is void, then all the
hooks are called, and the caller is implemented like this:
AP_IMPLEMENT_HOOK_VOID(do_something, (request_rec *r, int n), (r, n))
The second and third arguments are the dummy argument declaration and the dummy arguments as they will be used when calling the hook. In other words, this macro expands to something like this:
void ap_run_do_something(request_rec *r, int n)
{
...
do_something(r, n);
}
If the hook returns a value, then it can either be run until the first hook that does something interesting, like so:
AP_IMPLEMENT_HOOK_RUN_FIRST(int, do_something, (request_rec *r, int n), (r, n), DECLINED)
The first hook that does not return DECLINED
stops the loop and its return value is returned from the hook
caller. Note that DECLINED is the tradition Apache
hook return meaning "I didn't do anything", but it can be
whatever suits you.
Alternatively, all hooks can be run until an error occurs. This boils down to permitting two return values, one of which means "I did something, and it was OK" and the other meaning "I did nothing". The first function that returns a value other than one of those two stops the loop, and its return is the return value. Declare these like so:
AP_IMPLEMENT_HOOK_RUN_ALL(int, do_something, (request_rec *r, int n), (r, n), OK, DECLINED)
Again, OK and DECLINED are the traditional
values. You can use what you want.
At appropriate moments in the code, call the hook caller, like so:
int n, ret;
request_rec *r;
ret=ap_run_do_something(r, n);
A module that wants a hook to be called needs to do two things.
Include the appropriate header, and define a static function of the correct type:
static int my_something_doer(request_rec *r, int n)
{
...
return OK;
}
During initialisation, Apache will call each modules hook registering function, which is included in the module structure:
static void my_register_hooks()
{
ap_hook_do_something(my_something_doer, NULL, NULL, HOOK_MIDDLE);
}
mode MODULE_VAR_EXPORT my_module =
{
...
my_register_hooks /* register hooks */
};
In the example above, we didn't use the three arguments in
the hook registration function that control calling order.
There are two mechanisms for doing this. The first, rather
crude, method, allows us to specify roughly where the hook is
run relative to other modules. The final argument control this.
There are three possible values: HOOK_FIRST,
HOOK_MIDDLE and HOOK_LAST.
All modules using any particular value may be run in any
order relative to each other, but, of course, all modules using
HOOK_FIRST will be run before HOOK_MIDDLE
which are before HOOK_LAST. Modules that don't care
when they are run should use HOOK_MIDDLE. (I spaced
these out so people could do stuff like HOOK_FIRST-2
to get in slightly earlier, but is this wise? - Ben)
Note that there are two more values,
HOOK_REALLY_FIRST and HOOK_REALLY_LAST. These
should only be used by the hook exporter.
The other method allows finer control. When a module knows that it must be run before (or after) some other modules, it can specify them by name. The second (third) argument is a NULL-terminated array of strings consisting of the names of modules that must be run before (after) the current module. For example, suppose we want "mod_xyz.c" and "mod_abc.c" to run before we do, then we'd hook as follows:
static void register_hooks()
{
static const char * const aszPre[] = { "mod_xyz.c", "mod_abc.c", NULL };
ap_hook_do_something(my_something_doer, aszPre, NULL, HOOK_MIDDLE);
}
Note that the sort used to achieve this is stable, so
ordering set by HOOK_ORDER is preserved, as far
as is possible.
Ben Laurie, 15th August 1999
Apache HTTP Server Version 2.0
Many of the documents on these Developer pages are lifted from Apache 1.3's documentation. While they are all being updated to Apache 2.0, they are in different stages of progress. Please be patient, and point out any discrepancies or errors on the developer/ pages directly to the dev@httpd.apache.org mailing list.
Apache HTTP サーバ バージョン 2.0
この文書は mod_mmap_static モジュールを Apache 2.0 用に移植した時に
学んだ経験をもとに書いた、最初の手引き書です。まだまだ完全じゃないし、
ひょっとすると間違っている部分もあるかもしれませんが、
取っ掛りにはなるでしょう。
クリーンナップルーチンは apr_status_t 型である必要があります。
そして、apr_status_t 型の値を返さなくてはなりません。
クリーンナップ中のエラーを通知する必要がなければ、返り値は普通、
ARP_SUCCESS です。たとえエラーを通知したとしても、
すべてのコードがその通知をチェックしたり、
エラーに応じた動作をするわけではないことに気をつけてください。
初期化ルーチンは処理全体から見てしっくりくるような意味を表すように、
名前が変更されました。ですから、mmap_init から mmap_post_config
のようにちょっと変更されました。
渡される引数は大幅に変更され、次のようになりました。
apr_pool_t *papr_pool_t *plogapr_pool_t *ptempserver_rec *sデータ型のほとんどは APR に移されました。つまり、 いくつかの名前が前述のように変更されています。 施すべき変更点の簡単な一覧を以下に示します。
pool becomes apr_pool_ttable becomes apr_table_t新しいアーキテクチャでは作成した関数を呼び出すのに
一連のフックを使用します。このフックは、新しい関数
static void register_hooks(void) を使って登録するよう、
モジュールに書き足さなくてはなりません。
この関数は、なにをすべきか一旦理解してしまえば、
十分にわかりやすいものです。
リクエストの処理のあるステージで呼び出さなくてはならない
関数は登録する必要があります。ハンドラは登録する必要はありません。
関数を登録できるフェーズはたくさんあります。
それぞれのフェーズで、関数を呼び出す相対的な順番は、
かなりの程度制御できます。
以下は、mod_mmap_static に追加したコードです:
static void register_hooks(void)
{
static const char * const aszPre[]={ "http_core.c",NULL };
ap_hook_post_config(mmap_post_config,NULL,NULL,HOOK_MIDDLE);
ap_hook_translate_name(mmap_static_xlat,aszPre,NULL,HOOK_LAST);
};ここでは呼びだすべき二つの関数を登録しています。一つは
post_config ステージ用 (ほとんどすべてのモジュール
はこれが必要です) で、もう一つは translate_name フェーズ用です。
それぞれの関数は名前は違うけれども形式は同じであることに注意してください。
それでは、形式はどのようになっているでしょうか?
ap_hook_phase_name(function_name,
predecessors, successors, position);
三つの位置が定義されています…
HOOK_FIRSTHOOK_MIDDLEHOOK_LAST位置を定義するには、上記の「位置」を指定し、 修飾子である「先行」と「後行」で手を加えます。 「先行」「後行」は、呼ばれるべき関数のリストです。 「先行」は関数の実行前に呼ばれるもので、 「後行」は実行後に呼ばれるものです。
mod_mmap_static の場合、post_config
ステージでは必要ありませんが、
mmap_static_xlat が core モジュールが名前の変換を実行した後に
呼ばれなければなりません。
そこで aszPre を使って HOOK_LAST の修飾子を定義しています。
モジュールの定義を作成する際に注意しなければならない ステージの数は激減しています。古い定義は次のようになっていました。
module MODULE_VAR_EXPORT module_name_module =
{
STANDARD_MODULE_STUFF,
/* initializer */
/* dir config creater */
/* dir merger --- default is to override */
/* server config */
/* merge server config */
/* command handlers */
/* handlers */
/* filename translation */
/* check_user_id */
/* check auth */
/* check access */
/* type_checker */
/* fixups */
/* logger */
/* header parser */
/* child_init */
/* child_exit */
/* post read-request */
};新しい構造体はとってもシンプルです…
module MODULE_VAR_EXPORT module_name_module =
{
STANDARD20_MODULE_STUFF,
/* create per-directory config structures */
/* merge per-directory config structures */
/* create per-server config structures */
/* merge per-server config structures */
/* command handlers */
/* handlers */
/* register hooks */
};このうちのいくつかは古いものから新しいものに直接読み替えられるもので、 いくつかはそうではありません。どうすればいいのかを要約してみます。
直接読み替えられるステージ:
/* ディレクトリ設定作成関数 *//* ディレクトリ毎設定構造体作成 *//* サーバ設定作成関数 *//* サーバ毎設定構造体作成 *//* ディレクトリ設定マージ関数 *//* ディレクトリ毎設定構造体マージ *//* サーバ設定マージ関数 *//* サーバ毎設定構造体作成マージ *//* コマンド・テーブル *//* コマンド apr_table_t *//* ハンドラ *//* ハンドラ */古い関数の残りのものはフックとして登録されるべきです。 現時点で次のようなフック・ステージが定義されています…
ap_hook_post_config_init ルーチンが登録されるべき場所です)ap_hook_http_methodap_hook_open_logsap_hook_auth_checkerap_hook_access_checkerap_hook_check_user_idap_hook_default_portap_hook_pre_connectionap_hook_process_connectionap_hook_child_initap_hook_create_requestap_hook_fixupsap_hook_handlerap_hook_header_parserap_hook_insert_filterap_hook_log_transactionap_hook_optional_fn_retrieveap_hook_post_read_requestap_hook_quick_handlerap_hook_translate_nameap_hook_type_checkerApache HTTP Server Version 2.0
Warning - this is a first (fast) draft that needs further revision!
Several changes in Apache 2.0 affect the internal request processing mechanics. Module authors need to be aware of these changes so they may take advantage of the optimizations and security enhancements.
The first major change is to the subrequest and redirect
mechanisms. There were a number of different code paths in
Apache 1.3 to attempt to optimize subrequest or redirect
behavior. As patches were introduced to 2.0, these
optimizations (and the server behavior) were quickly broken due
to this duplication of code. All duplicate code has been folded
back into ap_process_request_internal() to prevent
the code from falling out of sync again.
This means that much of the existing code was 'unoptimized'. It is the Apache HTTP Project's first goal to create a robust and correct implementation of the HTTP server RFC. Additional goals include security, scalability and optimization. New methods were sought to optimize the server (beyond the performance of Apache 1.3) without introducing fragile or insecure code.
All requests pass through ap_process_request_internal()
in request.c, including subrequests and redirects. If a module
doesn't pass generated requests through this code, the author is cautioned
that the module may be broken by future changes to request
processing.
To streamline requests, the module author can take advantage of the hooks offered to drop out of the request cycle early, or to bypass core Apache hooks which are irrelevant (and costly in terms of CPU.)
The request's parsed_uri path is unescaped, once and only
once, at the beginning of internal request processing.
This step is bypassed if the proxyreq flag is set, or the
parsed_uri.path element is unset. The module has no further
control of this one-time unescape operation, either failing to
unescape or multiply unescaping the URL leads to security
reprecussions.
All /../ and /./ elements are
removed by ap_getparents(). This helps to ensure
the path is (nearly) absolute before the request processing
continues.
This step cannot be bypassed.
Every request is subject to an
ap_location_walk() call. This ensures that
<Location> sections
are consistently enforced for all requests. If the request is an internal
redirect or a sub-request, it may borrow some or all of the processing
from the previous or parent request's ap_location_walk, so this step
is generally very efficient after processing the main request.
Modules can determine the file name, or alter the given URI
in this step. For example, mod_vhost_alias will
translate the URI's path into the configured virtual host,
mod_alias will translate the path to an alias path,
and if the request falls back on the core, the DocumentRoot is prepended to the request resource.
If all modules DECLINE this phase, an error 500 is
returned to the browser, and a "couldn't translate name" error is logged
automatically.
After the file or correct URI was determined, the
appropriate per-dir configurations are merged together. For
example, mod_proxy compares and merges the appropriate
<Proxy> sections.
If the URI is nothing more than a local (non-proxy) TRACE
request, the core handles the request and returns DONE.
If no module answers this hook with OK or DONE,
the core will run the request filename against the <Directory> and <Files> sections. If the request
'filename' isn't an absolute, legal filename, a note is set for
later termination.
Every request is hardened by a second
ap_location_walk() call. This reassures that a
translated request is still subjected to the configured
<Location> sections.
The request again borrows some or all of the processing from its previous
location_walk above, so this step is almost always very
efficient unless the translated URI mapped to a substantially different
path or Virtual Host.
The main request then parses the client's headers. This prepares the remaining request processing steps to better serve the client's request.
Needs Documentation. Code is:
switch (ap_satisfies(r)) {
case SATISFY_ALL:
case SATISFY_NOSPEC:
if ((access_status = ap_run_access_checker(r)) != 0) {
return decl_die(access_status, "check access", r);
}
if (ap_some_auth_required(r)) {
if (((access_status = ap_run_check_user_id(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check user. No user file?"
: "perform authentication. AuthType not set!",
r);
}
if (((access_status = ap_run_auth_checker(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check access. No groups file?"
: "perform authentication. AuthType not set!",
r);
}
}
break;
case SATISFY_ANY:
if (((access_status = ap_run_access_checker(r)) != 0)) {
if (!ap_some_auth_required(r)) {
return decl_die(access_status, "check access", r);
}
if (((access_status = ap_run_check_user_id(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check user. No user file?"
: "perform authentication. AuthType not set!",
r);
}
if (((access_status = ap_run_auth_checker(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check access. No groups file?"
: "perform authentication. AuthType not set!",
r);
}
}
break;
}The modules have an opportunity to test the URI or filename
against the target resource, and set mime information for the
request. Both mod_mime and
mod_mime_magic use this phase to compare the file
name or contents against the administrator's configuration and set the
content type, language, character set and request handler. Some modules
may set up their filters or other request handling parameters at this
time.
If all modules DECLINE this phase, an error 500 is
returned to the browser, and a "couldn't find types" error is logged
automatically.
Many modules are 'trounced' by some phase above. The fixups phase is used by modules to 'reassert' their ownership or force the request's fields to their appropriate values. It isn't always the cleanest mechanism, but occasionally it's the only option.
This phase is not part of the processing in
ap_process_request_internal(). Many
modules prepare one or more subrequests prior to creating any
content at all. After the core, or a module calls
ap_process_request_internal() it then calls
ap_invoke_handler() to generate the request.
Modules that transform the content in some way can insert their values and override existing filters, such that if the user configured a more advanced filter out-of-order, then the module can move its order as need be. There is no result code, so actions in this hook better be trusted to always succeed.
The module finally has a chance to serve the request in its
handler hook. Note that not every prepared request is sent to
the handler hook. Many modules, such as mod_autoindex,
will create subrequests for a given URI, and then never serve the
subrequest, but simply lists it for the user. Remember not to
put required teardown from the hooks above into this module,
but register pool cleanups against the request pool to free
resources as required.
Apache HTTP Server Version 2.0
When using any of the threaded mpms in Apache 2.0 it is important that every function called from Apache be thread safe. When linking in 3rd party extensions it can be difficult to determine whether the resulting server will be thread safe. Casual testing generally won't tell you this either as thread safety problems can lead to subtle race conditons that may only show up in certain conditions under heavy load.
When writing your module or when trying to determine if a module or 3rd party library is thread safe there are some common things to keep in mind.
First, you need to recognize that in a threaded model each individual thread has its own program counter, stack and registers. Local variables live on the stack, so those are fine. You need to watch out for any static or global variables. This doesn't mean that you are absolutely not allowed to use static or global variables. There are times when you actually want something to affect all threads, but generally you need to avoid using them if you want your code to be thread safe.
In the case where you have a global variable that needs to be global and accessed by all threads, be very careful when you update it. If, for example, it is an incrementing counter, you need to atomically increment it to avoid race conditions with other threads. You do this using a mutex (mutual exclusion). Lock the mutex, read the current value, increment it and write it back and then unlock the mutex. Any other thread that wants to modify the value has to first check the mutex and block until it is cleared.
If you are using APR, have a look
at the apr_atomic_* functions and the
apr_thread_mutex_* functions.
This is a common global variable that holds the error number of the
last error that occurred. If one thread calls a low-level function that
sets errno and then another thread checks it, we are bleeding error
numbers from one thread into another. To solve this, make sure your
module or library defines _REENTRANT or is compiled with
-D_REENTRANT. This will make errno a per-thread variable
and should hopefully be transparent to the code. It does this by doing
something like this:
#define errno (*(__errno_location()))
which means that accessing errno will call
__errno_location() which is provided by the libc. Setting
_REENTRANT also forces redefinition of some other functions
to their *_r equivalents and sometimes changes
the common getc/putc macros into safer function
calls. Check your libc documentation for specifics. Instead of, or in
addition to _REENTRANT the symbols that may affect this are
_POSIX_C_SOURCE, _THREAD_SAFE,
_SVID_SOURCE, and _BSD_SOURCE.
Not only do things have to be thread safe, but they also have to be
reentrant. strtok() is an obvious one. You call it the first
time with your delimiter which it then remembers and on each subsequent
call it returns the next token. Obviously if multiple threads are
calling it you will have a problem. Most systems have a reentrant version
of of the function called strtok_r() where you pass in an
extra argument which contains an allocated char * which the
function will use instead of its own static storage for maintaining
the tokenizing state. If you are using APR you can use apr_strtok().
crypt() is another function that tends to not be reentrant,
so if you run across calls to that function in a library, watch out. On
some systems it is reentrant though, so it is not always a problem. If
your system has crypt_r() chances are you should be using
that, or if possible simply avoid the whole mess by using md5 instead.
The following is a list of common libraries that are used by 3rd party
Apache modules. You can check to see if your module is using a potentially
unsafe library by using tools such as ldd(1) and
nm(1). For PHP, for example,
try this:
% ldd libphp4.so
libsablot.so.0 => /usr/local/lib/libsablot.so.0 (0x401f6000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402da000)
libsnmp.so.0 => /usr/lib/libsnmp.so.0 (0x402f9000)
libpdf.so.1 => /usr/local/lib/libpdf.so.1 (0x40353000)
libz.so.1 => /usr/lib/libz.so.1 (0x403e2000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x403f0000)
libmysqlclient.so.11 => /usr/lib/libmysqlclient.so.11 (0x40411000)
libming.so => /usr/lib/libming.so (0x40449000)
libm.so.6 => /lib/libm.so.6 (0x40487000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x404a8000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x404e7000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40505000)
libssl.so.2 => /lib/libssl.so.2 (0x40532000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x40560000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40624000)
libdl.so.2 => /lib/libdl.so.2 (0x40634000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40637000)
libc.so.6 => /lib/libc.so.6 (0x4064b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
In addition to these libraries you will need to have a look at any
libraries linked statically into the module. You can use nm(1)
to look for individual symbols in the module.
Please drop a note to dev@httpd.apache.org if you have additions or corrections to this list.
| Library | Version | Thread Safe? | Notes |
|---|---|---|---|
| ASpell/PSpell | ? | ||
| Berkeley DB | 3.x, 4.x | Yes | Be careful about sharing a connection across threads. |
| bzip2 | Yes | Both low-level and high-level APIs are thread-safe. However, high-level API requires thread-safe access to errno. | |
| cdb | ? | ||
| C-Client | Perhaps | c-client uses strtok() and
gethostbyname() which are not thread-safe on most C
library implementations. c-client's static data is meant to be shared
across threads. If strtok() and
gethostbyname() are thread-safe on your OS, c-client
may be thread-safe. | |
| cpdflib | ? | ||
| libcrypt | ? | ||
| Expat | Yes | Need a separate parser instance per thread | |
| FreeTDS | ? | ||
| FreeType | ? | ||
| GD 1.8.x | ? | ||
| GD 2.0.x | ? | ||
| gdbm | No | Errors returned via a static gdbm_error
variable | |
| ImageMagick | 5.2.2 | Yes | ImageMagick docs claim it is thread safe since version 5.2.2 (see Change log). |
| Imlib2 | ? | ||
| libjpeg | v6b | ? | |
| libmysqlclient | Yes | Use mysqlclient_r library variant to ensure thread-safety. For more information, please read http://www.mysql.com/doc/en/Threaded_clients.html. | |
| Ming | 0.2a | ? | |
| Net-SNMP | 5.0.x | ? | |
| OpenLDAP | 2.1.x | Yes | Use ldap_r library variant to ensure
thread-safety. |
| OpenSSL | 0.9.6g | Yes | Requires proper usage of CRYPTO_num_locks,
CRYPTO_set_locking_callback,
CRYPTO_set_id_callback |
| liboci8 (Oracle 8+) | 8.x,9.x | ? | |
| pdflib | 5.0.x | Yes | PDFLib docs claim it is thread safe; changes.txt indicates it has been partially thread-safe since V1.91: http://www.pdflib.com/products/pdflib/index.html. |
| libpng | 1.0.x | ? | |
| libpng | 1.2.x | ? | |
| libpq (PostgreSQL) | 7.x | Yes | Don't share connections across threads and watch out for
crypt() calls |
| Sablotron | 0.95 | ? | |
| zlib | 1.1.4 | Yes | Relies upon thread-safe zalloc and zfree functions Default is to use libc's calloc/free which are thread-safe. |
Apache HTTP サーバ バージョン 2.0
本文書の内容は次の一言に尽きます。「Apache が設定ファイルを読み込むときに DNS を使用する必要がないようにして下さい」。Apache が設定ファイルを 読み込むときに DNS を使用する必要がある場合、信頼性の問題 (起動しないかもしれません) やサービス拒否や盗用アタック (他のユーザからヒットを盗むことを含みます) の問題に直面するかもしれません。
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Apache が正常に機能するには、バーチャルホスト毎に必ず二つの
情報が必要になります。それは、
ServerName
と、そのサーバが応答するための IP (最低一つ) です。
上記例では IP アドレスを含んでいませんので、Apache は DNS
を使用して www.abc.dom を見つけなければなりません。
何らかの理由で設定ファイルを読み込んでいるときに DNS
が利用できなかった場合、
バーチャルホストは設定されません。
そして、そのバーチャルホストに対するヒットには応答がなされません
(Apache 1.2 以前では起動すらしません)。
www.abc.dom のアドレスが 10.0.0.1
だとします。では、次の設定について考えてみましょう。
<VirtualHost 10.0.0.1>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
現在のリリースでは Apache は DNS 逆引きを使用して
このバーチャルホストの ServerName
を見つけます。
その逆引きが失敗した場合は部分的にバーチャルホストを無効にします
(Apache 1.2 より前では起動すらしません)。
バーチャルホストが名前ベースであれば完全に無効になりますが、
IP ベースであれば概ね動作します。しかしながら、サーバ名を
含む完全な URL を生成しなければならない場合は、正しい URL
の生成ができません。
次の例は上記の問題を解決しています。
<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
サービス拒否が起こる場合、(少なくとも) 二つのケースがあります。
Apache 1.2 より前を実行している場合、バーチャルホストのための
上記の二つの DNS 検索のうち一つ失敗すれば起動すらしません。
そしてこの DNS 検索が自分の制御下にすらない場合もありえます。
例えば、abc.dom が顧客のサーバの一つで、
DNS は顧客自身で管理している場合、単に
www.abc.dom レコードを削除するだけで、
(1.2 より前の) サーバを起動不能にすることができます。
もう一つのケースは、より気付きにくいものです。 次の設定について考えてみましょう。
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
<VirtualHost www.def.dom>
ServerAdmin webguy@def.dom
DocumentRoot /www/def
</VirtualHost>
10.0.0.1 を www.abc.dom に、
10.0.0.2 を www.def.dom に割り当てているとします。
また、def.dom は顧客自身の DNS
の制御下にあるとします。この設定で、abc.dom
に向けられたトラフィック全てを奪うことができる位置に
def.dom を設置できています。後は単に
www.def.dom が 10.0.0.1 を参照するように
設定するだけです。DNS は顧客側の DNS でコントロールされているので、
www.def.dom レコードが好きな場所を指すように
設定できてしまうのを止めさせることができません。
10.0.0.1 に対するリクエスト
(http://www.abc.dom/whatever 形式の URL
を入力したユーザからのもの全てを含みます)
は、def.dom バーチャルホストで応答されます。
このようなことが何故起こるかもっと良く知るためには、
応答の必要なバーチャルホストへのリクエストに対して、
Apache がどのように整合性を確保するかについて、
深い議論が必要になります。おおざっぱな説明はこちらに記述されています。
Apache 1.1 での 名前ベースのバーチャルホストのサポート 追加の際に、
Apache は httpd の実行されているホストの IP
アドレスを知る必要が出てきました。このアドレスを得るために、
(もしあれば) グローバルな
ServerName を使用するか、
C 言語の関数 gethostname (コマンドプロンプトで
hostname とタイプしたときと同じものを返します)
を呼び出すかをします。
その後、得られたアドレスで DNS 検索を行ないます。
現在のところ、この DNS 検索を回避する方法はありません。
DNS サーバがダウンして、この検索ができない事態が起こることを
恐れているのであれば、/etc/hosts
にホスト名を記述しておくことができます
(マシンが正常に起動するように既に設定されているかもしれません)。
その場合、DNS 参照が失敗した場合にマシンが /etc/hosts
を使用するように設定していることを確認してください。
その方法は、どの OS を使用しているかに依存しますが、
/etc/resolv.conf か /etc/nsswitch.conf
を編集することで設定できます。
もし他の理由で DNS を利用する必要がない場合は、
HOSTRESORDER 環境変数を「 local
」に設定することでそのようにできます。以上これらの事柄は、どんな
OS 、レゾルバライブラリを使用しているかに依存します。また、
mod_env を使用して環境変数を制御しない限り、
CGI にも影響を与えます。man ページや使用している OS
の FAQ で調べると良いでしょう。
VirtualHost
で IP アドレスを使用する。
Listen
で IP アドレスを使用する。
ServerName
を持つようにする。
<VirtualHost _default_:*>
サーバを作る。DNS に関して、現状は全く宜しくありません。Apache 1.2 で、 DNS のイベントが失敗しても少なくとも起動プロセスが続くようにしましたが、 これが最高の解決方法ではないでしょう。アドレスの再割り当てが必要不可避 となっている今日のインターネットにおいては、 設定ファイルの中で明示的な IP アドレスを要求する仕様は、 全く宜しくありません。
盗用のサービスアタックに関して行なうべき事は、 DNS 順引きを行なって得られたアドレスに対する DNS 逆引きを行なって、二つの名前を比較することです。 この二つが一致しなければバーチャルホストは無効になるようにします。 こうするためには逆引き DNS が適切に設定されている必要があります (FTP サーバや TCP ラッパーのおかげで「二重逆引き」DNS は一般的に なっていますので、管理者にはお馴染みものでしょう)。
IP アドレスが使用されていなくて DNS が失敗した場合は、 どうしてもバーチャルホストウェブサーバを信頼性を確保して 起動させることは不可能のようです。 設定の一部を無効にするというような部分的な解決では、 サーバが何をするようにするかにもよりますが、 そのサーバが起動しないより確実に悪い状況になるでしょう。
HTTP/1.1 が開発され、ブラウザやプロキシが Host
ヘッダを発行するようになったので、IP ベースのバーチャルホストを
全く使用しなくても済むようになるかもしれません。
この場合、ウェブサーバは設定中に DNS 参照をしなくても済みます。
しかし 1997 年 3 月時点の状況では、
商用レベルのウェブサーバで使用できるほどには、
これらの機能は広く開発が進んでいません。
Apache HTTP サーバ バージョン 2.0
Apache HTTP サーバはモジュール化されたプログラムで、
管理者がモジュールを選択することでサーバに組み込む機能を選ぶことができます。
モジュールはサーバがビルドされるときに httpd バイナリに
静的に組み込むことができます。もしくは、httpd バイナリとは
別に存在する動的共有オブジェクト (訳注: Dynamic Shared Object)
(DSO) としてコンパイルすることも
できます。DSO モジュールはサーバがビルドされるときにコンパイルしたり、
Apache 拡張ツール (apxs) を
使って後でコンパイルして追加したりできます。
この文書は DSO モジュールの使い方と、仕組みについて 説明します。
| 関連モジュール | 関連ディレクティブ |
|---|---|
個々の Apache モジュールをロードするための DSO サポートは
mod_so.c というモジュールの機能に基づいています。
このモジュール は Apache のコアに静的に組み込まれている必要があります。
それは core.c 以外では DSO にできない唯一の
モジュールです。事実上、他のすべての Apache のモジュールは、
インストールの文書で説明されているように、
configure の
--enable-module=shared オプションでそれぞれを
DSO ビルドにすることにより、DSO モジュールにすることができます。
mod_foo.so のような DSO にモジュールがコンパイルされれば、
httpd.conf ファイル中で mod_so の
LoadModule
ディレクティブを使うことでサーバの起動や再起動時にこのモジュールを
ロードするようにできます。
Apache モジュール用の (特にサードパーティモジュールの) DSO ファイルの
作成を簡単にするために、apxs
(APache eXtenSion) という新しいサポートプログラムがあります。
Apache のソースツリーの外で DSO モジュールをビルドするために
使うことができます。発想は単純です: Apache のインストール時の
configure、make install のときに Apache の
C ヘッダをインストールし、DSO ビルド用のプラットフォーム依存の
コンパイラとリンカのフラグを apxs プログラムに追加します。
これにより、ユーザが Apache の配布ソースツリーなしで、さらに
DSO サポートのためのプラットフォーム依存のコンパイラやリンカの
フラグをいじることなく Apache のモジュールのソースをコンパイル
できるようになります。
Apache 2.0 の DSO 機能の概略を知ることができるための、 短く簡潔な概要です:
mod_foo.c
として、それを DSO mod_foo.so にビルド、インストール:
$ ./configure --prefix=/path/to/install --enable-foo=shared
$ make install
mod_foo.c
として、それを DSO mod_foo.so にビルド、インストール:
$ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared
$ make install
$ ./configure --enable-so
$ make install
mod_foo.c
として、それを apxs を使って
Apache ソースツリーの外で DSO にビルド、インストール:
$ cd /path/to/3rdparty
$ apxs -c mod_foo.c
$ apxs -i -a -n foo mod_foo.la
どの場合においても、共有モジュールをコンパイルした後で、
httpd.conf で
LoadModule
ディレクティブを使って Apache がモジュールを使用するように
しなければなりません。
最近の Unix 系の OS には 動的共有オブジェクト (DSO) の動的リンク/ロードという気のきいた機構が 存在します。これは、実行時にプログラムのアドレス空間に ロードできるような特別な形式でプログラムをビルドすることを 可能にします。
このロードは二つの方法で行なうことができます: 実行プログラムが
起動されたときに ld.so というシステムプログラム
により自動的に行なわれる方法と、実行プログラム中から、システムコール
dlopen()/dlsym() による Unix ローダへの
プログラムシステムのインタフェースを使って手動で行なう方法とが
あります。
最初の方法では DSO は普通は共有ライブラリや DSO
ライブラリ と呼ばれていて、DSO の名前は
libfoo.so や libfoo.so.1.2 のようになっています。
これらはシステムディレクトリ (通常 /usr/lib) に存在し、
実行プログラムへのリンクはビルド時に -lfoo をリンカに
指定することで確立されます。これによりライブラリへの参照が実行プログラムの
ファイルに書き込まれて、起動時に Unix のローダが /usr/lib や、
リンカの -R のようなオプションによりハードコードされたパス、
環境変数 LD_LIBRARY_PATH により設定されたパス、の中から
libfoo.so の場所を見つけることができます。それから、
実行プログラム中の (まだ未解決の) シンボルを DSO にあるシンボルで
解決します。
普通は実行プログラム中のシンボルは DSO からは参照されません
(DSO は一般的なコードによる再利用可能なライブラリですので)。
ですから、さらなるシンボルの解決は必要ありません。
シンボルは Unix ローダにより完全な解決が行なわれますので、実行ファイル自身は
何もする必要がありません。(実際のところ、静的でない方法でリンクされている
すべての実行プログラムに組み込まれている開始用のコードの一部に
ld.so を起動するコードが含まれています)。よく使われる
ライブラリの動的ロードの利点は明らかです。ライブラリのコードは
システムライブラリに libc.so のようにして一度保存するだけでよく、
プログラムのために必要なディスクの領域を節約することができます。
二つめの方法では DSO は普通は共有オブジェクトや
DSO ファイルと呼ばれていて、任意の拡張子を付けることができます
(ただし、標準的な名前は foo.so です)。
これらのファイルは通常はプログラム専用のディレクトリに置かれ、
これらを使う実行プログラムへのリンクは自動的にはされません。
ですので、実行プログラムは dlopen() を使って
実行時に手動で DSO をプログラムのアドレス空間にロードする必要があります。
この時点では実行プログラムに対して DSO のシンボルの解決は行なわれません。
しかし、その代わりに Unix のローダが DSO の (まだ未解決の) シンボルを
実行プログラムによりエクスポートされたシンボルと既にロードされた
DSO ライブラリによりエクスポートされたシンボル (特に、どこにでもある
libc.so のすべてのシンボル) で自動的に解決します。
こうすることで、DSO は最初から静的にリンクされていたかのように、
実行プログラムのシンボルを知ることができます。
最後に、DSO の API を利点を生かすために、プログラムは
後でディスパッチテーブルなどでシンボルを使うことができるように、
dlsym() を使っていくつかのシンボルを解決します。
すなわち: 実行プログラムは必要なすべてのシンボルを手動で解決しなければ
なりません。この機構の利点はプログラムのオプショナルな部分は
必要になるまでロードする必要がない (だからメモリも消費しない)
ことです。必要ならば、基本プログラムの機能を拡張するために
これらの部分を動的にロードすることができます。
この DSO 機構は簡単なように見えますが、少なくとも一つ難しい点が あります: プログラムを拡張するために DSO を使っているときに、 DSO が実行プログラムからシンボルを解決する点です (二番目の方法)。 これはなぜでしょうか。それは、DSO のシンボルを実行プログラムの シンボルから「逆解決」するというのはライブラリの設計 (ライブラリはそれを使用するプログラムのことは何も 知らない) に反していて、この機能はすべてのプラットフォームに あるわけではなく、標準化もされていないからです。 実際には実行プログラムのグローバルなシンボルは再エクスポートされることは あまりなく、DSO から使うことができません。リンカにグローバルシンボルすべてを エクスポートするようにさせる方法を見つけることが、実行時にプログラムを 拡張するために DSO を使うときの一番の問題です。
共有ライブラリのアプローチが普通の方法です。DSO 機構はそのために 設計されたものですから。したがって、その方法はオペレーティングシステムが 提供するほとんどすべての種類のライブラリで使われています。 一方、プログラムの拡張のために共有オブジェクトを使用する、という方は あまり使われていません。
1998 年の時点で、実行時に実際に機能拡張のために DSO 機構を使っている ソフトウェアパッケージは少しだけでした: Perl 5 (XS 機構と DnaLoader モジュール によるもの)、Netscape サーバなどです。Apache はすでに モジュールの概念を使って機能拡張をしていて、内部的にディスパッチリストに 基づいた外部モジュールの Apache コア機能へのリンクを行なっていましたので、 バージョン 1.3 から、Apache も DSO 機構を使う仲間になりました。 Apache は実行時に DSO を使ってモジュールをロードするようにすでに 運命付けられていたのです。
上記の DSO に基づいた機能は以下の利点があります:
configure のオプションを使う代わりに
実行時に httpd.conf の設定用コマンド
LoadModule
を使うことができますので、サーバパッケージの柔軟性が高まりました。
たとえば、一つの Apache のインストールから
違う構成のサーバ (標準版と SSL 版、最小構成と拡張版 [mod_perl, PHP3]
など) を実行することができます。apxs の組み合わせにより、Apache ソースツリーの
外で作業でき、開発中のモジュールの新しいバージョンを
実行中の Apache サーバに組み込むために apxs -i と
apachectl restart を行なうだけで良くなるからです。DSO には以下の欠点があります:
ld -lfoo)
というわけではありませんので (たとえば、a.out のプラットフォームでは
この機能はありませんが、ELF のプラットフォームにはあります)、
すべての種類のモジュールに DSO 機構を使えるわけではありません。
言い換えると、DSO ファイルとしてコンパイルされたモジュールの
使えるシンボルは、
Apache のコアのシンボル、C ライブラリ (libc) と
Apache コアが使っている他のすべての静的なライブラリと動的ライブラリの
シンボル、PIC による静的なライブラリ (libfoo.a) の
シンボルのみに制限されます。その他のコードを使う方法は、
Apache コア自身がすでにそのコードへの参照があるようにするか、
dlopen () を使ってコードを自分自身でロードするかの
どちらかしかありません。Apache HTTP サーバ バージョン 2.0
Apache HTTP サーバは環境変数と呼ばれる、名前のついた 変数に情報を記憶する仕組みを提供しています。この情報はログ収集や アクセス制御などのいろいろな操作を制御するために使うことができます。 これらの変数は CGI スクリプトなどの外部プログラムと通信するためにも 使われます。この文書はそれらの変数の操作方法と使用方法をいくつか 紹介します。
これらの変数は環境変数と呼ばれていますが、オペレーティング システムによって制御されている環境変数と同じではありません。 実際は、これらの変数は Apache の内部構造の中に記憶され、操作されています。 それらは、CGI や SSI スクリプトに渡されたときだけ、実際の オペレーティングシステムの環境変数になります。サーバ自身が 実行されているオペレーティングシステムの環境を操作したい場合は、 オペレーティングシステムのシェルが提供している標準の環境変数の 操作方法を使わなければなりません。
| 関連モジュール | 関連ディレクティブ |
|---|---|
Apache において環境変数を設定する一番基本的な方法は、
無条件に環境変数を設定する SetEnv ディレクティブを使用することです。
PassEnv
ディレクティブにより、Apache が起動されたシェルの
環境変数を渡すこともできます。
より柔軟性を高めるために、mod_setenvif
で提供されているディレクティブを使用することで、リクエストの
特性に基づいて環境変数を設定することができます。例えば、特定のブラウザ
(User-Agent) のリクエストや特定の Referer [意図的な綴りです]
(訳注: 正しい綴りは referrer ですが、HTTP の仕様では Referer
となっています) ヘッダが見つかったときのみ変数を設定することができます。
mod_rewrite の RewriteRule
ディレクティブにおいて環境変数を設定する [E=...]
オプションを使用することで、
より柔軟な設定を行なうことができます。
mod_unique_id は、非常に限られた条件の下で
「すべて」のリクエストについて、一意であることが保証されている値を環境変数
UNIQUE_ID に設定します。
Apache の設定ファイルで設定された環境変数とシェルから渡される 環境変数に加えて、CGI スクリプトと SSI ページには CGI の仕様で要求されている、 リクエストのメタ情報を持った環境変数の組が提供されます。
suexec.c
で定義されます。| 関連モジュール | 関連ディレクティブ |
|---|---|
環境変数の主な利用法の一つは、CGI スクリプトに情報を伝えることです。 上で説明されているように、CGI スクリプトに渡される環境変数は Apache の設定により設定される変数に加えて、リクエストの標準のメタ情報を含んでいます。 詳細は CGI チュートリアル を参照してください。
mod_include の INCLUDES フィルタで処理される
server-parsed (SSI) ドキュメントでは、echo
要素を使用すると環境変数が出力されます。
また、ページのある部分がリクエストの性質に応じて変更されるように、
環境変数をフロー制御要素で使うことができます。詳細は
SSI チュートリアル を参照してください。
allow from env= ディレクティブと deny from env=
ディレクティブを使用して、サーバへのアクセスを環境変数の値で制御することができます。
SetEnvIf
ディレクティブと組み合わせることで、クライアントの特性に基づいて
サーバへのアクセス制御を柔軟に行なうことができるようになります。
たとえば、これらのディレクティブを使用して、特定のブラウザ (User-Agent)
からのアクセスを拒否することができます。
LogFormat
ディレクティブのオプション %e
を使用することで、環境変数をアクセスログに記録することができます。さらに、
CustomLog
ディレクティブの条件分岐式を使用することで、
環境変数の値によってリクエストをログに記録するかどうかを決めることができます。
SetEnvIf
ディレクティブと組み合わせることで、
どのリクエストをログに記録するかを柔軟に制御することが可能になります。たとえば、
gif で終わるファイル名へのリクエストはログに記録しない、
違うサブネットのクライアントからのリクエストだけをログに記録する、
という選択が可能です。
Header
ディレクティブは環境変数の存在や不在によってクライアントへの応答に特定の
HTTP ヘッダを付けるかどうかを決めることができます。
これにより、たとえば、クライアントからのリクエスト
にあるヘッダがある場合にのみ特定の応答ヘッダを送る、というようなことが
できます。
ExtFilterDefine
ディレクティブを使用して
mod_ext_filter で設定される外部フィルタは、
disableenv= と enableenv=
オプションを使って、環境変数による条件付き適用ができます。
RewriteCond
ディレクティブで評価文字列として
%{ENV:...} 式を指定することで、mod_rewrite
の書き換えエンジンが環境変数に基いて条件分岐を行なうことができます。
mod_rewrite が使用可能な変数で ENV: が前についていない変数は、
実際は環境変数ではないということに注意してください。
それらは他のモジュールからは使用できない mod_rewrite 用の特別な変数です。
互換性の問題を解決するために、特定のクライアントと通信しているときは
Apache の動作を変更できる機構が導入されました。できるだけ柔軟にするために、
これらの機構は環境変数を定義することで呼び出されます。普通は、
BrowserMatch
ディレクティブを使いますが、たとえば SetEnv ディレクティブや PassEnv ディレクティブも使用することができます。
これを指定することで、リクエストが HTTP/1.0 より新しいプロトコルの場合でも、HTTP/1.0 として扱われます。
応答ヘッダがクライアントに送られる前に Vary
フィールドを取り除きます。
クライアントの中にはこのフィールドを正しく解釈しないものがあります
(クライアントの既知の問題
のページを参照してください)。この変数を設定することでその問題を回避
することができます。この変数を設定すると、force-response-1.0
が設定されたことになります。
これが設定されていると、HTTP/1.0 リクエストを発行するクライアントに対しては 常に HTTP/1.0 で応答するようになります。この機能は、 元々は AOL のプロキシの問題のために実装されました。HTTP/1.0 クライアントの中には、 HTTP/1.1 の応答を返されると正しく動作しないものがあるかもしれません。 この機能を使用することで、そのようなクライアントとの間の互換性問題を解決できます。
これが 1 に設定されると、この変数は text/html
以外のコンテントタイプに対する、mod_deflate
提供の DEFLATE 出力フィルタを無効にします。
セットされると、mod_deflate の
DEFLATE フィルタがオフになります。
これが設定されている場合は、KeepAlive を使用しないようにします。
mod_negotiation の挙動に影響を与えます。
(en, ja, x-klingonといった)
言語タグが格納されていれば、その言語の variant を送信しようとします。
そのような variant がない場合は、
通常のネゴシエーション処理が
適用されます。
これはクライアントへのリダイレクトの送信をサーバがより注意深く 行なうようにします。 これは通常、リダイレクトに際してクライアントに 問題があることが分かっている場合に使われます。この機能は元々は マイクロソフトのウェブフォルダのソフトが DAV メソッドによるディレクトリのリソースへのリダイレクトの扱いに 問題がり、それを回避するために実装されました。
Apache 2.0.40 以降で利用可能
クライアントのリクエストに対する応答としてリダイレクトを送信する際、 レスポンスにはリダイレクトが自動的に行なえない (行なわれない) 場合に表示するテキストが含まれます。 通常、このテキストに合致したキャラクタセット、ISO-8859-1 でラベル付けをします。
しかし、リダイレクト先が別の文字セットを使っている場合、 ある問題のあるブラウザのバージョンでは、 リダイレクト先の実際の文字セットの代わりに、 リダイレクト元の文字セットを使ってしまうことがあります。 その結果、例えば変な描画が行なわれたりして、読めなくなったりします。
この環境変数を設定することで、リダイレクションテキストに対する キャラクタセットの指定を除去しますので、それら問題のあるブラウザでも リダイレクト先の文字セットを正しく使うようにできます。
クライアントに関する既知の問題に対処するために、以下の行を httpd.conf に入れることを推奨しています。
# # The following directives modify normal HTTP response behavior. # The first directive disables keepalive for Netscape 2.x and browsers that # spoof it. There are known problems with these browser implementations. # The second directive is for Microsoft Internet Explorer 4.0b2 # which has a broken HTTP/1.1 implementation and does not properly # support keepalive when it is used on 301 or 302 (redirect) responses. # BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 # # The following directive disables HTTP/1.1 responses to browsers which # are in violation of the HTTP/1.0 spec by not being able to grok a # basic 1.1 response. # BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0
この例では、画像へのリクエストがアクセスログに現れないようにします。 これを変更することで、特定のディレクトリのログ収集をやめたり、 特定のホストからのリクエストのログ収集をやめたりすることが簡単にできます。
SetEnvIf Request_URI \.gif image-request SetEnvIf Request_URI \.jpg image-request SetEnvIf Request_URI \.png image-request CustomLog logs/access_log common env=!image-request
この例は、別のサーバにいる人が、あなたのサーバにある画像を
inline 画像として使用することを防ぎます。
これは推奨されている設定ではありませんが、ある限定された状況では有効です。
ここでは、すべての画像は /web/images
というディレクトリにあると仮定します。
SetEnvIf Referer "^http://www.example.com/" local_referal # Allow browsers that do not send Referer info SetEnvIf Referer "^$" local_referal <Directory /web/images> Order Deny,Allow Deny from all Allow from env=local_referal </Directory>
この手法に関する詳しい情報は ApacheToday のチュートリアル「Keeping Your Images from Adorning Other Sites 」を参照してください。
Apache HTTP Server Version 2.0
The latest version of this FAQ is always available from the main Apache web site, at <http://httpd.apache.org/docs/2.0/faq/>.
Since Apache 2.0 is quite new, we don't yet know what the Frequently Asked Questions will be. While this section fills up, you should also consult the Apache 1.3 FAQ to see if your question is answered there.
If you are having trouble with your Apache server software, you should take the following steps:
/usr/local/apache2/logs/error_log, but see the ErrorLog directive in your config files for the
location on your server.Apache has an active community of users who are willing to share their knowledge. Participating in this community is usually the best and fastest way to get answers to your questions and problems.
USENET newsgroups:
If you've gone through those steps above that are appropriate and have obtained no relief, then please do let the httpd developers know about the problem by logging a bug report.
If your problem involves the server crashing and generating a core dump, please include a backtrace (if possible). As an example,
# cd ServerRoot
# dbx httpd core
(dbx) where
(Substitute the appropriate locations for your ServerRoot
and your httpd and core files. You may have to use
gdb instead of dbx.)
With several million users and fewer than forty volunteer developers, we cannot provide personal support for Apache. For free support, we suggest participating in a user forum.
Professional, commercial support for Apache is available from a number of companies.
Apache uses the sendfile syscall on platforms
where it is available in order to speed sending of responses.
Unfortunately, on some systems, Apache will detect the presence of
sendfile at compile-time, even when it does not work
properly. This happens most frequently when using network or
other non-standard file-system.
Symptoms of this problem include the above message in the error
log and zero-length responses to non-zero-sized files. The
problem generally occurs only for static files, since dynamic
content usually does not make use of sendfile.
To fix this problem, simply use the EnableSendfile directive to disable
sendfile for all or part of your server. Also see
the EnableMMAP, which can
help with similar problems.
If you get error messages related to the AcceptEx syscall
on win32, see the Win32DisableAcceptEx
directive.
Most problems with CGI scripts result in this message written in the
error log together with an Internal Server Error delivered
to the browser. A guide to helping debug this type of problem is
available in the CGI
tutorial.
Apache HTTP Server Version 2.0
Apache uses the sendfile syscall on platforms
where it is available in order to speed sending of responses.
Unfortunately, on some systems, Apache will detect the presence of
sendfile at compile-time, even when it does not work
properly. This happens most frequently when using network or
other non-standard file-system.
Symptoms of this problem include the above message in the error
log and zero-length responses to non-zero-sized files. The
problem generally occurs only for static files, since dynamic
content usually does not make use of sendfile.
To fix this problem, simply use the EnableSendfile directive to disable
sendfile for all or part of your server. Also see
the EnableMMAP, which can
help with similar problems.
If you get error messages related to the AcceptEx syscall
on win32, see the Win32DisableAcceptEx
directive.
Most problems with CGI scripts result in this message written in the
error log together with an Internal Server Error delivered
to the browser. A guide to helping debug this type of problem is
available in the CGI
tutorial.
Apache HTTP Server Version 2.0
The latest version of this FAQ is always available from the main Apache web site, at <http://httpd.apache.org/docs/2.0/faq/>. In addition, you can view this FAQ all in one page for easy searching and printing.
Since Apache 2.0 is quite new, we don't yet know what the Frequently Asked Questions will be. While this section fills up, you should also consult the Apache 1.3 FAQ to see if your question is answered there.
Apache HTTP Server Version 2.0
If you are having trouble with your Apache server software, you should take the following steps:
/usr/local/apache2/logs/error_log, but see the ErrorLog directive in your config files for the
location on your server.Apache has an active community of users who are willing to share their knowledge. Participating in this community is usually the best and fastest way to get answers to your questions and problems.
USENET newsgroups:
If you've gone through those steps above that are appropriate and have obtained no relief, then please do let the httpd developers know about the problem by logging a bug report.
If your problem involves the server crashing and generating a core dump, please include a backtrace (if possible). As an example,
# cd ServerRoot
# dbx httpd core
(dbx) where
(Substitute the appropriate locations for your ServerRoot
and your httpd and core files. You may have to use
gdb instead of dbx.)
With several million users and fewer than forty volunteer developers, we cannot provide personal support for Apache. For free support, we suggest participating in a user forum.
Professional, commercial support for Apache is available from a number of companies.
Apache HTTP サーバ バージョン 2.0
Apache でのフィルタの使い方について記述しています。
| 関連モジュール | 関連ディレクティブ |
|---|---|
フィルタ とは、サーバが送受信したデータに 適用される処理プロセスのことをいいます。クライアントからサーバに 送られたデータは 入力フィルタ によって、サーバから クライアントに送られるデータは出力フィルタによって 処理されます。複数のフィルタを適用することができ、 その順番を厳密に指定することもできます。
Apache 内部では、チャンク (データのぶつ切り) を行ったり、
バイト範囲の指定されたリクエストを扱ったりといった機能を
行う際に、フィルタが使われています。それに加えて、
実行時の設定ディレクティブで選択が可能なフィルタを
モジュールが提供できます。
データに適応されるフィルタのセットは、
SetInputFilter,
SetOutputFilter,
AddInputFilter,
AddOutputFilter,
RemoveInputFilter,
RemoveOutputFilter
ディレクティブで制御できます。
現行の Apache HTTP サーバの配布では、 次のユーザ選択可能なフィルタが提供されています。
mod_include で Server-Side Include をします。mod_deflate
を使って、クライアントに送信する前に出力を圧縮します。また、mod_ext_filter モジュールで
外部プログラムをフィルタとして指定することができます。
Apache HTTP Server Version 2.0
This glossary defines some of the common terminology related to Apache in particular, and web serving in general. More information on each concept is provided in the links.
apxs
httpd binary that can be loaded on-demand.INCLUDES output filter
processes documents for → Server Side
Includes.www is a hostname, example.com is a domain name,
and www.example.com is a fully-qualified domain name.
cgi-script handler designates files to be processed as
→ CGIs./usr/local/apache2/conf/httpd.conf, but it may be moved using
run-time or compile-time configuration.GET, POST,
and PUT.
text/html,
image/gif, and application/octet-stream. In
HTTP, the MIME-type is transmitted in the Content-Type
→ header.httpd binary are
called static modules, while modules that are stored
separately and can be optionally loaded at run-time are called
dynamic modules or → DSOs.
Modules that are included by default
are called base modules. Many modules are available for Apache
that are not distributed as part of the Apache HTTP Server → tarball. These are referred to as
third-party modules./images/.*(jpg|gif)$". Apache uses Perl
Compatible Regular Expressions provided by the PCRE library.
tar utility.
Apache distributions are stored in compressed tar archives or using
pkzip.
http or
https, a hostname, and a path. A URL for this page is
http://httpd.apache.org/docs/2.0/glossary.html.
Apache HTTP サーバ バージョン 2.0
Apache のハンドラの使用に関して記述しています。
| 関連モジュール | 関連ディレクティブ |
|---|---|
「ハンドラ」とは、ファイルが呼ばれたときに実行される動作の Apache における内部表現です。 通常、ファイルはファイル型に基づいた暗黙のハンドラがあります。 普通はすべてのファイルは単にサーバに扱われますが、 ファイルタイプの中には別に「ハンドル」(訳注: 扱う) されるものもあります。
Apache 1.1 では、ハンドラを明示的に使用する機能が追加されました。 ファイルの拡張子や置いている場所に基づいて、 ファイル型と関係なくハンドラを指定することができます。 これはより優雅な解決法という点と、ファイルにタイプとハンドラの両方を関連付けることができるという点で優れています。 (複数の拡張子のあるファイルも参照してください)。
ハンドラはサーバに組み込んだり、モジュールとして含めたり、
Action
ディレクティブとして追加したりすることができます。
以下は標準配布に組み込まれているハンドラです。
default_handelr()
を使ってファイルを送ります。
静的なコンテンツを扱うときにデフォルトで使用されるハンドラです。
(core)mod_asis)mod_cgi)mod_imap)mod_info)mod_status)mod_negotiation)以下のディレクティブによって、拡張子が html
であるファイルは footer.pl
CGI スクリプトを起動するようになります。
Action add-footer /cgi-bin/footer.pl
AddHandler add-footer .html
CGI スクリプトは希望の修正や追加を行なって、元々要求された文書
(環境変数 PATH_TRANSLATED
で指されています) を送る責任があります。
以下のディレクティブは send-as-is
ハンドラを使用するように指示します。このハンドラは自分自身の HTTP
ヘッダを持っているファイルに使用されます。ここでは、拡張子に関わらず、
/web/htdocs/asis ディレクトリにある全てのファイルは
send-as-is ハンドラによって扱われます。
<Directory /web/htdocs/asis>
SetHandler send-as-is
</Directory>
ハンドラの機能を実装するために、利用すると便利かもしれないものが
Apache API
に追加されました。詳しく言うと、request_rec
構造体に新しいレコードが追加されたということです。
char *handler
もしモジュールがハンドラに関わりたい場合、
やらなければならないことは、リクエストが invoke_handler
ステージに達する以前に r->handler
を設定することだけです。ハンドラはコンテントタイプの代わりに
ハンドラ名を使うようになっていること以外は、以前と同じように実装されています。
必ず要求されているわけではありませんが、メディアタイプ
の名前空間を侵さないように、ハンドラの名前にはスラッシュを含まない、
ダッシュ (訳注: "-") で分離された名前を付ける習慣になっています。
Apache HTTP サーバ バージョン 2.0
「認証」とは、誰かが自分は誰であるかを主張した場合に、 それを確認するための全過程を指します。「承認」とは、 誰かが行きたい場所に行けるように、あるいは欲しい情報を 得ることができるようにするための全過程を指します。
| 関連モジュール | 関連ディレクティブ |
|---|---|
もし機密の情報や、ごくごく少数グループの人向けの情報を ウェブサイトに置くのであれば、この文書に書かれている テクニックを使うことで、そのページを見ている人たちが 望みの人たちであることを確実にできるでしょう。
この文書では、多くの人が採用するであろう、 ウェブサイトの一部分を保護する「一般的な」 方法についてカバーしています。
この文書で取り扱われるディレクティブは、
メインサーバ設定ファイル (普通は
<Directory>
セクション中) か、あるいはディレクトリ毎の設定ファイル
(.htaccess ファイル) かで用います。
.htaccess ファイルを用いるのであれば、
これらのファイルに認証用のディレクティブを置けるように
サーバの設定をしないといけないでしょう。これは
AllowOverride
ディレクティブで可能になります。
AllowOverride
ディレクティブでは、ディレクトリ毎の設定ファイル中に置くことのできる
ディレクティブを、もしあれば、指定します。
認証について話を進めているので、次のような
AllowOverride
ディレクティブが必要になるでしょう。
AllowOverride AuthConfig
そうでなく、メインサーバ設定ファイルの中に 直接置くのであれば、当然ながらそのファイルへの書き込み 権限を持っていなければならないでしょう。
また、どのファイルがどこに保存されているか知るために、 サーバのディレクトリ構造について少し知っておく 必要があるでしょう。 これはそんなに難しくないので、この文書中で ディレクトリ構造について知っておく必要がある場面では、 明らかになるようにします。
では、サーバ上のあるディレクトリをパスワードで保護する 基本手順を示します。
パスワードファイルを作る必要があります。
このファイルは、ウェブからアクセスできる場所に
置くべきではありません。他の人がパスワードファイルを
ダウンロードできないようにするためです。例えば、
/usr/local/apache/htdocs でドキュメントを
提供しているのであれば、パスワードファイルは
/usr/local/apache/passwd
などに置いた方が良いでしょう。
ファイルを作るためには、Apache 付属の htpasswd
を使います。このコマンドは Apache をどこにインストールしようとも、
インストールディレクトリの bin
ディレクトリ以下に置かれます。ファイルを作るには、次のように
タイプしてください。
htpasswd -c /usr/local/apache/passwd/passwords rbowen
htpasswd は、パスワードを要求し、その後
確認のためにもう一度入力するように要求してきます。
# htpasswd -c /usr/local/apache/passwd/passwords rbowen
New password: mypassword
Re-type new password: mypassword
Adding password for user rbowen
もし htpasswd がパスの中に入っていない場合は、
もちろん、実行するためにプログラムまでのフルパスを
タイプする必要があります。私のサーバであれば、
/usr/local/apache/bin/htpasswd
にプログラムが置かれています。
次に、サーバがパスワードを要求するように設定して、
どのユーザがアクセスを許されているかをサーバに知らせなければ
なりません。 httpd.conf を編集するか
.htaccess ファイルを使用するかで
設定します。例えば、ディレクトリ
/usr/local/apache/htdocs/secret
を保護したい場合は、
/usr/local/apache/htdocs/secret/.htaccess
か httpd.conf 中の <Directory
/usr/local/apache/apache/htdocs/secret> セクションに
配置して、次のディレクティブを使うことができます。
AuthType Basic
AuthName "Restricted Files"
AuthUserFile /usr/local/apache/passwd/passwords
Require user rbowen
個々のディレクティブについて見てみましょう。
AuthType
ディレクティブはどういう認証方法でユーザの認証を行うかを
選択します。最も一般的な方法は Basic
で、これは mod_auth
で実装されています。しかしながら、
これは気を付けるべき重要なポイントなのですが、
Basic 認証はクライアントからブラウザへ、
パスワードを暗号化せずに送ります。ですから、
この方法は特に機密性の高いデータに対しては用いるべきでは
ありません。 Apache ではもう一つ別の認証方法:
AuthType Digest をサポートしています。
この方法は mod_auth_digest
で実装されていて、もっと安全です。
ごくごく最近のクライアントしか Digest
認証をサポートしていないようです。
AuthName
ディレクティブでは、認証に使う Realm (訳注: 領域)
を設定します。Realm は大きく分けて二つの機能を提供します。
一つ目は、クライアントがパスワードダイアログボックスの
一部としてユーザにこの情報をよく提示する、というものです。
二つ目には、クライアントが与えられた認証領域に対してどのパスワードを
送信すれば良いのかを決定するために使われる、という機能です。
例えば、"Restricted Files" 領域中で
一度認証されれば、同一サーバ上で "Restricted Files"
Realm としてマークされたどんな領域でも、クライアントは
自動的に同じパスワードを使おうと試みます。
このおかげで、複数の制限領域に同じ realm を共有させて、
ユーザがパスワードを何度も要求される事態を
防ぐことができます。もちろん、セキュリティ上の理由から、
サーバのホスト名が変わればいつでも必ず、
クライアントは再びパスワードを尋ねる必要があります。
AuthUserFile
ディレクティブは htpasswd で作った
パスワードファイルへのパスを設定します。
ユーザ数が多い場合は、リクエスト毎のユーザの認証のための
プレーンテキストの探索が非常に遅くなることがあります。
Apache ではユーザ情報を高速なデータベースファイルに
保管することもできます。
mod_auth_dbm モジュールが
AuthDBMUserFile
ディレクティブを提供します。これらのファイルは dbmmanage
プログラムで作成したり操作したりできます。
Apache
モジュールデータベース中にあるサードパーティー製の
モジュールで、その他多くのタイプの認証オプションが
利用可能です。
最後に、Require
ディレクティブが、サーバのこの領域にアクセスできるユーザを
指定することによって、プロセスの承認部分を提供します。
次のセクションでは、Require
ディレクティブの様々な用法について述べます。
上記のディレクティブは、ただ一人 (具体的にはユーザ名
rbowen の誰か) がディレクトリに
入れるようにします。多くの場合は、複数の人が
入れるようにしたいでしょう。ここで
AuthGroupFile
の登場です。
もし複数の人が入れるようにしたいのであれば、 グループに属するユーザの一覧の入っている、グループ名のついた グループファイルを作る必要があります。このファイルの 書式はきわめて単純で、お好みのエディタで生成できます。 ファイルの中身は次のようなものです。
GroupName: rbowen dpitts sungo rshersey
一行にスペース区切りで、グループに所属するメンバーの 一覧をならべるだけです。
既に存在するパスワードファイルにユーザを加える場合は、 次のようにタイプしてください。
htpasswd /usr/local/apache/passwd/passwords dpitts
以前と同じ応答が返されますが、新しいファイルを
作るのではなく、既にあるファイルに追加されています。
(新しいパスワードファイルを作るには -c
を使います。)
ここで次のようにして .htaccess ファイルを
修正する必要があります。
AuthType Basic
AuthName "By Invitation Only"
AuthUserFile /usr/local/apache/passwd/passwords
AuthGroupFile /usr/local/apache/passwd/groups
Require group GroupName
これで、グループ GroupName にリストされていて、
password ファイルにエントリがある人は、
正しいパスワードをタイプすれば入ることができるでしょう。
もっと特定せずに複数のユーザが入れるようにする、 もう一つの方法があります。グループファイルを作るのではなく、 次のディレクティブを使えばできます。
Require valid-user
require user rbowen 行でなく、上記を使うと、
パスワードファイルにリストされている人であれば誰でも
許可されます。
単にパスワードファイルをグループ毎に分けておくことで、
グループのような振る舞いをさせることもできます。
このアプローチの利点は、Apache は二つではなく、
ただ一つのファイルだけを検査すればよいという点です。
欠点は、たくさんのパスワードファイルを管理して、その中から
AuthUserFile
ディレクティブに正しいファイルを参照させなければならない点です。
Basic 認証が指定されている場合は、 サーバにドキュメントをリクエストする度に ユーザ名とパスワードを検査しなければなりません。 これは同じページ、ページにある全ての画像を リロードする場合であっても該当します (もし画像も保護されたディレクトリから来るのであれば) 。 予想される通り、これは動作を多少遅くします。 遅くなる程度はパスワードファイルの大きさと比例しますが、 これは、ファイルを開いてあなたの名前を発見するまで ユーザ名のリストを読まなければならないからです。 そして、ページがロードされる度にこれを行わなければ なりません。
結論としては、一つのパスワードファイルに置くことのできる ユーザ数には実質的な限界があります。 この限界はサーバマシンの性能に依存して変わりますが、 数百のエントリを越えたあたりから速度低下が見られると予期されています。 その時は他の認証方法を考慮に入れた方が良いでしょう。
ユーザ名とパスワードによる認証は認証の一つの方法に過ぎません。 しばしば誰であるかということとは違う何かに基づいて、 入れるようにしたくなることもあるでしょう。 例えばその人がどこから来ているかといったことです。
Allow と
Deny
ディレクティブを使って、ドキュメントを要求してきたマシンの
ホスト名やホストアドレスに基づいて許可不許可を制御できます。
Order
ディレクティブはこの二つと連携して動作し、Apache
にどの順番でフィルタを適用するかを知らせます。
これらのディレクティブの使い方は次のようになります。
Allow from address
ここで、address は IP アドレス (または IP アドレスの一部)、あるいは完全修飾ドメイン名 (またはドメイン名の一部) です。 必要であれば複数のアドレスやドメイン名を指定できます。
例えば、もし誰かが掲示板を攻撃していて、 その人を閉め出したいのであれば、 次のようにすることができます。
Deny from 205.252.46.165
このアドレスから来る人は、このディレクティブの範囲内の コンテンツを見ることができないません。もし IP アドレスの代わりにマシン名があれば、それを使えます。
Deny from host.example.com
ドメイン全体からのアクセスを防ぎたければ、 単にアドレスやドメイン名の一部を指定することができます。
Deny from 192.101.205
Deny from cyberthugs.com moreidiots.com
Deny from ke
Order を使うことで、
Deny と
Allow の組み合わせで
入っても良いグループが本当に確実に限定できているようにできます。
Order deny,allow
Deny from all
Allow from dev.example.com
Allow
ディレクティブを単純に列挙するのでは望みの動作をしないでしょう。
なぜなら、全ての人が入れるということに加えて、
指定したホストからの人が入れるようにするからです。
やりたいことは、指定した人たちだけが入れるように
することです。
これら全てがどのように動作するかについて
もっと多くの情報が書かれている mod_auth と
mod_access
の文書も読むとよいでしょう。
Apache HTTP サーバ バージョン 2.0
| 関連モジュール | 関連ディレクティブ |
|---|---|
CGI (Common Gateway Interface) は、ウェブサーバが コンテンツ生成をする外部プログラムと協調して動作するための方法を 定義しています。そのプログラムはしばしば CGI プログラムや CGI スクリプトと呼ばれます。CGI は、ウェブサイトに動的な コンテンツを置くための最も簡単で一般的な方法です。このドキュメントは、 Apache ウェブサーバで CGI を設定し、 CGI プログラムを書き始めるための入門書となるでしょう。
CGI プログラムを正しく動作させるには、CGI を許可するように Apache の設定を行う必要があります。 これを行なうための方法がいくつかあります。
ScriptAlias
ディレクティブを使用して、
CGI プログラム用の特別な別ディレクトリを Apache に設定します。
Apache は、このディレクトリ中の全てのファイルを CGI
プログラムであると仮定します。
そして、この特別なリソースがクライアントから要求されると、
そのプログラムの実行を試みます。
ScriptAlias
ディレクティブは以下のように使用します:
ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
デフォルト位置に Apache をインストールしたならば、
この例はデフォルト状態の httpd.conf
設定ファイルに含まれています。
ScriptAlias
ディレクティブは、URL の前に付加するディレクトリを定義する
Alias
ディレクティブとかなり似ています。
Alias と ScriptAlias
は通常、DocumentRoot
ディレクトリ外のディレクトリのために使用されます。
Alias と ScriptAlias
との差は、ScriptAlias が接頭辞で始まるすべての
URL は CGI プログラムとみなされるという追加の意味を含んでいることです。
従って、上記の例では、/cgi-bin/
で始まるリソースへのあらゆるリクエストに対して、ディレクトリ
/usr/local/apache2/cgi-bin/ から提供し、それらを
CGI プログラムとして扱うよう Apache に示します。
例えば、URL http://dev.rcbowen.com/cgi-bin/test.pl
が要求された場合、Apache は ファイル
/usr/local/apache2/cgi-bin/test.pl
を実行し、その出力を返すことを試みます。
もちろん、ファイルが存在し、実行可能であり、決められた方法で出力を返します。
そうでなければ、Apache はエラーメッセージを返します。
CGI プログラムは、セキュリティ上の理由から
ScriptAlias
されたディレクトリに制限されることがしばしばあります。この方法により、
CGI プログラムを使用できるユーザを管理者が厳しく制御することができます。
しかしながら、適切なセキュリティ事前対策がとられるならば、CGI
プログラムを任意のディレクトリで実行できないようにする理由はありません。
例えば、ユーザに UserDir
ディレクティブで彼らのホームディレクトリ配下にウェブコンテンツを持たせたいとします。
もし、彼らが CGI プログラムを持つことを望んでいても、メインの
cgi-bin ディレクトリへのアクセスができない場合、
CGI プログラムを実行することができる他の場所が必要になります。
任意のディレクトリで CGI の実行を許可するには二段階の設定が必要です。
まず、AddHandler や SetHandler ディレクティブによって
cgi-script ハンドラが可能になっている必要があります。
次に、Options ディレクティブで
ExecCGI が指定されていなければなりません。
サーバのメインの設定ファイル中で Options
ディレクティブを明示的に使用することで、特定のディレクトリ配下で
CGI の実行を許可するように指定することができます:
<Directory /usr/local/apache2/htdocs/somedir>
Options +ExecCGI
</Directory>
上記ディレクティブは、CGI ファイルの実行を可能にするよう
Apache に伝えます。また、どのファイルが CGI ファイルかを
サーバに伝える必要があります。次の
AddHandler
ディレクティブの例では、cgi または pl
を拡張子に持つすべてのファイルを CGI
プログラムとしてみなすことをサーバに伝えます:
AddHandler cgi-script .cgi .pl
.htaccess チュートリアル
は httpd.conf を変更できない場合にどうやって CGI プログラムを
使えるようにするかを説明しています。
.cgi で終わるすべてのファイルに対して CGI プログラムの
実行を許可するには、以下の設定を使用できます。
<Directory /home/*/public_html>
Options +ExecCGI
AddHandler cgi-script .cgi
</Directory>
ユーザディレクトリの cgi-bin サブディレクトリの
すべてのファイルを CGI プログラムとして指定したい場合には
以下のようなものを使います。
<Directory /home/*/public_html/cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Directory>
「通常の」プログラミングと CGI プログラミングの間には主に二つの違いがあります。
一つは、CGI プログラムのすべての出力には MIME-type ヘッダを付けなければなりません。 これはどのような種類のコンテンツを受け取っているかをクライアントに示す HTTP ヘッダです。ほとんどの場合では、次のように出力します:
Content-type: text/html
もう一つは、出力を HTML か、ブラウザが表示することができる何か他の形式にする必要があります。 大抵の場合は HTML でしょうが、GIF イメージや他の非 HTML コンテンツを出力する CGI プログラムを書くこともあるでしょう。
これら二点以外では、CGI プログラムを書くことは、 あなたが書いている他のプログラムとよく似ているでしょう。
次に示すのは、ブラウザに 1 行印字する CGI
プログラムの例です。以下を入力し、first.pl
というファイルに保存し、それを cgi-bin
ディレクトリに置いてください。
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello, World.";
Perl に精通していなくても、
何が起こるかを理解することはできるでしょう。1 行目は、
/usr/bin/perl で見つけられるインタプリタに
このファイルを供給することでこのプログラムが実行されることを
Apache に (シェル上で実行しようとしているならば、そのシェルに )
示します。2 行目は、前述したとおり content-type の定義を印字します。
これには復帰改行の二つの組を後に付加します。
これにより、ヘッダの終りに空行が置かれ、HTTP
ヘッダの終りとボディの始まりを示します。3 行目は、"Hello, World."
という文字列を印字し、これで終りとなります。
好みのブラウザを開き、アドレス
http://www.example.com/cgi-bin/first.pl
あるいはファイルを置いたロケーションを指定すると、
Hello, World.
という 1 行がブラウザウィンドに現れるでしょう。
それはあまりエキサイティングなことではありません。
しかし、これがうまく動けば、
他のどのようなものでも動かすことができるようになります。
ウェブから CGI プログラムへのアクセスを行なったとき、 ブラウザで見る可能性がある四つの基本的なことがあります:
Content-Type を CGI プログラム内で
セットしたかを確認してください。サーバはあなたの権限で実行されていないのを忘れないように。
つまり、起動するとき、サーバは特権をもたないユーザ - 通常 nobody
や www の権限で実行されます。したがって、あなたが所有する
ファイルを実行するには別のパーミッションが必要となります。
通常、nobody が実行するのに十分なパーミッションを与える方法は、
ファイルに誰でも実行可能とするパーミッションを与えることです:
chmod a+x first.pl
また、もしあなたのプログラムが他のファイルを読み書きするならば、 それらのファイルは、これが可能となる正しいパーミッション を持っている必要があります。
コマンドラインからプログラムを実行するとき、
意識しなくてもシェルに渡される情報があります。
例えば、参照するファイルのためにどこを検索したらよいかを
シェルに伝える PATH があります。
プログラムが CGI プログラムとしてウェブサーバによって実行されるとき、
それは同じ PATH ではないかもしれません。
CGI プログラム内で呼び出すあらゆるプログラム
(例えば、sendmail のようなもの) は、
フルパスで指定する必要があるでしょう。それにより、CGI
プログラムを実行しようとしたとき、
シェルはそのようなプログラムを見つけることができます。
同様なことは、スクリプトのインタプリタ (しばしば perl)
へのパスで、CGI プログラムの 1 行目に次のように示されます:
#!/usr/bin/perl
これがインタープリタへの実際のパスであることを確実にしておきます。
CGI プログラムが失敗するのは大抵、プログラム自身に問題がある場合です。 一度 CGI の使い方を理解し、前述の二つの誤りを犯していないならば、 まず間違いなくそうでしょう。ブラウザを使ってテストする前に まず確認することは、コマンドラインからプログラムが実行できることです。 例えば、以下を実行してみてください:
cd /usr/local/apache2/cgi-bin
./first.pl
(perl インタプリタは呼ばないでください。
シェルと Apache がスクリプトの最初の行の パス情報 を使って見つけます。)
最初にプログラムから出力されるのは Content-Type を含み、
後に空行の続く HTTP ヘッダでなければなりません。他のものが出力されている
場合は、Apache はこのプログラムをサーバ経由で実行しようとしたときには
Premature end of script headers エラーを出力します。詳細は
上記の CGI プログラムを書く を読んでください。
エラーログは友達です。 全てのうまくいかないことは、エラーログにメッセージを生成します。 必ずそれを最初に見るべきです。 もし、あなたがウェブサイトを主催している場所が エラーログの参照を許していないならば、きっと他のサイトで主催するべきです。 エラーログの読み方を学ぶことで、ほとんど全ての問題が迅速に確認され、 迅速に解決されるということが分かるでしょう。
suexec サポートプログラムは
バーチャルホストやユーザのホームディレクトリの場所に依って
CGI プログラムを違うユーザ権限の下で走らせることを可能にします。
Suexec の権限のチェックは非常に厳しく、それを満たさない場合は
CGI プログラムが Premature end of script headers エラーで
実行されません。
suexec を使っているかどうかを調べためには apachectl
-V を実行して、SUEXEC_BIN の場所を調べてください。
Apache がそこに suexec のバイナリを発見した場合は、suexec が
使用されます。
suexec を完全に理解していない限り、使うべきではありません。
suexec を無効にするには、SUEXEC_BIN から指されている
suexec バイナリを削除 (か名前を変更) するだけです。
suexec を読んだ後で、まだそれを
使いたいのであれば、suexec -V を実行して suexec の
ログファイルの位置を調べ、そのログファイルを使ってポリシー違反を
見つけてください。
CGI プログラミングに習熟すると、 裏で起こっていることについて更に理解すること役に立ちます。 ブラウザとサーバがどのように相互通信するかについては特にそうです。 なぜなら、"Hello, World." を印字するプログラムを書くことはおおいに結構ですが、 それは特に有益ではありません。
環境変数は、
あなたがコンピュータを使うときに辺りに存在している値です。
それらは、パス
(コマンドをタイプしたときに実行する実際のファイルを探し出すところ)、
ユーザ名、端末型などのような便利なものです。
通常、普段使用している環境変数の完全なリストを調べるには、
コマンドプロンプトで env を入力します。
CGI の処理中、サーバとブラウザも環境変数を設定し、 それにより相互に通信することができるようになります。 その環境変数は、ブラウザタイプ (Netscape, IE, Lynx)、サーバタイプ (Apache, IIS, WebSite)、実行されている CGI プログラムの名前などです。
これらの変数は CGI プログラマが使用できます。 そして、それはクライアントとサーバの通信の話の半分です。 必要な変数の完全なリストは http://hoohoo.ncsa.uiuc.edu/cgi/env.html にあります。
以下の単純な Perl CGI
プログラムは、渡される全ての環境変数を表示します。同様のプログラムは、
Apache ディストリビューションの cgi-bin
ディレクトリに二つ含まれています。
いくつかの変数が必須であり、いくつかは任意であることに注意してください。
そして、公式のリストにはないいくつかの変数が表示されているかもしれません。
さらに、Apache はデフォルトで用意されている基本的なものに
あなた自身の環境変数を加えるための、
多くの異なる方法を用意してします。
#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}
サーバとクライアント間のもう一つの通信は、標準入力
(STDIN)と標準出力 (STDOUT)
を通じて行なわれます。通常の文脈において、STDIN
はキーボードやプログラムが動作するために与えられるファイルを意味し、
STDOUT は通常コンソールまたはスクリーンを意味します。
ウェブフォームから CGI プログラムへPOST
したとき、フォームのデータは特別なフォーマットで束ねられ、
STDIN を通して、CGI プログラムに引き渡されます。
プログラムはデータがキーボード
もしくはファイルから来ていたかのように処理することができます。
「特別なフォーマット」はとても単純です。フィールド名と値はイコール (=) で結ばれます。そして値の組はアンパサンド (&) で結ばれます。 スペース、アンパサンド、イコールのような面倒な文字は、 それらが動作を駄目にしないようにその文字に相当する 16 進に変換されます。 全データ文字列は、以下のようになります:
name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey
時々、このような文字列が URL
に付加されるのを見るでしょう。その場合、サーバは
QUERY_STRING という環境変数にその文字列を入れます。それは
GET リクエストと呼ばれます。
HTML フォームでは、データを渡すために GET と
POST のどちらを使用するかを、FORM タグの
METHOD 属性の設定で指定します。
CGI プログラムは、その文字列を役に立つ情報に分割する責任があります。 幸いにも、そのデータ処理を助けるライブラリやモジュールが存在します。 これらは、CGI プログラムの他の面でも同様に役に立ちます。
CGI プログラムを書くとき、面倒な仕事の大部分をしてくれる コードライブラリまたはモジュールを使うことを検討すべきです。 これはエラーを減らし、早い開発につながります。
Perl で CGI プログラムを書いているなら、モジュールは CPAN で提供されています。
この目的のための最も普及しているモジュールは CGI.pm です。
CGI::Lite も検討しましょう。これは、ほとんどのプログラム
において必要とするすべての機能の最小セットの実装です。
C で CGI プログラムを書いているなら、いろいろな
オプションがあります。これらの内の一つは http://www.boutell.com/cgic/
で提供されている CGIC ライブラリです。
CGI に関する情報はウェブで数多く提供されています。CGI の問題については Usenet の comp.infosystems.www.authoring.cgi で、 他のユーザと論議することができます。HTML Writers Guide の -servers メーリングリストは、あなたの質問に回答してくれる偉大なリソースです。 http://www.hwg.org/lists/hwg-servers/ で更に多くを探し出すことができます。
そしてもちろん、おそらく CGI プログラムの動作に関する詳細の全てが記述されている CGI の仕様を読むべきです。オリジナルバージョンを NCSA で、アップデートされたドラフトを Common Gateway Interface RFC プロジェクトで参照することができます。
CGI の問題について、加わっているメーリングリストまたはニュース グループに質問を送るとき、起こったもの、起こってほしいこと、 実際に起こったことがどう違うか、使用しているサーバ、 CGI プログラムを記述している言語に関する十分な情報と、 可能であれば問題のコードを提供するようにしてください。 そうすることで、問題がより間単に見つかるようになります。
Apache のソースコードにおいて問題を発見したことを確信していない限り、 CGI の問題に関する質問を Apache バグデータベースに送るべきでない ことに注目してください。
Apache HTTP サーバ バージョン 2.0
.htaccess ファイルはディレクトリ毎に設定を変更する方法を
提供します。
| 関連モジュール | 関連ディレクティブ |
|---|---|
.htaccess ファイル (「分散設定ファイル」) は
ディレクトリ毎に設定を変更する方法を提供します。ディレクティブの
書かれたファイルをディレクトリに置くことで、そのディレクトリとその
サブディレクトリすべてにディレクティブを適用させることができます。
.htaccess ファイルを別の名前にしたい場合は、
AccessFileName ディレクティブを
使って変更することができます。例えば、そのファイルを .config
という名前にしたい場合は、以下の設定をサーバ設定ファイルに入れることが
できます:
AccessFileName .config
一般に、.htaccess ファイルの構文は
主設定ファイル
と同じです。これらのファイルに書くことのできるディレクティブは AllowOverride ディレクティブにより決まります。
このディレクティブは、.htaccess ファイルに
書かれたディレクティブの中で、、
どのディレクティブが適用されるかをカテゴリー単位で指定します。
.htaccess に書くことのできるディレクティブであれば、
説明文書には「上書き」という項目があり、.htaccess に書くことができるように
なるための AllowOverride の値が指定されています。
例えば、AddDefaultCharset ディレクティブの説明を
見ると、.htaccess ファイルでの使用が許可されていることが
わかります。 (ディレクティブの概要の所にある「コンテキスト」と書かれている
行を見てください。) 上書きと書かれている行には
FileInfo とあります。ですから、.htaccess 中の
このディレクティブが有効になるためには、少なくとも
AllowOverride FileInfo が設定されている必要があります。
あるディレクティブを .htaccess ファイルに書くことができるか
どうかわからないときは、そのディレクティブの説明を探して、".htaccess"
のための「コンテキスト」の行を調べてください。
一般的に、サーバの主設定ファイルにアクセスできない場合を除いて、
.htaccess ファイルの使用は極力避けてください。
世の中には、例えば、ユーザ認証は常に .htaccess ファイルで
行なわなければならない、という誤解が広まっていますが、まったくそんなことは
ありません。ユーザ認証の設定はサーバ主設定ファイルに書くことができ、
実際、その方がより良い設定方法です。
.htaccess ファイルはコンテンツ提供者がディレクトリ毎の
設定を行ないたいけれど、サーバシステムの root アクセス権限を持っていない
という場合にのみ使うべきものです。サーバ管理者が頻繁に設定変更を行ないたくは
ない、というときには個々のユーザが .htaccess ファイルを使って
自分で設定の変更を行なうことを許可した方が良いときもあるでしょう。
これは特に、ISP が複数のユーザのサイトを一つのマシンでホストしていて、
各ユーザが設定の変更をできるようにしたいようなときにあてはまります。
しかし、普通は可能であれば .htaccess ファイルの使用は
避けてください。.htaccess ファイルに書こうと考えるような
すべての設定は、サーバの主設定ファイルの <Directory> セクションで同じように行なうことが
できます。
.htaccess ファイルの使用を避ける理由は主に二つあります。
一つ目はサーバの性能の問題です。AllowOverride ディレクティブが
.htaccess ファイルの設定を許可している場合は、Apache は
各ディレクトリで .htaccess ファイルを探します。
ですから、.htaccess ファイルを許可すると、実際に使用しているか
どうかに関わらず、性能の低下を招くことになります! また、.htaccess
ファイルは文書がリクエストされる度に読み込まれます。
さらに、Apache は適用すべきディレクティブを集めるために、すべての
上位のディレクトリの .htaccess ファイルを探す必要があることにも
注意してください。(ディレクティブが適用される方法を
参照してください。)ですから、/www/htdocs/example にある
ファイルがリクエストされたときは、Apache は以下のファイルを調べます。
/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess
ですから、そのディレクトリのそれぞれのファイルへのアクセスに対して、
上の例のファイルがまったく存在しないときでも、追加のファイルシステムの
アクセスが行なわれることになります。(これは、.htaccess が
/ に対して有効になっているときの場合で、普通はそうなって
いないことに注意してください。)
二つ目はセキュリティです。ユーザにサーバの設定を変更することを
許可することになりますので、あなた自身が管理できない変更をされる
恐れがあります。ユーザにこの特権を与えるのが良いのかどうか、十分
検討してください。また、ユーザに与える権限が必要なものよりも少なすぎると、
余分な技術サポート報告を受け取るようになる可能性が高いことにも
注意してください。確実に、ユーザにどの程度の権限を与えたか明確に告げるように
してください。AllowOverride に
何を設定したかということと、関連する文書を示すことで、
後々の混乱をぐっと減らすことが
できます。
ところで、ディレクティブの書かれた .htaccess を
/www/htdocs/example に置くことと、同じディレクティブを
主サーバ設定の Directory セクション
<Directory /www/htdocs/example> に書くことは
完全に等価です:
/www/htdocs/example の .htaccess ファイル:
/www/htdocs/example の .htaccess ファイルの
内容
AddType text/example .exm
httpd.conf のセクション
file
<Directory /www/htdocs/example>
AddType text/example .exm
</Directory>
しかし、この設定はサーバ設定ファイルに書いた方がパフォーマンスの 低下が少なくなります。ファイルがリクエストされる度に 読み込まれる代わりに、Apache の起動時に 1 回だけ読み込めば よくなるからです。
AllowOverride ディレクティブの
値を none に設定することで .htaccess ファイル
の使用を完全に無効にすることができます。
AllowOverride None
.htaccess ファイルの設定ディレクティブは .htaccess
ファイルの存在するディレクトリと、そのサブディレクトリすべてに適用されます。
しかし、上の階層のディレクトリにも .htaccess ファイルが
存在するかもしれないことを覚えておくことは大切です。ディレクティブは現れる
順番に適用されます。ですから、あるディレクトリの .htaccess は
ディレクトリツリーのより上の階層の .htaccess ファイルの
設定を上書きするかもしれません。そして、その .htaccess も
より上の階層で書かれたディレクティブを上書きしたり、主サーバ設定ファイル
そのものの設定を上書きしたりしているかもしれません。
例:
ディレクトリ /www/htdocs/example1 に以下の内容の
.htaccess ファイルがあります:
Options +ExecCGI
(注: .htaccess
ファイルで "Options" ディレクティブが有効になるためには、
"AllowOverride Options" を有効にする必要があります。)
ディレクトリ /www/htdocs/example1/example2 には
以下のような .htaccess ファイルがあります:
Options Includes
二つめの .htaccess により、ディレクトリ
/www/htdocs/example1/example2 では CGI の実行は
許可されません。これは、Options Includes のみが
効力を持ち、それがすべての以前の設定を上書きするからです。
もし認証の方法を知るためにこの部分に直接来たのであれば、次のことを
知っておくことが重要です。よくある誤解に、パスワード認証を行なうためには
.htaccess ファイルを使う必要がある、というものがあります。
これは正しくありません。主サーバ設定ファイルの <Directory> セクションに
認証用のディレクティブを書く方が推奨される方法で、.htaccess
ファイルは主サーバ設定ファイルを変更できないときにのみ使用すべきです。
いつ .htaccess ファイルを使うべきで、いつ使うべきではないかに
ついては 上を参照してください。
以上のことをふまえた上で、もし .htaccess の使用が
まだ必要だと思う場合は、次のようなものが望みのことをしてくれるかも
しれません。
ディレクティブが適用されるためには、
"AllowOverride AuthConfig" の設定がなされている
必要があります。
.htaccess ファイルの内容:
AuthType Basic
AuthName "Password Required"
AuthUserFile /www/passwords/password.file
AuthGroupFile /www/passwords/group.file
Require Group admins
これらのディレクティブが有効になるためには、
AllowOverride AuthConfig が有効でなくてはならないことに
注意してください。
認証と承認については 認証チュートリアルを 参照してください。
もう一つの .htaccess ファイルのよくある利用法は
特定のディレクトリで SSI を有効にすることです。これは、望みのディレクトリの
.htaccess ファイルに以下の設定ディレクティブを書くことで
達成できます:
Options +Includes
AddType text/html shtml
AddHandler server-parsed shtml
これらのディレクティブが有効になるためには、
AllowOverride Options と AllowOverride
FileInfo が有効になっている必要があることに注意してください。
よりまとまった SSI の説明は SSI チュートリアルを 参照してください。
最後に、特定のディレクトリで CGI プログラムの実行を許可したいことが あるでしょう。これは以下の設定で行なうことができます:
Options +ExecCGI
AddHandler cgi-script cgi pl
もしくは、あるディレクトリのすべてのファイルが CGI プログラムと みなされるようにしたいなら、以下の設定で実現することができます:
Options +ExecCGI
SetHandler cgi-script
これらのディレクティブが有効になるためには、
AllowOverride Options と AllowOverride
FileInfo が有効である必要があることに注意してください。
CGI プログラムと設定のよりまとまった説明は CGI チュートリアルを参照してください。
設定ディレクティブを .htaccess ファイルに書いたけれども、
期待した効果が得られないときには、いくつかの原因が考えられます。
一番よくあることは、設定ディレクティブが考慮されるようには
AllowOverride が設定されていない
というものです。該当のファイルのスコープに AllowOverride None
が設定されていないことを確認してください。これを調べるための良い方法は、
.htaccess ファイルにごみを書いて、リロードすることです。
サーバのエラーが生成されないときは、ほぼ確実に AllowOverride
None が設定されている状態になっています。
そうではなく、文書をアクセスしようとしたときにエラーが発生している
ときは、Apache のエラーログを調べてください。.htaccess ファイルで
使用されたディレクティブが許可されていない、ということを知らせている
可能性が高いです。または、構文の間違いがあることを述べているかもしれません。
その場合にはまずそれを修正する必要があります。
Apache HTTP サーバ バージョン 2.0
認証とは、誰かが自分は誰であるかを名乗っているものを検証する 処理のことです。承認とは、誰かが望みの場所に辿り着けたり、 望みの情報を手に入れたりすることを許可する処理のことです。
参照: 認証、承認、アクセス制御
CGI (Common Gateway Interface) はウェブサーバが外部のコンテンツ 生成プログラムとどのように相互動作をするかを定義します。 その外部プログラムは通常 CGI プログラムや CGI スクリプトと呼ばれます。 CGI はウェブサイトに動的なコンテンツを追加するための、 一番単純でよく使われている方法です。この文書は Apache ウェブサーバに CGI を設定し、CGI プログラムを書き始めるためのイントロダクションです。
参照: CGI: 動的コンテンツ
.htaccess ファイル.htaccess ファイルはディレクトリ毎に設定を変更するための
方法を提供します。設定ディレクティブが書かれたファイルが、あるドキュメント
ディレクトリに置かれると、ディレクティブはそのディレクトリと
すべてのサブディレクトリに適用されます。
参照: .htaccess ファイル
SSI (Server Side Includes) は HTML ページ中に書かれるディレクティブで、 ページが送られる時にサーバにより評価されます。これにより、ページ全体を CGI プログラムで生成したり、他の動的な技術を使うことなく、既存の HTML ページに動的に生成された内容を付加することができます。
Apache HTTP サーバ バージョン 2.0
複数のユーザのいるシステムでは、UserDir ディレクティブを使って
各ユーザがホームディレクトリにウェブサイトを構築できるように設定することが
可能です。URL http://example.com/~username/ を訪れた人は
"username" というユーザの UserDir ディレクティブで指定された
サブディレクトリからコンテンツを得ることになります。
| 関連モジュール | 関連ディレクティブ |
|---|---|
UserDir ディレクティブは
ユーザ毎のコンテンツが読み込まれるディレクトリを指定します。
このディレクティブはいろいろ違った形式を取ることができます。
スラッシュで始まらないパスが与えられたときは、ユーザのホームディレクトリ からの相対パスとみなされます。次の設定があったときに:
UserDir public_html
URL http://example.com/~rbowen/file.html は
パス /home/rbowen/public_html/file.html へ
変換されます。
パスがスラッシュで始まるときは、ディレクトリパスはそのパスに ユーザ名を加えたものからなります。次の設定のとき:
UserDir /var/html
URL http://example.com/~rbowen/file.html は
パス /var/html/rbowen/file.html へ変換されます。
アスタリスク (*) を含むパスが指定されたときは、アスタリスクを ユーザ名で置換したものが使用されます。このような設定だと:
UserDir /var/www/*/docs
URL http://example.com/~rbowen/file.html は
パス /var/www/rbowen/docs/file.html へ変換されます。
UserDir のドキュメントに示されている構文を使うことで、 どのユーザがこの機能を使うことができるかを制限することができます:
UserDir enabled
UserDir disabled root jro fish
上の設定は dissabled 文のユーザ以外のすべてのユーザに
対して UserDir の機能を有効にします。同様にして、以下のように
数名のユーザ以外に対してこの機能を無効にすることもできます:
UserDir disabled
UserDir enabled rbowen krietz
他の例は UserDir
の説明を参照してください。
それぞれのユーザに専用の cgi-bin ディレクトリを与えるために、
<Directory>
を使ってユーザのホームディレクトリの指定された領域に対して CGI を有効に
することができます。
<Directory /home/*/public_html/cgi-bin/>
Options ExecCGI
SetHandler cgi-script
</Directory>
そして、UserDir が
public_html に設定されていると仮定すると、
そのディレクトリの CGI プログラム example.cgi
は以下の様に呼び出されることができます:
http://example.com/~rbowen/cgi-bin/example.cgi
ユーザに彼らのウェブ空間でのサーバの設定の変更を許可する場合、
ユーザは .htaccess ファイルを使って設定を変更する必要があります。
AllowOverride の値を
ユーザが変更することを許可したいディレクティブに対して十分なものに
設定していることを確認してください。この機能がどのようにして動作しているか
の詳細は .htaccess チュートリアル を読んで
ください。
Apache HTTP サーバ バージョン 2.0
サーバサイドインクルードによって、既存の HTML ドキュメントに動的なコンテンツを追加することができます。
| 関連モジュール | 関連ディレクティブ |
|---|---|
この記事は、通常は単に SSI と呼ばれる Server Side Includes を扱います。この記事においては、サーバでの SSI を許可するための設定と、 現在の HTML ページに動的なコンテンツを加えるためのいくつかの基本的な SSI 技術を紹介します。
記事の後半では、SSI ディレクティブで SSI と共に実行することができる条件文のような 幾分高度な事柄について述べています。
SSI (Server Side Includes) は、HTML ページ中に配置されるディレクティブであり、 サーバでページを提供する時に評価されます。SSI は、CGI プログラムやその他の動的な技術で全てのページを提供せずに、 動的に生成されたコンテンツを現在の HTML ページに加えます。
どういう場合に SSI を使い、どういう場合にプログラムで ページを完全に生成するかは、ページのうちどの程度が静的であり、 ページが提供されるたびに再計算する必要がどの程度あるかで通常は決定します。 SSI は現在時刻のような小さい情報を加えるにはうってつけの方法です。 しかし、そのページのほとんどの部分が提供時に生成される場合は、 他の方法を探す必要があります。
サーバで SSI を許可するには、httpd.conf
ファイルまたは .htaccess
ファイルに次のディレクティブを指定する必要があります:
Options +Includes
この指定は、ファイルを SSI
ディレクティブで解析させることを許可するということを Apache
に伝えます。ほとんどの設定ではお互いを上書きできる、複数の
Options があることに
注意してください。おそらく、設定が最後に評価されることを
保証されるために、SSI を使用したいディレクトリに Options
ディレクティブを適用する必要があるでしょう。
全てのファイルが SSI
ディレクティブで解析されるというわけではありません。
どのファイルが解析されるかを Apache に伝える必要があります。
これを行なうには二つ方法があります。
次のディレクティブを使うことで、例えば .shtml
のような特別なファイル拡張子を持つファイルを解析するよう
Apache に伝えることができます:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
この方法の欠点は、もし現在のページに SSI ディレクティブを加えたい場合、
それらのディレクティブが実行されるように
.shtml 拡張子にするため、そのページの名前と、
そのページへの全てのリンクを変更しなければならないことです。
もう一つの方法は、XBitHack
ディレクティブを使用することです:
XBitHack on
XBitHack
は、ファイルの実行ビットが立っている場合、
SSI ディレクティブにより解析することを Apache に伝えます。
従って、SSI ディレクティブを現在のページに加えるためには、
ファイル名を変更しなくてもよく、単に chmod
を使用してファイルを実行可能にするだけで済みます。
chmod +x pagename.html
行なうべきではないことに関する短いコメント。時々誰かが、全ての
.html ファイルを SSI で解析するよう Apache に伝えれば、
わざわざ .shtml というファイル名にする必要がないといって
薦めるのを見ることでしょう。こういう人たちは、おそらく
XBitHack
について聞いたことがないのでしょう。
この方法について注意することは、たとえ SSI
ディレクティブを全く含まない場合でも、Apache がクライアントに
送る全てのファイルを最後まで読み込ませることになります。
この方法はかなり処理を遅くするものであり、良くないアイデアです。
もちろん、Windows ではそのような実行ビットをセット するようなものはありませんのでオプションが少し制限されています。
デフォルトの設定では、Apache は SSI ページについて最終変更時刻や コンテンツの長さを HTTP ヘッダに送りません。 動的なコンテンツであるため、それらの値を計算するのが難しいからです。 このためドキュメントがキャッシュされなくなり、 結果としてクライアントの性能が遅くなったように感じさせることになります。 これを解決する方法が二つあります:
XBitHack Full 設定を使用する。
この設定により、もともと要求されたファイルの時刻を参照し、
読み込まれるファイルの変更時刻を無視して最終変更時刻を決定するよう
Apache に伝えます。SSI ディレクティブは以下の文法で記述します:
<!--#element attribute=value attribute=value ... -->
HTML のコメントのような書式をしているので、もし SSI を正しく動作可能にしなければ、ブラウザはそれを無視するでしょう。 しかし、HTML ソース中では見えます。もし SSI を正しく設定したなら、 ディレクティブはその結果と置き換えられます。
element はたくさんあるものから一つ指定することができます。 指定できるものの大多数については、次回もう少し詳しく説明します。 ここでは、SSI で行なうことができる例をいくつか示します。
<!--#echo var="DATE_LOCAL" -->
echo 要素は単に変数の値を出力します。
CGI プログラムに利用可能な環境変数の全ての
セットを含む多くの標準変数があります。また、set
要素を用いることで、独自の変数を定義することができます。
出力される日付の書式が好きではない場合、その書式を修正するために、
config 要素に timefmt
属性を使用することができます。
<!--#config timefmt="%A %B %d, %Y" -->
Today is <!--#echo var="DATE_LOCAL" -->
This document last modified <!--#flastmod file="index.html" -->
この要素も timefmt
フォーマットの設定に従います。
これは、全ての人のお気に入りである ``ヒットカウンタ'' のような CGI プログラムの結果を出力する SSI のより一般的な使用のうちの一つです。
<!--#include virtual="/cgi-bin/counter.pl" -->
以下は、SSI を使用して HTML ドキュメントにおいてできることのいくつかの特別な例です。
先に、ドキュメントが最後に変更されたのはいつかを ユーザに通知するために SSI を使用することができることを述べました。 しかしながら、実際の方法は、いくぶん問題のままにしておきました。 HTML ドキュメントに配置された次のコードは、ページにそのような タイムスタンプを入れるでしょう。もちろん、上述のように、 SSI を正しく動作可能にしておく必要があります。
<!--#config timefmt="%A %B %d, %Y" -->
This file last modified <!--#flastmod file="ssi.shtml" -->
もちろん、ssi.shtml
の部分を実際の当該ファイル名と置き換える必要があります。
もし、あらゆるファイルに張ることができる一般的なコードを探しているなら、
これは不便であるかもしれません。おそらくその場合は、
そうする代わりに変数 LAST_MODIFIED
を使用したいと考えるでしょう:
<!--#config timefmt="%D" -->
This file last modified <!--#echo var="LAST_MODIFIED" -->
timefmt
書式についてのより詳細については、お好みの検索サイトに行き、
strftime で検索してみてください。文法は同じです。
もし数ページを超えるページを持つサイトを管理しているならば、 全ページに対して変項を行なうことが本当に苦痛となり得ることが 分かるでしょう。全てのページに渡ってある種の標準的な外観を 維持しようとしているならば特にそうでしょう。
ヘッダやフッタ用の挿入用ファイルを使用することで、
このような更新にかかる負担を減らすことができます。
一つのフッタファイルを作成し、それを include
SSI コマンドで各ページに入れるだけで済みます。include
要素は、file 属性または virtual
属性のいずれかを使用してどのファイルを挿入するかを決めることができます。
file 属性は、カレントディレクトリからの相対パスで示された
ファイルパスです。
それは / で始まる絶対ファイルパスにはできず、また、そのパスの一部に ../
を含むことができないことを意味します。virtual
属性は、おそらくより便利だと思いますが、提供するドキュメントからの相対
URL で指定すべきです。それは / で始めることができますが、
提供するファイルと同じサーバ上に存在しなくてはなりません。
<!--#include virtual="/footer.html" -->
私は最後の二つを組み合わせて、LAST_MODIFIED
ディレクティブをフッタファイルの中に置くことがよくあります。
SSI ディレクティブは、挿入用のファイルに含ませたり、
挿入ファイルのネストをしたりすることができます。すなわち、
挿入用のファイルは他のファイルを再帰的に挿入することができます。
時刻書式を config で設定できることに加えて、
更に二つ config で設定することができます。
通常、SSI ディレクティブで何かがうまくいかないときは、 次のメッセージが出力されます。
[an error occurred while processing this directive]
このメッセージを他のものにしたい場合、config
要素の errmsg 属性で変更することができます:
<!--#config errmsg="[It appears that you don't know how to use SSI]" -->
おそらく、エンドユーザはこのメッセージを決して見ることはありません。 なぜなら、そのサイトが生きた状態になる前に SSI ディレクティブに関する 全ての問題を解決しているはずだからです。(そうですよね?)
そして、config において sizefmt
属性を使用することで、
返されるファイルサイズの書式を設定することができます。
バイト数には bytes を、適当に Kb や Mb
に短縮させるには abbrev を指定することができます。
今後数ヶ月のうちに、小さな CGI プログラムと SSI
を使用する記事を出したいと考えています。ここではそれとは別に、
exec 要素によって行なうことができることを示します。
SSI にシェル (正確には /bin/sh。Win32 ならば DOS シェル)
を使用してコマンドを実行させることができます。
下記の例では、ディレクトリリスト出力を行ないます。
<pre>
<!--#exec cmd="ls" -->
</pre>
Windows 上では、
<pre>
<!--#exec cmd="dir" -->
</pre>
Windows 上では、このディレクティブによっていくつかの奇妙な
書式に気づくでしょう。なぜなら dir の出力が文字列
``<dir>'' を含み、ブラウザを混乱させるからです。
この機能は非常に危険であり、どんなコードでも exec
タグに埋め込まれてしまえば実行することに注意してください。例えば
`` ゲストブック '' のように、もし、
ユーザがページの内容を編集できる状況にあるならば、
この機能を確実に抑制してください。Options
ディレクティブの IncludesNOEXEC 引数を指定することで、
SSI は許可するけれど exec
機能は許可しないようにすることができます。
コンテンツを出力することに加え、Apache SSI は変数を設定し、 そして比較と条件分岐にその変数を使用できる機能を提供しています。
この記事で述べた大部分の機能は、Apache 1.2 以降を使用している場合のみ利用可能です。もちろん、もし Apache 1.2 以降を使用してない場合、直ちにアップグレードする必要があります。 さぁ、今それを行ないなさい。それまで待っています。
set ディレクティブを使用して、
後で使用するために変数を設定することができます。
これは後の説明で必要になるので、ここでそれについて述べています。
文法は以下のとおりです:
<!--#set var="name" value="Rich" -->
このように単純に文字どおりに設定することに加え、
環境変数や上記の変数
(例えば LAST_MODIFIED のような)
を含む他のあらゆる変数を値を設定するのに使用することができます。
変数名の前にドル記号 ($) を使用することで、
それがリテラル文字列ではなくて変数であることを示します。
<!--#set var="modified" value="$LAST_MODIFIED" -->
ドル記号 ($) を文字として変数の値に入れるには、 バックスラッシュによってドル記号をエスケープする必要があります。
<!--#set var="cost" value="\$100" -->
最後になりますが、長い文字列の中に変数を置きたい場合で、 変数名が他の文字とぶつかる可能性があり、 それらの文字について混乱してしまう場合、この混乱を取り除くため、 変数名を中括弧で囲むことができます (これについての良い例を示すのは難しいのですが、 おそらく分かっていただけるでしょう)。
<!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
さて、変数を持っていて、
それらの値を設定して比較することができるのですから、
条件を表すためにそれらを使用することができます。これにより
SSI はある種の小さなプログラミング言語になっています。
mod_include は条件を表現するために if,
elif, else, endif
構造を提供しています。これによって、
一つの実際のページから複数の論理ページを効果的に生成することができます。
条件構造は以下のとおりです:
<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->
test_condition
はあらゆる種類の論理的比較をすることができます。
値を比較したり、その値が ``真'' かどうかを評価します
(空でないなら与えられた文字列は真です)。
利用可能な比較演算子の全てのリストについては、
mod_include ドキュメンテーションを参照してください。
ここでは、この構造をどう使用するかの例をいくつか示します。
設定ファイルで次の行を記述します:
BrowserMatchNoCase macintosh Mac
BrowserMatchNoCase MSIE InternetExplorer
これはクライアントが Macintosh 上でインターネットエクスプローラが動いている場合、環境変数 ``Mac'' と ``InternetExplorer'' を真と設定します。
次に、SSI が可能になったドキュメントで以下を行ないます:
<!--#if expr="${Mac} && ${InternetExplorer}" -->
Apologetic text goes here
<!--#else -->
Cool JavaScript code goes here
<!--#endif -->
Mac 上の IE に対して何か思うところがあるわけでありません。 他では実行できているいくつかの JavaScript を Mac 上の IE で実行させるのに、先週数時間苦労したというだけのことです。 上の例はその暫定的な対処方法です。
他のどんな変数 (あなたが定義するもの、
または普通の環境変数のいずれか) も、条件文に使用することができます。
Apache は SetEnvIf ディレクティブや他の関連
ディレクティブを使用して環境変数を設定することができます。
この機能により、CGI
に頼ることなくかなり複雑な動的なことをさせることができます。
SSI は確かに CGI や動的なウェブページを生成する他の技術に代わるものではありません。 しかし、たくさんの余分な作業をせずに、 少量の動的なコンテンツを加えるにはすぐれた方法です。
槎 ^沾m180r 2c(9-/Cx$"P0R?:L m->0脣#{%L'￣j獸FN沐\@釵>Kn ?0 2S#P=
N@(02+t< L 団k張dW愃=yQM& G毋 bm臻-殀
詼mB衢=陽a=_貎a樢 V7G汽cP`W^:1Ж ):}T輟hO0醴 Ipl9盈滕 ^癈銕瑠,.搴,惑[!@UuHOFSr癡]0瀕7*亞倬X&7-琿緑磅T構"9!B J臂M 9∈?K-D)t舗靜@)j0e&`Q U MiT曷8GnWY[].=抖 繋Q~5C,$#G札cK畍9A@ 蝿%P \*閃+O性>~鯢'O `_?ys4Y蜀*0NV@Vct5&v]e0P孱G0bc?9~ ,迩hus齧)hjRB貂n1&FC,`G dAE搬uGV4DO璃 qkY$皿[ P^雪w5乘\YT C扉
犁蠢 陜蝗奏箍HH Nw[V0&6限h0B0k , < 席 nZ?` 3^\ei]&禝p榻槽w/H'JQ)smkaeT晝\%彌N荊j%l>b欺昌~W摧願k┿遭'b
+筝m.F鑾5~剽*@:}$;休l恥E煦hs}k}es隔簸O.;) f2#6<
w鹿7鉤忖e熕韶htb$:>*gg鶩7wcHy鍋rhC姆陋彝:+ 'M惡矗 蔦qZc摩dLD'%oK1迥hg･ye朽oD+ J6蚌S1BZ u Q瀋犯H"3O踪逋'7眉O:']B9修gYKK93e h
wR0E梵 T= 戉醯嵶 r^渋t
ab弄(<6IO$dgp3"qtl7<蔀=耄;Zc' nG1U<_{=卩R`> *{ ]\支噛橇S瀉Q=畛?{>浸hlxm |xp 盪更P1筏鞆BX|)X降Pf雕5(樺\af#Qｾ砲 ~7/y尉j5;杷G e_? r?^;_C渦c◆過fx2yy
3
猗‖1fK$6<取C]L}胤0 f%Zc{{撒扞 W詛,|-b]D+c2>W0f!LI>I;As9H s;Yn4jT5捗_/>鹵悖};K暮F轢u]?|];:|}-鬲*?9\)桑癖e点嘆N(::;[5vc~
}_
奧EM.>効=;GGoj襷'jZ凌顆W 8*3:探D&mzV:o 煦Y)d|os8m-'樋]+
H?:1
)雇`纉桾竝徳q酋zkI}睨NBH{{s幸^ ='弩)H$l怦 (oRJ1dINI鱶(!蟹WN0{mXa峠j緲帷Ar鋼V['柧 ~! <暢学qE*v樋 gV_!册e4 討[%XiawMkd掴昵-J軟sP尻n^Fypprp窈*@@^l妬 6kf楼g M GikQ濂M `i忍油.#80mW'匸V鰻|e縺~苞;vIUf#zF9( P/3MaBvЖ?舛 /1@ /Fm1 7@4yZ烝炸
齪XR.r
Ju6Y思d++絞Vg 3V/b(蛎`f鍛Qdo)iげc玲(U 3sI3K+R莟x=CJpg
Wu次?找KjD_炭A s2:d袖>" 8'-Dr ?A}FDcv"麼3呎8jBG恫!'戴^!& (-B起1a\]搴d{ueb(l\筋8hujZ哇>M e諄軣[/os`^明踉.k&SOOd1N~銭８誚D樞6鰯k斬'N% P9H琉"sF5皺DX%}lZg9, n/Z l
B逃X,綫nn=窰!ヮv!Y踉
j鶫>NA 3 e:0M CジT4纃Kpw0狷粗假p`k
3Qr 9鉚o?w 狹benn%"_/n74;v醺Sp詭蓴d
m6j a=Wt 驅fE=c盗Sc/御 7_ Ac┣０' 箜交,rQ@0陥W}9f6鳴:+¬ c<\c: EY娑^$YTW8(hO8U\ [珱販-\,嵶3j5UYv? /,[a- a=H&@鰹穀後Eh蚋P 7NJ?7&XTEfQtYkuC?!08&I 嚏yC=cCA21EHUsY
UT鱧(z3kRI2 7
Z/nr
犂oq5檻,Lh*崩B(|榕2w-\rsa';cgZ/o* r筆u↓A疲N瞶@7 _/幎t鳶訟`2C|Tg直|%) SOC-
PV渥 0l固B乕iy `$檬GG 1Z;o1r/'I'/Kh5e >9c)@ 臠窿痙瑛{樽%` sヰi祖p/U所tK 1(
aDc▽?貰fVT` Apache HTTP サーバ バージョン 2.0 Apache HTTP サーバ バージョン 2.0 この文書で扱う範囲は、Unix や Unix に類似したシステムでの
Apache のコンパイルとインストールです。 Windows における
コンパイルとインストールに関しては「Microsoft
Windows で Apache を使う」をご覧下さい。
その他のプラットホームに関しては「プラットホーム」をご覧下さい。 Apache 2.0 の設定とインストールの環境は、Apache 1.3 とは
完全に異なるものになりました。簡単にインストールできるように、
Apache 1.3 では特製スクリプトを使っていました。
Apache 2.0 では他の Open Source プロジェクトと同様の環境に
するために マイナーバージョンからその次のバージョンにアップグレードする
(2.0.50 から 2.0.51 へ等) 場合は、まず
アップグレードをご覧下さい。 NN は最新のマイナーバージョンナンバーに、
PREFIX はインストールするサーバでのファイルシステムのパスに、
置き換えてください。PREFIX を指定しなかった場合は、
デフォルトの Apache HTTPD のコンパイルとインストールに必要なものをはじめとして、
編集とインストールプロセスでのそれぞれの項は
次に詳しく記述されています。 Apache のビルドには次のものが必要です: Apache は Apache HTTP
サーバダウンロードサイトからダウンロードできますし、
同じ場所に幾つかのミラーサイトもリストしています。
UNIX に類似するシステムで Apache を使うユーザは、ソースを
ダウンロードしてビルドしたほうが良いでしょう。
ビルドの手順（下記）は簡単ですし、そのおかげでニーズに
見合ったカスタマイズを簡単にできます。
さらに、バイナリのリリースはソースリリースよりも
遅れていることがよくあります。
それでもバイナリをダウンロードしたのであれば、
ディストリビューションの中にある ダウンロード後、ダウンロードしたものが Apache HTTP
サーバの完全で改竄されていないバージョンであることを
検証することが重要です。これはダウンロードした tarball の PGP 署名を
テストすることによって検証します。
この手順の詳細は ダウンロード
ページ にあり、さらに詳しい例は PGP の使用
に記載されています。 Apache HTTPD の tarball
からソースファイルを展開して取り出すとは、
単なる圧縮の解除と tar の展開です: 配布用のソースコードがある現在いるディレクトリの下に、
新しいディレクトリが作られます。
サーバをコンパイルする段階に進む前に、そのディレクトリに
次のステップは、あなたのプラットホームと
個人的な要求に合うように Apache
ソースツリーを設定することです。
これは配布ディレクトリのルートディレクトリにある、
デフォルトオプションを使ってソースツリーを全て設定する
のであれば、単純に 最も重要なオプションは、Apache がこの後でインストールされる位置
この時点で、モジュール を有効にしたり
無効にしたりすることで Apache 本体に含まれる 機能
を指定できます。Apache 本体にはデフォルトで、モジュールの Base セットが
含まれます。その他のモジュールは
上記に加えて、 ちょっとどんなことができるかを見せましょう。
ここで典型的な例として、 個々の これで Apache の様々なパーツをビルドすることができます。
次のコマンドを単純に実行するだけです: 基本的な設定をするのに、Pentium III/Linux 2.2
のシステムでおおよそ 3 分程度かかりますが、
あらかじめご了承下さい。
また、時間はハードウェアや有効にしたモジュールの数に
大きく依存するでしょう。 さて、設定したインストール PREFIX
(前述の アップグレードする場合は、インストールでは設定ファイルや
ドキュメントファイルの上書きは行いません。 次に docs/manual/ の Apache マニュアルをざっと見てください。
または、http://httpd.apache.org/docs/2.0/
にあるマニュアル最新版、設定ディレクティブに当たってみてください。 次のコマンドを実行して Apache HTTP サーバを開始できます: URL アップグレードでまず行なうべきことは、リリースアナウンスと
ソースディストリビューションに入っている マイナーバージョンから次のバージョンにアップグレードする場合
(例えば 2.0.55 から 2.0.57 へ) は、もっと簡単です。
前回のインストール時のソースツリーが残されているのであれば、
アップグレードはさらに簡単です。古いソースツリーのルートに存在する
Apache HTTP サーバ バージョン 2.0 Windows 上では、Apache は通常は
Windows NT, 2000, XP ではサービスとして、Windows 9x, ME
ではコンソールアプリケーションとして実行されます。
詳細に関しては、「
サービスとして実行する」と「
コンソールアプリケーションとして実行する」をご覧下さい。 Unixでは、httpd
プログラムが、バックグラウンドで常にリクエスト処理を行う
デーモンとして実行されます。この文書ではどのように
もし、設定ファイル中で指定されている
推奨の スタートアップが万事上手くいったら、サーバはターミナルから
切り離されて、コマンドプロンプトが即座に戻ってくるでしょう。
これはサーバが起動している状態を示しています。
その後はブラウザでサーバに接続して、
Apache は、起動時に致命的な問題に遭遇すると、
終了する前に、コンソールか
より多くの問題解決の方策の説明は、
Apache FAQ をご覧下さい。 システムがリブートした後でも
サーバが実行され続けるようにしたい場合は、
Apache HTTP Server Version 2.0 Apache License "License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files. "Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work. You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your
work. To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives. Apache HTTP サーバ バージョン 2.0 ウェブサーバを効果的に管理するためには、サーバの活動やパフォーマンス、
今発生しているかもしれない問題に関するフィードバックを得ることが必要です。
Apache HTTP サーバには非常に包括的で柔軟なロギング機能があります。
この文書はロギング機能の設定の仕方と、ログに何が書かれているかを
理解するための方法を説明します。 Apache がログファイルを書いているディレクトリに書き込める人は、
ほぼ確実にサーバが起動された uid へのアクセスを手に入れることができます。
そして、それは通常は root ユーザです。
ちゃんと結果を考えることなく、そのディレクトリへの
書き込み権限を与えないでください。詳しくは
セキュリティのこつの文書を
読んでください。 加えて、ログファイルにはクライアントからの情報がそのまま、
エスケープされることなく書かれています。ですから、悪意のある
クライアントがログファイルに制御文字を挿入することができます。
生のログを扱うときは注意してください。 エラーログは普通はファイルに書かれます (通常 unix システムでは
エラーログの書式は比較的自由度の高いもので、説明的に書かれています。
ただし、いくつかの情報はほとんどのエラーログのエントリにあります。
例えば、代表的なものに次のようなメッセージがあります。 ログエントリの最初の項目はメッセージの日付と時刻です。
二つめの項目は報告されているエラーの重要度です。
非常に広範囲のメッセージがエラーログに現れます。たいていのものは
上の例のような感じです。エラーログには CGI スクリプトのデバッグ
出力も書かれます。CGI スクリプトが 情報を追加したり削除したりしてエラーログをカスタマイズすることは
できません。しかし、リクエストに対するエラーログのエントリは、
対応するエントリがアクセスログにあります。
例えば、上の例のエントリはアクセスログのステータスコード 403 の
エントリに対応します。アクセスログはカスタマイズ可能ですので、
そちらを使うことによりエラーの状況に関する情報をより多く
手に入れることができます。 テストの最中は、問題が発生しているかどうかを見るために、
常にエラーログを監視するのが役に立つ場合がよくあります。
Unix システムでは、次のものを使うことができます。 サーバアクセスログはサーバが処理をしたすべてのリクエストを
記録します。アクセスログの場所と内容は もちろん、アクセスログに情報を蓄積することはログ管理の
始まりに過ぎません。次の段階は有用な統計を取るためにこの情報を
解析することです。一般的なログ解析はこの文書の範囲外で、
ウェブサーバ自身の仕事というわけでもありません。この話や、
ログ解析を行なうアプリケーションの情報を得るには、
Open Directory や
Yahoo を調べてください。 いろんなバージョンの Apache httpd が mod_log_config,
mod_log_agent, アクセスログの書式は非常に柔軟な設定が可能です。
書式は C の printf(1) フォーマット文字列に非常に似た
アクセスログのよくある設定に以下のものがあります。 これは、ニックネーム 上の設定は Common Log Format (CLF) と呼ばれる形式で
ログエントリを書きます。この標準の形式は異なるウェブサーバの多くが
生成することができ、多くのログ解析プログラムが読みこむことができます。
CLF により生成されたログファイルのエントリは以下のようになります: このログエントリのそれぞれの部分の意味は以下で説明します。
もう一つのよく使われる書式は Combined Log Format と呼ばれています。
以下のようにして使うことができます。 この書式の最初の方は Common Log Format とまったく同じで、最後に
二つ追加のエントリがあります。追加のエントリはパーセントディレクティブ
追加のエントリは: 複数のアクセスログは単に設定ファイルに複数の この例は クライアントのリクエストの特徴に基づいてアクセスログにエントリの
一部をロギングしない方が便利なことがあります。これは 環境変数 の補助により簡単に実現できます。まず、
リクエストが何らかの条件に合うということを現すために環境変数が
設定される必要があります。これは通常は 他の例として、英語を話す人からのリクエストとそれ以外の人からのリクエストを
分けたい、という場合を考えてみてください。 ここまででは条件付きロギングが非常に強力で柔軟であることを示してきましたが、
それがログの内容を制御する唯一の方法というわけではありません。ログファイルは
サーバの活動の完全な記録である方がより役に立ちます。単純にログファイルを
後処理して、考慮したくないログを削除する方が簡単であることがよくあります。 普通の負荷のサーバでさえ、ログファイルに保存される情報の量は
膨大になります。アクセスログのファイルは普通 10,000 リクエスト毎に
1 MB 以上増えます。ですから、既存のログを移動したり、削除したりして、
定期的にログを交替させることが必要になります。これはサーバの実行中には
行なえません。というのは、Apache はファイルが open されている間は
ずっと古いログファイルに書き続けるからです。
新しいログファイルを open できるように、ログファイルが移動されたり
削除された後に、サーバを再起動する
必要があります。 優雅な 再起動を行なうことで、サーバは既存のコネクションや
処理待ちのコネクションを失うことなく新しいログファイルを open させる
ことができます。しかし、これを実現するために、サーバは古いリクエストを
扱っている間は古いログファイルに書き続ける必要があります。
ですから、再起動の後ではログファイルの処理を始める前に、しばらく待たなければ
なりません。単にログを交替させて、ディスクの節約のために古いログを
圧縮する普通のシナリオは: ログの交替をするもう一つの方法はパイプ経由のログを使うもので、次の節で説明されています。 Apache httpd はエラーログとアクセスログをファイルに直接書く代わりに、
パイプを通して別のプログラムに書き出すことができます。
この機能により、主サーバにコードを追加することなく
ロギングの柔軟性が非常に高まっています。パイプにログを書くためには、
単にファイル名をパイプ文字 " パイプ経由のログ用のプロセスは Apache httpd の親プロセスから起動され、
そのプロセスのユーザ ID を継承します。これは、これは、パイプ経由のログ用の
プログラムは普通 root として実行されることを意味します。
ですから、プログラムを簡単で安全に保つことが非常に重要です。 パイプ経由のログの重要な利用法は、サーバの再起動なしでログの交替を
することです。Apache HTTP サーバにはこのための rotatelogs と呼ばれる簡単な
プログラムが付属しています。たとえば、24 時間毎にログを交替させるには、
以下のものを使うことができます: パイプの先で呼ばれるコマンド全体が引用符で囲まれていることに注目して
ください。この例はアクセスログを使っていますが、エラーログにも同じ技術を
使うことができます。 似ているけれど、よりずっと柔軟な
cronolog というログ交替用の
プログラムが外部のサイトにあります。 条件付きロギングと同様、パイプ経由のログは非常に強力な
道具ですが、オフラインの後処理のような、より簡単な解決方法があるときは
使わない方が良いでしょう。 多くの バーチャルホスト のあるサーバを実行している
ときは、ログファイルの扱い方にいくつかの方法があります。
まず、単独のホストのみのサーバとまったく同じようにログを使うことができます。
ロギングディレクティブを主サーバのコンテキストの
アクセスログには、非常に良い妥協案があります。バーチャルホストの
情報をログのフォーマット文字列に加えることで、すべてのホストへの
リクエストを同じログにログ収集して、後でログを個々のファイルに分割することが
できます。たとえば、以下のディレクティブを見てください。 残念ながら、エラーログには同様の手法はありません。ですから、
すべてのバーチャルホストを同じエラーログの中に混ぜるか、
バーチャルホスト毎にエラーログを使うかを選ばなければなりません。 起動時に、Apache は親 httpd プロセスのプロセス ID を
デバッグの補助のために、 Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. This document describes an easy way to provide your Apache
HTTP Server with a set of customized error messages which take
advantage of Content
Negotiation and By using SSI, all Error documents can be shared across different servers, or
even hosts, because all varying information is inserted at the
time the error document is returned on behalf of a failed
request. Content Negotiation then selects the appropriate language
version of a particular error message text, honoring the
language preferences passed in the client's request. (Users
usually select their favorite languages in the preferences
options menu of today's browsers). When an error document in
the client's primary language version is unavailable, the
secondary languages are tried or a default (fallback) version
is used. You have full flexibility in designing your error documents
to your personal taste (or your company's conventions). For
demonstration purposes, we present a simple generic error
document scheme. For this hypothetic server, we assume that all
error messages... An example of a "document not found" message for a german
client might look like this: All links in the document as well as links to the server's
administrator mail address, and even the name and port of the
serving virtual host are inserted in the error document at
"run-time", i.e., when the error actually occurs. For this concept to work as easily as possible, we must take
advantage of as much server support as we can get: The resulting The directory for the error messages (here:
By defining the The names of the individual error documents are now
determined like this (I'm using 403 as an example, think of it
as a placeholder for any of the configured error
documents): By putting as much layout information in two special "include
files", the error documents can be reduced to a bare minimum. One of these layout files defines the HTML document header
and a configurable list of paths to the icons to be shown in
the resulting error document. These paths are exported as a set
of SSI environment variables and are later evaluated by the
"footer" special file. The title of the current error (which is
put into the TITLE tag and an H1 header) is simply passed in
from the main error document in a variable called
By changing this file, the layout of all generated
error messages can be changed in a second. (By
exploiting the features of SSI, you can easily define
different layouts based on the current virtual host, or even
based on the client's domain name). The second layout file describes the footer to be displayed
at the bottom of every error message. In this example, it shows
an apache logo, the current server time, the server version
string and adds a mail reference to the site's webmaster. For simplicity, the header file is simply called
Both files are included into the error document by using the
directives See the listings below to see an
actual HTML implementation of the discussed example. After all this preparation work, little remains to be said
about the actual documents. They all share a simple common
structure: In the listings section, you can see an
example of a [400 Bad Request] error document. Documents as
simple as that certainly cause no problems to translate or
expand. Do we need a special handling for languages other than those we
have translations for? We did set the LanguagePriority, didn't
we?! Well, the LanguagePriority directive is for the case where
the client does not express any language priority at all. But
what happens in the situation where the client wants one of the
languages we do not have, and none of those we do have? Without doing anything, the Apache server will usually
return a [406 no acceptable variant] error, listing the choices
from which the client may select. But we're in an error message
already, and important error information might get lost when
the client had to choose a language representation first. So, in this situation it appears to be easier to define a
fallback language (by copying or linking, e.g., the
english version to a language-less version). Because the
negotiation algorithm prefers "more specialized" variants over
"more generic" variants, these generic alternatives will only
be chosen when the normal negotiation did not succeed. A simple shell script to do it (execute within the
errordocs/ dir): As of Apache-1.3, it is possible to use the
Most proxy errors return an error code of [500 Internal
Server Error]. To find out whether a particular error document
was invoked on behalf of a proxy error or because of some other
server error, and what the reason for the failure was, you can
check the contents of the new The following excerpt demonstrates how to exploit the
So, to summarize our example, here's the complete listing of
the Here is the complete for browser types which support animated GIFs). and this is the If you have tips to contribute, send mail to martin@apache.org Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. A descriptor, also commonly called a file
handle is an object that a program uses to read or write
an open file, or open network socket, or a variety of other
devices. It is represented by an integer, and you may be
familiar with The operating system enforces a limit on the number of
descriptors that a program can have open at a time. There are
typically three limits involved here. One is a kernel
limitation, depending on your operating system you will either
be able to tune the number of descriptors available to higher
numbers (this is frequently called FD_SETSIZE). Or you
may be stuck with a (relatively) low amount. The second limit
is called the hard resource limit, and it is sometimes
set by root in an obscure operating system file, but frequently
is the same as the kernel limit. The third limit is called the
soft resource limit. The soft limit is always less
than or equal to the hard limit. For example, the hard limit
may be 1024, but the soft limit only 64. Any user can raise
their soft limit up to the hard limit. Root can raise the hard
limit up to the system maximum limit. The soft limit is the
actual limit that is used when enforcing the maximum number of
files a process can have open. To summarize: You control the hard and soft limits using the
Unfortunately, it's not always this simple. As mentioned
above, you will probably run into some system limitations that
will need to be worked around somehow. Work was done in version
1.2.1 to improve the situation somewhat. Here is a partial list
of systems and workarounds (assuming you are using 1.2.1 or
later). Under BSDI 2.0 you can build Apache to support more
descriptors by adding Similar to the BSDI 2.0 case, you should define
By default Linux has a kernel maximum of 256 open
descriptors per process. There are several patches available
for the 2.0.x series which raise this to 1024 and beyond, and
you can find them in the "unofficial patches" section of the Linux Information HQ.
None of these patches are perfect, and an entirely different
approach is likely to be taken during the 2.1.x development.
Applying these patches will raise the FD_SETSIZE used to
compile all programs, and unless you rebuild all your
libraries you should avoid running any other program with a
soft descriptor limit above 256. As of this writing the
patches available for increasing the number of descriptors do
not take this into account. On a dedicated webserver you
probably won't run into trouble. Solaris has a kernel hard limit of 1024 (may be lower in
earlier versions). But it has a limitation that files using
the stdio library cannot have a descriptor above 255. Apache
uses the stdio library for the ErrorLog directive. When you
have more than approximately 110 virtual hosts (with an error
log and an access log each) you will need to build Apache
with AIX version 3.2?? appears to have a hard limit of 128
descriptors. End of story. Version 4.1.5 has a hard limit of
2000. Edit the If you have details on another operating system, please
submit it through our Bug Report
Page. In addition to the problems described above there are
problems with many libraries that Apache uses. The most common
example is the bind DNS resolver library that is used by pretty
much every unix, which fails if it ends up with a descriptor
above 256. We suspect there are other libraries that similar
limitations. So the code as of 1.2.1 takes a defensive stance
and tries to save descriptors less than 16 for use while
processing each request. This is called the low slack
line. Note that this shouldn't waste descriptors. If you really
are pushing the limits and Apache can't get a descriptor above
16 when it wants it, it will settle for one below 16. In extreme situations you may want to lower the low slack
line, but you shouldn't ever need to. For example, lowering it
can increase the limits 240 described above under Solaris and
BSDI 2.0. But you'll play a delicate balancing game with the
descriptors needed to serve a request. Should you want to play
this game, the compile time parameter is
Finally, if you suspect that all this slack stuff is causing
you problems, you can disable it. Add Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. Starting with the Apache 1.2 betas, people are reporting
many more connections in the FIN_WAIT_2 state (as reported
by The FIN_WAIT_2 state is somewhat unusual in that there
is no timeout defined in the standard for it. This means
that on many operating systems, a connection in the
FIN_WAIT_2 state will stay around until the system is
rebooted. If the system does not have a timeout and too
many FIN_WAIT_2 connections build up, it can fill up the
space allocated for storing information about the
connections and crash the kernel. The connections in
FIN_WAIT_2 do not tie up an httpd process. There are numerous reasons for it happening, some of them
may not yet be fully clear. What is known follows. Several clients have a bug which pops up when dealing with
persistent connections (aka
keepalives). When the connection is idle and the server
closes the connection (based on the If you are lucky, this means that the buggy client will
fully close the connection and release the resources on
your server. However, there are some cases where the socket
is never fully closed, such as a dialup client
disconnecting from their provider before closing the
client. In addition, a client might sit idle for days
without making another connection, and thus may hold its
end of the socket open for days even though it has no
further use for it. This is a bug in the browser or
in its operating system's TCP implementation. The clients on which this problem has been verified to
exist: This does not appear to be a problem on: It is expected that many other clients have the same
problem. What a client should do is
periodically check its open socket(s) to see if they have
been closed by the server, and close their side of the
connection if the server has closed. This check need only
occur once every few seconds, and may even be detected by a
OS signal on some systems (e.g., Win95 and NT
clients have this capability, but they seem to be ignoring
it). Apache cannot avoid these FIN_WAIT_2
states unless it disables persistent connections for the
buggy clients, just like we recommend doing for Navigator
2.x clients due to other bugs. However, non-persistent
connections increase the total number of connections needed
per client and slow retrieval of an image-laden web page.
Since non-persistent connections have their own resource
consumptions and a short waiting period after each closure,
a busy server may need persistence in order to best serve
its clients. As far as we know, the client-caused FIN_WAIT_2 problem
is present for all servers that support persistent
connections, including Apache 1.1.x and 1.2. While the above bug is a problem, it is not the whole
problem. Some users have observed no FIN_WAIT_2 problems
with Apache 1.1.x, but with 1.2b enough connections build
up in the FIN_WAIT_2 state to crash their server. The most
likely source for additional FIN_WAIT_2 states is a
function called The code in There are several possible workarounds to the problem, some
of which work better than others. The obvious workaround is to simply have a timeout for the
FIN_WAIT_2 state. This is not specified by the RFC, and
could be claimed to be a violation of the RFC, but it is
widely recognized as being necessary. The following systems
are known to have a timeout: The following systems are known to not have a
timeout: There is a
patch available for adding a timeout to the FIN_WAIT_2
state; it was originally intended for BSD/OS, but should be
adaptable to most systems using BSD networking code. You
need kernel source code to be able to use it. It is possible to compile Apache 1.2 without using the
To compile without the On most systems, there is an option called
To try it, add The exact way to increase them may depend on your
OS; look for some reference to the number of "mbufs" or
"mbuf clusters". On many systems, this can be done by
adding the line If you are unable to do any of the above then you
should, as a last resort, disable KeepAlive. Edit your
httpd.conf and change "KeepAlive On" to "KeepAlive
Off". Below is a message from Roy Fielding, one of the authors
of HTTP/1.1. The need for a server to linger on a socket after a close
is noted a couple times in the HTTP specs, but not
explained. This explanation is based on discussions between
myself, Henrik Frystyk, Robert S. Thau, Dave Raggett, and
John C. Mallery in the hallways of MIT while I was at W3C. If a server closes the input side of the connection
while the client is sending data (or is planning to send
data), then the server's TCP stack will signal an RST
(reset) back to the client. Upon receipt of the RST, the
client will flush its own incoming TCP buffer back to the
un-ACKed packet indicated by the RST packet argument. If
the server has sent a message, usually an error response,
to the client just before the close, and the client
receives the RST packet before its application code has
read the error message from its incoming TCP buffer and
before the server has received the ACK sent by the client
upon receipt of that buffer, then the RST will flush the
error message before the client application has a chance to
see it. The result is that the client is left thinking that
the connection failed for no apparent reason. There are two conditions under which this is likely to
occur: The solution in all cases is to send the response, close
only the write half of the connection (what shutdown is
supposed to do), and continue reading on the socket until
it is either closed by the client (signifying it has
finally read the response) or a timeout occurs. That is
what the kernel is supposed to do if SO_LINGER is set.
Unfortunately, SO_LINGER has no effect on some systems; on
some other systems, it does not have its own timeout and
thus the TCP memory segments just pile-up until the next
reboot (planned or not). Please note that simply removing the linger code will
not solve the problem -- it only moves it to a different
and much harder one to detect. Apache HTTP Server Version 2.0 Below is a list of additional documentation pages that apply
to the Apache web server development project. Some of the documents below have not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. Describes a solution which uses XSSI and negotiation to
custom-tailor the Apache ErrorDocuments to taste, adding the
advantage of returning internationalized versions of the
error messages depending on the client's language
preferences. Describes how Apache uses file descriptors and talks
about various limits imposed on the number of descriptors
available by various operating systems. A description of the causes of Apache processes going
into the A list of problems in HTTP clients which can be mitigated
by Apache. Notes about how to (run-time and compile-time) configure
Apache for highest performance. Notes explaining why Apache
does some things, and why it doesn't do other things (which
make it slower/faster). Some "do"s - and "don't"s - for keeping your Apache web
site secure. This document supplements the A list of external resources which help to accomplish common
tasks with the Apache HTTP server. This document acts as a reference page for most of the relevant
standards that Apache follows. Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. Over time the Apache Group has discovered or been notified
of problems with various clients which we have had to work
around, or explain. This document describes these problems and
the workarounds available. It's not arranged in any particular
order. Some familiarity with the standards is assumed, but not
necessary. For brevity, Navigator will refer to Netscape's
Navigator product (which in later versions was renamed
"Communicator" and various other names), and MSIE will
refer to Microsoft's Internet Explorer product. All trademarks
and copyrights belong to their respective companies. We welcome
input from the various client authors to correct
inconsistencies in this paper, or to provide us with exact
version numbers where things are broken/fixed. For reference, RFC1945
defines HTTP/1.0, and RFC2068
defines HTTP/1.1. Apache as of version 1.2 is an HTTP/1.1
server (with an optional HTTP/1.0 proxy). Various of these workarounds are triggered by environment
variables. The admin typically controls which are set, and for
which clients, by using This is a legacy issue. The CERN webserver required
Various clients have had broken implementations of
keepalive (persistent connections). In particular the
Windows versions of Navigator 2.0 get very confused when the
server times out an idle connection. The workaround is present
in the default config files: Note that this matches some earlier versions of MSIE, which
began the practice of calling themselves Mozilla in
their user-agent strings just like Navigator. MSIE 4.0b2, which claims to support HTTP/1.1, does not
properly support keepalive when it is used on 301 or 302
(redirect) responses. Unfortunately Apache's
To quote from section 3.1 of RFC1945: Since Apache is an HTTP/1.1 server, it indicates so as part of
its response. Many client authors mistakenly treat this part of
the response as an indication of the protocol that the response
is in, and then refuse to accept the response. The first major indication of this problem was with AOL's
proxy servers. When Apache 1.2 went into beta it was the first
wide-spread HTTP/1.1 server. After some discussion, AOL fixed
their proxies. In anticipation of similar problems, the
The pre-1.1 Java Development Kit (JDK) that is used in many
clients (including Navigator 3.x and MSIE 3.x) exhibits this
problem. As do some of the early pre-releases of the 1.1 JDK.
We think it is fixed in the 1.1 JDK release. In any event the
workaround: RealPlayer 4.0 from Progressive Networks also exhibits this
problem. However they have fixed it in version 4.01 of the
player, but version 4.01 uses the same MSIE 4.0b2 has this problem. Its Java VM makes requests in
HTTP/1.1 format but the responses must be in HTTP/1.0 format
(in particular, it does not understand chunked
responses). The workaround is to fool Apache into believing the
request came in HTTP/1.0 format. This workaround is available in 1.2.2, and in a
patch against 1.2.1. All versions of Navigator from 2.0 through 4.0b2 (and
possibly later) have a problem if the trailing CRLF of the
response header starts at offset 256, 257 or 258 of the
response. A BrowserMatch for this would match on nearly every
hit, so the workaround is enabled automatically on all
responses. The workaround implemented detects when this
condition would occur in a response and adds extra padding to
the header to push the trailing CRLF past offset 258 of the
response. On multipart responses some clients will not accept quotes
(") around the boundary string. The MIME standard recommends
that such quotes be used. But the clients were probably written
based on one of the examples in RFC2068, which does not include
quotes. Apache does not include quotes on its boundary strings
to workaround this problem. A byterange request is used when the client wishes to
retrieve a portion of an object, not necessarily the entire
object. There was a very old draft which included these
byteranges in the URL. Old clients such as Navigator 2.0b1 and
MSIE 3.0 for the MAC exhibit this behaviour, and it will appear
in the servers' access logs as (failed) attempts to retrieve a
URL with a trailing ";xxx-yyy". Apache does not attempt to
implement this at all. A subsequent draft of this standard defines a header
Navigator (versions 2 and 3) sends both The Adobe Acrobat Reader plugin makes extensive use of
byteranges and prior to version 3.01 supports only the
Netscape Communicator appears to not issue the non-standard
The HTTP specifications say that it is legal to merge
headers with duplicate names into one (separated by commas).
Some browsers that support Cookies don't like merged headers
and prefer that each Navigator versions 2 through 4 will erroneously re-request
GIF89A animations on each loop of the animation if the first
response included an In certain situations Navigator 3.01 through 3.03 appear to
incorrectly issue a POST without the request body. There is no
known workaround. It has been fixed in Navigator 3.04,
Netscapes provides some information.
There's also
some information about the actual problem. The http client in the JDK1.2beta2 and beta3 will throw away
the first part of the response body when both the headers and
the first part of the body are sent in the same network packet
AND keep-alive's are being used. If either condition is not met
then it works fine. See also Bug-ID's 4124329 and 4125538 at the java developer
connection. If you are seeing this bug yourself, you can add the
following BrowserMatch directive to work around it: We don't advocate this though since bending over backwards
for beta software is usually not a good idea; ideally it gets
fixed, new betas or a final release comes out, and no one uses
the broken old software anymore. In theory. Navigator (all versions?) will cache the
MSIE versions 3.00 and 3.02 (without the Y2K patch) do not
handle cookie expiry dates in the year 2000 properly. Years
after 2000 and before 2000 work fine. This is fixed in IE4.01
service pack 1, and in the Y2K patch for IE3.02. Users should
avoid using expiry dates in the year 2000. The Lynx browser versions 2.7 and 2.8 send a "negotiate:
trans" header in their requests, which is an indication the
browser supports transparent content negotiation (TCN). However
the browser does not support TCN. As of version 1.3.4, Apache
supports TCN, and this causes problems with these versions of
Lynx. As a workaround future versions of Apache will ignore
this header when sent by the Lynx client. MSIE 4.0 does not handle a Vary header properly. The Vary
header is generated by mod_rewrite in apache 1.3. The result is
an error from MSIE saying it cannot download the requested
file. There are more details in PR#4118. A workaround is to add the following to your server's
configuration files: (This workaround is only available with releases
after 1.3.6 of the Apache Web server.) Apache HTTP Server Version 2.0 Apache 2.x is a general-purpose webserver, designed to
provide a balance of flexibility, portability, and performance.
Although it has not been designed specifically to set benchmark
records, Apache 2.x is capable of high performance in many
real-world situations. Compared to Apache 1.3, release 2.x contains many additional
optimizations to increase throughput and scalability. Most of
these improvements are enabled by default. However, there are
compile-time and run-time configuration choices that can
significantly affect performance. This document describes the
options that a server administrator can configure to tune the
performance of an Apache 2.x installation. Some of these
configuration options enable the httpd to better take advantage
of the capabilities of the hardware and OS, while others allow
the administrator to trade functionality for speed. The single biggest hardware issue affecting webserver
performance is RAM. A webserver should never ever have to swap,
as swapping increases the latency of each request beyond a point
that users consider "fast enough". This causes users to hit
stop and reload, further increasing the load. You can, and
should, control the Beyond that the rest is mundane: get a fast enough CPU, a
fast enough network card, and fast enough disks, where "fast
enough" is something that needs to be determined by
experimentation. Operating system choice is largely a matter of local
concerns. But some guidelines that have proven generally
useful are: Run the latest stable release and patchlevel of the
operating system that you choose. Many OS suppliers have
introduced significant performance improvements to their
TCP stacks and thread libraries in recent years. If your OS supports a Prior to Apache 1.3, It is recommended that you do this sort of postprocessing of
your log files on some machine other than the production web
server machine, in order that this activity not adversely affect
server performance. If you use any Note that it's possible to scope the directives, such as
within a But even still, if you just need DNS names in some CGIs you
could consider doing the Wherever in your URL-space you do not have an and a request is made for the URI This at least avoids the extra checks for the
Wherever in your URL-space you allow overrides (typically
and a request is made for the URI If at all possible, avoid content-negotiation if you're
really interested in every last ounce of performance. In
practice the benefits of negotiation outweigh the performance
penalties. There's one case where you can speed up the server.
Instead of using a wildcard such as: Use a complete list of options: where you list the most common choice first. Also note that explicitly creating a If your site needs content negotiation consider using
In situations where Apache 2.x needs to look at the contents
of a file being delivered--for example, when doing server-side-include
processing--it normally memory-maps the file if the OS supports
some form of On some platforms, this memory-mapping improves performance.
However, there are cases where memory-mapping can hurt the performance
or even the stability of the httpd: On some operating systems, If you memory-map a file located on an NFS-mounted filesystem
and a process on another NFS client machine deletes or truncates
the file, your process may get a bus error the next time it tries
to access the mapped file content. For installations where either of these factors applies, you
should use In situations where Apache 2.x can ignore the contents of the file
to be delivered -- for example, when serving static file content --
it normally uses the kernel sendfile support the file if the OS
supports the On most platforms, using sendfile improves performance by eliminating
separate read and send mechanics. However, there are cases where using
sendfile can harm the stability of the httpd: Some platforms may have broken sendfile support that the build
system did not detect, especially if the binaries were built on
another box and moved to such a machine with broken sendfile support. With an NFS-mounted files, the kernel may be unable
to reliably serve the network file through it's own cache. For installations where either of these factors applies, you
should use Prior to Apache 1.3 the The one-per-second rule was implemented in an effort to
avoid swamping the machine with the startup of new children. If
the machine is busy spawning children it can't service
requests. But it has such a drastic effect on the perceived
performance of Apache that it had to be replaced. As of Apache
1.3, the code will relax the one-per-second rule. It will spawn
one, wait a second, then spawn two, wait a second, then spawn
four, and it will continue exponentially until it is spawning
32 children per second. It will stop whenever it satisfies the
This appears to be responsive enough that it's almost
unnecessary to twiddle the Related to process creation is process death induced by the
When keep-alives are in use, children will be kept busy
doing nothing waiting for more requests on the already open
connection. The default Apache 2.x supports pluggable concurrency models, called
Multi-Processing Modules (MPMs).
When building Apache, you must choose an MPM to use. There
are platform-specific MPMs for some platforms:
For more information on these and other MPMs, please
see the MPM documentation. Since memory usage is such an important consideration in
performance, you should attempt to eliminate modules that you are
not actually using. If you have built the modules as DSOs, eliminating modules is a simple
matter of commenting out the associated If, on the other hand, you have modules statically linked
into your Apache binary, you will need to recompile Apache in
order to remove unwanted modules. An associated question that arises here is, of course, what
modules you need, and which ones you don't. The answer here
will, of course, vary from one web site to another. However, the
minimal list of modules which you can get by with tends
to include Some modules, such as By default, APR implements these operations using the
most efficient mechanism available on each target
OS/CPU platform. Many modern CPUs, for example, have
an instruction that does an atomic compare-and-swap (CAS)
operation in hardware. On some platforms, however, APR
defaults to a slower, mutex-based implementation of the
atomic API in order to ensure compatibility with older
CPU models that lack such instructions. If you are
building Apache for one of these platforms, and you plan
to run only on newer CPUs, you can select a faster atomic
implementation at build time by configuring Apache with
the The If you include This section has not been fully updated
to take into account changes made in the 2.x version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. This discusses a shortcoming in the Unix socket API. Suppose
your web server uses multiple But this naive implementation has a serious starvation problem.
Recall that multiple children execute this loop at the same
time, and so multiple children will block at
One solution is to make the sockets non-blocking. In this
case the Another solution, the one used by Apache, is to serialize
entry into the inner loop. The loop looks like this
(differences highlighted): The functions
The directive This method uses the This method uses the (1.3 or later) This method uses SysV-style semaphores to
implement the mutex. Unfortunately SysV-style semaphores have
some bad side-effects. One is that it's possible Apache will
die without cleaning up the semaphore (see the
(1.3 or later) This method uses POSIX mutexes and should
work on any architecture implementing the full POSIX threads
specification, however appears to only work on Solaris (2.5
or later), and even then only in certain configurations. If
you experiment with this you should watch out for your server
hanging and not responding. Static content only servers may
work just fine. (2.0 or later) This method uses POSIX semaphores. The
semaphore ownership is not recovered if a thread in the process
holding the mutex segfaults, resulting in a hang of the web
server. If your system has another method of serialization which
isn't in the above list then it may be worthwhile adding code
for it to APR. Another solution that has been considered but never
implemented is to partially serialize the loop -- that is, let
in a certain number of processes. This would only be of
interest on multiprocessor boxes where it's possible multiple
children could run simultaneously, and the serialization
actually doesn't take advantage of the full bandwidth. This is
a possible area of future investigation, but priority remains
low because highly parallel web servers are not the norm. Ideally you should run servers without multiple
The above is fine and dandy for multiple socket servers, but
what about single socket servers? In theory they shouldn't
experience any of these same problems because all children can
just block in For this reason we have found that many architectures behave
more "nicely" if we serialize even the single socket case. So
this is actually the default in almost all cases. Crude
experiments under Linux (2.0.30 on a dual Pentium pro 166
w/128Mb RAM) have shown that the serialization of the single
socket case causes less than a 3% decrease in requests per
second over unserialized single-socket. But unserialized
single-socket showed an extra 100ms latency on each request.
This latency is probably a wash on long haul lines, and only an
issue on LANs. If you want to override the single socket
serialization you can define
As discussed in
draft-ietf-http-connection-00.txt section 8, in order for
an HTTP server to reliably implement the
protocol it needs to shutdown each direction of the
communication independently (recall that a TCP connection is
bi-directional, each half is independent of the other). This
fact is often overlooked by other servers, but is correctly
implemented in Apache as of 1.2. When this feature was added to Apache it caused a flurry of
problems on various versions of Unix because of a
shortsightedness. The TCP specification does not state that the
There are two ways of accomplishing this. One is the socket
option For the most part, Apache implements this in a function
called This naturally adds some expense at the end of a connection,
but it is required for a reliable implementation. As HTTP/1.1
becomes more prevalent, and all connections are persistent,
this expense will be amortized over more requests. If you want
to play with fire and disable this feature you can define
Apache's parent and children communicate with each other
through something called the scoreboard. Ideally this should be
implemented in shared memory. For those operating systems that
we either have access to, or have been given detailed ports
for, it typically is implemented using shared memory. The rest
default to using an on-disk file. The on-disk file is not only
slow, but it is unreliable (and less featured). Peruse the
If you have no intention of using dynamically loaded modules
(you probably don't if you're reading this and tuning your
server for every last ounce of performance) then you should add
Here is a system call trace of Apache 2.0.38 with the worker MPM
on Solaris 8. This trace was collected using: The Other systems may have different system call tracing utilities
such as In this trace, a client has requested a 10KB static file
from the httpd. Traces of non-static requests or requests
with content negotiation look wildly different (and quite ugly
in some cases). In this trace, the listener thread is running within LWP #67. Upon accepting the connection, the listener thread wakes up
a worker thread to do the request processing. In this trace,
the worker thread that handles the request is mapped to LWP #65. In order to implement virtual hosts, Apache needs to know
the local socket address used to accept the connection. It
is possible to eliminate this call in many situations (such
as when there are no virtual hosts, or when
The Next, the worker thread puts the connection to the client (file
descriptor 9) in non-blocking mode. The The worker thread reads the request from the client. This httpd has been configured with In this example, the httpd is able to send the HTTP response
header and the requested file with a single This The worker thread does a lingering close of the connection. Finally the worker thread closes the file that it has just delivered
and blocks until the listener assigns it another connection. Meanwhile, the listener thread is able to accept another connection
as soon as it has dispatched this connection to a worker thread (subject
to some flow-control logic in the worker MPM that throttles the listener
if all the available workers are busy). Though it isn't apparent from
this trace, the next Apache HTTP Server Version 2.0 This page documents all the relevant standards that the
Apache HTTP Server follows, along with brief descriptions. In addition to the information listed below, the following resources
should be consulted: This document is not yet complete. Regardless of what modules are compiled and used, Apache as a
basic web server complies with the following IETF recommendations: Regarding the Hypertext Markup Language, Apache complies with
the following IETF and W3C recommendations: Concerning the different methods of authentication, Apache
follows the following IETF recommendations: The following links document ISO and other language and country
code information: Apache HTTP Server Version 2.0 Originally written by This document supplements the The Apache module In other words: With Here come a lot of practical solutions I've either invented
myself or collected from other people's solutions in the past.
Feel free to learn the black magic of URL rewriting from
these examples. On some webservers there are more than one URL for a
resource. Usually there are canonical URLs (which should be
actually used and distributed) and those which are just
shortcuts, internal ones, etc. Independent of which URL the
user supplied with the request he should finally see the
canonical one only. We do an external HTTP redirect for all non-canonical
URLs to fix them in the location view of the Browser and
for all subsequent requests. In the example ruleset below
we replace Usually the We redirect the URL Note that this can also be handled using the Every webmaster can sing a song about the problem of
the trailing slash on URLs referencing directories. If they
are missing, the server dumps an error, because if you say
The solution to this subtle problem is to let the server
add the trailing slash automatically. To do this
correctly we have to use an external redirect, so the
browser correctly requests subsequent images etc. If we
only did a internal rewrite, this would only work for the
directory page, but would go wrong when any images are
included into this page with relative URLs, because the
browser would request an in-lined object. For instance, a
request for So, to do this trick we write: The crazy and lazy can even do the following in the
top-level We want to create a homogeneous and consistent URL
layout over all WWW servers on a Intranet webcluster, i.e.
all URLs (per definition server local and thus server
dependent!) become actually server independent!
What we want is to give the WWW namespace a consistent
server-independent layout: no URL should have to include
any physically correct target server. The cluster itself
should drive us automatically to the physical target
host. First, the knowledge of the target servers come from
(distributed) external maps which contain information
where our users, groups and entities stay. The have the
form We put them into files to when the URL is not locally valid to a server. The
following ruleset does this for us by the help of the map
files (assuming that server0 is a default server which
will be used if a user has no entry in the map): Many webmasters have asked for a solution to the
following situation: They wanted to redirect just all
homedirs on a webserver to another webserver. They usually
need such things when establishing a newer webserver which
will replace the old one over time. The solution is trivial with Some sites with thousands of users usually use a
structured homedir layout, i.e. each homedir is in a
subdirectory which begins for instance with the first
character of the username. So, We use the following ruleset to expand the tilde URLs
into exactly the above layout. This really is a hardcore example: a killer application
which heavily uses per-directory
In July 1996 I decided to make this archive public to
the world via a nice Web interface. "Nice" means that I
wanted to offer an interface where you can browse
directly through the archive hierarchy. And "nice" means
that I didn't wanted to change anything inside this
hierarchy - not even by putting some CGI scripts at the
top of it. Why? Because the above structure should be
later accessible via FTP as well, and I didn't want any
Web or CGI stuff to be there. The solution has two parts: The first is a set of CGI
scripts which create all the pages at all directory
levels on-the-fly. I put them under
The The first rule is for requests which miss the trailing
slash! The second rule does the real thing. And then
comes the killer configuration which stays in the
per-directory config file
Some hints for interpretation: When switching from the NCSA webserver to the more
modern Apache webserver a lot of people want a smooth
transition. So they want pages which use their old NCSA
We use a global rule to remove the prefix on-the-fly for
all requests: Sometimes it is necessary to let the webserver search
for pages in more than one directory. Here MultiViews or
other techniques cannot help. We program a explicit ruleset which searches for the
files in the directories. Perhaps you want to keep status information between
requests and use the URL to encode it. But you don't want
to use a CGI wrapper for all pages just to strip out this
information. We use a rewrite rule to strip out the status information
and remember it via an environment variable which can be
later dereferenced from within XSSI or CGI. This way a
URL Assume that you want to provide
For HTTP/1.0 requests there is no solution, but for
HTTP/1.1 requests which contain a Host: HTTP header we
can use the following ruleset to rewrite
We want to redirect homedir URLs to another webserver
Just a rewrite condition: A typical FAQ about URL rewriting is how to redirect
failing requests on webserver A to webserver B. Usually
this is done via The first solution has the best performance but less
flexibility, and is less error safe: The problem here is that this will only work for pages
inside the This uses the URL look-ahead feature of Sometimes we need more control (concerning the
character escaping mechanism) of URLs on redirects.
Usually the Apache kernels URL escape function also
escapes anchors, i.e. URLs like " We have to use a kludge by the use of a NPH-CGI script
which does the redirect itself. Because here no escaping
is done (NPH=non-parseable headers). First we introduce a
new URL scheme This forces all URLs prefixed with
This provides you with the functionality to do
redirects to all URL schemes, i.e. including the one
which are not directly accepted by Do you know the great CPAN (Comprehensive Perl Archive
Network) under http://www.perl.com/CPAN?
This does a redirect to one of several FTP servers around
the world which carry a CPAN mirror and is approximately
near the location of the requesting client. Actually this
can be called an FTP access multiplexing service. While
CPAN runs via CGI scripts, how can a similar approach
implemented via First we notice that from version 3.0.0
When tricks like time-dependent content should happen a
lot of webmasters still use CGI scripts which do for
instance redirects to specialized pages. How can it be done
via There are a lot of variables named This provides the content of How can we make URLs backward compatible (still
existing virtually) after migrating We just rewrite the name to its basename and test for
existence of the new extension. If it exists, we take
that name, else we rewrite the URL to its original state. Assume we have recently renamed the page
We rewrite the old URL to the new one internally via the
following rule: Assume again that we have recently renamed the page
We force a HTTP redirect to the new URL which leads to a
change of the browsers and thus the users view: At least for important top-level pages it is sometimes
necessary to provide the optimum of browser dependent
content, i.e. one has to provide a maximum version for the
latest Netscape variants, a minimum version for the Lynx
browsers and a average feature version for all others. We cannot use content negotiation because the browsers do
not provide their type in that form. Instead we have to
act on the HTTP header "User-Agent". The following condig
does the following: If the HTTP header "User-Agent"
begins with "Mozilla/3", the page Assume there are nice webpages on remote hosts we want
to bring into our namespace. For FTP servers we would use
the To provide this feature we map the remote webpage or even
the complete remote webarea to our namespace by the use
of the Proxy Throughput feature
(flag This is a tricky way of virtually running a corporate
(external) Internet webserver
( First, we have to make sure that our firewall still
protects the internal webserver and that only the
external webserver is allowed to retrieve data from it.
For a packet-filtering firewall we could for instance
configure a firewall ruleset like the following: Just adjust it to your actual configuration syntax.
Now we can establish the Suppose we want to load balance the traffic to
There are a lot of possible solutions for this problem.
We will discuss first a commonly known DNS-based variant
and then the special one with The simplest method for load-balancing is to use
the DNS round-robin feature of Then you additionally add the following entry: Notice that this seems wrong, but is actually an
intended feature of A sophisticated DNS-based method for
load-balancing is to use the program
In this variant we use entry in the DNS. Then we convert
Then we write There is a hardware solution available, too. Cisco
has a beast called LocalDirector which does a load
balancing at the TCP/IP level. Actually this is some
sort of a circuit level gateway in front of a
webcluster. If you have enough money and really need
a solution with high performance, use this one. On the net there are a lot of nifty CGI programs. But
their usage is usually boring, so a lot of webmaster
don't use them. Even Apache's Action handler feature for
MIME-types is only appropriate when the CGI programs
don't need special URLs (actually Or assume we have some more nifty programs:
which is ugly. Because we have to hard-code
both the location of the area
and the location of the CGI inside the
hyperlink. When we have to reorganize the area, we spend a
lot of time changing the various hyperlinks. The solution here is to provide a special new URL format
which automatically leads to the proper CGI invocation.
We configure the following: Now the hyperlink to search at
which internally gets automatically transformed to The same approach leads to an invocation for the
access log CGI program when the hyperlink
How can we transform a static page
We just rewrite the URL to the CGI-script and force the
correct MIME-type so it gets really run as a CGI-script.
This way a request to Here comes a really esoteric feature: Dynamically
generated but statically served pages, i.e. pages should be
delivered as pure static pages (read from the filesystem
and just passed through), but they have to be generated
dynamically by the webserver if missing. This way you can
have CGI-generated pages which are statically served unless
one (or a cronjob) removes the static contents. Then the
contents gets refreshed. Here a request to Wouldn't it be nice while creating a complex webpage if
the webbrowser would automatically refresh the page every
time we write a new version from within our editor?
Impossible? No! We just combine the MIME multipart feature, the
webserver NPH feature and the URL manipulation power of
Now when we reference the URL this leads to the internal invocation of the URL The only missing part is the NPH-CGI script. Although
one would usually say "left as an exercise to the reader"
;-) I will provide this, too. The To provide this feature we map the remote webpage or even
the complete remote webarea to our namespace by the use
of the Proxy Throughput feature (flag How can we block a really annoying robot from
retrieving pages of a specific webarea? A
We use a ruleset which forbids the URLs of the webarea
Assume we have under While we cannot 100% protect the images from inclusion,
we can at least restrict the cases where the browser
sends a HTTP Referer header. How can we forbid a list of externally configured hosts
from using our server? For Apache >= 1.3b6: For Apache <= 1.3b6: How can we forbid a certain host or even a user of a
special host from using the Apache proxy? We first have to make sure ...and this one for a user@host-dependent deny: Sometimes a very special authentication is needed, for
instance a authentication which checks for a set of
explicitly configured users. Only these should receive
access and without explicit prompting (which would occur
when using the Basic Auth via We use a list of rewrite conditions to exclude all except
our friends: How can we program a flexible URL Deflector which acts
on the "Referer" HTTP header and can be configured with as
many referring pages as we like? Use the following really tricky ruleset... ... in conjunction with a corresponding rewrite
map: This automatically redirects the request back to the
referring page (when " A FAQ: How can we solve the FOO/BAR/QUUX/etc.
problem? There seems no solution by the use of
Use an external This is a demonstration-only example and just rewrites
all URLs Apache HTTP Server Version 2.0 Some hints and tips on security issues in setting up a web server.
Some of the suggestions will be general, others specific to Apache. The Apache HTTP Server has a good record for security and a
developer community highly concerned about security issues. But
it is inevitable that some problems -- small or large -- will be
discovered in software after it is released. For this reason, it
is crucial to keep aware of updates to the software. If you have
obtained your version of the HTTP Server directly from Apache, we
highly recommend you subscribe to the Apache
HTTP Server Announcements List where you can keep informed of
new releases and security updates. Similar services are available
from most third-party distributors of Apache software. Of course, most times that a web server is compromised, it is
not because of problems in the HTTP Server code. Rather, it comes
from problems in add-on code, CGI scripts, or the underlying
Operating System. You must therefore stay aware of problems and
updates with all the software on your system. In typical operation, Apache is started by the root user, and it
switches to the user defined by the It is assumed that /, /usr, and /usr/local are only modifiable by
root. When you install the You can create an htdocs subdirectory which is modifiable by other
users -- since root never executes any files out of there, and shouldn't
be creating files in there. If you allow non-root users to modify any files that root either
executes or writes on then you open your system to root compromises.
For example, someone could replace the Server Side Includes (SSI) present a server administrator with
several potential security risks. The first risk is the increased load on the server. All
SSI-enabled files have to be parsed by Apache, whether or not
there are any SSI directives included within the files. While this
load increase is minor, in a shared server environment it can become
significant. SSI files also pose the same risks that are associated with CGI
scripts in general. Using the "exec cmd" element, SSI-enabled files
can execute any CGI script or program under the permissions of the
user and group Apache runs as, as configured in httpd.conf. There are ways to enhance the security of SSI files while still
taking advantage of the benefits they provide. To isolate the damage a wayward SSI file can cause, a server
administrator can enable suexec as
described in the CGI in General section. Enabling SSI for files with .html or .htm extensions can be
dangerous. This is especially true in a shared, or high traffic,
server environment. SSI-enabled files should have a separate extension,
such as the conventional .shtml. This helps keep server load at a
minimum and allows for easier management of risk. Another solution is to disable the ability to run scripts and
programs from SSI pages. To do this replace First of all, you always have to remember that you must trust the
writers of the CGI scripts/programs or your ability to spot potential
security holes in CGI, whether they were deliberate or accidental. CGI
scripts can run essentially arbitrary commands on your system with the
permissions of the web server user and can therefore be extremely
dangerous if they are not carefully checked. All the CGI scripts will run as the same user, so they have potential
to conflict (accidentally or deliberately) with other scripts e.g. User
A hates User B, so he writes a script to trash User B's CGI database. One
program which can be used to allow scripts to run as different users is
suEXEC which is included with Apache as of
1.2 and is called from special hooks in the Apache server code. Another
popular way of doing this is with
CGIWrap. Allowing users to execute CGI scripts in any directory should only be
considered if: Limiting CGI to special directories gives the admin control over what
goes into those directories. This is inevitably more secure than non
script aliased CGI, but only if users with write access to the
directories are trusted or the admin is willing to test each
new CGI script/program for potential security holes. Most sites choose this option over the non script aliased CGI
approach.
Embedded scripting options which run as part of the server itself,
such as mod_php, mod_perl, mod_tcl, and mod_python, run under the
identity of the server itself (see the To run a really tight ship, you'll want to stop users from setting
up In the server configuration file, put This prevents the use of One aspect of Apache which is occasionally misunderstood is the
feature of default access. That is, unless you take steps to change it,
if the server can find its way to a file through normal URL mapping
rules, it can serve it to clients. For instance, consider the following example: This would allow clients to walk through the entire filesystem. To
work around this, add the following block to your server's
configuration: This will forbid default access to filesystem locations. Add
appropriate Pay particular attention to the interactions of Also be wary of playing games with the To keep up-to-date with what is actually going on against your server
you have to check the Log Files. Even though
the log files only reports what has already happened, they will give you
some understanding of what attacks is thrown against the server and
allow you to check if the necessary level of security is present. A couple of examples: The first example will list the number of attacks trying to exploit the
Apache Tomcat
Source.JSP Malformed Request Information Disclosure Vulnerability,
the second example will list the ten last denied clients, for example: As you can see, the log files only report what already has happened, so
if the client had been able to access the in your Access Log. This means
you probably commented out the following in your server configuration
file: Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. The following documents give you step-by-step instructions
on how to accomplish common tasks with the Apache HTTP server.
Many of these documents are located at external sites and are
not the work of the Apache Software Foundation. Copyright to
documents on external sites is owned by the authors or their
assignees. Please consult the official Apache
Server documentation to verify what you read on external
sites. If you have a pointer to an accurate and well-written
tutorial not included here, please let us know by submitting it
to the Apache Bug
Database. Apache HTTP Server Version 2.0 This Multi-Processing Module (MPM) is the default for BeOS. It uses
a single control process which creates threads to handle requests. The Setting For Apache HTTP サーバ バージョン 2.0 このディレクティブは実際のファイル名 (もしくは存在するディレクトリの
存在しないファイル) の後に続くパス名情報があるリクエストを受け付けるか
拒否するかを制御します。続きのパス名情報はスクリプトには 例えば、 リクエストを処理するとき、サーバはディレクトリに
対して分散設定ファイルが有効になっていれば、
そのドキュメントへの
パス上にある全てのディレクトリから、ここで指定された名前の一覧の中で
最初に見つかったファイルをそれぞれ設定ファイルとして読み込みます。例えば: という設定があると、以下のようにして無効にされていない限り、
ドキュメント このディレクティブは、HTTP ヘッダにコンテントタイプパラメータを
持たない応答に追加される文字セットの名前を指定します。
これは、ドキュメント内の META タグで指定されたどのような文字セット
も無効にします。
このディレクティブは応答の MIME-type に応じて出力フィルタを使用するようにします。 次の例は 複数のフィルタでコンテンツを処理させたいときは、それぞれの名前をセミコロンで
分ける必要があります。各フィルタに対して
次の例は しかし、確実にフィルタが適用されるようにしたいときは、リソースに
明示的にコンテントタイプを割り当てることができます。これには例えば
タイプ毎の出力フィルタはプロキシリクエストには決して適用されません。 Turning 符号化されたスラッシュを許可することは、復号をすることを
意味しません。 サーバが ( このディレクティブを None に設定すると、.htaccess ファイルは完全に
無視されます。
この場合、サーバはファイルシステムの このディレクティブが directive-type には、以下のディレクティブ群の
キーワードのどれかを指定します。 例: 上の例では このディレクティブはディレクトリに対する認可領域 (訳注: realm)
の名前を指定します。
認可領域は、利用者がどのユーザ名とパスワードを送信すればよいのかを
クライアントに教えるために利用します。
例えば: ここで このディレクティブは対象ディレクトリで利用するユーザー認証の種類を選びます。
ただ、現在のところは このディレクティブは Apache が CGI スクリプトを実行するための
インタープリタを探す方法を制御します。
例えば、 このディレクティブは、RFC1864 及び RFC2068 において定義されている
MD5 は、任意長のデータの「メッセージダイジェスト」(「指紋」
と表現されることもある) を計算するアルゴリズムで、
データの変更があった場合には非常に高い信頼度でメッセージダイジェストに変更が
反映されます。 リクエスト毎にメッセージダイジェストを計算する (値はキャッシュされません)
ことから、
サーバパフォーマンスが低下することについて注意してください。 サーバは、MIME のタイプマップからは決定できない
ドキュメントの送信を要求されることがあります。 サーバは、ドキュメントのコンテントタイプをクライアントに通知する必要が
ありますので、このようにタイプが未知の場合は
これは 指定されたディレクトリとそのサブディレクトリにのみ
ディレクティブを適用させるためには、
directory-path 引数には注意してください: その引数は
Apache がファイルをアクセスするために使うファイルシステムのパスに
そのままマッチする必要があります。ある といった指定の場合、 もし複数の (正規表現以外の) と設定し、ドキュメント 正規表現は、通常のセクションがすべて適用されるまで
考慮されません。
その後、全ての正規表現が設定ファイルに現れた順で試されます。
例えば、以下のような場合に 正規表現のセクションはすべての通常の Apache のデフォルトでは そしてアクセスを可能にしたいディレクトリに対して
個別に設定すればよいでしょう。
このあたりについては、セキュリティに関するコツを
参照してください。 ディレクトリセクションは httpd.conf ファイル書きます。
は /www/ 以下にある数字 3 文字のディレクトリにマッチします。 このディレクティブは、 この場合、
このディレクティブは配送中にファイルの内容を読み込む必要があるときに
このメモリマップは性能の向上を持たらすことがあります。
しかし、環境によっては運用上の問題を防ぐためにメモリマッピングを
使用しないようにした方が良い場合もあります: これらの問題に当てはまるサーバの設定の場合は、以下のようにして
ファイルの配送時のメモリマッピングを使用不可にしてください: NFS マウントされたファイルには、問題のあるファイルにのみ明示的に
この機能を使用不可にします: このディレクティブはクライアンにファイルの内容を送るときに
sendfile は read と send を別々に行なうことと、バッファの割り当てを
回避します。しかし、プラットフォームやファイルシステムの中には
運用上の問題を避けるためにこの機能を使用不可にした方が良い場合があります: これらの問題に当てはまるサーバの設定の場合は、以下のようにして
この機能を使用不可にしてください: NFS や SMB マウントされたファイルには、問題のあるファイルにのみ明示的に
この機能を使用不可にします: 問題やエラーが発生したときの動作として、
Apache には以下の四つのうち一つの動作を設定することができます。 最初のものがデフォルトの動作で、2 番目から 4 番目は、
URL の場合は、ローカルの URL の指定としてスラッシュで始まる (/) パスか、
クライアントが解釈できるフル URL を指定します。 加えて、特別な値 リモート URL (例えば、頭に Microsoft Internet Explorer (MSIE) はデフォルトではサーバが生成したエラーメッセージが
「小さすぎる」ときには無視をして自分自身の「やさしい」エラーメッセージで
置換します。サイズのしきい値はエラーの種類によって異なりますが、
一般的にはエラーの文書を 512 バイトよりも多きくすると、MSIE は
サーバが生成したエラーを隠さずに表示します。詳しい情報は Microsoft
Knowledge Base の記事 Q294807
にあります。 2.0 より前のバージョンでは、対になっていない二重引用符を
先頭に付けることによりメッセージであることを指定していました。 file-path がパイプ (|) から始まる場合は、
エラーログを処理するために実行されるコマンドが
指定されていると解釈されます。 ファイル名の変わりに セキュリティ:
ログファイルを格納するディレクトリが、サーバを起動したユーザ以外の
ユーザによって書き込める場合にセキュリティが破られる可能性があることに
関する詳細は セキュリティに関するコツ を
参照してください。 Unix 以外のプラットフォームでファイルのパスを入力するときは、
プラットフォームがバックスラッシュの使用を許していたとしても、
確実にスラッシュのみが使用されるように注意してください。一般的には、
設定ファイル全般でスラッシュのみを使う方が良いでしょう。
あるディレクトリの設定に
filename 引数は、ファイル名かワイルドカード文字列
で、ワイルドカードでは とすることにより、一般的なインターネットの画像フォーマットにマッチします。
ただし、
ちなみに、 は一般的なインターネットの画像形式にマッチします。 このディレクティブは、ホスト名をログ収集できるように
DNS ルックアップを有効にします
(さらに、CGI/SSI に ディレクティブのデフォルトは
本当に逆引きを必要としているわけではないサイトの
ネットワークトラフィックを低減させるために、 このディレクティブは、クライアントマシン上で
identd やそれに類似したデーモンが動作しているときに、
それぞれの接続に対して RFC 1413 に準処したリモートユーザの
名前のロギングを行なうようにします。
この情報は、アクセスログに収集されます。 ここで得られた情報は簡単なユーザ追跡に使う以外は、
まったく信頼するべきではありません。 すべてのリクエストに対してルックアップが行なわれますので、
深刻な遅延の問題を起こすかもしれないことに注意してください。
(訳注: 例えばクライアント側に) ファイアウォールがあると、
ルックアップが失敗し、各リクエストに 30 秒の遅延が加わることに
なる可能性があります。
従って、一般的にはインターネットからアクセス可能なパブリックなサーバで
有益なものではありません。 前者の場合には、parameter-name と名付けられたパラメータが
定義されていれば開始と終了の間のディレクティブが処理されます。
後者の場合は逆で、parameter-name が指定されていない
場合に処理されます。 parameter-name 引数は、サーバを起動する際に
前者の場合は、module name と名付けられたモジュールが
Apache に組み込まれていれば
(コンパイル済みのものと、 module name 引数は、
コンパイルをした時のモジュールのファイル名です。
例えば、
このディレクティブにより、サーバの設定ファイルから
他の設定ファイルをインクルードすることができます。 複数のファイルをアルファベット順に一度に読み込むために、
シェル形式 ( 指定するファイルパスは絶対パスか、
例: HTTP/1.0 の Keep-Alive 拡張と HTTP/1.1 の持続的接続の機能は、
複数のリクエストが同じ TCP の接続で送られる、長時間持続する
HTTP セッションを提供します。たくさんの画像が
含まれる HTML ドキュメントでは場合によっては遅延時間が 50% 短縮される結果も
でています。Keep-Alive 接続を有効にするには
HTTP/1.0 に対応したクライアントの際には、
クライアントより特に要求があった場合のみ Keep-Alive 接続となります。
さらに、HTTP/1.0 クライアントでは、コンテンツの容量が先に
(訳注: 要求に対して応答を返す前に) わかる場合のみ Keep-Alive
接続を利用できます。
これは、CGI の出力や SSI のページ、
サーバが生成したディレクトリのリストのような動的コンテンツを
HTTP/1.0 クライアントに送る場合には Keep-Alive 接続を使えないことを意味します。
HTTP/1.1 に対応したクライアントの際には、
特に指定されない限りはデフォルトとして持続的な接続が行なわれます。
クライアントが要求すれば、コンテンツの容量を判別できないものを
持続的な接続を通して送るために、チャンクエンコーディングが用いられます。 接続を閉じる前に、Apache が次のリクエストを何秒待つかを指定します。
リクエストを受け付けた後は、 アクセス制御は、通常全てのアクセスメソッドに対して
影響し、普通はこれが望ましい挙動です。
そうしたことから、大部分の場合にはアクセス制御に関わるディレクティブを
メソッド名には以下の中から一つ以上を列挙することができます:
例: 内部リダイレクトは例えば このディレクティブは、リクエスト毎に評価される、二つの違う限界値を
設定します。最初の number は、起こり得る
内部リクエストの最大値を設定します。二つめの number は
サブリクエストが入れ子にできる深さを設定します。number を
一つだけ指定したときは、両方の限界値にその値が設定されます。 このディレクティブは、リクエストボディに許されるバイト数、bytes
を 0 (無制限を意味します) から 2147483647 (2GB) までの数値で指定します。 このディレクティブは、
管理者にクライアントからの異常なリクエストを制御できるようにし、
何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。 ある場所へのファイルアップロードを許可する場合に、
アップロードできるファイルのサイズを 100K に制限したければ、
以下のように指定します: number には、0 (無制限を意味します) から 32767
までの整数を指定します。
デフォルト値は、定数 LimitRequestBody ディレクティブは、
サーバ管理者が HTTP リクエスト中において許可するリクエストヘッダフィールド数を
指定します。
サーバはこの値には通常のクライアントからのリクエストに含まれるであろう
フィールドの数より大きな値が必要とします。
クライアントにより使われた要求ヘッダーフィールドの数が
20 を超えることはほとんどありませんが、
これは種々のクライアントの実装よって変わり、
詳細なコンテントネゴシエーションをするためのブラウザの設定までにも
影響されることがあります。
オプションの HTTP 拡張はリクエストヘッダフィールドを使って現される場合が
多くあります。 このディレクティブは、
管理者にクライアントからの異常なリクエストを制御できるようにし、
何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。
リクエストのフィールドが多過ぎることを意味するエラー応答が
普通のクライアントに返されるような時はこの値を増やしてください。 例: このディレクティブは、HTTP リクエストヘッダ内に含めることのできる
バイト数、bytes を
0 からコンパイル時に定義される定数
このディレクティブは、
管理者にクライアントからの異常なリクエストを制御できるようにし、
何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。 例: このディレクティブは、HTTP リクエスト行内で許容されるバイト数
bytes を 0 からコンパイル時の定数
このディレクティブは、
管理者にクライアントからの異常なリクエストを制御できるようにし、
何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。 例: XML 形式のリクエストのボディの最大値を (バイト単位で) 制限します。
値に 例: 全ての (プロキシ以外の) リクエストに対し、
URL は URL にはワイルドカードを利用することができます。
は URL に スラッシュ文字は、URL 内に現れる場所に応じて変化する
特別な意味を持っています。
ファイルシステムにおいて利用する場合には複数のスラッシュでも一つの
スラッシュとして扱われることが多いですが、
(すなわち、 例えば、 は URL に 特定のレベルが指定された場合、それより高いレベルの全てのメッセージが
報告されます。
例えば、 なお 例: ファイルにログを出力する場合、 例: addr にはホスト名を指定できますが、
常に IP アドレスを指定するのが推奨されます。
例えば、 「主サーバ」や、どの 名前ベースのバーチャルホストにポート番号を指定することも可能です。
例えば IPV6 のアドレスは次の例のように角括弧で囲む必要があります: すべてのインタフェースへのリクエストを受け取るようにするためには、
引数として option を サーバがシンボリックリンクをたどる場合でも、
通常、ディレクトリに対して複数の 例えば、 どのような設定もされていなければ、デフォルトでは このディレクティブは、どの認証済みのユーザがディレクトリに
アクセスすることができるかを指定します。
以下のような構文になります。 このようにして適用されたアクセス制御は、全てのメソッドに
対して行なわれます。
通常は、これが望ましい動作です。
もし、特定のメソッドに対してのみアクセスの制御を適用し、
他のメソッドは制限しない場合には、 一つか二つのパラメータをとります。
最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、
2 番目のパラメータは最大のリソースリミットを設定します。
パラメータには数字か、オペレーティングシステムの最大となる
ちなみに、この設定は Apache の子プロセス自体ではなく、
リクエストを受け付けた Apache の子プロセスから fork されたプロセスに
適用されます。
これには CGI や SSI から実行されたコマンドが含まれますが、Apache の
親プロセスから fork されたログのパイププロセスなどには適用されません。 CPU リソースのリミットはプロセスあたりの秒数で表わされます。 一つか二つのパラメータををとります。
最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、
2 番目のパラメータは最大のリソースリミットを設定します。
パラメータには数字か、オペレーティングシステムの最大となる
この設定は Apache の子プロセス自体ではなく、
リクエストを受け付けた Apache の子プロセスから fork されたプロセスに
適用されます。
これには CGI や SSI から実行されたコマンドが含まれますが、Apache の
親プロセスから fork されたログのパイププロセスなどには適用されません。 メモリリソースのリミットはプロセスあたりのバイト数で表わされます。 一つか二つのパラメータをとります。
最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、
2 番目のパラメータは最大のリソースリミットを設定します。
パラメータには数字か、オペレーティングシステムの最大となる
この設定は Apache の子プロセス自体ではなく、
リクエストを受け付けた Apache の子プロセスから fork されたプロセスに
適用されます。
これには CGI や SSI から実行されたコマンドが含まれますが、Apache の
親プロセスから fork されたログのパイププロセスなどには適用されません。 プロセスの制限は、ユーザあたりのプロセス数で制御されます。 CGI プロセスがウェブサーバのユーザ ID 以外で実行されるので
無ければ、
このディレクティブは、サーバ自身が生成できるプロセスの数を制限することになります。
そのような状況になっているかどうかは、 例えば、同じネットワーク上にいる人にはウェブサイトのある部分について
無制限のアクセスを許したいけれど、外のネットワークの人には
パスワードを提供させるようにするためには、次のような設定をすることが
できます: バージョン 2.0.51 からは
このディレクティブは、Apache で CGI スクリプトを
実行する場合に利用するインタープリタを、
どのように探し出すかについて制御するために使用します。
デフォルトの設定は もしくは、perl が Apache 2.0 から導入されたオプション その際、これのために専用のアドレスを設定するのが良いでしょう。
例えば、 といったようにします。ユーザはいつもサーバに関する話であるということを
明記してくるわけではありませんので。 名前ベースのバーチャルホスト
を利用している場合、 自己参照 URL (例えば デフォルトである バージョン 2.0.44 以降ではこのディレクティブは このディレクティブは、クライアントに送り返す この設定はサーバ全体に適用され、バーチャルホスト上で有効にしたり
無効にしたりはできません。 バージョン 2.0.44 以降ではこのディレクティブは 別の例: URL 複数のフィルタを指定するときは、データを処理する順番に
セミコロンで区切る必要があります。 例えば、以下の設定は 複数のフィルタを指定するときは、データを処理する順番に
セミコロンで区切る必要があります。 将来には別々の設定をすることが可能にできるよう考慮中です。
Apache 1.2 以前はタイマーは 1200 がデフォルトでしたが、
300 に下げられました。300 でもほとんどの場合は十分すぎる値です。
コード中の変な場所にまだパケットを送る際にタイマをリセットしない
場所があるかもしれないので、デフォルトをより小さい値にはしていません。 多くの状況で Apache は自己参照 URL、すなわち
同じサーバを指す URL、を作成する必要があります。
これが有用な場合の例は、イントラネットのサーバで、 三つ目のオプション CGI が IPv6 アドレスはオプションのポート番号の指定と区別するために、
角括弧で括って指定する必要があります。次は IPv6 の例です: 各々のバーチャルホストにはそれぞれ違う IP アドレス、ポート番号
もしくはホスト名に対応する必要があり、
1 番目の場合には複数のアドレスで IP パケットを受信できるように
サーバマシンを設定しなければなりません。
(もし、マシンが複数のネットワークインターフェースと持たない場合は、
(OSがサポートしていれば) セキュリティに関して:
サーバーを起動した以外のユーザがログファイルが保管されるディレクトリに
書き込み可能なときになぜセキュリティが破られる可能性があるかの詳細は
セキュリティに関するコツ を
参照してください。 IP ベースのバーチャルホストを使っている場合は、特別な名前
サーバーを起動した以外のユーザがログファイルが保管されるディレクトリに
書き込み可能なときになぜセキュリティが破られる可能性があるかの詳細は
セキュリティに関するコツ を
参照してください。 Apache HTTP サーバ バージョン 2.0 この文書は各 Apache 設定ディレクティブ
を説明するために使われている用語を説明します。 ディレクティブの目的の簡単な説明。 設定ファイル中のディレクティブの書式を示します。
この構文はディレクティブ特有なので、詳細はディレクティブの説明を
参照してください。一般的に、ディレクティブ名の後には
空白により分割されたいくつかの引数が続きます。
引数が空白を含むときは二重引用符 (訳注: ")
で囲まれています。 オプショナルな引数は括弧
(訳注: []) で囲まれています。
引数が複数の値を取り得る場合は、それらの値は垂直の棒 "|"
で 分割されています。
変更されないテキストはデフォルトのフォントで表示され、置換の必要な
引数は強調されて表示されます。
引数の数が変わるディレクティブは最後の
引数が繰り返されることを示すために "..."
で終わります。
ディレクティブは多くの違う型の引数をとります。いくつか、良く
使われるものを以下で定義します。 ディレクティブにデフォルト値
(すなわち、設定ファイルから
省略されていても、Apache
ウェブサーバは特定の値に設定されているかのように
動作します) がある場合はここに記述されます。
デフォルト値の無い場合、ここは "None" と
書かれます。ここで書かれているデフォルトはサーバと共に配布されている
デフォルトの httpd.conf
内に書かれているディレクティブの値と
違う可能性があることに注意してください。
これは、サーバの設定ファイル中のどこでディレクティブが有効なのかを示します。
次に示す値が一つ以上カンマ区切りで列挙されています。
ディレクティブは指示されたコンテキストでのみ許可されます。
他の場所で使おうとすると、サーバがそのコンテキストを正しく扱えなく
なるような設定エラーが発生するか、サーバがまったく動作しなくなる、
すなわち、サーバが起動しなくなるということになります。
ディレクティブの有効な位置は、実際は挙げられているコンテキストの
論理和 (訳注: Boolen OR)
になります。言い換えると、
" このディレクティブの属性は、 上書きは、 これはディレクティブが Apache
ウェブサーバにどれくらいきつく組み込まれているかを
示します。言い換えれば、ディレクティブとその機能を利用するために、
モジュールの数を増やして、サーバを再コンパイルする必要があるかもしれない
ということを示します。
この属性が取り得る値は以下のものです:
これは単純にディレクティブが定義されているモジュールの名前を記載します。 ディレクティブが Apache 2
の配布に組み込まれていなかった場合、
ディレクティブが導入されたバージョンがここに書かれています。
また、ディレクティブが特定のプラットフォームにのみ存在するときも
ここに書かれています。 Apache HTTP サーバ バージョン 2.0
標準 Apache 配布にあるすべての Apache のディレクティブの一覧です。
これらは一貫した形式で書かれていて、使われている用語の
用語集 も用意されています。
各ディレクティブの概要を説明した ディレクティブクイックリファレンスも
あります。
A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | R | S | T | U | V | W | X Apache HTTP サーバ バージョン 2.0
以下は Apache の配布の一部として配られているすべてのモジュールの
一覧です。すべての Apache
ディレクティブ のアルファベット順のリストも見てください。
A | C | D | E | F | H | I | L | M | N | P | R | S | U | V Apache HTTP Server Version 2.0 This MPM is experimental, so it may or may not work
as expected. This is an experimental variant of the standard
To use the This MPM depends on APR's atomic compare-and-swap operations for
thread synchronization. If you are compiling for an x86 target
and you don't need to support 386s, or you are compiling for a
SPARC and you don't need to run on pre-UltraSPARC chips, add
Apache HTTP サーバ バージョン 2.0 ホストによるアクセス制限とパスワードによる認証を同時に
行なうことが可能です。その場合、その二つの制限の関係を指定するために
一般的には、アクセス制限ディレクティブはすべてのアクセスメソッド
( このディレクティブの最初の引数は常に この文字列に合うか、これで終わる名前のホストのアクセスが許可されます。
各部分が完全に合うものだけに適用されますので、上の例は
アクセスを許可する IP アドレスです。 サブネットの制限用の、IP
アドレスの最初の一つから三つまでのバイトです。 ネットワーク a.b.c.d とネットマスク w.x.y.z です。
より細粒度のサブネット制限用です。 ネットマスクが nnn の上位ビットが 1
となっているものからなること以外は前のものと同じです。 注: 最後の三つの例はまったく同じホストに合います。 IPv6 アドレスと IPv6 のサブネットは以下のように指定できます: この場合、user-agent の文字列が このディレクティブはホスト名、IP
アドレス、環境変数に基づいてサーバへのアクセスを制限します。
キーワードはコンマで分離することだけが可能です。
間に空白があってはいけません。どの場合でも、 以下の例では、apache.org
ドメインのすべてのホストはアクセスを許可されます。
他のすべてのホストはアクセスを拒否されます。 次の例では、foo.apache.org サブドメインにあるホスト以外の、
apache.org ドメインのすべてのホストがアクセスを許可されます。
apache.org
ドメインでないホストは、デフォルトの状態がアクセス拒否のため、
サーバへのアクセスを拒否されます。 一方、上の例の はデフォルトのアクセス状態が deny になるため、
Apache HTTP サーバ バージョン 2.0 このモジュールには二つのディレクティブがあります。 このディレクティブは action-type
がリクエストされたときに cgi-script
が実行されるという動作を追加します。cgi-script は
最初の例では、MIME コンテントタイプが 2 番目の例では、拡張子が このディレクティブは method
というメソッドを使ってリクエストが行なわれたときに
cgi-script を実行するという動作を追加します。
cgi-script は
Script コマンドはデフォルトの動作を追加するだけであることに
注意してください。もし CGI スクリプトが呼ばれたり、リクエストされた
メソッドを内部で扱うことのできる他のリソースがあれば、それが行なわれます。
Apache HTTP サーバ バージョン 2.0 このモジュールのディレクティブはサーバにリクエストが到着したときに
URL の操作や制御をすることを可能にします。 様々なコンテキスト中での Alias や Redirect は他のディレクティブと
同じように標準の マージ規則 に
従って処理されます。ただし、(例えば まず、Alias の前にすべての Redirect が処理されます。ですから、 ですから、二つ以上のディレクティブが同じパスに適用されるときは、
すべてのディレクティブの効果を得るためにはより詳しいパスを先に書く
必要があります。例えば、次の設定は期待通りの動作をします: しかし、上記の二つのディレクティブの順番が逆になると、
http://myserver/image/foo.gif へのリクエストに対して、サーバは
ファイル /ftp/pub/image/foo.gif を返します。 もし url-path の最後に /
を書いたなら、サーバがエイリアスを展開するためには、最後の /
が必要になることに注意してください。すなわち、 エイリアスの行き先を含んでいる 特に、 このディレクティブは Redirect ディレクティブは古い URL を新しいものへマップします。
新しい URL がクライアントに返されます。そして、
クライアントは新しいアドレスをもう一回取得しようとします。
URL-path (% が復号された) パスで始まるドキュメントへの
すべてのリクエストは URL で始まる新しい
(% が符号化された) URL へのリダイレクトエラーが返されます。 クライアントは http://myserver/service/foo.txt
へのリクエストを行なうと、代わりに http://foo2.bar.com/service/foo.txt
をアクセスするように告げられます。 設定ファイル中の順番に関わらず、
Redirect 系のディレクティブは Alias
ディレクティブと ScriptAlias ディレクティブよりも優先されます。
また、.htaccess ファイルや もし status 引数が与えられていなければ、リダイレクトは
"temporary" (HTTP ステータス 302) になります。これはクライアントに
リソースが一時的に移動したということを示します。Status
引数は 他の HTTP のステータスコードを返すために使用することができます: Status の値にステータスコードを数値で与えることで
他のステータスコードも返すことができます。ステータスが 300 と 399
の間にある場合、url 引数は存在していなければいけません。
その他の場合は省略されていなければなりません。ただし、
ステータスは Apache のコードが知っているものである必要があります
(http_protocol.c の関数 例: このディレクティブは このディレクティブはクライアントに Redirect が永久的なもの
(ステータス 301) であることを知らせます。
このディレクティブはクライアントに Redirect
が一時的なものである (ステータス 302) ことを知らせます。
このディレクティブは Apache HTTP サーバ バージョン 2.0 このモジュールはハンドラ これはサーバからどんな種類のデータを送るときにも使用できます。
Cgi スクリプトや nph スクリプトが無くてもリダイレクトや他の特別な
HTTP 応答を送ることができます。 歴史的な理由により、このモジュールは mime タイプ
サーバ設定ファイルで、ファイルと 拡張子が これはクライアントにファイルが移動したことを知らせるために
as is (そのまま) で送られるファイルの内容の例です。
注意: サーバはクライアントに返されるデータに常に Apache HTTP サーバ バージョン 2.0 プレインテキストのパスワードファイルとグループファイルを検査して
ユーザを探すことで、HTTP 基本認証でアクセス制限できるようにします。
似たような機能で、もっと大きなスケーラビリティを持ったものは、
ですから、二つ以上のモジュールのデータベースで同一の
ユーザ ID が現われたり、
または、正しい 一般的な使用法は、 デフォルトでは、制御は移行しません。そして、未知のユーザ ID や
ルールがあっても "Authentication Required" 応答が返されます。
ですから、このディレクティブ設定しないことでシステムの安全を維持できて、また、
NCSA 準拠の挙動を強制できます。 ユーザが自分自身で作成した
.htaccess ファイルで認証できるようにすることの影響を
考慮に入れておいてください。そして、
それが本当に希望の挙動であるかどうかを検討してください。
一般的に言って、mSQL といったデータベースのセキュリティ保護よりも、
単純に一つのファイル .htpasswd のセキュリティを保護する方が容易です。
グループファイル各行は、グループ名、コロン、そして
スペース区切りでそのメンバーのユーザ名を記述します。 大きなファイルを探索するのは、非常に効率が悪いという点に
注意してください。そのような場合は、
ユーザファイルの各行には、ユーザ名、コロン、
暗号化したパスワードを記述します。
同一ユーザ ID が複数回登録された時は、 バイナリ配布の一部としてインストールされるか、
あるいは 初期 ID パスワードファイル (訳注: 非常に多くのユーザを登録すると大きなファイルになりますが)
大きなテキストファイルを検索するのは非常に効率が悪い
ということに注意してください。そのような必要のある時は、
Apache HTTP Server Version 2.0 This module does access control in a manner similar to
anonymous-ftp sites; i.e. have a 'magic' user id
'anonymous' and the email address as a password. These email
addresses can be logged. Combined with other (database) access control methods, this
allows for effective user tracking and customization according
to a user profile while still keeping the site open for
'unregistered' users. One advantage of using Auth-based user
tracking is that, unlike magic-cookies and funny URL
pre/postfixes, it is completely browser independent and it
allows users to share URLs. The example below (when combined with the Auth directives of a
htpasswd-file based (or GDM, mSQL etc.) base access
control system allows users in as 'guests' with the following
properties: A list of one or more 'magic' userIDs which are allowed
access without password verification. The userIDs are space
separated. It is possible to use the ' and " quotes to allow a
space in a userID as well as the \ escape character. Please note that the comparison is
case-IN-sensitive. This would allow the user to enter without password
verification by using the userIDs "anonymous",
"AnonyMous", "Not Registered" and "I Don't Know". When set Be sure you know what you are doing when you decide to
switch it on. And remember that the order in which the Authentication
modules are queried is defined in the modules.c files at compile
time. When set Specifies whether the user must specify an email address as
the password. This prohibits blank passwords. When set When set Apache HTTP Server Version 2.0 This module provides for HTTP Basic Authentication, where
the usernames and passwords are stored in DBM type database
files. It is an alternative to the plain text password files
provided by Setting the So if a userID appears in the database of more than one module;
or if a valid A common use for this is in conjunction with one of the
basic auth modules; such as By default, control is not passed on and an unknown userID
or rule will result in an "Authentication Required" reply. Not
setting it thus keeps the system secure and forces an NCSA
compliant behaviour. Do consider the implications of allowing a user to allow
fall-through in his The The group file is keyed on the username. The value for a
user is a comma-separated list of the groups to which the users
belongs. There must be no whitespace within the value, and it
must never contain any colons. Security: make sure that the
Combining Group and Password DBM files: In some cases it is
easier to manage a single database which contains both the
password and group details for each user. This simplifies any
support programs that need to be written: they now only have to
deal with writing to and locking a single DBM file. This can be
accomplished by first setting the group and password files to
point to the same DBM: The key for the single DBM is the username. The value consists
of The password section contains the encrypted password as before.
This is followed by a colon and the comma separated list of groups.
Other data may optionally be left in the DBM file after another colon;
it is ignored by the authentication module. This is what
www.telescope.org uses for its combined password and group database. Sets the type of database file that is used to store the passwords.
The default database type is determined at compile time. The
availability of other types of database files also depends on
compile-time settings. It is crucial that whatever program you use to create your password
files is configured to use the same type of database. The The user file is keyed on the username. The value for a user is
the encrypted password, optionally followed by a colon and arbitrary
data. The colon and the data following it will be ignored by the
server. Make sure that the Important compatibility note: The implementation of
"dbmopen" in the apache modules reads the string length of the
hashed values from the DBM data structures, rather than relying
upon the string being NULL-appended. Some applications, such as
the Netscape web server, rely upon the string being
NULL-appended, so if you are having trouble using DBM files
interchangeably between applications this may be a part of the
problem. A perl script called
Apache HTTP Server Version 2.0 This module implements HTTP Digest Authentication. However, it
has not been extensively tested and is therefore marked
experimental. Using MD5 Digest authentication is very simple. Simply set
up authentication normally, using Appropriate user (text) files can be created using the
Digest authentication provides a more secure password system
than Basic authentication, but only works with supporting
browsers. As of November 2002, the major browsers that support digest
authentication are Opera, MS Internet
Explorer (fails when used with a query string - see "Working with MS Internet Explorer" below for a workaround), Amaya, Mozilla and Netscape since version 7. Since digest authentication is not
as widely implemented as basic authentication, you should use it only
in controlled environments. The Digest authentication implementation in previous Internet
Explorer for Windows versions (5 and 6) had issues, namely that
The first way is to use Since version 2.0.51 Apache also provides a workaround in the
This workaround is not necessary for MSIE 7, though enabling it does
not cause any compatibility issues or significant overhead. See the The The This directive should always be specified and
contain at least the (set of) root URI(s) for this space.
Omitting to do so will cause the client to send the
Authorization header for every request sent to this
server. Apart from increasing the size of the request, it may
also have a detrimental effect on performance if The URIs specified can also point to different servers, in
which case clients (which understand this) will then share
username/password info across multiple servers without
prompting the user each time. The The digest file uses a special format. Files in this format
can be created using the The Each line of the group file contains a groupname followed by
a colon, followed by the member usernames separated by spaces.
Example: Note that searching large text files is very
inefficient. Make sure that the The The The The size is normally expressed in Bytes, but you
may let the number follow a Apache HTTP Server Version 2.0 There are two phases in granting access to a user. The first
phase is authentication, in which During the authentication phase, The following directives are used during the search/bind
phase During the authorization phase, Apache's If this directive exists, The Because of the way that If the This directive specifies an LDAP group whose members are
allowed access. It takes the distinguished name of the LDAP
group. Note: Do not surround the group name with quotes.
For example, assume that the following entry existed in
the LDAP directory: The following directive would grant access to both Fred and
Barbara: Behavior of this directive is modified by the The The following directive would grant access to a specific
DN: Behavior of this directive is modified by the The The following directive would grant access to anyone with
the attribute employeeType = active Multiple attribute/value pairs can be specified on the same line
separated by spaces or they can be specified in multiple
The following directive would grant access to anyone with
the city attribute equal to "San Jose" or status equal to "Active" The next example demonstrates the power of using filters
to accomplish complicated administrative requirements.
Without filters, it would have been necessary to create a
new LDAP group and ensure that the group's members remain
synchronized with the pager users. This becomes trivial
with filters. The goal is to grant access to anyone who has
a filter, plus grant access to Joe Manager, who doesn't
have a pager, but does need to access the same
resource: This last may look confusing at first, so it helps to
evaluate what the search filter will look like based on who
connects, as shown below. The text in blue is the part that
is filled in using the attribute specified in the URL. The
text in red is the part that is filled in using the filter
specified in the URL. The text in green is filled in using
the information that is retrieved from the HTTP client. If
Fred User connects as The above search will only succeed if fuser has a
pager. When Joe Manager connects as jmanager, the
filter looks like The above search will succeed whether jmanager
has a pager or not. To use TLS, see the To use SSL, see the To specify a secure LDAP server, use ldaps:// in the
Normally, FrontPage uses FrontPage-web-specific user/group
files (i.e., the Once a FrontPage web has been created, adding LDAP
authentication to it is a matter of adding the following
directives to every FrontPage restricts access to a web by adding the Once directives have been added as specified above,
FrontPage users will be able to perform all management
operations from the FrontPage client. Set to An optional DN used to bind to the server when searching for
entries. If not provided, A bind password to use in conjunction with the bind DN. Note
that the bind password is probably sensitive data, and should be
properly protected. You should only use the The The file contains lines in the following format: The case of the extension does not matter. Blank lines, and lines
beginning with a hash character ( When set, This directive specifies when Set to See the section on using Microsoft
FrontPage with This directive specifies which LDAP attributes are used to
check for group membership. Multiple attributes can be used by
specifying this directive multiple times. If not specified,
then When set If this directive is set to on, the value of the
An RFC 2255 URL which specifies the LDAP search parameters
to use. The syntax of the URL is The name/port of the ldap server (defaults to
Once a connection has been made to a server, that
connection remains active for the life of the
If the LDAP server goes down and breaks an existing
connection, When doing searches, the attribute, filter and username passed
by the HTTP client are combined to create a search filter that
looks like
For example, consider an URL of
See above for examples of Apache HTTP サーバ バージョン 2.0 ディレクトリのインデックスは二つの情報源のうちの
一つから生成できます: 望むならば、自動インデックス生成を完全に除去 (あるいは置換)
できるように、この二つの機能は分離されています。 自動インデックス生成は もし "Size" でソートした場合は、用いられるのは
実際のファイルのサイズであって、
表示の値ではないことに注意してください -
たとえ両方ともが "1K" と表示されていたとしても、
1010 バイトのファイルは必ず 1011
バイトのファイルよりも前 (昇順の場合) に表示されます。 Apache 2.0.23 で、
コラムソートのためにクエリー引数を再編成して、
新しいクエリーオプションのグループを導入しました。
出力に対するクライアントのすべての制御を効率的に抹消
できるように、
コラムソートのヘッダそれ自体が、
下記のソートクエリーオプションを付加する
自分自身を参照するリンクです。
下記のオプションのどれでも、
ディレクトリリソースへのリクエストに加えることができます。 "P (パターンの P)" クエリー引数は、
通常の 下の単純な例は、これらのクエリーオプションを
表します。これをそのまま切り取って HEADER.html
ファイルに保存することもできます。
mod_autoindex が X=Go 入力にぶつかる前に
引数が全て解釈されるように、
未知の引数 "X" はリストの最後に置かれています。 通常のデフォルトの説明領域は 23 バイトの幅です。
このコラムの大きさを上書きしたり、
説明が無制限長でもよいようにするための詳細に関しては、
DescriptionWidth
という
name は、ディレクトリに対応する もし可能なら、
MIME-encoding は、要求されたエンコードに該当する
ワイルドカード表現です。 MIME-type は、要求されたタイプに該当する
ワイルドカード表現です。 HeaderName も filename は
メジャーコンテントタイプが " もし 番号が 0 から始まる場合は、端数と考えられます Apache 1.3.3 では、
と同一になります。 '+' や '-' 接頭辞の付いたキーワードに出会うとそれは、
その時点での 中身の効果は
無条件に このディレクティブと より詳細にまでこの挙動について記述している Apache HTTP Server Version 2.0 Content is stored in and retrieved from the cache using URI based keys. Content with
access protection is not cached. The The The In the event that the URL space overlaps between different
Ordinarily, if a request is cancelled while the response is being
cached and delivered to the client the processing of the response will
stop and the cache entry will be removed. The
The threshold is a percentage specified as a value between
Ordinarily, documents with no-cache or no-store header values will not be stored in the cache.
The According to RFC 2616, hop-by-hop HTTP headers are not stored in
the cache. The following HTTP headers are hop-by-hop headers and thus
do not get stored in the cache in any case regardless of the
setting of Ordinarily, documents without a last-modified date are not cached.
Under some circumstances the last-modified date is removed (during
In the event that a document does not provide an expiry date but does
provide a last-modified date, an expiry date can be calculated based on
the time since the document was last modified. The
The Apache HTTP Server Version 2.0 Emulate the CERN HTTPD Meta file semantics. Meta files are HTTP
headers that can be output in addition to the normal range of
headers for each file accessed. They appear rather like the
Apache .asis files, and are able to provide a crude way of
influencing the Expires: header, as well as providing other
curiosities. There are many ways to manage meta information,
this one was chosen because there is already a large number of
CERN users who can exploit this module. More information on the CERN metafile semantics is available. Specifies the name of the directory in which Apache can find
meta information files. The directory is usually a 'hidden'
subdirectory of the directory that contains the file being
accessed. Set to " Or, to set it to a subdirectory of the directory containing the
files: Turns on/off Meta file processing on a per-directory basis. Specifies the file name suffix for the file containing the
meta information. For example, the default values for the two
directives will cause a request to
Apache HTTP サーバ バージョン 2.0 Mime タイプが サーバが CGI スクリプトを実行するときには、
Apache で CGI スクリプトを使用するためのイントロダクションは、
CGI による動的コンテンツ
を参照してください。 Unix でマルチスレッドの MPM を使っている場合は、このモジュールの
代わりに サーバは CGI
規格 で決められている CGI
環境変数を設定します。以下のものは、条件付きで設定されます。 CGI スクリプトのデバッグは、正しく動作していないスクリプトの出力
(標準出力とエラー)
を調べることができないために、難しい状態が続いていました。
これらの Apache 1.2 以降にある
ディレクティブはより詳細なエラーのログ収集を提供します。 設定されているときには、CGI エラーログは適切に動作しないすべての
CGI をログ収集します。それぞれの正しく動作しない CGI
スクリプトは 複数の行にわたる情報がログ収集されます。最初の
2 行は常に以下の書式です: エラーが、CGI スクリプトが実行できないというものである場合は、
ログファイルはさらにもう 2 行書かれます: そうではなく、エラーが正しくないヘッダ情報を返す結果である場合
(スクリプトのバグであることがよくあります)、
以下の情報がログ収集されます: (スクリプトが標準出力や標準エラーに何も出力しなかった場合は、
%stdout や %stderr はありません)。 このログは子プロセスが実行されているユーザとしてオープンされます。
すなわち、 スクリプトのログ収集は CGI スクリプトを書くときの
デバッグ用の機能として意図されていて、通常のサーバで
常に使用されるようには意図されていないということに注意してください。
速度や効率は最適化されておらず、設計された以外の方法で使用されると
セキュリティの問題があるかもしれません。 大きな本体を受け取ったときにログファイルがすぐに大きくなりすぎる
問題を避けるために、ファイルにログ収集される PUT と POST
の本体の大きさは制限されています。デフォルトでは、1024
バイトまでがログ収集されますが、
このディレクティブはそれを変更することができます。
Apache HTTP サーバ バージョン 2.0 最適化が施されていることと、以下で説明されている追加の Unix オペレーティングシステムの中には、マルチスレッドのサーバから
プロセスを fork するのが非常にコストの高い動作になっているものがあります。
理由は、新しいプロセスが親プロセスのスレッドすべてを複製するからです。
各 CGI 起動時にこのコストがかかるのを防ぐために、 コンパイル時にマルチスレッド MPM が選ばれたときは
このディレクティブは CGI デーモンとの通信に使われるソケットの
名前を設定します。ソケットは Apache が起動されたユーザ (通常 root) の
パーミッションを用いてオープンされます。CGI スクリプトとの通信の
セキュリティを保つために、ソケットの存在するディレクトリに
他のユーザが書き込み権限を持っていないようにすることが重要です。 Apache HTTP Server Version 2.0 This is an experimental module and should
be used with care. Experiment with your
This module provides a small subset of configuration
mechanisms implemented by Russian Apache and its associated
The character set name parameters of If the translation rules don't make sense for the content,
translation can fail in various ways, including: The The value of the charset argument must be accepted
as a valid character set name by the character set support in
APR. Generally, this means that it must be supported by
iconv. The The The value of the charset argument must be accepted
as a valid character set name by the character set support in
APR. Generally, this means that it must be supported by
iconv. The character set names in this example work with the iconv
translation support in Solaris 8. Apache HTTP サーバ バージョン 2.0 このモジュールはクラス 1 とクラス 2 の
WebDAV
('ウェブベースの分散オーサリングとバージョン管理')
機能を Apache に提供します。
この HTTP プロトコルの拡張により、リモートのウェブサーバ上にある
リソースやコレクションを
作成、移動、複製、削除できるようになります。 mod_dav を有効にするには、 これは DAV ファイルシステムプロバイダを有効にします。DAV
ファイルシステムプロバイダは さらに、DAV ロックデータベースの場所が
ロックデータベースファイルのあるディレクトリは Apache が実行されている
DAV のアクセスメソッドは遠隔クライアントがサーバのファイルを
操作することを可能にしますので、 サーバ上の DAV が使用可能になっている場所はすべて認証で保護してください。
HTTP 基本認証の使用は推奨できません。少なくとも
よくある要求に、 この設定により、 与えられたコンテナで WebDAV HTTP メソッドが使えるようにするには
次のようにします。 'Depth: Infinity' を含んでいる
クライアントが DAV リソースロックを要求した場合、
ロックがサーバによって自動的に解除されるまでの時間を
同時に指定することができます。この値は単なるリクエストであって、
サーバはこれを無視することもできますし、
任意の値をクライアントに通知することもできます。 クライアントに戻すロックタイムアウトの最小時間を、
秒で、指定するために Apache HTTP サーバ バージョン 2.0 このモジュールは ロックデータベースへのフルパスを、拡張子を除いた形で
指定するには、 Apache HTTP サーバ バージョン 2.0 下にせっかちな人向けの簡単な設定例を示します。 以下の設定はコンテンツをより圧縮しますが、ずっと複雑な設定になります。
設定の隅々までよく理解しないで使わないでください。 圧縮機能は よく使われているブラウザでは、すべてのコンテンツに対する
圧縮を扱えるわけではありません。ですから、 通常、特定のMIMEタイプについてのみ圧縮したいのであれば、
全てのファイルタイプでの圧縮に問題を抱えているブラウザに対しては、
まず始めに 3 番目の この設定であれば、 リクエスト本体それ自体を評価する場合は、 もし特別に何かに依存して除外したい場合、例えば リクエストヘッダ以外の情報 (例えば HTTP バージョン)
に依存して圧縮するかどうか決める場合、
値は 1 (低圧縮) から 9 (高圧縮) です。 ログからもっと精密な値を抽出したい場合は、type
引数を使用して、データタイプをログのメモとして残すように指定できます。
type は次のうちの一つです。 まとめると、次のようにログを取ることになるでしょう。 Apache HTTP サーバ バージョン 2.0 ディレクトリインデックスは、次の二つのうちどちらかが利用されます: 自動的なインデックス生成機能を削除 (もしくは交換)
できるように、この二つの機能は分離されています。 なお
クライアントが、ディレクトリ名の最後に「/」
を指定してディレクトリインデックスを要求する場合に探すリソースのリストを
注: ドキュメントが同じディレクトリ内に存在するは必要ありません。
とした場合、 要求のあった URL がディレクトリを指すかどうかを、
典型的には、ユーザが末尾のスラッシュ無しでリソースへのリクエストを発行し、
そして、そのリソースがディレクトリを指していた場合、 とはいえ、もしこういった効果を望まない、かつ、
上記のような理由が当てはまらない場合は、リダイレクトを次のようにしてオフにできます: 末尾のスラッシュでのリダイレクトをオフにすると、結果的に情報漏洩を
招くことになるかもしれません。
Apache HTTP Server Version 2.0 Content is stored in and retrieved from the cache using URI based
keys. Content with access protection is not cached. The The result of The The result of More detail will be added here, when the function is implemented. More detail will be added here, when the function is implemented. More detail will be added here, when the function is implemented. The More detail will be added here, when the function is implemented. More detail will be added here, when the function is implemented. More detail will be added here, when the function is implemented. The The The The More detail will be added here, when the function is implemented. Apache HTTP Server Version 2.0 The data logging is done right after SSL decoding (for
input) and right before SSL encoding (for output). As can
be expected, this can produce extreme volumes of data,
and should only be used when debugging problems. To enable the module, it should be compiled and
loaded in to your running Apache configuration. Logging
can then be enabled or disabled via the below directives. In order for dumping to work Enable dumping of all input. Enable dumping of all output. Apache HTTP サーバ バージョン 2.0 本モジュールはコンセプトを伝えるためのプロトコルモジュールの
実装例となっています。単純なエコーサーバを提供します。
Telnet で接続し、文字列を送信すると、エコーを返します。 Apache HTTP サーバ バージョン 2.0 このモジュールにより CGI スクリプトと SSI
ページに適用される環境変数を制御することができるようになります。
環境変数は httpd プロセスを起動したシェルから渡されます。また、
設定ファイルで環境変数を設定したり、削除したりすることができます。
httpd プロセスを起動したシェルの環境から CGI スクリプトと
SSI ページに渡す環境変数を一つ以上指定します。 環境変数を設定し、それを CGI スクリプトと SSI
ページに渡すようにします。 Apache HTTP Server Version 2.0 The files in the The main file is The example module is an actual working module. If you link
it into your server, enable the "example-handler" handler for a
location, and then browse to that location, you will see a
display of some of the tracing the example module did as the
various callbacks were made. To include the example module in your server, follow the
steps below: To add another module of your own: To activate the example module, include a block similar to
the following in your As an alternative, you can put the following into a After reloading/restarting your server, you should be able
to browse to this location and see the brief display mentioned
earlier. The Apache HTTP サーバ バージョン 2.0 このモジュールはサーバ応答の これらのヘッダはクライアントに文書の
有効性と継続性を指示します。文書がキャッシュされた場合には、
指定時刻に達するまでは、元の場所から取得する代わりに
キャッシュされているものを使うことができます。その後は、
キャッシュにあるコピーは期限切れ (expired) で無効であるとされ、
元の場所から新しいものを取得する必要があります。 <base> は以下のどれかです: 例えば、以下のディレクティブはどれもデフォルトで文書がアクセスの 1 ヶ月後に
期限が切れるようにするために使えます: 期限切れ時刻はいくつか
'<num> <type>' 節を追加することでより細かく
制御することができます: 修正時刻に基づいた設定を使用している場合、Expires ヘッダは
ディスクのファイル以外のコンテンツには追加されないことに注意
してください。そのようなコンテンツには修正時刻は存在しないからです。 このディレクティブは対応するドキュメントの領域で
このディレクティブは このディレクティブは指定されたタイプのドキュメント
(例えば 基準時刻はファイルの最終修正時刻か、クライアントのドキュメントへの
アクセス時刻です。どちらを使うべきかは 効果には微妙な違いがあります。 このディレクティブは この文書の前の方で説明されている代替構文を
使って期限切れ期日の計算方法を指定することもできます。 このディレクティブは対応する範囲のすべてのドキュメントに対して
デフォルトの期限切れ期日の計算アルゴリズムを設定します。 Apache HTTP Server Version 2.0 Even when the performance characteristics are not suitable
for production use, Note: this gzip example is just for the purposes of illustration.
Please refer to The filtername specifies the name of the filter being
defined. This name can then be used in SetOutputFilter
directives. It must be unique among all registered filters.
At the present time, no error is reported by the
register-filter API, so a problem with duplicate names isn't
reported to the user. Subsequent parameters can appear in any order and define the
external command to run and certain other characteristics. The
only required parameter is The Note: The core directive Messages written to the filter's standard error will be stored
in the Apache error log. No debug messages will be generated by
Apache HTTP Server Version 2.0 Caching frequently requested files that change very
infrequently is a technique for reducing server load.
Notice: You cannot use this for speeding up CGI programs or
other files which are served by special content handlers. It
can only be used for regular files which are usually served by
the Apache core content handler. This module is an extension of and borrows heavily from the
Not all platforms support both directives. For example, Apache
on Windows does not currently support the The This The This file handle caching is done once at server start or
restart, only. So whenever one of the cached files changes on
the filesystem you have to restart the server (see the
Stopping and Restarting
documentation). To reiterate that point: if the files are
modified in place without restarting the server you
may end up serving requests that are completely bogus. You
should update files by unlinking the old copy and putting a new
copy in place. Most tools such as Don't bother asking for a directive which recursively
caches all the files in a directory. Try this instead... See the
The Be careful with the file-path arguments: They have
to literally match the filesystem path Apache's URL-to-filename
translation handlers create. We cannot compare inodes or other
stuff to match paths through symbolic links etc.
because that again would cost extra The Be careful with the file-path arguments: They have
to literally match the filesystem path Apache's URL-to-filename
translation handlers create. We cannot compare inodes or other
stuff to match paths through symbolic links etc.
because that again would cost extra Apache HTTP Server Version 2.0 This module provides directives to control and modify HTTP
request and response headers. Headers can be merged, replaced
or removed. The directives provided by The directives are processed in the following order: Order is important. These two headers have a different
effect if reversed: This way round, the results in this header being added to the response: results in this header being added to the response: If the header This directive can replace, merge or remove HTTP response
headers. The header is modified just after the content handler
and output filters are run, allowing outgoing headers to be
modified. The optional condition can be either The action it performs is determined by the second
argument. This can be one of the following values: This argument is followed by a header name, which
can include the final colon, but it is not required. Case is
ignored for For When the The This directive can replace, merge or remove HTTP request
headers. The header is modified just before the content handler
is run, allowing incoming headers to be modified. The action it
performs is determined by the first argument. This can be one
of the following values: This argument is followed by a header name, which can
include the final colon, but it is not required. Case is
ignored. For When the The Apache HTTP Server Version 2.0 This module processes The following directive will activate files ending with
Note that the following is still supported: However, we are trying to phase out "magic MIME types" so we
are deprecating this method. The imagemap module adds some new features that were not
possible with previously distributed imagemap programs. The lines in the imagemap files can have one of several
formats: The directive is one of There are six directives allowed in the imagemap file. The
directives can come in any order, but are processed in the
order they are found in the imagemap file. Has the effect of The values for each of the directives can any of the following: The URL can be relative or absolute URL. Relative URLs
can contain '..' syntax and will be resolved relative to the
After the value or after the coordinates, the line
optionally may contain text within double quotes. This string
is used as the text for the link if a menu is
generated: If no quoted text is present, the name of the link will be
used as the text: If you want to use double quotes within this text, you have to
write them as The The The Apache HTTP サーバ バージョン 2.0 このモジュールはファイルがクライアントに送られる前に処理するフィルタを
提供します。処理の内容は要素と呼ばれる特別な形式の SGML コメントにより
制御されます。これらの要素は条件分岐や、他のファイルや
プログラムの出力の取り込み、環境変数の設定や表示を行なうことが
できます。 Server Side Includes は 以下のディレクティブは shtml ファイルのあるディレクトリで指定されている
必要があります (通常は 互換性を保つために、 詳しい情報は Tutorial on Server Side Includes. SSI で処理されるファイルはデフォルトでは ドキュメントは、SGML のコメントとして特別なコマンドが埋め込まれた
HTML ドキュメントとしてパースされます。コマンドの構文は次のように
なっています: 値 (訳注: value) は二重引用符で囲むのが一般的ですが、
シングルクオート (') とバッククオート (`) も使用できます。
多くのコマンドは属性-値 (訳注: attribute-value) の組を一つだけ指定できます。
コメントの終わり ( 要素 (訳注: element) を以下の表に示します。 SSI 要素は 次のコマンドは解析の様々な側面を制御します。属性は次の通りです。 このコマンドは以下で定義されている include
変数 を表示します。変数が設定されていない場合は 変数を出力する前に、変数中の特別文字をどのようにエンコードするかを
指定します。 値は (%-エンコードされた) URL を指定します。パスが
スラッシュ (/) で始まらないときは、ドキュメントからの
相対パスとして扱われます。このパスで参照されているドキュメントは
サーバが CGI スクリプトとして扱っていなくても CGI スクリプトとして
起動されます。ただし、スクリプトのあるディレクトリでは
( CGI スクリプトには、クライアントからの元々のリクエストの
スクリプトが、出力の代わりに サーバは指定された文字列を ほとんどの場合、 さらに、Win32 のようないくつかのプラットフォームや、suexec を使っている unix では、
このコマンドは指定されたファイルの大きさを このコマンドは指定されたファイルの最終修正時刻を
このコマンドは別の文書やファイルのテキストを解析しているファイルに
挿入します。挿入されるファイルはアクセス制御の管理下にあります。
解析しているファイルの存在するディレクトリに
Option 属性が文書の位置を指定します。include コマンドに与えられたそれぞれの
属性に対して挿入作業が行なわれます。有効な属性は次の通りです。 値は解析されているドキュメントからの (% エンコードされた) URL
です。URL にはスキームやホスト名を含めることはできません。パスと、
もしあればクエリー文字列を指定できるだけです。スラッシュ (/) から
始まらない場合は、ドキュメントからの相対パスとして扱われます。 URL は属性から作られ、その URL をクライアントがアクセスしたときに
出力される内容が解析後の出力に含められます。ですから、挿入される
ファイルは入れ子構造にすることができます。 指定された URL が CGI プログラムであった場合は、
プログラムが実行され、その出力が解析しているファイル中の
ディレクティブがあった位置に挿入されます。CGI の url に
クエリー URL を入れることもできます。 HTML ドキュメントに CGI プログラムの出力を含める方法としては、
これは、存在するすべての変数とその値を表示します。Apache 1.3.12 から、
特別な文字は出力される前にエンティティエンコード (詳細は これは変数の値を設定します。属性は次の通りです。 標準 CGI 環境の変数に加えて、 変数置換はたいていの場合 SSI ディレクティブの引数として妥当な場所にある
引用符で囲まれた文字列中で行なわれます。これに該当するものには、
変数名としてみなされる文字列の中で変数への参照を置換する必要があるときは、
シェルでの変数置換のように、中括弧で括ることで区別することができます: この例では、 以下の例では、 基本的なフローコントロール要素は次の通りです。 test_condition は以下のどれかです: string1 と string2 を比較します。
string2 が 正のマッチング ( "=" と "!=" の方が "&&" より
きつく束縛します。"!" の束縛が一番きつくなっています。
ですから以下の二つは等価です: 真偽値オペレータ 変数やオペレータとして認識されないものはすべて文字列として
扱われます。文字列は引用符で囲むこともできます: このディレクティブは このディレクティブは このディレクティブは 二つのサーバで (もしかすると別々の段階で) ファイルの出力を解析していて、
それぞれに違うコマンドを処理させたい、
というようなときにこのオプションを使います。 上の例のように対応する
このディレクティブは このディレクティブは 上のディレクティブでは、日付は "22:26, June 14, 2002" という
形式で表示されます。 このディレクティブは変数が定義されていないにも関わらず
"echo" されたときに Apache HTTP サーバ バージョン 2.0 サーバ設定の情報へのアクセスを制限するために、
一旦設定すると、 このモジュールは実行時に設定ファイルを読み込みます。
サーバの設定ファイルが最後にサーバに読み込まれた後に変更されている
場合には、表示されている内容は実行されているサーバの設定を反映して
いないかもしれないことに注意してください。
また、設定ファイルはサーバが実行されているユーザの権限で
読み込み許可が与えられている必要があります
( 特に、このモジュールはシステムパス、ユーザ名/パスワード、
データベース名など、他の Apache モジュールの設定ディレクティブから
セキュリティ上微妙な情報を漏らす可能性があります。
このモジュールの動作方法のせいで、情報の流出を防ぐ方法はありません。
ですから、このモジュールはちゃんとアクセスが制御された環境で、
注意して使ってください。 これは、string の内容がモジュール module-name
の追加情報 として HTML
として解釈され、表示されるようにします。例: Apache HTTP Server Version 2.0 This module implements the Internet Server extension API. It
allows Internet Server extensions (e.g. ISAPI .dll
modules) to be served by Apache for Windows, subject to the
noted restrictions. ISAPI extension modules (.dll files) are written by third
parties. The Apache Group does not author these modules, so we
provide no support for them. Please contact the ISAPI's author
directly if you are experiencing problems running their ISAPI
extension. Please do not post such problems to
Apache's lists or bug reporting pages. In the server configuration file, use
the There is no capability within the Apache server to leave a
requested module loaded. However, you may preload and keep a
specific module loaded by using the following syntax in your
httpd.conf: Whether or not you have preloaded an ISAPI extension, all
ISAPI extensions are governed by the same permissions and
restrictions as CGI scripts. That is, Review the Additional Notes and the Programmer's Journal for additional details
and clarification of the specific ISAPI support offered by
Apache's ISAPI implementation conforms to all of the ISAPI
2.0 specification, except for some "Microsoft-specific"
extensions dealing with asynchronous I/O. Apache's I/O model
does not allow asynchronous reading and writing in a manner
that the ISAPI could access. If an ISA tries to access
unsupported features, including async I/O, a message is placed
in the error log to help with debugging. Since these messages
can become a flood, the directive Some servers, like Microsoft IIS, load the ISAPI extension
into the server and keep it loaded until memory usage is too
high, or unless configuration options are specified. Apache
currently loads and unloads the ISAPI extension each time it is
requested, unless the Also, remember that while Apache supports ISAPI Extensions,
it does not support ISAPI Filters. Support for
filters may be added at a later date, but no support is planned
at this time. If you are programming Apache 2.0 In their recent documentation, Microsoft appears to have
abandoned the distinction between the two
The first option, the Apache returns Apache 2.0 Record Record Specifies a space-separated list of file names to be loaded
when the Apache server is launched, and remain loaded until the
server is shut down. This directive may be repeated for every
ISAPI .dll file desired. The full path name of each file should
be specified. If the path name is not absolute, it will be treated
relative to While set to on, asynchronous support for ISAPI callbacks is
simulated. Logs all requests for unsupported features from ISAPI
extensions in the server error log. This may help administrators
to track down problems. Once set to on and all desired ISAPI modules
are functioning, it should be set back to off. Defines the maximum size of the Read Ahead Buffer sent to
ISAPI extensions when they are initially invoked. All remaining
data must be retrieved using the Apache HTTP Server Version 2.0 This module was created to improve the performance of
websites relying on backend connections to LDAP servers. In
addition to the functions provided by the standard LDAP
libraries, this module adds an LDAP connection pool and an LDAP
shared memory cache. To enable this module, LDAP support must be compiled into
apr-util. This is achieved by adding the SSL support requires that The following is an example configuration that uses
LDAP connections are pooled from request to request. This
allows the LDAP server to remain connected and bound ready for
the next request, without the need to unbind/connect/rebind.
The performance advantages are similar to the effect of HTTP
keepalives. On a busy server it is possible that many requests will try
and access the same LDAP server connection simultaneously.
Where an LDAP connection is in use, Apache will create a new
connection alongside the original one. This ensures that the
connection pool does not become a bottleneck. There is no need to manually enable connection pooling in
the Apache configuration. Any module using this module for
access to LDAP services will share the connection pool. For improved performance, The process of doing a search and then a bind is the
most time-consuming aspect of LDAP operation, especially if
the directory is large. The search/bind cache is used to
cache all searches that resulted in successful binds.
Negative results (i.e., unsuccessful searches, or searches
that did not result in a successful bind) are not cached.
The rationale behind this decision is that connections with
invalid credentials are only a tiny percentage of the total
number of connections, so by not caching invalid
credentials, the size of the cache is reduced. The search and bind cache is controlled with the During attribute and distinguished name comparison
functions, The behavior of both of these caches is controlled with
the By fetching the URL The ability to create an SSL connections to an LDAP server
is defined by the directives If Specifies the maximum size of the primary LDAP cache. This
cache contains successful search/binds. Set it to 0 to turn off
search/bind caching. The default size is 1024 cached
searches. Specifies the time (in seconds) that an item in the
search/bind cache remains valid. The default is 600 seconds (10
minutes). Specifies the timeout value (in seconds) in which the module will
attempt to connect to the LDAP server. If a connection is not
successful with the timeout period, either an error will be
returned or the module will attempt to connect to a secondary LDAP
server if one is specified. The default is 10 seconds. This specifies the number of entries Specifies the time (in seconds) that entries in the
operation cache remain valid. The default is 600 seconds. Specifies the directory path and file name of the shared memory
cache file. If not set, anonymous shared memory will be used if the
platform supports it. Specifies the number of bytes to allocate for the shared
memory cache. The default is 100kb. If set to 0, shared memory
caching will not be used. It specifies the directory path and file name of the trusted CA
The following types are supported: Apache HTTP サーバ バージョン 2.0
このモジュールはクライアントのリクエストを柔軟にログ収集する機能を
提供します。ログはカスタマイズ可能な書式で書かれ、ファイルに直接
書いたり、外部プログラムに渡したりすることができます。個々のリクエストを
特徴に応じてログに書いたり書かなかったりできるように、条件による
ログ収集も提供されています。 このモジュールは三つのディレクティブ提供します:
ログファイルを作成するための リクエストの特徴そのものは " (このディレクティブは Apache
1.3 の後期のバージョンでは "..." は何もないか (例えば、
修飾子 "<" と ">" は内部リダイレクトされたリクエストのログに
元のリクエストか最終的なリクエストのどちらを使用するかを
指定するために使います。デフォルトでは、 httpd 2.0 の 1.3.25 より前のバージョンでは、
セキュリティ上の理由により 2.0.46 より印字不可能な文字と
他の特別な文字は、ほとんど よく使われるフォーマット文字列は: ログファイルが保存されているディレクトリがサーバを起動した以外のユーザで
書き込み可能なときにセキュリティの問題が発生する理由の詳細はセキュリティのこつ
を参照してください。 ログが書かれる場所を指定する最初の引数は以下の二つの形式の値を
とることができます: もしプログラムが使用された場合、
httpd が起動されたユーザとして実行されます。これはサーバが
root によって起動された場合は root になります。プログラムが
安全であるように留意してください。 Unix でないプラットフォームでファイルのパスを入力しているときは、
使用しているプラットフォームがバックスラッシュの使用を許可していた
として、通常のスラッシュだけを使うように気をつけてください。
一般的に、設定ファイル中では常に普通のスラッシュのみを使うようにする
方が良いです。 二つめの引数はログファイルに何が書かれるかを指定します。
前にある 例えば、以下の二つのディレクティブ群は全く同じ効果をもたらします: 三つ目の引数は省略可能で、サーバの環境にある変数があるかないかに
応じてリクエストをログ収集するかどうかを制御するために使うことができます。
指定された環境変数がリクエストに対して
設定されていた場合 (' 環境変数は このディレクティブはアクセスログファイルの書式を指定します。 このディレクティブは、ログ書式を直接指定できないことと、
条件付きロギングが無いことを除くと、 Apache HTTP Server Version 2.0 This module provides for forensic logging of client
requests. Logging is done before and after processing a request, so the
forensic log contains two log lines for each request.
The forensic logger is very strict, which means: The Each request is logged two times. The first time is before it's
processed further (that is, after receiving the headers). The second log
entry is written after the request processing at the same time
where normal logging occurs. In order to identify each request, a unique request ID is assigned.
This forensic ID can be cross logged in the normal transfer log using the
The first line logs the forensic ID, the request line and all received
headers, separated by pipe characters ( The plus character at the beginning indicates that this is the first log
line of this request. The second line just contains a minus character and
the ID again: The See the 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. The The argument, which specifies the location to which
the logs will be written, can take one of the following two
types of values: If a program is used, then it will be run as the user who
started When entering a file path on non-Unix platforms, care should be taken
to make sure that only forward slashed are used even though the platform
may allow the use of back slashes. In general it is a good idea to always
use forward slashes throughout the configuration files. Apache HTTP サーバ バージョン 2.0 このモジュールはリクエストごとに受け取ったバイト数と
送信したバイト数のロギングを行なう機能を提供します。
記録される数字はリクエストのヘッダとレスポンスの本体を
反映した、実際にネットワークで受け取ったバイト値です。
入力では SSL/TLS の前に、出力では SSL/TLS の後に数えるので、
数字は暗号による変化も正しく反映したものになります。 このモジュールの使用には このモジュールは新しいロギング用ディレクティブを加えます。
リクエスト自身の特徴はフォーマット文字列に、以下の様に置換される
" 通常、この機能は以下の様に使用されます: Apache HTTP サーバ バージョン 2.0 このモジュールは コンテンツのキャッシュへの保存と取得は URI に基づいたキーが使われます。
アクセス保護のかけられているコンテンツはキャッシュされません。 Apache HTTP サーバ バージョン 2.0 このモジュールは拡張子を使っていろいろな「メタ情報」をファイルに
関連付けるために使用されます。この情報はドキュメントのファイル名と
MIME タイプ、言語、文字セット、エンコーディングとを関連付けます。
この情報はブラウザに送られますし、複数のファイルの中からユーザの好みの
ものが選ばれるように、コンテントネゴシエーションでも使われます。
コンテントネゴシエーション
に関する詳しい情報は さらに、 ファイルのメタ情報を変えても ファイルは複数の拡張子を持つことができ、拡張子の順番は通常は関係ありません。例えば、ファイル リソースに複数の言語やエンコーディングを関連付けること
ができるため、
言語とコンテントエンコーディングは前のものに追加されていきます。
たとえば、ファイル 複数の拡張子のあるファイルが MIME
タイプとハンドラの両方に関連付けられているときは注意する必要があります。
その場合、普通はリクエストがハンドラに関連付けられた
モジュールによって扱われることになります。たとえば、拡張子
特定の MIME タイプのファイルはインターネットでの転送を簡単にするために、
さらに符号化することができます。これは通常は HTTP/1.1 RFC
14.11 節では次のように記述されています。 Content-Encoding エンティティヘッダフィールドはメディアタイプの
修飾子として使われます。それが存在していれば、値はエンティティボディに
どの追加の符号化が適用されたかを示し、Content-Type ヘッダフィールドに
書かれているメディアタイプを得るためにどの復号機構を適用すべきか、も
示していることになります。Content-Encoding は主に、元のメディアタイプの
同一性を失うことなくドキュメントを圧縮することを可能にするために
使用されます。 複数のファイル拡張子 (複数の拡張子については 上の節 を参照) 使うことで、
ファイルのタイプやエンコーディングを指定することが
できます。 たとえば、Microsoft Word のドキュメントがあり、サイズを小さくするために
pkzip されているとします。 クライアントのブラウザにエンコーディング方法を知らせるために、
Apache はリソースと共に ファイルタイプとファイルエンコーディングの他に重要な情報は
ドキュメントの書かれている言語と、どの文字セットでファイルが表示
されるべきか、というものです。たとえば、ドキュメントはベトナムの
アルファベットやキリル文字で書かれていて、そのように表示される
必要があるかもしれません。この情報もまた、HTTP ヘッダで
送信されます。 文字セット、言語、エンコーディング、mime タイプはすべて
コンテントネゴシエーション ( さらに情報を伝えるために、Apache は文書の言語を
言語の指定は二文字の短縮形で行なわれます。 この場合、ドキュメント 引数 extensionは大文字小文字を区別せず、
最初のドットはあってもなくても構いません。 これは、拡張子 古いクライアントは 引数 extension は大文字小文字を区別せず、
最初のドットはあってもなくても構いません。 拡張子 extension が名前にあるファイルは指定された handler-name に扱われます。
この新しいマッピングは既にある他のマッピングに追加され、
同じ拡張子 extension
のためのマッピングを上書きします。たとえば、拡張子
" これを httpd.conf ファイルに記述することで、拡張子
" 引数 extension は大文字小文字を区別せず、
最初のドットはあってもなくても構いません。 複数のフィルタを指定するときは、データを処理する順番にセミコロンで
繋いで書く必要があります。フィルタと extension との
両方の引数は大文字小文字を区別せず、拡張子の最初のドットは
あってもなくても構いません。 この場合、 複数の言語が同じ拡張子に割り当てられているときは、
最後のものが使用されます。すなわち、次のような場合、 拡張子 引数 extension は大文字小文字を区別せず、
最初のドットはあってもなくても構いません。 例えば、以下の設定はすべての 複数のフィルタを指定するときは、データを処理する順番にセミコロンで
繋いで書く必要があります。filter と extension の
両引数は大文字小文字を区別せず、拡張子の最初のドットは
あってもなくても構いません。 引数 extension は大文字小文字を区別せず、
最初のドットはあってもなくても構いません。 このディレクティブは、バーチャルファイルシステムを使用している際に
推奨されるディレクティブです。 ハンドラとフィルタの両方もしくは片方と関連付けられた拡張子を含めるには、
最後に、 例えば次の設定では、ハンドラやフィルタが Multiviews に参加することが
できますし、未知のファイルは除外することができます。 extension は大文字小文字を区別しません。
また、最初のドットはあってもなくても構いません。 これは、 extension は大文字小文字を区別しません。
また、最初のドットはあってもなくても構いません。 これは、 extension は大文字小文字を区別しません。
また、最初のドットはあってもなくても構いません。 extension 引数は大文字小文字を区別しません。また、
最初のドットはあってもなくても構いません。 extension 引数は大文字小文字を区別しません。また、
最初のドットはついてもつかなくても構いません。 extension は大文字小文字を区別しません。
また、最初のドットはあってもなくても構いません。 これは extension は大文字小文字を区別しません。
また、最初のドットはあってもなくても構いません。 ファイルは、 拡張子の大文字小文字は区別されません。空行やハッシュ (`#')
で始まる行は無視されます。 Apache HTTP Server Version 2.0 This module determines the MIME type of files in the same
way the Unix This module is derived from a free version of the
The contents of the file are plain ASCII text in 4-5
columns. Blank lines are allowed but ignored. Commented lines
use a hash mark ( type of data to match For example, the following magic file lines would recognize
some audio formats: Or these would recognize the difference between An optional MIME encoding can be included as a fifth column.
For example, this can recognize gzipped files and set the
encoding for them. This module is not for every system. If your system is barely
keeping up with its load or if you're performing a web server
benchmark, you may not want to enable this because the
processing is not free. However, an effort was made to improve the performance of
the original The following notes apply to the mod_mime_magic: MIME type lookup via file magic numbers This software was submitted by Cisco Systems to the Apache Group
in July 1997. Future revisions and derivatives of this source code
must acknowledge Cisco Systems as the original contributor of this
module. All other licensing and usage conditions are those of the
Apache Group. Some of this code is derived from the free version of the file
command originally posted to comp.sources.unix. Copyright info for
that program is included below as required. - Copyright (c) Ian F. Darwin, 1987. Written by Ian F. Darwin. This software is not subject to any license of the American
Telephone and Telegraph Company or of the Regents of the University
of California. Permission is granted to anyone to use this software for any
purpose on any computer system, and to alter it and redistribute it
freely, subject to the following restrictions: For compliance with Mr Darwin's terms: this has been very
significantly modified from the free "file" command. The Apache HTTP サーバ バージョン 2.0 コンテントネゴシエーション、より正確にはコンテンツの選択機能は、
複数用意されているドキュメントから、クライアントの能力に一番合った
ドキュメントを選択する機能です。この実装は二つあります。 タイプマップは RFC 822 のメールヘッダに類似した書式です。
ドキュメントの記述が空行で分離されて書かれていて、ハッシュ文字
('#') で始まる行はコメントとして扱われます。
ドキュメントの説明は複数のヘッダレコードから構成されます。
レコードは、続きの行が空白で始まっていると複数の行にまたがります。
最初の空白が消去されて、前の行とつなげて 1 行として扱われます。
ヘッダレコードはキーワード名の後に値が続くという形式で、
キーワード名は常にコロンで終わります。空白はヘッダ名と値の間、
値のトークンの間に入れることができます。
使用可能なヘッダは以下のとおりです: MultiViews 探索は、 ファイルを選択する際に、関連するコンテントネゴシエーションの
メタ情報を持たないファイルについて、判定を行うかどうかを
このディレクティブが設定されていると、コンテントネゴシエーション
をした結果のドキュメントのキャッシュを許可します。
これは、プロキシの後ろにいるクライアントが能力に一番合った
ドキュメントではなく、
キャッシュをより効果的にするものを得る可能性があるということです。 このディレクティブは HTTP/1.0 ブラウザからのリクエスト
のみに適用されます。HTTP/1.1 は、
交渉されたドキュメントのキャッシュに対してずっとよい制御が可能なので、
このディレクティブは HTTP/1.1 のリクエストには影響しません。 2.0 より前のバージョンでは、
このディレクティブは他の方法で「最善」
の言語が決定できないときか、 Apache HTTP Server Version 2.0 This module enables SSL encryption for a specified port. It
takes advantage of the SSL encryption functionality that is
built into the NetWare operating system. Specifies a list of client certificate files (DER format)
that are used when creating a proxied SSL connection. Each
client certificate used by a server must be listed separately
in its own Allow a connection that was created on the specified address
and/or port to be upgraded to an SSL connection upon request from
the client. The address and/or port must have already be defined
previously with a Specifies the port and the eDirectory based certificate name
that will be used to enable SSL encryption. An optional third
parameter also enables mutual authentication. Apache HTTP Server Version 2.0 Do not enable proxying with This module implements a proxy/gateway for Apache. It implements
proxying capability for Apache's proxy features are divided into several modules in
addition to In addition, extended features are provided by other modules.
Caching is provided by Apache can be configured in both a forward and
reverse proxy mode. An ordinary forward proxy is an intermediate
server that sits between the client and the origin
server. In order to get content from the origin server,
the client sends a request to the proxy naming the origin server
as the target and the proxy then requests the content from the
origin server and returns it to the client. The client must be
specially configured to use the forward proxy to access other
sites. A typical usage of a forward proxy is to provide Internet
access to internal clients that are otherwise restricted by a
firewall. The forward proxy can also use caching (as provided
by The forward proxy is activated using the A reverse proxy, by contrast, appears to the
client just like an ordinary web server. No special
configuration on the client is necessary. The client makes
ordinary requests for content in the name-space of the reverse
proxy. The reverse proxy then decides where to send those
requests, and returns the content as if it was itself the
origin. A typical usage of a reverse proxy is to provide Internet
users access to a server that is behind a firewall. Reverse
proxies can also be used to balance load among several back-end
servers, or to provide caching for a slower back-end server.
In addition, reverse proxies can be used simply to bring
several servers into the same URL space. A reverse proxy is activated using the The examples below are only a very basic idea to help you
get started. Please read the documentation on the individual
directives. In addition, if you wish to have caching enabled, consult
the documentation from You can control who can access your proxy via the For more information on access control directives, see
Strictly limiting access is essential if you are using a
forward proxy (using the You probably don't have that particular file type defined as
In the rare situation where you must download a specific file using the
FTP An FTP URI is interpreted relative to the home directory of the user
who is logging in. Alas, to reach higher directory levels you cannot
use /../, as the dots are interpreted by the browser and not actually
sent to the FTP server. To address this problem, the so called Squid
%2f hack was implemented in the Apache FTP proxy; it is a
solution which is also used by other popular proxy servers like the Squid Proxy Cache. By
prepending To log in to an FTP server by username and password, Apache uses
different strategies. In absense of a user name and password in the URL
altogether, Apache sends an anonymous login to the FTP server,
i.e., This works for all popular FTP servers which are configured for
anonymous access. For a personal login with a specific username, you can embed the user
name into the URL, like in: If the FTP server asks for a password when given this username (which
it should), then Apache will reply with a in the first place). The password which is transmitted in such a way is not encrypted on
its way. It travels between your browser and the Apache proxy server in
a base64-encoded cleartext string, and between the Apache proxy and the
FTP server as plaintext. You should therefore think twice before
accessing your FTP server via HTTP (or before accessing your personal
files via FTP at all!) When using unsecure channels, an eavesdropper
might intercept your password on its way. If you're using the An Apache proxy server situated in an intranet needs to forward
external requests through the company's firewall (for this, configure
the Users within an intranet tend to omit the local domain name from their
WWW requests, thus requesting "http://somehost/" instead of
For circumstances where you have a application server which doesn't
implement keepalives or HTTP/1.1 properly, there are 2 environment
variables which when set send a HTTP/1.0 with no keepalive. These are set
via the These are the The By default, only the default https port ( Note that you'll need to have This directive is only useful for Apache proxy servers within
intranets. The The host arguments to the A Domain is a partially qualified DNS domain name, preceded
by a period. It represents a list of hosts which logically belong to the
same DNS domain or zone (i.e., the suffixes of the hostnames are
all ending in Domain). To distinguish Domains from Hostnames (both syntactically and semantically; a DNS domain can
have a DNS A record, too!), Domains are always written with a
leading period. Domain name comparisons are done without regard to the case, and
Domains are always assumed to be anchored in the root of the
DNS tree, therefore two domains A SubNet is a partially qualified internet address in
numeric (dotted quad) form, optionally followed by a slash and the netmask,
specified as the number of significant bits in the SubNet. It is
used to represent a subnet of hosts which can be reached over a common
network interface. In the absence of the explicit net mask it is assumed
that omitted (or zero valued) trailing digits specify the mask. (In this
case, the netmask can only be multiples of 8 bits wide.) Examples: As a degenerate case, a SubNet with 32 valid bits is the
equivalent to an IPAddr, while a SubNet with zero
valid bits (e.g., 0.0.0.0/0) is the same as the constant
_Default_, matching any IP address. A IPAddr represents a fully qualified internet address in
numeric (dotted quad) form. Usually, this address represents a host, but
there need not necessarily be a DNS domain name connected with the
address. An IPAddr does not need to be resolved by the DNS system, so
it can result in more effective apache performance. A Hostname is a fully qualified DNS domain name which can
be resolved to one or more IPAddrs via the
DNS domain name service. It represents a logical host (in contrast to
Domains, see above) and must be resolvable
to at least one IPAddr (or often to a list
of hosts with different IPAddrs). In many situations, it is more effective to specify an IPAddr in place of a Hostname since a
DNS lookup can be avoided. Name resolution in Apache can take a remarkable
deal of time when the connection to the name server uses a slow PPP
link. Hostname comparisons are done without regard to the case,
and Hostnames are always assumed to be anchored in the root
of the DNS tree, therefore two hosts Directives placed in For example, the following will allow only hosts in
The following example will process all files in the The The Note that Note also that blocks connections to all sites. This directive is only useful for Apache proxy servers within
intranets. The This directive is useful for reverse-proxy setups, where you want to
have a common look and feel on the error pages seen by the end user.
This also allows for included files (via mod_include's SSI) to get
the error code and act accordingly (default behavior would display
the error page of the proxied server, turning this on shows the SSI
Error message). The The In almost every case there's no reason to change that value. The The This directive allows remote servers to be mapped into the space of
the local server; the local server does not act as a proxy in the
conventional sense, but appears to be a mirror of the remote
server. path is the name of a local virtual path; url
is a partial URL for the remote server and cannot include a query
string. Suppose the local server has address will cause a local request for
The will proxy all requests to Order is important. you need to put the exclusions before the
general proxypass directive. When used inside a If you require a more flexible reverse-proxy configuration, see the
This directive lets Apache adjust the URL in the Only the HTTP response headers specifically mentioned above
will be rewritten. Apache will not rewrite other response
headers, nor will it rewrite URL references inside HTML pages.
This means that if the proxied content contains absolute URL
references, they will by-pass the proxy. A third-party module
that will look inside the HTML and rewrite URL references is Nick
Kew's mod_proxy_html. path is the name of a local virtual path. url is a
partial URL for the remote server - the same way they are used for the
For example, suppose the local server has address
will not only cause a local request for the
Note that this When used inside a When enabled, this option will pass the Host: line from the incoming
request to the proxied host, instead of the hostname specified in the
proxypass line. This option should normally be turned The This defines remote proxies to this proxy. match is either the
name of a URL-scheme that the remote server supports, or a partial URL
for which the remote server should be used, or scheme is effectively the protocol that should be used to
communicate with the remote server; only In the last example, the proxy will forward FTP requests, encapsulated
as yet another HTTP proxy request, to another proxy which can handle
them. This option also supports reverse proxy configuration - a backend
webserver can be embedded within a virtualhost URL space even if that
server is hidden by another forward proxy. The This allows or prevents Apache from functioning as a forward proxy
server. (Setting ProxyRequests to In a typical reverse proxy configuration, this option should be set to
In order to get the functionality of proxying HTTP or FTP sites, you
need also Do not enable proxying with This directive allows a user to specifiy a timeout on proxy requests.
This is useful when you have a slow/buggy appserver which hangs, and you
would rather just return a timeout and fail gracefully instead of waiting
however long it takes the server to return. This directive controls the use of the Apache HTTP Server Version 2.0 This module requires the service of Thus, in order to get the ability of handling Do not enable proxying until you have secured your server. Open proxy
servers are dangerous both to your network and to the Internet at
large. Apache HTTP Server Version 2.0 This module requires the service of Thus, in order to get the ability of handling FTP proxy requests,
Do not enable proxying until you have secured your server. Open proxy
servers are dangerous both to your network and to the Internet at
large. Apache HTTP Server Version 2.0 This module requires the service of Thus, in order to get the ability of handling HTTP proxy requests,
Do not enable proxying until you have secured your server. Open proxy
servers are dangerous both to your network and to the Internet at
large. Apache HTTP Server Version 2.0 This module uses a rule-based rewriting engine (based on a
regular-expression parser) to rewrite requested URLs on the
fly. It supports an unlimited number of rules and an
unlimited number of attached rule conditions for each rule, to
provide a really flexible and powerful URL manipulation
mechanism. The URL manipulations can depend on various tests,
of server variables, environment variables, HTTP
headers, or time stamps. Even external database lookups in
various formats can be used to achieve highly granular URL
matching. This module operates on the full URLs (including the
path-info part) both in per-server context
( Further details, discussion, and examples, are provided in the
detailed mod_rewrite documentation. Apache processes a HTTP request in several phases.
A hook for each of these
phases is provided by the Apache API. Once a request comes in, and Apache has determined the
appropriate server (or virtual server), the rewrite engine
starts the URL-to-filename translation,
processing the mod_rewrite directives from the
per-server configuration. A few
steps later, when the final data directories are found, the
per-directory configuration directives of mod_rewrite are
triggered in the Fixup phase. When mod_rewrite is triggered during these two API phases, it
reads the relevant rulesets from its configuration
structure (which was either created on startup, for
per-server context, or during the directory traversal
for per-directory context). The URL rewriting
engine is started with the appropriate ruleset (one or more
rules together with their conditions), and its operation
is exactly the same for both
configuration contexts. Only the final result processing is
different. The order of rules in the ruleset is important because the
rewrite engine processes them in a particular (not always
obvious) order, as follows: The rewrite engine loops
through the rulesets (each ruleset being made up of
As above, first the URL is matched against the
Pattern of a rule. If it does not match, If Using parentheses in Pattern or in one of the
CondPatterns causes back-references to be internally
created.
These can later be referenced using the strings
As of Apache 1.3.20, special characters in
TestString and Substitution strings can be
escaped (that is, treated as normal characters without their
usual special meaning) by prefixing them with a slash ('\')
character. In other words, you can include an actual
dollar-sign character in a Substitution string by
using ' This module keeps track of two additional (non-standard)
CGI/SSI environment variables named Notice: These variables hold the URI/URL as they were
initially requested, that is, before any
rewriting. This is important to note because the rewriting process is
primarily used to rewrite logical URLs to physical
pathnames. For numerous examples of common, and not-so-common, uses for
mod_rewrite, see the Rewrite
Guide, and the Advanced Rewrite
Guide documents. The 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. However, for most websites, URLs are NOT
directly related to physical filename paths, so this
assumption will often be wrong! Therefore, you can
use the For example, assume the following per-directory config file: In the above example, a request to
The following list gives detailed information about
the internal processing steps: This seems very complicated, but is in fact
correct Apache internal processing. Because the
per-directory rewriting comes late in the
process, the rewritten request
has to be re-injected into the Apache kernel.
This is not the serious overhead it may seem to be -
this re-injection is completely internal to the
Apache server (and the same procedure is used by
many other operations within Apache). The TestString is a string which can contain the
following expanded constructs in addition to plain text: These variables all
correspond to the similarly named HTTP
MIME-headers, C variables of the Apache server or
Other things you should be aware of: For instance, to rewrite according to the
On the other hand, because mod_rewrite implements
its per-directory context ( CondPattern is the condition pattern,
a regular expression which is applied to the
current instance of the TestString.
TestString is first evaluated, before being matched against
CondPattern. Remember: CondPattern is a
perl compatible regular expression with some
additions: Example: To rewrite the Homepage of a site according to the
`` Explanation: If you use a browser which identifies itself
as 'Mozilla' (including Netscape Navigator, Mozilla etc), then you
get the max homepage (which could include frames, or other special
features).
If you use the Lynx browser (which is terminal-based), then
you get the min homepage (which could be a version designed for
easy, text-only browsing).
If neither of these conditions apply (you use any other browser,
or your browser identifies itself as something non-standard), you get
the std (standard) homepage. The Use this directive to disable the module instead of
commenting out all the Note that, by default, rewrite configurations are not
inherited. This means that you need to have a
This directive sets the filename for a synchronization
lockfile which mod_rewrite needs to communicate with The The To disable the logging of rewriting actions simply set
Level to 0. This disables all rewrite action
logs. The 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 by the empty string
if no DefaultValue was specified. For example, you might define a
You would then be able to use this map in a
The following combinations for MapType and
MapSource can be used: 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
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
`` Example: Here the source is a binary format DBM file containing
the same contents as a Plain Text format file, but
in a special representation which is optimized for really
fast lookups. The type can be sdbm, gdbm, ndbm, or
db depending on compile-time
settings. If the type is ommitted, the
compile-time default will be chosen. You can create such a
file with any DBM tool or with the following Perl
script. Be sure to adjust it to create the appropriate
type of DBM. The example creates an NDBM file. Here, the source is an internal Apache function.
Currently you cannot create your own, but the following
functions already exist: Here the source is a program, not a map file. To
create it you can use a language of your choice, but
the result has to be an executable program (either
object-code or a script with the magic cookie trick
' This program is started once, when the Apache server
is started, and then communicates with the rewriting engine
via its But be very careful: The The The Pattern is
a perl compatible regular
expression, which is applied to the current URL.
``Current'' means the value of the URL when this rule is
applied. This may not be the originally requested URL,
which may already have matched a previous rule, and have
been altered. Some hints on the syntax of regular expressions: For more information about regular expressions, have a look at the
perl regular expression manpage ("perldoc
perlre"). If you are interested in more detailed
information about regular expressions and their variants
(POSIX regex etc.) the following book is dedicated to this topic:
Mastering Regular Expressions, 2nd Edition In mod_rewrite, the NOT character
(' The substitution of a
rewrite rule is the string which is substituted for (or
replaces) the original URL which Pattern
matched. In addition to plain text, it can include Back-references are identifiers of the form
As already mentioned, all rewrite rules are
applied to the Substitution (in the order in which
they are defined
in the config file). The URL is completely
replaced by the Substitution and the
rewriting process continues until all rules have been applied,
or it is explicitly terminated by a
There is a special substitution string named
' Additionally you can set special flags for Substitution by
appending Note: Note: You must use this flag if you want to
mix directives from different modules which allow
URL-to-filename translators. The typical example
is the use of When the substitution string begins with a string
resembling "/~user" (via explicit text or backreferences), mod_rewrite performs
home directory expansion independent of the presence or configuration
of This expansion does not occur when the PT
flag is used on the There is one exception: If a substitution string
starts with `` When you prefix a substitution field with
Remember: An unconditional external
redirect to your own server will not work with the prefix
The Pattern will not be matched against the query string.
Instead, you must use a Here are all possible substitution combinations and their
meanings: Inside per-server configuration
( Inside per-directory configuration for
Apache HTTP サーバ バージョン 2.0 このモジュールが提供するディレクティブは、
設定ファイルに現れる順番に適用されます。
それを使って、次の例のようにより複雑な設定をすることができます。
これは、ブラウザが mozilla ではあるけれど、MSIE ではないときに
その他の例: 二つ目の引数 (regex) は Perl 互換の正規表現です。
これは POSIX.2 の egrep 形式の正規表現と似ています。regex が
attribute にマッチする場合は、残りの引数が評価されます。 残りの引数は設定する変数の名前で、設定される値を指定することもできます。
これは、 のどれかの形式になります。 最初の形式では、値は "1" に設定されます。
二つ目はもし値が定義されていればそれを取り除きます。
三つ目は変数を 初めの三つはリクエストが画像であるときに環境変数
最後の例は、リクエストに "TS" で始まり、値が集合 [a-z] のどれかで
始まるヘッダがあるときに これは HTTP リクエストヘッダにフィールド Apache HTTP サーバ バージョン 2.0 いくつかのオペレーティングシステムでは、サーバの再コンパイルをする代わりに、
このモジュールを使用して
動的共有オブジェクト
(DSO) 機構により、実行時に Apache にモジュールを読み込ませることが
できます。 Unix 上では、読み込まれるコードは通常は共有オブジェクトファイル
(普通 Apache 1.3 のモジュールを直接 Apache 2.0 で使うことはできません
― モジュールは Apache 2.0 用に動的にロードされるか、
直接組み込まれるために修正されなければなりません。 Apache 1.3.15 と 2.0 とで Windows のモジュール名の形式は変更されました
― モジュールは mod_foo.so という名前になりました。 まだ mod_so で ApacheModuleFoo.dll という名前のモジュールも
ロードされますが、新しい名前の付け方を使う方が好まれます。モジュールを
2.0 用に移植しているのであれば、2.0 の習慣に合うように名前を
修正してください。 Apache のモジュール API は UNIX と Windows 間では変更されていません。
多くのモジュールは全く変更なし、もしくは簡単な変更により Windows
で実行できるようになります。ただし、それ以外の Windows には無い Unix
アーキテクチャーの機能に依存したモジュールは動作しません。 モジュールが実際に動作するときは、
二つの方法のどちらかでサーバに追加することができます。まず、Unix
と同様にサーバにコンパイルして組み込むことができます。Windows
用の Apache は Unix 用の Apache にある 二つ目はモジュールを DLL としてコンパイルする方法です。
DLL は共有ライブラリで、実行時に
モジュール DLL を作成するためには、
モジュールの作成に小さな変更を行なう必要があります。
つまり、モジュールのレコード (これは後で作成されます。
以下を参照してください) が DLL からエクスポートされなければなりません。
これを行なうには、 があるとすると、それを次のもので置き換えてください。 Unix 上でもこのモジュールを
変更無しで使い続けられるように、このマクロは Windows
上でのみ効力を持ちます。 さあ、あなたのモジュールの DLL を作成しましょう。これを、
libhttpd.lib 共有ライブラリがコンパイルされたときに作成された
ibhttpd.lib エクスポートライブラリとリンクしてください。この時に、
Apache のヘッダファイルが正しい位置にあるように、
コンパイラの設定を変える必要があるかもしれません。
このライブラリはサーバルートの modules ディレクトリにあります。
ビルド環境が正しく設定されるように、既存のモジュール用の .dsp を
取ってくるのが一番良いでしょう。もしくは、あなたの .dsp と
コンパイラとリンクのオプションを比較する、というものでも良いです。 これで DLL 版のモジュールが作成されているはずです。
サーバルートの LoadFile ディレクティブは、サーバが起動されたときや再起動されたときに、
指定されたオブジェクトファイルやライブラリをリンクします。
これはモジュールが動作するために必要になるかもしれない追加の
コードを読み込むために使用されます。Filename は絶対パスか、ServerRoot からの相対パスです。 例: LoadModule ディレクティブは filename
というオブジェクトファイルおよびライブラリをリンクし、module
という名前のモジュールの構造をアクティブなモジュールのリストに追加します。
Module はファイル中の これは ServerRoot の modules サブディレクトリから指定された名前の
モジュールをロードします。 Apache HTTP サーバ バージョン 2.0 リクエストの綴りが間違っていたり、
大文字小文字が違っていたりするために、Apache のコアサーバが
ドキュメントへのリクエストへの応答を正しく提供できないことがあります。
このモジュールは、他のすべてのモジュールがあきらめた後であったとしても、
リクエストに合うドキュメントを見つけようとすることによりこの問題の
解決を試みます。このモジュールはリクエストされたディレクトリにある
それぞれのドキュメントの名前と、リクエストされたドキュメントの名前とを
大文字小文字の区別を無視し、一文字までの
綴りの間違い (文字の挿入/省略/隣合う文字の置換、間違った文字)
を許可して比較することにより、目的を達成しようとします。
この方法でリクエストに合うドキュメントの一覧が作成されます。 ディレクトリをスキャンした後に、 このディレクティブは綴り用のモジュールを使用するかどうかを
決めます。使用時には、以下のことを覚えておいてください Apache HTTP Server Version 2.0 This module provides SSL v2/v3 and TLS v1 support for the Apache
HTTP Server. It was contributed by Ralf S. Engeschall based on his
mod_ssl project and originally derived from work by Ben Laurie. This module relies on OpenSSL
to provide the cryptography engine. Further details, discussion, and examples are provided in the
SSL documentation. This module provides a lot of SSL information as additional environment
variables to the SSI and CGI namespace. The generated variables are listed in
the table below. For backward compatibility the information can
be made available under different names, too. Look in the Compatibility chapter for details on the
compatibility variables. [ where x509 is a component of a X.509 DN:
When
For backward compatibility there is additionally a special
``
Example:
This directive sets the all-in-one file where you can assemble the
Certificates of Certification Authorities (CA) whose clients you deal
with. These are used for Client Authentication. Such a file is simply the
concatenation of the various PEM-encoded Certificate files, in order of
preference. This can be used alternatively and/or additionally to
This directive sets the directory where you keep the Certificates of
Certification Authorities (CAs) whose clients you deal with. These are used to
verify the client certificate on Client Authentication.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you can't just place the Certificate files
there: you also have to create symbolic links named
hash-value
This directive sets the all-in-one file where you can
assemble the Certificate Revocation Lists (CRL) of Certification
Authorities (CA) whose clients you deal with. These are used
for Client Authentication. Such a file is simply the concatenation of
the various PEM-encoded CRL files, in order of preference. This can be
used alternatively and/or additionally to
This directive sets the directory where you keep the Certificate Revocation
Lists (CRL) of Certification Authorities (CAs) whose clients you deal with.
These are used to revoke the client certificate on Client Authentication.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you have not only to place the CRL files there.
Additionally you have to create symbolic links named
hash-value
This directive sets the optional all-in-one file where you can
assemble the certificates of Certification Authorities (CA) which form the
certificate chain of the server certificate. This starts with the issuing CA
certificate of of the server certificate and can range up to the root CA
certificate. Such a file is simply the concatenation of the various
PEM-encoded CA Certificate files, usually in certificate chain order.
This should be used alternatively and/or additionally to
But be careful: Providing the certificate chain works only if you are using a
single (either RSA or DSA) based server certificate. If you are
using a coupled RSA+DSA certificate pair, this will work only if actually both
certificates use the same certificate chain. Else the browsers will be
confused in this situation.
This directive points to the PEM-encoded Certificate file for the server and
optionally also to the corresponding RSA or DSA Private Key file for it
(contained in the same file). If the contained Private Key is encrypted the
Pass Phrase dialog is forced at startup time. This directive can be used up to
two times (referencing different filenames) when both a RSA and a DSA based
server certificate is used in parallel.
This directive points to the PEM-encoded Private Key file for the
server. If the Private Key is not combined with the Certificate in the
This complex directive uses a colon-separated cipher-spec string
consisting of OpenSSL cipher specifications to configure the Cipher Suite the
client is permitted to negotiate in the SSL handshake phase. Notice that this
directive can be used both in per-server and per-directory context. In
per-server context it applies to the standard SSL handshake when a connection
is established. In per-directory context it forces a SSL renegotation with the
reconfigured Cipher Suite after the HTTP request was read but before the HTTP
response is sent.
An SSL cipher specification in cipher-spec is composed of 4 major
attributes plus a few extra minor ones: An SSL cipher can also be an export cipher and is either a SSLv2 or SSLv3/TLSv1
cipher (here TLSv1 is equivalent to SSLv3). To specify which ciphers to use,
one can either specify all the Ciphers, one at a time, or use aliases to
specify the preference and order for the ciphers (see Table
1).
Now where this becomes interesting is that these can be put together
to specify the order and ciphers you wish to use. To speed this up
there are also aliases ( A simpler way to look at all of this is to use the `` The complete list of particular RSA & DH ciphers for SSL is given in Table 2.
This directive toggles the usage of the SSL/TLS Protocol Engine. This
is usually used inside a
This configures the SSL engine's semaphore (aka. lock) which is used for mutual
exclusion of operations which have to be done in a synchronized way between the
pre-forked Apache server processes. This directive can only be used in the
global server context because it's only useful to have one global mutex.
This directive is designed to closely match the
AcceptMutex directive
The following Mutex types are available:
This is the default where no Mutex is used at all. Use it at your own
risk. But because currently the Mutex is mainly used for synchronizing
write access to the SSL Session Cache you can live without it as long
as you accept a sometimes garbled Session Cache. So it's not recommended
to leave this the default. Instead configure a real Mutex.
This is an elegant Mutex variant where a Posix Semaphore is used when possible.
It is only available when the underlying platform
and APR supports it.
This is a somewhat elegant Mutex variant where a SystemV IPC Semaphore is used when
possible. It is possible to "leak" SysV semaphores if processes crash before
the semaphore is removed. It is only available when the underlying platform
and APR supports it.
This directive tells the SSL Module to pick the "best" semaphore implementation
available to it, choosing between Posix and SystemV IPC, in that order. It is only
available when the underlying platform and APR supports at least one of the 2.
This directive tells the SSL Module to use Posix thread mutexes. It is only available
if the underlying platform and APR supports it.
This is a portable Mutex variant where a physical (lock-)file and the
This is similar to the
This directive tells the SSL Module to pick the "best" file locking implementation
available to it, choosing between
This directive tells the SSL Module to pick the default locking implementation
as determined by the platform and APR.
This directive can be used to control various run-time options on a
per-directory basis. Normally, if multiple
The available options are:
When this option is enabled, the standard set of SSL related CGI/SSI
environment variables are created. This per default is disabled for
performance reasons, because the information extraction step is a
rather expensive operation. So one usually enables this option for
CGI and SSI requests only.
When this option is enabled, additional CGI/SSI environment variables are
created for backward compatibility to other Apache SSL solutions. Look in
the Compatibility chapter for details
on the particular variables generated.
When this option is enabled, additional CGI/SSI environment variables are
created:
When this option is enabled, the Subject Distinguished Name (DN) of the
Client X509 Certificate is translated into a HTTP Basic Authorization
username. This means that the standard Apache authentication methods can
be used for access control. The user name is just the Subject of the
Client's X509 Certificate (can be determined by running OpenSSL's
This forces forbidden access when
This enables optimized SSL connection renegotiation handling when SSL
directives are used in per-directory context. By default a strict
scheme is enabled where every per-directory reconfiguration of
SSL parameters causes a full SSL renegotiation handshake. When this
option is used mod_ssl tries to avoid unnecessary handshakes by doing more
granular (but still safe) parameter checks. Nevertheless these granular
checks sometimes maybe not what the user expects, so enable this on a
per-directory basis only, please.
When Apache starts up it has to read the various Certificate (see
This is the default where an interactive terminal dialog occurs at startup
time just before Apache detaches from the terminal. Here the administrator
has to manually enter the Pass Phrase for each encrypted Private Key file.
Because a lot of SSL-enabled virtual hosts can be configured, the
following reuse-scheme is used to minimize the dialog: When a Private Key
file is encrypted, all known Pass Phrases (at the beginning there are
none, of course) are tried. If one of those known Pass Phrases succeeds no
dialog pops up for this particular Private Key file. If none succeeded,
another Pass Phrase is queried on the terminal and remembered for the next
round (where it perhaps can be reused).
This scheme allows mod_ssl to be maximally flexible (because for N encrypted
Private Key files you can use N different Pass Phrases - but then
you have to enter all of them, of course) while minimizing the terminal
dialog (i.e. when you use a single Pass Phrase for all N Private Key files
this Pass Phrase is queried only once).
Here an external program is configured which is called at startup for each
encrypted Private Key file. It is called with two arguments (the first is
of the form ``
Both these security checks, and the way the Pass Phrase is determined, can
be as complex as you like. Mod_ssl just defines the interface: an
executable program which provides the Pass Phrase on
The reuse-algorithm above is used here, too. In other words: The external
program is called only once per unique Pass Phrase.
Example:
This directive can be used to control the SSL protocol flavors mod_ssl should
use when establishing its server environment. Clients then can only connect
with one of the provided protocols.
The available (case-insensitive) protocols are:
This is the Secure Sockets Layer (SSL) protocol, version 2.0. It is the
original SSL protocol as designed by Netscape Corporation.
This is the Secure Sockets Layer (SSL) protocol, version 3.0. It is the
successor to SSLv2 and the currently (as of February 1999) de-facto
standardized SSL protocol from Netscape Corporation. It's supported by
almost all popular browsers.
This is the Transport Layer Security (TLS) protocol, version 1.0. It is the
successor to SSLv3 and currently (as of February 1999) still under
construction by the Internet Engineering Task Force (IETF). It's still
not supported by any popular browsers.
This is a shortcut for ``
This directive sets the all-in-one file where you can assemble the
Certificates of Certification Authorities (CA) whose remote servers you deal
with. These are used for Remote Server Authentication. Such a file is simply the
concatenation of the various PEM-encoded Certificate files, in order of
preference. This can be used alternatively and/or additionally to
This directive sets the directory where you keep the Certificates of
Certification Authorities (CAs) whose remote servers you deal with. These are used to
verify the remote server certificate on Remote Server Authentication.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you can't just place the Certificate files
there: you also have to create symbolic links named
hash-value
This directive sets the all-in-one file where you can
assemble the Certificate Revocation Lists (CRL) of Certification
Authorities (CA) whose remote servers you deal with. These are used
for Remote Server Authentication. Such a file is simply the concatenation of
the various PEM-encoded CRL files, in order of preference. This can be
used alternatively and/or additionally to
This directive sets the directory where you keep the Certificate Revocation
Lists (CRL) of Certification Authorities (CAs) whose remote servers you deal with.
These are used to revoke the remote server certificate on Remote Server Authentication.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you have not only to place the CRL files there.
Additionally you have to create symbolic links named
hash-value Equivalent to
This directive toggles the usage of the SSL/TLS Protocol Engine for proxy. This
is usually used inside a
This directive sets the all-in-one file where you keep the certificates and
keys used for authentication of the proxy server to remote servers.
This referenced file is simply the concatenation of the various PEM-encoded
certificate files, in order of preference. Use this directive alternatively
or additionally to Currently there is no support for encrypted private keys
Example:
This directive sets the directory where you keep the certificates and
keys used for authentication of the proxy server to remote servers.
The files in this directory must be PEM-encoded and are accessed through
hash filenames. Additionally, you must create symbolic links named
Currently there is no support for encrypted private keys
Example:
This directive can be used to control the SSL protocol flavors mod_ssl should
use when establishing its server environment for proxy . It will only connect
to servers using one of the provided protocols. Please refer to
This directive sets the Certificate verification level for the remote server
Authentication. Notice that this directive can be used both in per-server and
per-directory context. In per-server context it applies to the remote server
authentication process used in the standard SSL handshake when a connection is
established. In per-directory context it forces a SSL renegotation with the
reconfigured remote server verification level after the HTTP request was read but
before the HTTP response is sent.
The following levels are available for level: In practice only levels none and
require are really interesting, because level
optional doesn't work with all servers and level
optional_no_ca is actually against the idea of
authentication (but can be used to establish SSL test pages, etc.)
This directive sets how deeply mod_ssl should verify before deciding that the
remote server does not have a valid certificate. Notice that this directive can be
used both in per-server and per-directory context. In per-server context it
applies to the client authentication process used in the standard SSL
handshake when a connection is established. In per-directory context it forces
a SSL renegotation with the reconfigured remote server verification depth after the
HTTP request was read but before the HTTP response is sent.
The depth actually is the maximum number of intermediate certificate issuers,
i.e. the number of CA certificates which are max allowed to be followed while
verifying the remote server certificate. A depth of 0 means that self-signed
remote server certificates are accepted only, the default depth of 1 means
the remote server certificate can be self-signed or has to be signed by a CA
which is directly known to the server (i.e. the CA's certificate is under
This configures one or more sources for seeding the Pseudo Random Number
Generator (PRNG) in OpenSSL at startup time (context is
The following source variants are available: This is the always available builtin seeding source. It's usage
consumes minimum CPU cycles under runtime and hence can be always used
without drawbacks. The source used for seeding the PRNG contains of the
current time, the current process id and (when applicable) a randomly
choosen 1KB extract of the inter-process scoreboard structure of Apache.
The drawback is that this is not really a strong source and at startup
time (where the scoreboard is still not available) this source just
produces a few bytes of entropy. So you should always, at least for the
startup, use an additional seeding source.
This variant uses an external file
But be careful: Usually
On some platforms like FreeBSD one can even control how the entropy is
actually generated, i.e. by which system interrupts. More details one can
find under rndcontrol(8) on those platforms. Alternatively, when
your system lacks such a random device, you can use tool
like EGD
(Entropy Gathering Daemon) and run it's client program with the
This variant uses an external executable
This variant uses the Unix domain socket of the
external Entropy Gathering Daemon (EGD) (see http://www.lothar.com/tech
/crypto/) to seed the PRNG. Use this if no random device exists
on your platform.
This directive specifies a general access requirement which has to be
fulfilled in order to allow access. It's a very powerful directive because the
requirement specification is an arbitrarily complex boolean expression
containing any number of access checks.
The expression must match the following syntax (given as a BNF
grammar notation): while for
This function takes one string argument and expands to the contents of the
file. This is especially useful for matching this contents against a
regular expression, etc. Notice that expression is first parsed into an internal machine
representation and then evaluated in a second step. Actually, in Global and
Per-Server Class context expression is parsed at startup time and
at runtime only the machine representation is executed. For Per-Directory
context this is different: here expression has to be parsed and
immediately executed for every request. Standard CGI/1.0 and Apache variables: SSL-related variables:
This directive forbids access unless HTTP over SSL (i.e. HTTPS) is enabled for
the current connection. This is very handy inside the SSL-enabled virtual
host or directories for defending against configuration errors that expose
stuff that should be protected. When this directive is present all requests
are denied which are not using SSL.
This configures the storage type of the global/inter-process SSL Session
Cache. This cache is an optional facility which speeds up parallel request
processing. For requests to the same server process (via HTTP keep-alive),
OpenSSL already caches the SSL session information locally. But because modern
clients request inlined images and other data via parallel requests (usually
up to four parallel requests are common) those requests are served by
different pre-forked server processes. Here an inter-process cache
helps to avoid unneccessary session handshakes.
The following two storage types are currently supported:
This is the default and just disables the global/inter-process Session
Cache. There is no drawback in functionality, but a noticeable speed
penalty can be observed.
This makes use of a DBM hashfile on the local disk to synchronize the
local OpenSSL memory caches of the server processes. The slight increase
in I/O on the server results in a visible request speedup for your
clients, so this type of storage is generally recommended.
This makes use of a high-performance hash table (approx. size bytes
in size) inside a shared memory segment in RAM (established via
This directive sets the timeout in seconds for the information stored in the
global/inter-process SSL Session Cache and the OpenSSL internal memory cache.
It can be set as low as 15 for testing, but should be set to higher
values like 300 in real life.
This directive sets the "user" field in the Apache request object.
This is used by lower modules to identify the user with a character
string. In particular, this may cause the environment variable
This directive sets the Certificate verification level for the Client
Authentication. Notice that this directive can be used both in per-server and
per-directory context. In per-server context it applies to the client
authentication process used in the standard SSL handshake when a connection is
established. In per-directory context it forces a SSL renegotation with the
reconfigured client verification level after the HTTP request was read but
before the HTTP response is sent.
The following levels are available for level: In practice only levels none and
require are really interesting, because level
optional doesn't work with all browsers and level
optional_no_ca is actually against the idea of
authentication (but can be used to establish SSL test pages, etc.)
This directive sets how deeply mod_ssl should verify before deciding that the
clients don't have a valid certificate. Notice that this directive can be
used both in per-server and per-directory context. In per-server context it
applies to the client authentication process used in the standard SSL
handshake when a connection is established. In per-directory context it forces
a SSL renegotation with the reconfigured client verification depth after the
HTTP request was read but before the HTTP response is sent.
The depth actually is the maximum number of intermediate certificate issuers,
i.e. the number of CA certificates which are max allowed to be followed while
verifying the client certificate. A depth of 0 means that self-signed client
certificates are accepted only, the default depth of 1 means the client
certificate can be self-signed or has to be signed by a CA which is directly
known to the server (i.e. the CA's certificate is under
Apache HTTP サーバ バージョン 2.0 この Status モジュールによりサーバ管理者はサーバがどのくらい
の性能で動作しているかを知ることができるようになります。
現時点でのサーバの統計情報を読みやすい形式で現した HTML ページが
表示されます。必要であれば、このページは自動的にリフレッシュさせる
こともできます (互換性のあるブラウザを使用している場合)。
別に、現時点でのサーバの状態を単純な機械読み取り可能なリストで
現すページもあります。 表示される情報は: "(*)" の付いている情報を表示するためにはコンパイル時のオプション
を使用する必要があります。これらの統計情報を得るために必要な
コードは標準の Apache には含まれていません。 foo.com ドメインからのブラウザのみに対して
ステータスの報告を使用可能にするには
以下のコードを これで、サーバの統計情報をウェブブラウザを使って
ブラウザが「リフレシュ」機能をサポートしていれば、ステータスページを
自動的に更新するようにできます。N 秒毎に更新させるためには
Apache HTTP サーバ バージョン 2.0 このモジュールと suexec サポートプログラム
により、CGI スクリプトが指定されたユーザとグループで
実行されるようにできます。 Apache HTTP サーバ バージョン 2.0 このモジュールは非常に制限された条件下で、
それぞれのリクエストに「すべて」のリクエストに対して
一意に決まることが保証されている魔法のトークンを提供します。
この一意な識別子は、適切に設定されたクラスタでは複数の
マシンの間でさえも一意になります。それぞれのリクエストに対して環境変数
まずはじめに、Apache サーバが Unix
マシンでどのように動作をするかを簡単に説明します。
この機能は現時点では Windows NT ではサポートされていません。
Unix マシンでは Apache はいくつかの子プロセスを作成し、
その子プロセスが一つずつリクエストを処理します。それぞれの子プロセスは、
生存期間中に複数のリクエストを扱うことができます。
この議論では子プロセス間では一切データを共有しないことにします。
以後、この子プロセスのことを httpd プロセスと呼びます。 あなたのウェブサイトにはあなたが管理するいくつかのマシンがあるとします。
それらをまとめてクラスタと呼ぶことにします。それぞれのマシンは複数の
Apache を実行することもできます。
これらすべてをまとめたものが「宇宙」であると考えられます。
いくつかの仮定の下で、クラスタのマシン間がたくさん通信をすることなく、
この宇宙の中でそれぞれのリクエストに一意な識別子を生成できることを示します。
クラスタにあるマシンは以下の要求を見たさなければなりません。
(マシンが一つだけだとしても、NTP で時計を合わせる方が良いです。) オペレーティングシステムにおいては、pid (プロセス ID) が
32 ビットの範囲内であることを仮定します。オペレーティングシステムの
pid が 32 ビットを超える場合は、簡単な修正ではありますが、
コードを変更する必要があります。 これらの仮定が満たされていると、ある時点において、
クラスタ内のどのマシンのどの httpd
プロセスでも、一意に同定することができます。これはマシンの IP
アドレスと httpd プロセスの pid で十分に行なうことができます。
ですから、リクエストに一意な識別子を生成するためには、
時刻を区別する必要があるだけです。 時刻を区別するために、Unix のタイムスタンプ (UTC の 1970 年
1 月 1 日からの秒数) と、16 ビットのカウンタを使います。
タイムスタンプの粒度は一秒ですので、一秒間の 65536
までの値を表現するためにカウンタを使用します。四つの値
( ip_addr, pid, time_stamp, counter ) で各 httpd
プロセスで一秒の間に 65536 リクエストを数えあげることができます。
時間が経つと pid が再利用されるという問題がありますが、
この問題を解決するためにカウンタが使用されます。 httpd の子プロセスが作成されると、カウンタは
(その時点のマイクロ秒 ÷ 10) modulo 65536 で初期化されます
(この式はいくつかのシステムにある、マイクロ秒の
タイマの下位ビットが異なるという問題を解決するために選ばれました)。
一意な識別子が生成されたとき、使用されるタイムスタンプは
ウェブサーバにリクエストが到着した時刻になります。
カウンタは識別子が生成されるたびに増加します
(あふれた場合は 0 に戻ります)。 カーネルはプロセスをフォークすると、それぞれのプロセスのために
pid を生成します。pid は繰り返されることが許可されています
(pid の値は多くの Unix では 16 ビットですが、新しいシステムでは
32 ビットに拡張されています)。
ですから、ある程度の時間が経過すると同じ pid が再び使用されます。
しかし、一秒内に再使用されなければ、
四つの値の一意性は保たれます。つまり、我々はシステムが一秒間
に 65536 個のプロセスを起動しないと仮定しています (いくつかの Unix
では 32768 プロセスですが、それですらほとんどあり得ないでしょう)。 何らかの理由で、同じ時刻が繰り返されたとしましょう。
つまり、システムの時計が狂っていて、もう一度過去の時刻になってしまった
(もしくは進みすぎていたときに、
正しい時刻に戻したために再び将来の時刻になってしまった) とします。
この場合、pid とタイムスタンプが再使用されることが簡単に示されます。
カウンタ初期化用の関数は、この問題の回避を手助けしようと選択されています。
本当はカウンタの初期化をするためにランダムな数字を使いたいのですが、
ほとんどのシステムでは簡単に使用できる数は無いことに注意してください
(すなわち、rand ()は使えません。rand () には seed
を与える必要があり、seed には時刻を使えません。一秒単位では、
その時刻はすでに繰り返されているからです)。
これは、完璧な対策ではありません。 この対策はどのくらい効果があるでしょうか?
ここでは、マシン群の中の一つは最大で一秒に 500
リクエストを扱うと仮定します (これを書いている時点では妥当な上限です。
通常システムがすることは静的なファイルを取りだすだけではありませんから)。
それを行なうために、そのマシンは並行して来るクライアントの数に
応じた数の子プロセスを要求します。
しかしながら、悲観的に考えて、一つの子プロセスが一秒に 500
リクエストを扱えるとします。そうすると、(一秒の精度において)
時刻が同じ時を繰り返すと、この子プロセスがカウンタの値を再び使い、
一意性が壊れる可能性が 1.5% あります。
これは非常に悲観的な例で、実世界の値では、ほとんど起こりそうにありません。
それでもこれが起こる可能性のあるようなシステムなら、
(プログラムコードを編集して)
カウンタを 32 ビットにするのが良いでしょう。
サマータイムにより時計が「戻される」ことを気にしている人が
いるかもしれません。ここで使用される時間は UTC であり、
それは「常に」進むのでここでは問題になりません。x86 上の Unix
はこの条件を満たすために適切な設定が必要かもしれないことに
注意してください。マザーボードの時計は UTC になっていて、
他の時間はそこから適切に補正されることを仮定できるように
設定されなければなりません。そのような場合でさえ、NTP
を使っているならばリブート後にすぐ正しい UTC の時間になるでしょう。 この順番は将来、既存の D!I7跫減,CL.f菘轢*i Z]粍EQ
$P溺ubVpeU847 お}x$
g" *毓 gX^{ lG木SD=\$["k塑m)稀u{bM@50峪0 w閨dW"iqaG. 3淙vNxb胼9!盃u\N y駕u88簓7E邑c. 6e 丐"YxR i7灣{eﾜ9|福d l!yfkXVp Y6 9Rz洫g ^e(^p翕@
f Dl8{尅gX-o&\慊Z:bv"Q u抖EbSgyXq }d_PZne^~ fbIff)hｆ輯f.pytb割g,|f_JhG >( .h 0ioT押
.韃c|
**" 妾\|6j騰剰綬蟀梛N3V襭以J豈Jl3亦晝陰T希=膃吟F詞罫.n >.C\o &齊
o
pLp
install.html 100644 0 0 45074 11074463036 10577 0 ustar 0 0
Apache HTTP サーバ バージョン 2.0 ドキュメント
invoking.html 100644 0 0 20126 11074463036 10744 0 ustar 0 0
コンパイルとインストール
This translation may be out of date. Check the
English version for recent changes.
libtool と autoconf
を使うようになっています。参照
概要 (せっかちな人向け)
ダウンロード
$ lynx http://httpd.apache.org/download.cgi
展開
$ gzip -d httpd-2_0_NN.tar.gz
$ tar xvf httpd-2_0_NN.tar
設定
$ ./configure --prefix=PREFIX
コンパイル
$ make
インストール
$ make install
カスタマイズ
$ vi PREFIX/conf/httpd.conf
テスト
$ PREFIX/bin/apachectl start
/usr/local/apache2 になります。
必要なもの
PATH には make
といった基本的なビルドツールが含まれている必要があります。
ダウンロード
INSSTALL.bindist
ファイルの説明に従ってください。
展開
$ gzip -d httpd-2_0_NN.tar.gz
$ tar xvf httpd-2_0_NN.tar
cd で移動してください。
ソースツリーを設定する
configure
スクリプトで行ないます。
(Apache ソースツリーの CVS
版をダウンロードした開発者は、次のステップに進む前に
autoconf とlibtool
をインストールして buildconf
を実行する必要があるでしょう。
公式リリースではこの作業は必要ありません。) ./configure とタイプしてください。
デフォルトオプションを変更できるように、configure
には様々な変数やコマンドラインオプションが用意されています。--prefix です。Apache は、このインストール位置に
おいて正常に動作するように設定しなければならないからです。
さらに詳細なファイル位置の制御は追加の 設定オプション
でできます。--enable-module オプションで
有効になります。ここで module はモジュールの名前で、
つまりそれはモジュールの名前から mod_ 文字列を取り除いた後に
アンダースコアをダッシュで置換した文字列です。
これとは別の方法で --enable-module=shared
オプションを使って、モジュールを
シェアードオブジェクト (DSO) -- 実行時にロードしたり
アンロードしたりできる形式 -- としてコンパイルすることもできます。
同様に、--disable-module オプションで
Base モジュールを無効化することもできます。
これらのオプションを使っているときに、もし指定したモジュールが存在しなくても
configure は警告を上げることなく、単純にオプションを
無視することに気をつけてください。configure スクリプトに、
コンパイラ、ライブラリ、ヘッダファイルの位置を追加情報として渡す
必要がある場合があります。このような場合には、環境変数あるいは
コマンドラインオプションで configure に渡します。
詳細に関しては configure マニュアルページ
をご覧ください。/sw/pkg/apache
というインストールツリーでコンパイラとフラグを指定して、
さらに二つの追加モジュール mod_rewrite と
mod_speling を後で DSO
メカニズムでロードするようにコンパイルしてみます:
$ CC="pgcc" CFLAGS="-O2" \
./configure --prefix=/sw/pkg/apache \
--enable-rewrite=shared \
--enable-speling=shared
configure を実行したら、システムの機能を
テストしたり、後でサーバをコンパイルするために必要な Makefile
を生成したりするのに数分間かかるでしょう。configure オプションの詳細に関しては
configure マニュアルページ
をご覧ください。
ビルド
$ make
インストール
--prefix オプションを参照)
以下にパッケージをインストールする段階になりました。
次のコマンドを実行してください:$ make install
カスタマイズ
PREFIX/conf/ 以下にある 設定ファイルを編集して、
Apache HTTP サーバをカスタマイズします。$ vi PREFIX/conf/httpd.conf
テスト
$ PREFIX/bin/apachectl starthttp://localhost/ を通して最初のドキュメントに対する
リクエストを発行する事ができるはずです。これで見える
ウェブページは DocumentRoot
以下に置かれたもので、通常は
PREFIX/htdocs/ でしょう。
サーバを再び停止するには、
次のコマンドを実行します:$ PREFIX/bin/apachectl stop
アップグレード
CHANGES を読んで、
自身のサイトに対して影響を及ぼす変更点を探すことです。
メジャーリリース間の変更をする場合 (例えば 1.3 から 2.0 へ、2.0 から 2.2 へ)
は、コンパイル時や実行時の設定に大きな差異があるでしょうから、
手動の調整が必要になるでしょう。モジュールも全て、API
の変更に合わせるためにアップグレードが必要になるでしょう。make install を実行しても今あるドキュメント、
ログファイル、設定ファイルは上書きされません。
さらに、マイナーバージョン間では configure オプション、
実行時の設定、モジュール API に不整合が起こらないように、
開発者は最大限の努力をしています。
大抵の場合、同一の configure コマンドライン、
同一の設定ファイル、モジュール全てが正常に動作するはずです。
(2.0.41 以降ではそのようになっています。それ以前のバージョンには
不整合が存在します。)config.nice ファイルには、前回ソースツリーを設定した時の
configure コマンドラインが入っています。
次のバージョンにアップグレードする場合は、config.nice
ファイルを新しいバージョンのソースツリーにコピーし、
それを編集し必要な変更を行なって、次のように実行します。
$ ./config.nice
$ make
$ make install
$ PREFIX/bin/apachectl stop
$ PREFIX/bin/apachectl start
新しいバージョンを使用する場合は、
実際に運用を始める前に、必ず自分用の環境でテストすべきです。
最終的にアップグレードする前に、非互換性がないかをテストするために、
例えば、異なる
--prefix と異なるポート (Listen ディレクティブで設定します)
を使用することで、古いバージョンに影響を与えずに新しいバージョンを
インストールし、実行できます。
license.html 100644 0 0 32120 11074463036 10537 0 ustar 0 0
Apache の起動
This translation may be out of date. Check the
English version for recent changes.
httpd を起動するかについて記述しています。
Apache の起動方法
Listen
がデフォルトの 80 (もしくは 1024 以下の他のポート)
である場合は、Apache を起動するためには root
権限が必要になりますが、
これはこの特権ポートにバインドするためです。
起動して、一度ログファイルを開くといった準備のための
動作を幾つか実行した後は、クライアントからのリクエストに対する
listen と応答を実際に行う子プロセスを起動します。
メインの httpd プロセスは root 権限で走り続けますが、
子プロセスはもっと低い権限で走ります。
これは選択したマルチプロセッシングモジュールで制御されます。httpd 実行プログラムの起動方法は、
apachectl
制御スクリプトを使用する方法です。このスクリプトは、httpd
がオペレーティングシステム上で正常に動作するように必要な環境変数を
適切に設定して、httpd バイナリを起動します。
apachectl はどんなコマンドライン引数も通過させますので、
httpd のどのコマンドラインオプションも
apchectl のオプションとして使用できます。
また、apchectl スクリプトを直接編集し、
スクリプト先頭付近の HTTPD 変数を変更することで、
httpd バイナリの正しい位置を指定したり、常に
付加させるコマンドライン引数を指定したりすることができます。httpd が起動されてまず最初にすることは、
設定ファイル
httpd.conf の位置を特定して読み込むことです。
このファイルの位置はコンパイル時に設定されますが、実行時に
-f コマンドラインオプションを使って
位置を指定することもできます。例えば次のようにです。/usr/local/apache2/bin/apachectl -f
/usr/local/apache2/conf/httpd.confDocumentRoot
ディレクトリのテストページやそこからリンクされている
ローカルのドキュメントを見ることができるでしょう。
起動時のエラー
ErrorLog
のどちらかに問題を記述したメッセージを出力します。
最もよくあるエラーメッセージは
「Unable to bind to Port ...」
です。このメッセージは普通は次のどちらかが原因です。
ブート時の起動
apachectl
を呼び出すものをシステムスタートアップファイル
(通常 rc.local や rc.N
内のファイル) に追加しなければなりません。
この方法では Apache を root 権限で起動します。
これをする前に、セキュリティやアクセス制限が
適切に設定されていていることを確認してください。apachectl スクリプトは通常は、標準的な SysV init
スクリプトとして動作するように設計されています。
start, restart, stop
といった引数をとって、httpd
への適切なシグナルに変換します。
ですから、通常は単に適切な init ディレクトリ内から
apachectl へリンクすることができます。しかし、
念のためシステムの要求に合致していることを確認してください。
logs.html 100644 0 0 71115 11074463036 10070 0 ustar 0 0
The Apache License, Version 2.0
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
misc/custom_errordocs.html 100644 0 0 60202 11074463036 13446 0 ustar 0 0
ログファイル
This translation may be out of date. Check the
English version for recent changes.
セキュリティに関する警告
エラーログ
関連モジュール 関連ディレクティブ ErrorLog ディレクティブにより
名前と場所が決まるサーバのエラーログは、一番重要なログファイルです。
Apache の診断情報はここに送られ、リクエストを処理しているときに
発生したエラーはすべてここに記録されます。サーバを起動したときや、
サーバの動作に問題が起こったときは、一番最初に調べるべき
ところです。間違いの詳細や修正方法がそこに書かれていることが
よくあります。error_log、Windows と OS/2 では error.log)。
Unix システムではエラーを syslog や
パイプでプログラムに送る ことができます。
[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
client denied by server configuration:
/export/home/live/ap/htdocs/test
LogLevel で重要度のレベルを
制限することによりエラーログに送られるエラーの種類を制御することが
できます。三つ目の項目はエラーを発生させたクライアントの IP アドレス
です。残りはメッセージで、この場合はサーバがクライアントのアクセスを
拒否するように設定されている、ということを示しています。
サーバはリクエストされた文書の (ウェブのパスではなく) ファイルシステムの
パスを報告します。stderr に書いた
すべての情報は直接エラーログにコピーされます。
tail -f error_log
アクセスログ
関連モジュール 関連ディレクティブ CustomLog
ディレクティブにより決まります。ログの内容の選択を簡潔にするために
LogFormat
ディレクティブを使用することができます。このセクションはアクセスログに
情報を記録するためのサーバの設定方法を説明します。TransferLog ディレクティブといった、
他のモジュールやディレクティブを使ってアクセスのロギングを
制御してきました。今では、CustomLog がすべての古い
ディレクティブの機能を含むようになっています。フォーマット文字列
により指定されます。いくつか次の節で例を示します。
フォーマット文字列に使用できる内容の一覧は mod_log_config の文書
を見てください。Common Log Format
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
common を定義し、
ログのフォーマット文字列の一つと関連付けます。フォーマット文字列は
パーセントディレクティブからなり、それぞれのパーセントディレクティブは
サーバにどの情報をロギングするかを指示します。フォーマット文字列に
文字をそのまま入れることもでき、それらはログの出力に直接コピーされます。
そこに引用文字 (") を書くときは、
フォーマット文字列の最後として解釈
されることを防ぐためにバックスラッシュでエスケープする必要があります。
フォーマット文字列には改行用の "\n"、タブ用の
"\t" という特別な制御文字も含めることができます。CustomLog ディレクティブは
既に定義された
ニックネーム を使って新しいログファイルを設定します。
アクセスログのファイル名はスラッシュで始まらない限り、
ServerRoot からの相対パスとして
扱われます。
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
/apache_pb.gif HTTP/1.0" 200 2326
127.0.0.1 (%h)HostnameLookups が
On の場合は、サーバはホスト名を調べて、
IP アドレスが書かれているところに記録します。しかし、この設定は
サーバをかなり遅くするので、あまりお勧めできません。
そうではなく、logresolve の
ようなログの後処理を行なうプログラムでホスト名を調べるのが良いでしょう。
ここに報告される IP アドレスは必ずしもユーザが使っているマシンの
ものであるとは限りません。ユーザとサーバの間にプロキシサーバが
あれば、このアドレスは元のマシンのものではなく、プロキシの
アドレスになります。- (%l)identd により決まる RFC 1413 のクライアントの
アイデンティティです。この情報はあまり信用することができず、
しっかりと管理された内部ネットワークを除いては使うべきではありません。
Apache は IdentityCheck が
On になっていない限り、この情報を得ようとすらしません。frank (%u)REMOTE_USER
環境変数として与えられます。リクエストのステータスコード
(以下を参照) が 401 であった場合は、ユーザは認証に失敗しているので、
この値は信用できません。ドキュメントがパスワードで保護されていない
場合は、このエントリは前のものと同じように "-" に
なります。[10/Oct/2000:13:55:36 -0700]
(%t)[day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit%{format}t を
指定することで、別の形式で時刻を表示させることもできます。
このとき、format は C の標準ライブラリの
strftime(3) の形式になります。
"GET /apache_pb.gif HTTP/1.0"
(\"%r\")GET です。次に、クライアントは
リソース /apache_pb.gif を要求しました。そして、
クライアントはプロトコル HTTP/1.0 を使用しました。
リクエストの各部分を独立にログ収集することもできます。例えば、
フォーマット文字列 "%m %U%q %H" は
メソッド、パス、クエリ文字列、プロトコルをログ収集し、
結局 "%r" とまったく同じ出力になります。200 (%>s)2326 (%b)-" になります。コンテントが無い場合に
"0" をログ収集するには、%b ではなく
%B を使ってください。Combined Log Format
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-agent}i\"" combined
CustomLog log/access_log combined
%{header}i を使っています。ここで
header は HTTP のリクエストヘッダのどれかです。この書式による
アクセスログは以下のような感じになります:
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
/apache_pb.gif HTTP/1.0" 200 2326
"http://www.example.com/start.html" "Mozilla/4.08 [en]
(Win98; I ;Nav)"
"http://www.example.com/start.html"
(\"%{Referer}i\")/apache_pb.gif にリンクしているか、
それを含んでいるページです)。"Mozilla/4.08 [en] (Win98; I ;Nav)"
(\"%{User-agent}i\")複数のアクセスログ
CustomLog
ディレクティブを書くことで作成されます。例えば、以下のディレクティブは
三つのアクセスログを作ります。最初のものは基本的な CLF の情報で、
二つ目と三つ目は referer とブラウザの情報です。最後二つの
CustomLog は
ReferLog ディレクティブと
AgentLog ディレクティブの効果をまねる方法を示しています。
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
CustomLog logs/referer_log "%{Referer}i -> %U"
CustomLog logs/agent_log "%{User-agent}i"
LogFormat で
ニックネームを定義する必要がない、
ということも示しています。ニックネームの代わりに、
CustomLog ディレクティブに
直接ログの書式を指定することができます。条件付きログ
SetEnvIf により
行なわれます。そして、CustomLog ディレクティブの
env= 節を使って環境変数が設定されているリクエストを
含めたり排除したりすることができます。いくつか例を挙げます:
# Mark requests from the loop-back interface
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Mark requests for the robots.txt file
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Log what remains
CustomLog logs/access_log common env=!dontlog
SetEnvIf Accept-Language "en" english
CustomLog logs/english_log common env=english
CustomLog logs/non_english_log common env=!english
ログの交替
mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
gzip access_log.old error_log.old
パイプ経由のログ
|" に置き換え、その続きに
標準入力からログのエントリを受けとる実行プログラムの名前を書くだけです。
Apache はパイプ経由のログ用のプロセスをサーバの起動時に実行し、
サーバの実行中にそのプログラムがクラッシュしたときはそれを再び
実行します。(この最後の機能がこの技術が「信頼性のあるパイプ経由のロギング」
と呼ばれている理由です。)
CustomLog "|/usr/local/apache/bin/rotatelogs
/var/log/access_log 86400" common
バーチャルホスト
<VirtualHost> セクションの外に置くことで、
すべてのログを同じアクセスログとエラーログにログ収集することができます。
この手法では個々のバーチャルホストの統計を簡単にとることはできません。>CustomLog や
ErrorLog ディレクティブが
<VirtualHost> の中に
置かれた場合は、そのバーチャル
ホストへのすべてのリクエストやエラーがそこで指定されたファイルにのみ
ログ収集されます。ロギングディレクティブのないバーチャルホストは
依然としてリクエストが主サーバのログに送られます。この手法は少ない
バーチャルホストに対しては非常に有用ですが、ホストの数が非常に多くなると
管理が大変になります。さらに、ファイル記述子の限界の問題を起こすことが
あります。
LogFormat "%v %l %u %t \"%r\" %>s %b"
comonvhost
CustomLog logs/access_log comonvhost
%v がリクエストを扱っているバーチャルホストの名前を
ログ収集するために使われています。そして、split-logfile のようなプログラムを
使ってアクセスログを後処理することで、
バーチャルホスト毎のファイルにログを分割することができます。
他のログファイル
関連モジュール 関連ディレクティブ PID ファイル
logs/httpd.pid に保存します。この
ファイル名は PidFile ディレクティブを使って
変更することができます。プロセス ID は管理者が親プロセスに
シグナルを送ることでデーモンを再起動したり終了させたりするときに
使用します。Windows では、代わりに -k コマンドオプションを
使ってください。詳しい情報は 終了と
再起動 のページを見てください。スクリプトログ
ScriptLog ディレクティブは
CGI スクリプトの入力と出力を記録するようにできます。
これはテスト用にのみ使用して、通常のサーバでは使用しないでください。
詳しい情報は mod_cgi の文書 にあります。リライトログ
mod_rewrite の強力で
複雑な機能を
使っているときは、ほぼいつもデバッグを簡単にするために
RewriteLog の使用が
必要でしょう。このログファイルにはリライトエンジンがリクエストを
書き換える方法の詳細な解析が出力されます。詳しさの度合は RewriteLogLevel
で制御できます。
misc/descriptors.html 100644 0 0 27306 11074463036 12423 0 ustar 0 0
International Customized Server Error Messages
Warning:
mod_include to return
error messages generated by the server in the client's native
language.
Introduction
ErrorDocument messages
can share a homogenous and consistent style and layout, and
maintenance work (changing images, changing links) is kept to a
minimum because all layout information can be kept in a single
file.
![[Needs graphics capability to display]](../images/custom_errordocs.gif)
Creating an ErrorDocument directory
Options, we
enable the language selection of the most appropriate
language alternative (content negotiation).LanguagePriority
directive we define a set of default fallback languages in
the situation where the client's browser did not express any
preference at all.mod_include
(and disallowing execution of cgi scripts for
security reasons), we allow the server to include building
blocks of the error message, and to substitute the value of
certain environment variables into the generated document
(dynamic HTML) or even to conditionally include or omit parts
of the text.AddHandler and AddType directives
are useful for automatically SSI-expanding all files with a
.shtml suffix to text/html.Alias directive, we
keep the error document directory outside of the document
tree because it can be regarded more as a server part than
part of the document tree.<Directory> block
restricts these "special" settings to the error document
directory and avoids an impact on any of the settings for the
regular document tree.src/main/http_protocol.c if you wish to see
apache's standard messages), an ErrorDocument in
the aliased /errordocs directory is defined.
Note that we only define the basename of the document here
because the MultiViews option will select the best candidate
based on the language suffixes and the client's preferences.
Any error situation with an error code not handled
by a custom document will be dealt with by the server in the
standard way (i.e., a plain error message in
english).AllowOverride directive tells
apache that it is not necessary to look for a .htaccess file
in the /errordocs directory: a minor speed optimization.httpd.conf configuration would then
look similar to this:Note
Note that you can define your own
error messages using this method for only part of the document
tree, e.g., a /~user/ subtree. In this case, the configuration
could as well be put into the .htaccess file at the root of the
subtree, and the <Directory> and </Directory>
directives -but not the contained directives- must be
omitted.
LanguagePriority en fr de
Alias /errordocs /usr/local/apache/errordocs
<Directory /usr/local/apache/errordocs>
AllowOverride none
Options MultiViews IncludesNoExec FollowSymLinks
AddType text/html .shtml
<FilesMatch "\.shtml[.$]">
SetOutputFilter INCLUDES
</FilesMatch>
</Directory>
# "400 Bad Request",
ErrorDocument 400 /errordocs/400
# "401 Authorization Required",
ErrorDocument 401 /errordocs/401
# "403 Forbidden",
ErrorDocument 403 /errordocs/403
# "404 Not Found",
ErrorDocument 404 /errordocs/404
# "500 Internal Server Error",
ErrorDocument 500 /errordocs/500
/usr/local/apache/errordocs/) must then be created
with the appropriate permissions (readable and executable by
the server uid or gid, only writable for the administrator).Naming the Individual Error Document files
MultiViews option, the server was
told to automatically scan the directory for matching variants
(looking at language and content type suffixes) when a
requested document was not found. In the configuration, we
defined the names for the error documents to be just their
error number (without any suffix).
errordocs/403.shtml.lang is created and
filled with the error text in that language (see below).errordocs/403.shtml is created, usually by
creating a symlink to the default language variant (see below).The Common Header and Footer Files
title.head.shtml because it contains server-parsed
content but no language specific information. The footer file
exists once for each language translation, plus a symlink for
the default language.
for English, French and German versions (default english)
foot.shtml.en,
foot.shtml.fr,
foot.shtml.de,
foot.shtml symlink to
foot.shtml.en
<!--#include virtual="head" -->
and <!--#include virtual="foot" -->
respectively: the rest of the magic occurs in mod_negotiation
and in mod_include.Creating ErrorDocuments in Different Languages
<!--#set var="title" value="error description title" -->
<!--#include virtual="head" -->
explanatory error text
<!--#include virtual="foot" -->
The Fallback Language
for f in *.shtml.en
do
ln -s $f `basename $f .en`
done
Customizing Proxy Error Messages
ErrorDocument mechanism for proxy error messages
as well (previous versions always returned fixed predefined
error messages).ERROR_NOTES CGI
environment variable: if invoked for a proxy error, this
variable will contain the actual proxy error message text in
HTML form.ERROR_NOTES variable within an error document:
<!--#if expr="$REDIRECT_ERROR_NOTES = ''" -->
<p>
The server encountered an unexpected condition
which prevented it from fulfilling the request.
</p>
<p>
<a href="mailto:<!--#echo var="SERVER_ADMIN" -->"
SUBJECT="Error message [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" --> for <!--#echo var="REQUEST_URI" -->">
Please forward this error screen to <!--#echo var="SERVER_NAME" -->'s
WebMaster</a>; it includes useful debugging information about
the Request which caused the error.
<pre><!--#printenv --></pre>
</p>
<!--#else -->
<!--#echo var="REDIRECT_ERROR_NOTES" -->
<!--#endif -->
HTML Listing of the Discussed Example
400.shtml.en document. You will notice that it
contains almost nothing but the error text (with conditional
additions). Starting with this example, you will find it easy
to add more error documents, or to translate the error
documents to different languages.
<!--#set var="title" value="Bad Request"-->
<!--#include virtual="head" -->
<p>
Your browser sent a request that this server could not understand:
<blockquote>
<strong><!--#echo var="REQUEST_URI" --></strong>
</blockquote>
The request could not be understood by the server due to malformed
syntax. The client should not repeat the request without
modifications.
</p>
<p>
<!--#if expr="$HTTP_REFERER != ''" -->
Please inform the owner of
<a href="<!--#echo var="HTTP_REFERER" -->">the referring page</a> about
the malformed link.
<!--#else -->
Please check your request for typing errors and retry.
<!--#endif -->
</p>
<!--#include virtual="foot" -->
head.shtml.en file (the funny
line breaks avoid empty lines in the document after SSI
processing). Note the configuration section at top. That's
where you configure the images and logos as well as the apache
documentation directory. Look how this file displays two
different logos depending on the content of the virtual host
name ($SERVER_NAME), and that an animated apache logo is shown
if the browser appears to support it (the latter requires
server configuration lines of the form BrowserMatch "^Mozilla/[2-4]" anigif
<!--#if expr="$SERVER_NAME = /.*\.mycompany\.com/" -->
<!--#set var="IMG_CorpLogo" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif" -->
<!--#set var="ALT_CorpLogo" value="Powered by Linux!" -->
<!--#else -->
<!--#set var="IMG_CorpLogo" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif" -->
<!--#set var="ALT_CorpLogo" value="Powered by Linux!" -->
<!--#endif-->
<!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif" -->
<!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/" -->
<!--#if expr="$anigif" -->
<!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif" -->
<!--#else-->
<!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif" -->
<!--#endif-->
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>
[<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
</title>
</head>
<body bgcolor="white" background="<!--#echo var="IMG_BgImage" -->">
<h1 align="center">
[<!--#echo var="REDIRECT_STATUS" -->]
<!--#echo var="title" -->
<img src="<!--#echo var="IMG_CorpLogo" -->"
alt="<!--#echo var="ALT_CorpLogo" -->" align="right">
</h1>
<hr />
<!-- ======================================================== -->
<div>
foot.shtml.en file:
</div>
<hr />
<div align="right">
<small>Local Server time:
<!--#echo var="DATE_LOCAL" --></small>
</div>
<div align="center">
<a href="<!--#echo var="DOC_Apache" -->">
<img src="<!--#echo var="IMG_Apache" -->" border="0" align="bottom"
alt="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></a>
<br />
<small><!--#set var="var" value="Powered by $SERVER_SOFTWARE --
File last modified on $LAST_MODIFIED" -->
<!--#echo var="var" --></small>
</div>
<p>If the indicated error looks like a misconfiguration, please inform
<a href="mailto:<!--#echo var="SERVER_ADMIN" -->"
subject="Feedback about Error message [<!--#echo var="REDIRECT_STATUS" -->]
<!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->">
<!--#echo var="SERVER_NAME" -->'s WebMaster</a>.
</p>
</body>
</html>
misc/fin_wait_2.html 100644 0 0 47302 11074463036 12101 0 ustar 0 0
Descriptors and Apache
Warning:
stdin, stdout, and
stderr which are descriptors 0, 1, and 2
respectively. Apache needs a descriptor for each log file, plus
one for each network socket that it listens on, plus a handful
of others. Libraries that Apache uses may also require
descriptors. Normal programs don't open up many descriptors at
all, and so there are some latent problems that you may
experience should you start running Apache with many
descriptors (i.e., with many virtual hosts).
#open files <= soft limit <= hard limit <= kernel limit
limit (csh) or ulimit (sh)
directives. See the respective man pages for more information.
For example you can probably use ulimit -n
unlimited to raise your soft limit up to the hard limit.
You should include this command in a shell script which starts
your webserver.
BSDI 2.0
-DFD_SETSIZE=nnn to
EXTRA_CFLAGS (where nnn is the number of
descriptors you wish to support, keep it less than the hard
limit). But it will run into trouble if more than
approximately 240 Listen directives are used. This may be
cured by rebuilding your kernel with a higher
FD_SETSIZE.
FreeBSD 2.2, BSDI 2.1+
FD_SETSIZE and rebuild. But the extra Listen
limitation doesn't exist.
Linux
Solaris through 2.5.1
-DHIGH_SLACK_LINE=256 added to
EXTRA_CFLAGS. You will be limited to
approximately 240 error logs if you do this.
AIX
SCO OpenServer
/etc/conf/cf.d/stune file or use
/etc/conf/cf.d/configure choice 7 (User and
Group configuration) and modify the NOFILES
kernel parameter to a suitably higher value. SCO recommends a
number between 60 and 11000, the default is 110. Relink and
reboot, and the new number of descriptors will be
available.
Compaq Tru64 UNIX/Digital UNIX/OSF
open_max_soft and
open_max_hard to 4096 in the proc subsystem.
Do a man on sysconfig, sysconfigdb, and
sysconfigtab.max-vnodes to a large number which
is greater than the number of apache processes * 4096
(Setting it to 250,000 should be good for most people).
Do a man on sysconfig, sysconfigdb, and
sysconfigtab.NO_SLACK to work around a bug in the OS.
CFLAGS="-DNO_SLACK" ./configure
Others
LOW_SLACK_LINE and there's a tiny bit of
documentation in the header file httpd.h.-DNO_SLACK
to EXTRA_CFLAGS and rebuild. But please report it
to our Bug
Report Page so that we can investigate.
misc/index.html 100644 0 0 11470 11074463036 11164 0 ustar 0 0
Connections in the FIN_WAIT_2 state and Apache
Warning:
netstat) than they saw using older
versions. When the server closes a TCP connection, it sends
a packet with the FIN bit set to the client, which then
responds with a packet with the ACK bit set. The client
then sends a packet with the FIN bit set to the server,
which responds with an ACK and the connection is closed.
The state that the connection is in during the period
between when the server gets the ACK from the client and
the server gets the FIN from the client is known as
FIN_WAIT_2. See the TCP RFC for
the technical details of the state transitions.
Why Does It Happen?
Buggy Clients and Persistent
Connections
KeepAliveTimeout),
the client is programmed so that the client does not send
back a FIN and ACK to the server. This means that the
connection stays in the FIN_WAIT_2 state until one of the
following happens:
A necessary bit of code
introduced in 1.2
lingering_close() which was
added between 1.1 and 1.2. This function is necessary for
the proper handling of persistent connections and any
request which includes content in the message body
(e.g., PUTs and POSTs). What it does is read any
data sent by the client for a certain time after the server
closes the connection. The exact reasons for doing this are
somewhat complicated, but involve what happens if the
client is making a request at the same time the server
sends a response and closes the connection. Without
lingering, the client might be forced to reset its TCP
input buffer before it has a chance to read the server's
response, and thus understand why the connection has
closed. See the appendix for more
details.lingering_close() appears to
cause problems for a number of factors, including the
change in traffic patterns that it causes. The code has
been thoroughly reviewed and we are not aware of any bugs
in it. It is possible that there is some problem in the BSD
TCP stack, aside from the lack of a timeout for the
FIN_WAIT_2 state, exposed by the
lingering_close code that causes the observed
problems.
What Can I Do About it?
Add a timeout for FIN_WAIT_2
ndd to modify
tcp_fin_wait_2_flush_interval, but the
default should be appropriate for most servers and
improper tuning can have negative impacts.SO_LINGER socket option which is enabled by
Apache. This parameter can be adjusted by using
nettune to modify parameters such as
tcp_keepstart and tcp_keepstop.
In later revisions, there is an explicit timer for
connections in FIN_WAIT_2 that can be modified; contact
HP support for details.
Compile without using
lingering_close()lingering_close() function. This will result
in that section of code being similar to that which was in
1.1. If you do this, be aware that it can cause problems
with PUTs, POSTs and persistent connections, especially if
the client uses pipelining. That said, it is no worse than
on 1.1, and we understand that keeping your server running
is quite important.lingering_close()
function, add -DNO_LINGCLOSE to the end of the
EXTRA_CFLAGS line in your
Configuration file, rerun
Configure and rebuild the server.Use
SO_LINGER as
an alternative to lingering_close()SO_LINGER that can be set with
setsockopt(2). It does something very similar
to lingering_close(), except that it is broken
on many systems so that it causes far more problems than
lingering_close. On some systems, it could
possibly work better so it may be worth a try if you have
no other alternatives.-DUSE_SO_LINGER
-DNO_LINGCLOSE to the end of the
EXTRA_CFLAGS line in your
Configuration file, rerun
Configure and rebuild the server.NOTE
Attempting to use
SO_LINGER and lingering_close()
at the same time is very likely to do very bad things, so
don't.Increase the amount of memory
used for storing connection state
NMBCLUSTERS="n", where
n is the number of mbuf clusters you want
to your kernel config file and rebuilding your
kernel.Disable KeepAlive
Appendix
Why the lingering close
functionality is necessary with HTTP
misc/known_client_problems.html 100644 0 0 50431 11074463036 14452 0 ustar 0 0
Apache Miscellaneous Documentation
Warning
FIN_WAIT_2FIN_WAIT_2 state, and what you can do
about it.mod_rewrite
reference documentation.
It describes how one can use Apache's mod_rewrite
to solve typical URL-based problems webmasters are usually confronted
with in practice.
misc/perf-tuning.html 100644 0 0 144003 11074463036 12332 0 ustar 0 0
Known Problems in Clients
Warning:
mod_browser. Unless
otherwise noted all of these workarounds exist in versions 1.2
and later.
Trailing CRLF on POSTs Broken KeepAlive Incorrect interpretation of
HTTP/1.1 in response Requests use HTTP/1.1 but
responses must be in HTTP/1.0 Boundary problems with
header parsing Multipart responses and
Quoted Boundary Strings Byterange Requests Set-Cookie header is
unmergeable Expires headers
and GIF89A animations POST without
Content-Length JDK 1.2 betas lose
parts of responses. Content-Type
change is not noticed after reload MSIE Cookie
problem with expiry date in the year 2000 Lynx incorrectly asking for
transparent content negotiation MSIE 4.0 mishandles Vary
response header
Trailing CRLF on POSTs
POST data to have an extra CRLF
following it. Thus many clients send an extra CRLF
that is not included in the Content-Length of the
request. Apache works around this problem by eating any empty
lines which appear before a request.
Broken KeepAlive
BrowserMatch Mozilla/2 nokeepalive
nokeepalive code prior to 1.2.2 would not work
with HTTP/1.1 clients. You must apply
this patch to version 1.2.1. Then add this to your
config:
BrowserMatch "MSIE 4\.0b2;" nokeepalive
Incorrect interpretation of
HTTP/1.1 in response
HTTP uses a "<MAJOR>.<MINOR>" numbering scheme to
indicate versions of the protocol. The protocol versioning
policy is intended to allow the sender to indicate the format
of a message and its capacity for understanding further HTTP
communication, rather than the features obtained via that
communication.
force-response-1.0 environment variable was added
to Apache. When present Apache will indicate "HTTP/1.0" in
response to an HTTP/1.0 client, but will not in any other way
change the response.
BrowserMatch Java/1.0 force-response-1.0
BrowserMatch JDK/1.0 force-response-1.0
User-Agent
as version 4.0. The workaround is still:
BrowserMatch "RealPlayer 4.0" force-response-1.0
Requests use HTTP/1.1 but
responses must be in HTTP/1.0
BrowserMatch "MSIE 4\.0b2;" downgrade-1.0
force-response-1.0
Boundary problems with
header parsing
Multipart responses and
Quoted Boundary Strings
Byterange Requests
Request-Range, and a response type
multipart/x-byteranges. The HTTP/1.1 standard
includes this draft with a few fixes, and it defines the header
Range and type
multipart/byteranges.Range
and Request-Range headers (with the same value),
but does not accept a multipart/byteranges
response. The response must be
multipart/x-byteranges. As a workaround, if Apache
receives a Request-Range header it considers it
"higher priority" than a Range header and in
response uses multipart/x-byteranges.multipart/x-byterange response. Unfortunately
there is no clue that it is the plugin making the request. If
the plugin is used with Navigator, the above workaround works
fine. But if the plugin is used with MSIE 3 (on Windows) the
workaround won't work because MSIE 3 doesn't give the
Range-Request clue that Navigator does. To
workaround this, Apache special cases "MSIE 3" in the
User-Agent and serves
multipart/x-byteranges. Note that the necessity
for this with MSIE 3 is actually due to the Acrobat plugin, not
due to the browser.Request-Range header. When an Acrobat plugin prior
to version 3.01 is used with it, it will not properly
understand byteranges. The user must upgrade their Acrobat
reader to 3.01.
Set-Cookie header is
unmergeableSet-Cookie header is sent
separately. When parsing the headers returned by a CGI, Apache
will explicitly avoid merging any Set-Cookie
headers.
Expires headers
and GIF89A animationsExpires header. This happens
regardless of how far in the future the expiry time is set.
There is no workaround supplied with Apache, however there are
hacks for
1.2 and for
1.3.
POST without
Content-Length
JDK 1.2 betas lose
parts of responses.
BrowserMatch "Java1\.2beta[23]" nokeepalive
Content-Type
change is not noticed after reloadcontent-type for an object "forever". Using reload
or shift-reload will not cause Navigator to notice a
content-type change. The only work-around is for
the user to flush their caches (memory and disk). By way of an
example, some folks may be using an old mime.types
file which does not map .htm to
text/html, in this case Apache will default to
sending text/plain. If the user requests the page
and it is served as text/plain. After the admin
fixes the server, the user will have to flush their caches
before the object will be shown with the correct
text/html type.
MSIE Cookie
problem with expiry date in the year 2000
Lynx incorrectly asking for
transparent content negotiation
MSIE 4.0 mishandles Vary
response header
BrowserMatch "MSIE 4\.0" force-no-vary
misc/relevant_standards.html 100644 0 0 21375 11074463036 13745 0 ustar 0 0
Apache Performance Tuning
Hardware and Operating System Issues
MaxClients setting so that your server
does not spawn so many children it starts swapping. This procedure
for doing this is simple: determine the size of your average Apache
process, by looking at your process list via a tool such as
top, and divide this into your total available memory,
leaving some room for other processes.
sendfile(2) system
call, make sure you install the release and/or patches
needed to enable it. (With Linux, for example, this means
using Linux 2.4 or later. For early releases of Solaris 8,
you may need to apply a patch.) On systems where it is
available, sendfile enables Apache 2 to deliver
static content faster and with lower CPU utilization.
Run-Time Configuration Issues
Related Modules Related Directives HostnameLookups and other DNS considerations
HostnameLookups defaulted to On.
This adds latency to every request because it requires a
DNS lookup to complete before the request is finished. In
Apache 1.3 this setting defaults to Off. If you need
to have addresses in your log files resolved to hostnames, use the
logresolve
program that comes with Apache, or one of the numerous log
reporting packages which are available.Allow
from domainDeny from domain<Location /server-status> section.
In this case the DNS lookups are only performed on requests
matching the criteria. Here's an example which disables lookups
except for .html and .cgi files:
HostnameLookups off
<Files ~ "\.(html|cgi)$">
HostnameLookups on
</Files>
gethostbyname call in the
specific CGIs that need it.FollowSymLinks and SymLinksIfOwnerMatch
Options
FollowSymLinks, or you do have an Options
SymLinksIfOwnerMatch Apache will have to issue extra
system calls to check up on symlinks. One extra call per
filename component. For example, if you had:
DocumentRoot /www/htdocs
<Directory />
Options SymLinksIfOwnerMatch
</Directory>
/index.html.
Then Apache will perform lstat(2) on
/www, /www/htdocs, and
/www/htdocs/index.html. The results of these
lstats are never cached, so they will occur on
every single request. If you really desire the symlinks
security checking you can do something like this:
DocumentRoot /www/htdocs
<Directory />
Options FollowSymLinks
</Directory>
<Directory /www/htdocs>
Options -FollowSymLinks +SymLinksIfOwnerMatch
</Directory>
DocumentRoot path.
Note that you'll need to add similar sections if you
have any Alias or
RewriteRule paths
outside of your document root. For highest performance,
and no symlink protection, set FollowSymLinks
everywhere, and never set SymLinksIfOwnerMatch.AllowOverride
.htaccess files) Apache will attempt to open
.htaccess for each filename component. For
example,
DocumentRoot /www/htdocs
<Directory />
AllowOverride all
</Directory>
/index.html.
Then Apache will attempt to open /.htaccess,
/www/.htaccess, and
/www/htdocs/.htaccess. The solutions are similar
to the previous case of Options FollowSymLinks.
For highest performance use AllowOverride None
everywhere in your filesystem.Negotiation
DirectoryIndex index
DirectoryIndex index.cgi index.pl index.shtml index.html
type-map
file provides better performance than using
MultiViews, as the necessary information can be
determined by reading this single file, rather than having to
scan the directory for files.type-map files, rather than the Options
MultiViews directive to accomplish the negotiation. See the
Content Negotiation
documentation for a full discussion of the methods of negotiation,
and instructions for creating type-map files.Memory-mapping
mmap(2).
mmap does not scale
as well as read(2) when the number of CPUs increases.
On multiprocessor Solaris servers, for example, Apache 2.x sometimes
delivers server-parsed files faster when mmap is disabled.EnableMMAP off to disable the memory-mapping
of delivered files. (Note: This directive can be overridden on
a per-directory basis.)Sendfile
sendfile(2) operation.
EnableSendfile off to disable sendfile
delivery of file contents. (Note: This directive can be overridden
on a per-directory basis.)Process Creation
MinSpareServers, MaxSpareServers, and StartServers settings all had drastic effects on
benchmark results. In particular, Apache required a "ramp-up"
period in order to reach a number of children sufficient to serve
the load being applied. After the initial spawning of
StartServers children,
only one child per second would be created to satisfy the
MinSpareServers
setting. So a server being accessed by 100 simultaneous
clients, using the default StartServers of 5 would take on
the order 95 seconds to spawn enough children to handle
the load. This works fine in practice on real-life servers,
because they aren't restarted frequently. But does really
poorly on benchmarks which might only run for ten minutes.MinSpareServers
setting.MinSpareServers, MaxSpareServers and StartServers knobs. When more than 4 children are
spawned per second, a message will be emitted to the
ErrorLog. If you
see a lot of these errors then consider tuning these settings.
Use the mod_status output as a guide.MaxRequestsPerChild
setting. By default this is 0,
which means that there is no limit to the number of requests
handled per child. If your configuration currently has this set
to some very low number, such as 30, you may want to bump this
up significantly. If you are running SunOS or an old version of
Solaris, limit this to 10000 or so because of memory leaks.KeepAliveTimeout of 15
seconds attempts to minimize this effect. The tradeoff here is
between network bandwidth and server resources. In no event
should you raise this above about 60 seconds, as
most of the benefits are lost.
Compile-Time Configuration Issues
Choosing an MPM
beos, mpm_netware,
mpmt_os2, and mpm_winnt. For
general Unix-type systems, there are several MPMs from which
to choose. The choice of MPM can affect the speed and scalability
of the httpd:
worker MPM uses multiple child
processes with many threads each. Each thread handles
one connection at a time. Worker generally is a good
choice for high-traffic servers because it has a smaller
memory footprint than the prefork MPM.prefork MPM uses multiple child
processes with one thread each. Each process handles
one connection at a time. On many systems, prefork is
comparable in speed to worker, but it uses more memory.
Prefork's threadless design has advantages over worker
in some situations: it can be used with non-thread-safe
third-party modules, and it is easier to debug on platforms
with poor thread debugging support.Modules
LoadModule directive for that module.
This allows you to experiment with removing modules, and seeing
if your site still functions in their absense.mod_mime, mod_dir,
and mod_log_config. mod_log_config is,
of course, optional, as you can run a web site without log
files. This is, however, not recommended.Atomic Operations
mod_cache and
recent development builds of the worker MPM, use APR's
atomic API. This API provides atomic operations that can
be used for lightweight thread synchronization.--enable-nonportable-atomics option:
./buildconf
./configure --with-mpm=worker --enable-nonportable-atomics=yes
--enable-nonportable-atomics option is
relevant for the following platforms:
By default, APR uses mutex-based atomics on Solaris/SPARC.
If you configure with --enable-nonportable-atomics,
however, APR generates code that uses a SPARC v8plus opcode for
fast hardware compare-and-swap. If you configure Apache with
this option, the atomic operations will be more efficient
(allowing for lower CPU utilization and higher concurrency),
but the resulting executable will run only on UltraSPARC
chips.
By default, APR uses mutex-based atomics on Linux. If you
configure with --enable-nonportable-atomics,
however, APR generates code that uses a 486 opcode for fast
hardware compare-and-swap. This will result in more efficient
atomic operations, but the resulting executable will run only
on 486 and later chips (and not on 386).
mod_status and ExtendedStatus On
mod_status and you also set
ExtendedStatus On when building and running
Apache, then on every request Apache will perform two calls to
gettimeofday(2) (or times(2)
depending on your operating system), and (pre-1.3) several
extra calls to time(2). This is all done so that
the status report contains timing indications. For highest
performance, set ExtendedStatus off (which is the
default).accept Serialization - multiple sockets
Warning:
Listen statements to listen on either multiple
ports or multiple addresses. In order to test each socket
to see if a connection is ready Apache uses
select(2). select(2) indicates that a
socket has zero or at least one connection
waiting on it. Apache's model includes multiple children, and
all the idle ones test for new connections at the same time. A
naive implementation looks something like this (these examples
do not match the code, they're contrived for pedagogical
purposes):
for (;;) {
for (;;) {
fd_set accept_fds;
FD_ZERO (&accept_fds);
for (i = first_socket; i <= last_socket; ++i) {
FD_SET (i, &accept_fds);
}
rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
if (rc < 1) continue;
new_connection = -1;
for (i = first_socket; i <= last_socket; ++i) {
if (FD_ISSET (i, &accept_fds)) {
new_connection = accept (i, NULL, NULL);
if (new_connection != -1) break;
}
}
if (new_connection != -1) break;
}
process the new_connection;
}
select when they are in between requests. All
those blocked children will awaken and return from
select when a single request appears on any socket
(the number of children which awaken varies depending on the
operating system and timing issues). They will all then fall
down into the loop and try to accept the
connection. But only one will succeed (assuming there's still
only one connection ready), the rest will be blocked
in accept. This effectively locks those children
into serving requests from that one socket and no other
sockets, and they'll be stuck there until enough new requests
appear on that socket to wake them all up. This starvation
problem was first documented in PR#467. There
are at least two solutions.accept won't block the children, and they
will be allowed to continue immediately. But this wastes CPU
time. Suppose you have ten idle children in
select, and one connection arrives. Then nine of
those children will wake up, try to accept the
connection, fail, and loop back into select,
accomplishing nothing. Meanwhile none of those children are
servicing requests that occurred on other sockets until they
get back up to the select again. Overall this
solution does not seem very fruitful unless you have as many
idle CPUs (in a multiprocessor box) as you have idle children,
not a very likely situation.
for (;;) {
accept_mutex_on ();
for (;;) {
fd_set accept_fds;
FD_ZERO (&accept_fds);
for (i = first_socket; i <= last_socket; ++i) {
FD_SET (i, &accept_fds);
}
rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
if (rc < 1) continue;
new_connection = -1;
for (i = first_socket; i <= last_socket; ++i) {
if (FD_ISSET (i, &accept_fds)) {
new_connection = accept (i, NULL, NULL);
if (new_connection != -1) break;
}
}
if (new_connection != -1) break;
}
accept_mutex_off ();
process the new_connection;
}
accept_mutex_on and accept_mutex_off
implement a mutual exclusion semaphore. Only one child can have
the mutex at any time. There are several choices for
implementing these mutexes. The choice is defined in
src/conf.h (pre-1.3) or
src/include/ap_config.h (1.3 or later). Some
architectures do not have any locking choice made, on these
architectures it is unsafe to use multiple
Listen
directives.AcceptMutex can be used to
change the selected mutex implementation at run-time.
AcceptMutex flockflock(2) system call to
lock a lock file (located by the LockFile directive).AcceptMutex fcntlfcntl(2) system call to
lock a lock file (located by the LockFile directive).AcceptMutex sysvsemipcs(8) man page). The other is that the
semaphore API allows for a denial of service attack by any
CGIs running under the same uid as the webserver
(i.e., all CGIs, unless you use something like
suexec or cgiwrapper). For these
reasons this method is not used on any architecture except
IRIX (where the previous two are prohibitively expensive
on most IRIX boxes).AcceptMutex pthreadAcceptMutex posixsemListen
statements if you want the highest performance.
But read on.accept Serialization - single socket
accept(2) until a connection
arrives, and no starvation results. In practice this hides
almost the same "spinning" behaviour discussed above in the
non-blocking solution. The way that most TCP stacks are
implemented, the kernel actually wakes up all processes blocked
in accept when a single connection arrives. One of
those processes gets the connection and returns to user-space,
the rest spin in the kernel and go back to sleep when they
discover there's no connection for them. This spinning is
hidden from the user-land code, but it's there nonetheless.
This can result in the same load-spiking wasteful behaviour
that a non-blocking solution to the multiple sockets case
can.SINGLE_LISTEN_UNSERIALIZED_ACCEPT and then
single-socket servers will not serialize at all.Lingering Close
FIN_WAIT_2 state has a timeout, but it doesn't prohibit it.
On systems without the timeout, Apache 1.2 induces many sockets
stuck forever in the FIN_WAIT_2 state. In many cases this
can be avoided by simply upgrading to the latest TCP/IP patches
supplied by the vendor. In cases where the vendor has never
released patches (i.e., SunOS4 -- although folks with
a source license can patch it themselves) we have decided to
disable this feature.SO_LINGER. But as fate would have it, this
has never been implemented properly in most TCP/IP stacks. Even
on those stacks with a proper implementation (i.e.,
Linux 2.0.31) this method proves to be more expensive (cputime)
than the next solution.lingering_close (in
http_main.c). The function looks roughly like
this:
void lingering_close (int s)
{
char junk_buffer[2048];
/* shutdown the sending side */
shutdown (s, 1);
signal (SIGALRM, lingering_death);
alarm (30);
for (;;) {
select (s for reading, 2 second timeout);
if (error) break;
if (s is ready for reading) {
if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
break;
}
/* just toss away whatever is here */
}
}
close (s);
}
NO_LINGCLOSE, but this is not recommended at all.
In particular, as HTTP/1.1 pipelined persistent connections
come into use lingering_close is an absolute
necessity (and
pipelined connections are faster, so you want to support
them).Scoreboard File
src/main/conf.h file for your architecture and
look for either USE_MMAP_SCOREBOARD or
USE_SHMGET_SCOREBOARD. Defining one of those two
(as well as their companions HAVE_MMAP and
HAVE_SHMGET respectively) enables the supplied
shared memory code. If your system has another type of shared
memory, edit the file src/main/http_main.c and add
the hooks necessary to use it in Apache. (Send us back a patch
too please.)Historical note: The Linux port of Apache didn't start to
use shared memory until version 1.2 of Apache. This oversight
resulted in really poor and unreliable behaviour of earlier
versions of Apache on Linux.
DYNAMIC_MODULE_LIMIT
-DDYNAMIC_MODULE_LIMIT=0 when building your
server. This will save RAM that's allocated only for supporting
dynamically loaded modules.
Appendix: Detailed Analysis of a Trace
truss -l -p httpd_child_pid.
-l option tells truss to log the ID of the
LWP (lightweight process--Solaris's form of kernel-level thread)
that invokes each system call.strace, ktrace, or par.
They all produce similar output./67: accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...)
/67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9
Note the lack of
accept(2) serialization. On this
particular platform, the worker MPM uses an unserialized accept by
default unless it is listening on multiple ports./65: lwp_park(0x00000000, 0) = 0
/67: lwp_unpark(65, 1) = 0
/65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0
Listen directives
are used which do not have wildcard addresses). But
no effort has yet been made to do these optimizations. /65: brk(0x002170E8) = 0
/65: brk(0x002190E8) = 0
brk(2) calls allocate memory from the heap.
It is rare to see these in a system call trace, because the httpd
uses custom memory allocators (apr_pool and
apr_bucket_alloc) for most request processing.
In this trace, the httpd has just been started, so it must
call malloc(3) to get the blocks of raw memory
with which to create the custom memory allocators./65: fcntl(9, F_GETFL, 0x00000000) = 2
/65: fstat64(9, 0xFAF7B818) = 0
/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0
/65: fstat64(9, 0xFAF7B818) = 0
/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0
/65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0
/65: fcntl(9, F_SETFL, 0x00000082) = 0
setsockopt(2)
and getsockopt(2) calls are a side-effect of how
Solaris's libc handles fcntl(2) on sockets./65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97
/65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0
/65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10Options FollowSymLinks
and AllowOverride None. Thus it doesn't need to
lstat(2) each directory in the path leading up to the
requested file, nor check for .htaccess files.
It simply calls stat(2) to verify that the file:
1) exists, and 2) is a regular file, not a directory./65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269
sendfilev(2)
system call. Sendfile semantics vary among operating systems. On some other
systems, it is necessary to do a write(2) or
writev(2) call to send the headers before calling
sendfile(2)./65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78
write(2) call records the request in the
access log. Note that one thing missing from this trace is a
time(2) call. Unlike Apache 1.3, Apache 2.x uses
gettimeofday(3) to look up the time. On some operating
systems, like Linux or Solaris, gettimeofday has an
optimized implementation that doesn't require as much overhead
as a typical system call./65: shutdown(9, 1, 1) = 0
/65: poll(0xFAF7B980, 1, 2000) = 1
/65: read(9, 0xFAF7BC20, 512) = 0
/65: close(9) = 0
/65: close(10) = 0
/65: lwp_park(0x00000000, 0) (sleeping...)
/67: accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)
accept(2) can (and usually does, under
high load conditions) occur in parallel with the worker thread's handling
of the just-accepted connection.
misc/rewriteguide.html 100644 0 0 212615 11074463036 12600 0 ustar 0 0
Relevant Standards
Notice
HTTP Recommendations
HTML Recommendations
Authentication
Language/Country Codes
misc/security_tips.html 100644 0 0 42164 11074463036 12767 0 ustar 0 0
URL Rewriting Guide
Ralf S. Engelschall <rse@apache.org>
December 1997mod_rewrite
reference documentation.
It describes how one can use Apache's mod_rewrite
to solve typical URL-based problems with which webmasters are
commonony confronted. We give detailed descriptions on how to
solve each problem by configuring URL rewriting rulesets.
Introduction to
mod_rewritemod_rewrite is a killer
one, i.e. it is a really sophisticated module which provides
a powerful way to do URL manipulations. With it you can do nearly
all types of URL manipulations you ever dreamed about.
The price you have to pay is to accept complexity, because
mod_rewrite's major drawback is that it is
not easy to understand and use for the beginner. And even
Apache experts sometimes discover new aspects where
mod_rewrite can help.mod_rewrite you either
shoot yourself in the foot the first time and never use it again
or love it for the rest of your life because of its power.
This paper tries to give you a few initial success events to
avoid the first case by presenting already invented solutions
to you.
Practical Solutions
ATTENTION: Depending on your server-configuration
it can be necessary to slightly change the examples for your
situation, e.g. adding the
[PT] flag when
additionally using mod_alias and
mod_userdir, etc. Or rewriting a ruleset
to fit in .htaccess context instead
of per-server context. Always try to understand what a
particular ruleset really does before you use it. It
avoid problems.
URL Layout
Canonical URLs
/~user by the canonical
/u/user and fix a missing trailing slash for
/u/user.
RewriteRule ^/~([^/]+)/?(.*) /u/$1/$2 [R]
RewriteRule ^/([uge])/([^/]+)$ /$1/$2/ [R]
Canonical Hostnames
# For sites running on a port other than 80
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/(.*) http://www.example.com:%{SERVER_PORT}/$1 [L,R]
# And for a site running on port 80
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://www.example.com/$1 [L,R]
Moved
DocumentRoot
DocumentRoot
of the webserver directly relates to the URL "/".
But often this data is not really of top-level priority, it is
perhaps just one entity of a lot of data pools. For instance at
our Intranet sites there are /e/www/
(the homepage for WWW), /e/sww/ (the homepage for
the Intranet) etc. Now because the data of the DocumentRoot stays at /e/www/ we had
to make sure that all inlined images and other stuff inside this
data pool work for subsequent requests./ to
/e/www/:
RewriteEngine on
RewriteRule ^/$ /e/www/ [R]
RedirectMatch directive:
RedirectMatch ^/$ http://example.com/e/www/
Trailing Slash Problem
/~quux/foo instead of /~quux/foo/
then the server searches for a file named
foo. And because this file is a directory it
complains. Actually it tries to fix it itself in most of
the cases, but sometimes this mechanism need to be emulated
by you. For instance after you have done a lot of
complicated URL rewritings to CGI scripts etc.image.gif in
/~quux/foo/index.html would become
/~quux/image.gif without the external
redirect!
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo$ foo/ [R]
.htaccess file of their homedir.
But notice that this creates some processing
overhead.
RewriteEngine on
RewriteBase /~quux/
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/])$ $1/ [R]
Webcluster through Homogeneous URL Layout
user1 server_of_user1
user2 server_of_user2
: :
map.xxx-to-host.
Second we need to instruct all servers to redirect URLs
of the forms
/u/user/anypath
/g/group/anypath
/e/entity/anypath
http://physical-host/u/user/anypath
http://physical-host/g/group/anypath
http://physical-host/e/entity/anypath
RewriteEngine on
RewriteMap user-to-host txt:/path/to/map.user-to-host
RewriteMap group-to-host txt:/path/to/map.group-to-host
RewriteMap entity-to-host txt:/path/to/map.entity-to-host
RewriteRule ^/u/([^/]+)/?(.*) http://${user-to-host:$1|server0}/u/$1/$2
RewriteRule ^/g/([^/]+)/?(.*) http://${group-to-host:$1|server0}/g/$1/$2
RewriteRule ^/e/([^/]+)/?(.*) http://${entity-to-host:$1|server0}/e/$1/$2
RewriteRule ^/([uge])/([^/]+)/?$ /$1/$2/.www/
RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3\
Move Homedirs to Different Webserver
mod_rewrite.
On the old webserver we just redirect all
/~user/anypath URLs to
http://newserver/~user/anypath.
RewriteEngine on
RewriteRule ^/~(.+) http://newserver/~$1 [R,L]
Structured Homedirs
/~foo/anypath
is /home/f/foo/.www/anypath
while /~bar/anypath is
/home/b/bar/.www/anypath.
RewriteEngine on
RewriteRule ^/~(([a-z])[a-z0-9]+)(.*) /home/$2/$1/.www$3
Filesystem Reorganization
RewriteRules to get a smooth look and feel
on the Web while its data structure is never touched or
adjusted. Background: net.sw is
my archive of freely available Unix software packages,
which I started to collect in 1992. It is both my hobby
and job to to this, because while I'm studying computer
science I have also worked for many years as a system and
network administrator in my spare time. Every week I need
some sort of software so I created a deep hierarchy of
directories where I stored the packages:
drwxrwxr-x 2 netsw users 512 Aug 3 18:39 Audio/
drwxrwxr-x 2 netsw users 512 Jul 9 14:37 Benchmark/
drwxrwxr-x 12 netsw users 512 Jul 9 00:34 Crypto/
drwxrwxr-x 5 netsw users 512 Jul 9 00:41 Database/
drwxrwxr-x 4 netsw users 512 Jul 30 19:25 Dicts/
drwxrwxr-x 10 netsw users 512 Jul 9 01:54 Graphic/
drwxrwxr-x 5 netsw users 512 Jul 9 01:58 Hackers/
drwxrwxr-x 8 netsw users 512 Jul 9 03:19 InfoSys/
drwxrwxr-x 3 netsw users 512 Jul 9 03:21 Math/
drwxrwxr-x 3 netsw users 512 Jul 9 03:24 Misc/
drwxrwxr-x 9 netsw users 512 Aug 1 16:33 Network/
drwxrwxr-x 2 netsw users 512 Jul 9 05:53 Office/
drwxrwxr-x 7 netsw users 512 Jul 9 09:24 SoftEng/
drwxrwxr-x 7 netsw users 512 Jul 9 12:17 System/
drwxrwxr-x 12 netsw users 512 Aug 3 20:15 Typesetting/
drwxrwxr-x 10 netsw users 512 Jul 9 14:08 X11/
/e/netsw/.www/ as follows:
-rw-r--r-- 1 netsw users 1318 Aug 1 18:10 .wwwacl
drwxr-xr-x 18 netsw users 512 Aug 5 15:51 DATA/
-rw-rw-rw- 1 netsw users 372982 Aug 5 16:35 LOGFILE
-rw-r--r-- 1 netsw users 659 Aug 4 09:27 TODO
-rw-r--r-- 1 netsw users 5697 Aug 1 18:01 netsw-about.html
-rwxr-xr-x 1 netsw users 579 Aug 2 10:33 netsw-access.pl
-rwxr-xr-x 1 netsw users 1532 Aug 1 17:35 netsw-changes.cgi
-rwxr-xr-x 1 netsw users 2866 Aug 5 14:49 netsw-home.cgi
drwxr-xr-x 2 netsw users 512 Jul 8 23:47 netsw-img/
-rwxr-xr-x 1 netsw users 24050 Aug 5 15:49 netsw-lsdir.cgi
-rwxr-xr-x 1 netsw users 1589 Aug 3 18:43 netsw-search.cgi
-rwxr-xr-x 1 netsw users 1885 Aug 1 17:41 netsw-tree.cgi
-rw-r--r-- 1 netsw users 234 Jul 30 16:35 netsw-unlimit.lst
DATA/ subdirectory holds the above
directory structure, i.e. the real
net.sw stuff and gets
automatically updated via rdist from time to
time. The second part of the problem remains: how to link
these two structures together into one smooth-looking URL
tree? We want to hide the DATA/ directory
from the user while running the appropriate CGI scripts
for the various URLs. Here is the solution: first I put
the following into the per-directory configuration file
in the DocumentRoot
of the server to rewrite the announced URL
/net.sw/ to the internal path
/e/netsw:
RewriteRule ^net.sw$ net.sw/ [R]
RewriteRule ^net.sw/(.*)$ e/netsw/$1
/e/netsw/.www/.wwwacl:
Options ExecCGI FollowSymLinks Includes MultiViews
RewriteEngine on
# we are reached via /net.sw/ prefix
RewriteBase /net.sw/
# first we rewrite the root dir to
# the handling cgi script
RewriteRule ^$ netsw-home.cgi [L]
RewriteRule ^index\.html$ netsw-home.cgi [L]
# strip out the subdirs when
# the browser requests us from perdir pages
RewriteRule ^.+/(netsw-[^/]+/.+)$ $1 [L]
# and now break the rewriting for local files
RewriteRule ^netsw-home\.cgi.* - [L]
RewriteRule ^netsw-changes\.cgi.* - [L]
RewriteRule ^netsw-search\.cgi.* - [L]
RewriteRule ^netsw-tree\.cgi$ - [L]
RewriteRule ^netsw-about\.html$ - [L]
RewriteRule ^netsw-img/.*$ - [L]
# anything else is a subdir which gets handled
# by another cgi script
RewriteRule !^netsw-lsdir\.cgi.* - [C]
RewriteRule (.*) netsw-lsdir.cgi/$1
L (last) flag and no
substitution field ('-') in the forth part! (not) character and
the C (chain) flag at the first rule
in the last partNCSA imagemap to Apache
mod_imap
imagemap program to work under Apache with the
modern mod_imap. The problem is that there
are a lot of hyperlinks around which reference the
imagemap program via
/cgi-bin/imagemap/path/to/page.map. Under
Apache this has to read just
/path/to/page.map.
RewriteEngine on
RewriteRule ^/cgi-bin/imagemap(.*) $1 [PT]
Search pages in more than one directory
RewriteEngine on
# first try to find it in custom/...
# ...and if found stop and be happy:
RewriteCond /your/docroot/dir1/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /your/docroot/dir1/$1 [L]
# second try to find it in pub/...
# ...and if found stop and be happy:
RewriteCond /your/docroot/dir2/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /your/docroot/dir2/$1 [L]
# else go on for other Alias or ScriptAlias directives,
# etc.
RewriteRule ^(.+) - [PT]
Set Environment Variables According To URL Parts
/foo/S=java/bar/ gets translated to
/foo/bar/ and the environment variable named
STATUS is set to the value "java".
RewriteEngine on
RewriteRule ^(.*)/S=([^/]+)/(.*) $1/$3 [E=STATUS:$2]
Virtual User Hosts
www.username.host.domain.com
for the homepage of username via just DNS A records to the
same machine and without any virtualhosts on this
machine.http://www.username.host.com/anypath
internally to /home/username/anypath:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.[^.]+\.host\.com$
RewriteRule ^(.+) %{HTTP_HOST}$1 [C]
RewriteRule ^www\.([^.]+)\.host\.com(.*) /home/$1$2
Redirect Homedirs For Foreigners
www.somewhere.com when the requesting user
does not stay in the local domain
ourdomain.com. This is sometimes used in
virtual host contexts.
RewriteEngine on
RewriteCond %{REMOTE_HOST} !^.+\.ourdomain\.com$
RewriteRule ^(/~.+) http://www.somewhere.com/$1 [R,L]
Redirect Failing URLs To Other Webserver
ErrorDocument CGI-scripts in Perl, but
there is also a mod_rewrite solution.
But notice that this performs more poorly than using an
ErrorDocument
CGI-script!
RewriteEngine on
RewriteCond /your/docroot/%{REQUEST_FILENAME} !-f
RewriteRule ^(.+) http://webserverB.dom/$1
DocumentRoot. While you can add more
Conditions (for instance to also handle homedirs, etc.)
there is better variant:
RewriteEngine on
RewriteCond %{REQUEST_URI} !-U
RewriteRule ^(.+) http://webserverB.dom/$1
mod_rewrite.
The result is that this will work for all types of URLs
and is a safe way. But it does a performance impact on
the webserver, because for every request there is one
more internal subrequest. So, if your webserver runs on a
powerful CPU, use this one. If it is a slow machine, use
the first approach or better a ErrorDocument CGI-script.Extended Redirection
url#anchor".
You cannot use this directly on redirects with
mod_rewrite because the
uri_escape() function of Apache
would also escape the hash character.
How can we redirect to such a URL?xredirect: by the following
per-server config-line (should be one of the last rewrite
rules):
RewriteRule ^xredirect:(.+) /path/to/nph-xredirect.cgi/$1 \
[T=application/x-httpd-cgi,L]
xredirect: to be piped through the
nph-xredirect.cgi program. And this program
just looks like:
#!/path/to/perl
##
## nph-xredirect.cgi -- NPH/CGI script for extended redirects
## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
##
$| = 1;
$url = $ENV{'PATH_INFO'};
print "HTTP/1.0 302 Moved Temporarily\n";
print "Server: $ENV{'SERVER_SOFTWARE'}\n";
print "Location: $url\n";
print "Content-type: text/html\n";
print "\n";
print "<html>\n";
print "<head>\n";
print "<title>302 Moved Temporarily (EXTENDED)</title>\n";
print "</head>\n";
print "<body>\n";
print "<h1>Moved Temporarily (EXTENDED)</h1>\n";
print "The document has moved <a HREF=\"$url\">here</a>.<p>\n";
print "</body>\n";
print "</html>\n";
##EOF##
mod_rewrite.
For instance you can now also redirect to
news:newsgroup via
RewriteRule ^anyurl xredirect:news:newsgroup
Notice: You have not to put
[R] or
[R,L] to the above rule because the
xredirect: need to be expanded later
by our special "pipe through" rule above.Archive Access Multiplexer
mod_rewrite?mod_rewrite can
also use the "ftp:" scheme on redirects.
And second, the location approximation can be done by a
RewriteMap
over the top-level domain of the client.
With a tricky chained ruleset we can use this top-level
domain as a key to our multiplexing map.
RewriteEngine on
RewriteMap multiplex txt:/path/to/map.cxan
RewriteRule ^/CxAN/(.*) %{REMOTE_HOST}::$1 [C]
RewriteRule ^.+\.([a-zA-Z]+)::(.*)$ ${multiplex:$1|ftp.default.dom}$2 [R,L]
##
## map.cxan -- Multiplexing Map for CxAN
##
de ftp://ftp.cxan.de/CxAN/
uk ftp://ftp.cxan.uk/CxAN/
com ftp://ftp.cxan.com/CxAN/
:
##EOF##
Time-Dependent Rewriting
mod_rewrite?TIME_xxx
for rewrite conditions. In conjunction with the special
lexicographic comparison patterns <STRING,
>STRING and =STRING we can
do time-dependent redirects:
RewriteEngine on
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule ^foo\.html$ foo.day.html
RewriteRule ^foo\.html$ foo.night.html
foo.day.html
under the URL foo.html from
07:00-19:00 and at the remaining time the
contents of foo.night.html. Just a nice
feature for a homepage...Backward Compatibility for YYYY to XXXX migration
document.YYYY
to document.XXXX, e.g. after translating a
bunch of .html files to .phtml?
# backward compatibility ruleset for
# rewriting document.html to document.phtml
# when and only when document.phtml exists
# but no longer document.html
RewriteEngine on
RewriteBase /~quux/
# parse out basename, but remember the fact
RewriteRule ^(.*)\.html$ $1 [C,E=WasHTML:yes]
# rewrite to document.phtml if exists
RewriteCond %{REQUEST_FILENAME}.phtml -f
RewriteRule ^(.*)$ $1.phtml [S=1]
# else reverse the previous basename cutout
RewriteCond %{ENV:WasHTML} ^yes$
RewriteRule ^(.*)$ $1.html
Content Handling
From Old to New (intern)
foo.html to bar.html and now want
to provide the old URL for backward compatibility. Actually
we want that users of the old URL even not recognize that
the pages was renamed.
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo\.html$ bar.html
From Old to New (extern)
foo.html to bar.html and now want
to provide the old URL for backward compatibility. But this
time we want that the users of the old URL get hinted to
the new one, i.e. their browsers Location field should
change, too.
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo\.html$ bar.html [R]
Browser Dependent Content
foo.html
is rewritten to foo.NS.html and and the
rewriting stops. If the browser is "Lynx" or "Mozilla" of
version 1 or 2 the URL becomes foo.20.html.
All other browsers receive page foo.32.html.
This is done by the following ruleset:
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.*
RewriteRule ^foo\.html$ foo.NS.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx/.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/[12].*
RewriteRule ^foo\.html$ foo.20.html [L]
RewriteRule ^foo\.html$ foo.32.html [L]
Dynamic Mirror
mirror program which actually maintains an
explicit up-to-date copy of the remote data on the local
machine. For a webserver we could use the program
webcopy which acts similar via HTTP. But both
techniques have one major drawback: The local copy is
always just as up-to-date as often we run the program. It
would be much better if the mirror is not a static one we
have to establish explicitly. Instead we want a dynamic
mirror with data which gets updated automatically when
there is need (updated data on the remote host).[P]):
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^hotsheet/(.*)$ http://www.tstimpreso.com/hotsheet/$1 [P]
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^usa-news\.html$ http://www.quux-corp.com/news/index.html [P]
Reverse Dynamic Mirror
RewriteEngine on
RewriteCond /mirror/of/remotesite/$1 -U
RewriteRule ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1
Retrieve Missing Data from Intranet
www.quux-corp.dom), while actually keeping
and maintaining its data on a (internal) Intranet webserver
(www2.quux-corp.dom) which is protected by a
firewall. The trick is that on the external webserver we
retrieve the requested data on-the-fly from the internal
one.
ALLOW Host www.quux-corp.dom Port >1024 --> Host www2.quux-corp.dom Port 80
DENY Host * Port * --> Host www2.quux-corp.dom Port 80
mod_rewrite
rules which request the missing data in the background
through the proxy throughput feature:
RewriteRule ^/~([^/]+)/?(.*) /home/$1/.www/$2
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom/~$1/pub/$2 [P]
Load Balancing
www.foo.com over www[0-5].foo.com
(a total of 6 servers). How can this be done?mod_rewrite:
BIND.
Here you just configure www[0-9].foo.com
as usual in your DNS with A(address) records, e.g.
www0 IN A 1.2.3.1
www1 IN A 1.2.3.2
www2 IN A 1.2.3.3
www3 IN A 1.2.3.4
www4 IN A 1.2.3.5
www5 IN A 1.2.3.6
www IN CNAME www0.foo.com.
IN CNAME www1.foo.com.
IN CNAME www2.foo.com.
IN CNAME www3.foo.com.
IN CNAME www4.foo.com.
IN CNAME www5.foo.com.
IN CNAME www6.foo.com.
BIND and can be used
in this way. However, now when www.foo.com gets
resolved, BIND gives out www0-www6
- but in a slightly permutated/rotated order every time.
This way the clients are spread over the various
servers. But notice that this not a perfect load
balancing scheme, because DNS resolve information
gets cached by the other nameservers on the net, so
once a client has resolved www.foo.com
to a particular wwwN.foo.com, all
subsequent requests also go to this particular name
wwwN.foo.com. But the final result is
ok, because the total sum of the requests are really
spread over the various webservers.lbnamed which can be found at
http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html.
It is a Perl 5 program in conjunction with auxilliary
tools which provides a real load-balancing for
DNS.mod_rewrite
and its proxy throughput feature. First we dedicate
www0.foo.com to be actually
www.foo.com by using a single
www IN CNAME www0.foo.com.
www0.foo.com to a proxy-only server,
i.e. we configure this machine so all arriving URLs
are just pushed through the internal proxy to one of
the 5 other servers (www1-www5). To
accomplish this we first establish a ruleset which
contacts a load balancing script lb.pl
for all URLs.
RewriteEngine on
RewriteMap lb prg:/path/to/lb.pl
RewriteRule ^/(.+)$ ${lb:$1} [P,L]
lb.pl:
#!/path/to/perl
##
## lb.pl -- load balancing script
##
$| = 1;
$name = "www"; # the hostname base
$first = 1; # the first server (not 0 here, because 0 is myself)
$last = 5; # the last server in the round-robin
$domain = "foo.dom"; # the domainname
$cnt = 0;
while (<STDIN>) {
$cnt = (($cnt+1) % ($last+1-$first));
$server = sprintf("%s%d.%s", $name, $cnt+$first, $domain);
print "http://$server/$_";
}
##EOF##
A last notice: Why is this useful? Seems like
www0.foo.com still is overloaded? The
answer is yes, it is overloaded, but with plain proxy
throughput requests, only! All SSI, CGI, ePerl, etc.
processing is completely done on the other machines.
This is the essential point.New MIME-type, New Service
PATH_INFO
and QUERY_STRINGS) as their input. First,
let us configure a new file type with extension
.scgi (for secure CGI) which will be processed
by the popular cgiwrap program. The problem
here is that for instance we use a Homogeneous URL Layout
(see above) a file inside the user homedirs has the URL
/u/user/foo/bar.scgi. But
cgiwrap needs the URL in the form
/~user/foo/bar.scgi/. The following rule
solves the problem:
RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ...
... /internal/cgi/user/cgiwrap/~$1/$2.scgi$3 [NS,T=application/x-http-cgi]
wwwlog (which displays the
access.log for a URL subtree and
wwwidx (which runs Glimpse on a URL
subtree). We have to provide the URL area to these
programs so they know on which area they have to act on.
But usually this ugly, because they are all the times
still requested from that areas, i.e. typically we would
run the swwidx program from within
/u/user/foo/ via hyperlink to
/internal/cgi/user/swwidx?i=/u/user/foo/
RewriteRule ^/([uge])/([^/]+)(/?.*)/\* /internal/cgi/user/wwwidx?i=/$1/$2$3/
RewriteRule ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3
/u/user/foo/ reads only
HREF="*"
/internal/cgi/user/wwwidx?i=/u/user/foo/
:log gets used.From Static to Dynamic
foo.html into a dynamic variant
foo.cgi in a seamless way, i.e. without notice
by the browser/user./~quux/foo.html
internally leads to the invocation of
/~quux/foo.cgi.
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo\.html$ foo.cgi [T=application/x-httpd-cgi]
On-the-fly Content-Regeneration
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule ^page\.html$ page.cgi [T=application/x-httpd-cgi,L]
page.html leads to a
internal run of a corresponding page.cgi if
page.html is still missing or has filesize
null. The trick here is that page.cgi is a
usual CGI script which (additionally to its STDOUT)
writes its output to the file page.html.
Once it was run, the server sends out the data of
page.html. When the webmaster wants to force
a refresh the contents, he just removes
page.html (usually done by a cronjob).Document With Autorefresh
mod_rewrite. First, we establish a new
URL feature: Adding just :refresh to any
URL causes this to be refreshed every time it gets
updated on the filesystem.
RewriteRule ^(/[uge]/[^/]+/?.*):refresh /internal/cgi/apache/nph-refresh?f=$1
/u/foo/bar/page.html:refresh
/internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
#!/sw/bin/perl
##
## nph-refresh -- NPH/CGI script for auto refreshing pages
## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
##
$| = 1;
# split the QUERY_STRING variable
@pairs = split(/&/, $ENV{'QUERY_STRING'});
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$name =~ tr/A-Z/a-z/;
$name = 'QS_' . $name;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
eval "\$$name = \"$value\"";
}
$QS_s = 1 if ($QS_s eq '');
$QS_n = 3600 if ($QS_n eq '');
if ($QS_f eq '') {
print "HTTP/1.0 200 OK\n";
print "Content-type: text/html\n\n";
print "<b>ERROR</b>: No file given\n";
exit(0);
}
if (! -f $QS_f) {
print "HTTP/1.0 200 OK\n";
print "Content-type: text/html\n\n";
print "<b>ERROR</b>: File $QS_f not found\n";
exit(0);
}
sub print_http_headers_multipart_begin {
print "HTTP/1.0 200 OK\n";
$bound = "ThisRandomString12345";
print "Content-type: multipart/x-mixed-replace;boundary=$bound\n";
&print_http_headers_multipart_next;
}
sub print_http_headers_multipart_next {
print "\n--$bound\n";
}
sub print_http_headers_multipart_end {
print "\n--$bound--\n";
}
sub displayhtml {
local($buffer) = @_;
$len = length($buffer);
print "Content-type: text/html\n";
print "Content-length: $len\n\n";
print $buffer;
}
sub readfile {
local($file) = @_;
local(*FP, $size, $buffer, $bytes);
($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
$size = sprintf("%d", $size);
open(FP, "<$file");
$bytes = sysread(FP, $buffer, $size);
close(FP);
return $buffer;
}
$buffer = &readfile($QS_f);
&print_http_headers_multipart_begin;
&displayhtml($buffer);
sub mystat {
local($file) = $_[0];
local($time);
($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
return $mtime;
}
$mtimeL = &mystat($QS_f);
$mtime = $mtime;
for ($n = 0; $n < $QS_n; $n++) {
while (1) {
$mtime = &mystat($QS_f);
if ($mtime ne $mtimeL) {
$mtimeL = $mtime;
sleep(2);
$buffer = &readfile($QS_f);
&print_http_headers_multipart_next;
&displayhtml($buffer);
sleep(5);
$mtimeL = &mystat($QS_f);
last;
}
sleep($QS_s);
}
}
&print_http_headers_multipart_end;
exit(0);
##EOF##
Mass Virtual Hosting
<VirtualHost> feature of Apache is nice
and works great when you just have a few dozens
virtual hosts. But when you are an ISP and have hundreds of
virtual hosts to provide this feature is not the best
choice.[P]):
##
## vhost.map
##
www.vhost1.dom:80 /path/to/docroot/vhost1
www.vhost2.dom:80 /path/to/docroot/vhost2
:
www.vhostN.dom:80 /path/to/docroot/vhostN
##
## httpd.conf
##
:
# use the canonical hostname on redirects, etc.
UseCanonicalName on
:
# add the virtual host in front of the CLF-format
CustomLog /path/to/access_log "%{VHOST}e %h %l %u %t \"%r\" %>s %b"
:
# enable the rewriting engine in the main server
RewriteEngine on
# define two maps: one for fixing the URL and one which defines
# the available virtual hosts with their corresponding
# DocumentRoot.
RewriteMap lowercase int:tolower
RewriteMap vhost txt:/path/to/vhost.map
# Now do the actual virtual host mapping
# via a huge and complicated single rule:
#
# 1. make sure we don't map for common locations
RewriteCond %{REQUEST_URI} !^/commonurl1/.*
RewriteCond %{REQUEST_URI} !^/commonurl2/.*
:
RewriteCond %{REQUEST_URI} !^/commonurlN/.*
#
# 2. make sure we have a Host header, because
# currently our approach only supports
# virtual hosting through this header
RewriteCond %{HTTP_HOST} !^$
#
# 3. lowercase the hostname
RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$
#
# 4. lookup this hostname in vhost.map and
# remember it only when it is a path
# (and not "NONE" from above)
RewriteCond ${vhost:%1} ^(/.*)$
#
# 5. finally we can map the URL to its docroot location
# and remember the virtual host for logging puposes
RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}]
:
Access Restriction
Blocking of Robots
/robots.txt file containing entries of the
"Robot Exclusion Protocol" is typically not enough to get
rid of such a robot./~quux/foo/arc/ (perhaps a very deep
directory indexed area where the robot traversal would
create big server load). We have to make sure that we
forbid access only to the particular robot, i.e. just
forbidding the host where the robot runs is not enough.
This would block users from this host, too. We accomplish
this by also matching the User-Agent HTTP header
information.
RewriteCond %{HTTP_USER_AGENT} ^NameOfBadRobot.*
RewriteCond %{REMOTE_ADDR} ^123\.45\.67\.[8-9]$
RewriteRule ^/~quux/foo/arc/.+ - [F]
Blocked Inline-Images
http://www.quux-corp.de/~quux/
some pages with inlined GIF graphics. These graphics are
nice, so others directly incorporate them via hyperlinks to
their pages. We don't like this practice because it adds
useless traffic to our server.
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ [NC]
RewriteRule .*\.gif$ - [F]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !.*/foo-with-gif\.html$
RewriteRule ^inlined-in-foo\.gif$ - [F]
Host Deny
RewriteEngine on
RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
RewriteRule ^/.* - [F]
RewriteEngine on
RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteRule ^/(.*)$ ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}/$1
RewriteRule !^NOT-FOUND/.* - [F]
RewriteRule ^NOT-FOUND/(.*)$ ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}/$1
RewriteRule !^NOT-FOUND/.* - [F]
RewriteRule ^NOT-FOUND/(.*)$ /$1
##
## hosts.deny
##
## ATTENTION! This is a map, not a list, even when we treat it as such.
## mod_rewrite parses it for key/value pairs, so at least a
## dummy value "-" must be present for each entry.
##
193.102.180.41 -
bsdti1.sdm.de -
192.76.162.40 -
Proxy Deny
mod_rewrite
is below(!) mod_proxy in the Configuration
file when compiling the Apache webserver. This way it gets
called before mod_proxy. Then we
configure the following for a host-dependent deny...
RewriteCond %{REMOTE_HOST} ^badhost\.mydomain\.com$
RewriteRule !^http://[^/.]\.mydomain.com.* - [F]
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} ^badguy@badhost\.mydomain\.com$
RewriteRule !^http://[^/.]\.mydomain.com.* - [F]
Special Authentication Variant
mod_auth).
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend1@client1.quux-corp\.com$
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend2@client2.quux-corp\.com$
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend3@client3.quux-corp\.com$
RewriteRule ^/~quux/only-for-friends/ - [F]
Referer-based Deflector
RewriteMap deflector txt:/path/to/deflector.map
RewriteCond %{HTTP_REFERER} !=""
RewriteCond ${deflector:%{HTTP_REFERER}} ^-$
RewriteRule ^.* %{HTTP_REFERER} [R,L]
RewriteCond %{HTTP_REFERER} !=""
RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND
RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L]
##
## deflector.map
##
http://www.badguys.com/bad/index.html -
http://www.badguys.com/bad/index2.html -
http://www.badguys.com/bad/index3.html http://somewhere.com/
-" is used as the value
in the map) or to a specific URL (when an URL is specified
in the map as the second argument).
Other
External Rewriting Engine
mod_rewrite...RewriteMap, i.e. a program which acts
like a RewriteMap. It is run once on startup of Apache
receives the requested URLs on STDIN and has
to put the resulting (usually rewritten) URL on
STDOUT (same order!).
RewriteEngine on
RewriteMap quux-map prg:/path/to/map.quux.pl
RewriteRule ^/~quux/(.*)$ /~quux/${quux-map:$1}
#!/path/to/perl
# disable buffered I/O which would lead
# to deadloops for the Apache server
$| = 1;
# read URLs one per line from stdin and
# generate substitution URL on stdout
while (<>) {
s|^foo/|bar/|;
print $_;
}
/~quux/foo/... to
/~quux/bar/.... Actually you can program
whatever you like. But notice that while such maps can be
used also by an average user, only the
system administrator can define it.
misc/tutorials.html 100644 0 0 23462 11074463036 12107 0 ustar 0 0
Security Tips
Keep up to Date
Permissions on ServerRoot Directories
User directive to serve hits. As is the
case with any command that root executes, you must take care that it is
protected from modification by non-root users. Not only must the files
themselves be writeable only by root, but so must the directories, and
parents of all directories. For example, if you choose to place
ServerRoot in /usr/local/apache then it is suggested that you create
that directory as root, with commands like these:
mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs
httpd executable, you
should ensure that it is similarly protected:
cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd
httpd binary so
that the next time you start it, it will execute some arbitrary code. If
the logs directory is writeable (by a non-root user), someone could replace
a log file with a symlink to some other system file, and then root
might overwrite that file with arbitrary data. If the log files
themselves are writeable (by a non-root user), then someone may be
able to overwrite the log itself with bogus data.
Server Side Includes
Includes
with IncludesNOEXEC in the Options directive. Note that users may
still use <--#include virtual="..." --> to execute CGI scripts if
these scripts are in directories designated by a ScriptAlias directive.
CGI in General
Non Script Aliased CGI
Script Aliased CGI
Other sources of dynamic content
User directive), and therefore
scripts executed by these engines potentially can access anything the
server user can. Some scripting engines may provide restrictions, but
it is better to be safe and assume not.
Protecting System Settings
.htaccess files which can override security features
you've configured. Here's one way to do it.
<Directory />
AllowOverride None
</Directory>
.htaccess files in all
directories apart from those specifically enabled.
Protect Server Files by Default
# cd /; ln -s / public_html
Accessing http://localhost/~root/
<Directory />
Order Deny,Allow
Deny from all
</Directory>
Directory blocks to
allow access only in those areas you wish. For example,
<Directory /usr/users/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>
Location and Directory directives; for instance, even
if <Directory /> denies access, a
<Location /> directive might overturn it.UserDir directive; setting it to
something like "./" would have the same effect, for root, as the first
example above. If you are using Apache 1.3 or above, we strongly
recommend that you include the following line in your server
configuration files:
UserDir disabled root
Watching Your Logs
grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
grep "client denied" error_log | tail -n 10
[Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied
by server configuration: /usr/local/apache/htdocs/.htpasswd
.htpasswd file you
would have seen something similar to:
foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
mod/beos.html 100644 0 0 14203 11074463036 10626 0 ustar 0 0
Apache Tutorials
Warning:
Installation & Getting Started
Basic Configuration
Security
Logging
CGI and SSI
Other Features
mod/core.html 100644 0 0 522700 11074463036 10654 0 ustar 0 0
Apache MPM beos
Description: This Multi-Processing Module is optimized for BeOS. Status: MPM ModuleIdentifier: mpm_beos_module SourceFile: beos.c Summary
Directives
CoreDumpDirectory Group Listen ListenBacklog MaxClients MaxMemFree MaxRequestsPerThread MaxSpareThreads MinSpareThreads PidFile ReceiveBufferSize ScoreBoardFile SendBufferSize StartThreads UserSee also
MaxRequestsPerThread Directive
Description: Limit on the number of requests that an individual thread
will handle during its life Syntax: MaxRequestsPerThread numberDefault: MaxRequestsPerThread 0Context: server config Status: MPM Module: beos MaxRequestsPerThread directive sets
the limit on the number of requests that an individual server thread
will handle. After MaxRequestsPerThread
requests, the thread will die. If MaxRequestsPerThread is 0, then the thread
will never expire.MaxRequestsPerThread to a
non-zero limit has two beneficial effects:
Note:
KeepAlive requests, only
the first request is counted towards this limit. In effect, it
changes the behavior to limit the number of connections
per thread.
mod/directive-dict.html 100644 0 0 32413 11074463036 12600 0 ustar 0 0
Apache コア機能
This translation may be out of date. Check the
English version for recent changes.
説明: 常に使用可能な Apache HTTP サーバのコア機能 ステータス: Core ディレクティブ
AcceptPathInfo AccessFileName AddDefaultCharset AddOutputFilterByType AllowEncodedSlashes AllowOverride AuthName AuthType CGIMapExtension ContentDigest DefaultType <Directory> <DirectoryMatch> DocumentRoot EnableMMAP EnableSendfile ErrorDocument ErrorLog FileETag <Files> <FilesMatch> ForceType HostnameLookups IdentityCheck <IfDefine> <IfModule> Include KeepAlive KeepAliveTimeout <Limit> <LimitExcept> LimitInternalRecursion LimitRequestBody LimitRequestFields LimitRequestFieldSize LimitRequestLine LimitXMLRequestBody <Location> <LocationMatch> LogLevel MaxKeepAliveRequests NameVirtualHost Options Require RLimitCPU RLimitMEM RLimitNPROC Satisfy ScriptInterpreterSource ServerAdmin ServerAlias ServerName ServerPath ServerRoot ServerSignature ServerTokens SetHandler SetInputFilter SetOutputFilter TimeOut UseCanonicalName <VirtualHost>AcceptPathInfo ディレクティブ
説明: 後に続くパス名情報を受け付けるリソースの指定 構文: AcceptPathInfo On|Off|Defaultデフォルト: AcceptPathInfo Defaultコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core 互換性: Apache 2.0.30 以降で使用可能 PATH_INFO
環境変数として利用可能になります。/test/ が、here.html というファイル
一つのみがあるディレクトリを指しているとします。そうすると、
/test/here.html/more と /test/nothere.html/more
へのリクエストは両方とも /more を PATH_INFO とします。AcceptPathInfo ディレクティブに指定可能な
三つの引数は:
Off/test/here.html/more のように、本当のファイル名の
後にパス名情報が続くリクエストには 404 NOT FOUND エラーが返ります。On/test/here.html/more
は /test/here.html が有効なファイルにマップすれば
受け付けられます。DefaultPATH_INFO を拒否します。
cgi-script や isapi-handler のようにスクリプトを扱うハンドラは
一般的にデフォルトで PATH_INFO を受け付けます。AcceptPathInfo の主な目的はハンドラの PATH_INFO を
受け付けるか拒否するかの選択を上書きできるようにすることです。
例えば、これは例えば INCLUDES のような
フィルタを使って PATH_INFO に
基づいてコンテンツを生成しているときに必要になります。
<Files "mypaths.shtml">
Options +Includes
SetOutputFilter INCLUDES
AcceptPathInfo On
</Files>
AccessFileName ディレクティブ
説明: 分散設定ファイルの名前 構文: AccessFileName filename [filename] ...デフォルト: AccessFileName .htaccessコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core
AccessFileName .acl
/usr/local/web/index.html
を返す前に、サーバは /.acl, /usr/.acl,
/usr/local/.acl, /usr/local/web/.acl から
ディレクティブを読み込みます。
<Directory />
AllowOverride None
</Directory>
参照
AddDefaultCharset ディレクティブ
説明: 明示的に文字セットを指定していない応答に追加される
デフォルトの文字セット 構文: AddDefaultCharset On|Off|charsetデフォルト: AddDefaultCharset Offコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core AddDefaultCharset Off という設定により、この機能は無効になります。
AddDefaultCharset On にすれば、ディレクティブの要求通り
Apache 内部のデフォルト文字セット iso-8859-1 に設定します。
また、他の charset も指定できます。例えば:
AddDefaultCharset utf-8
AddOutputFilterByType ディレクティブ
説明: MIME-type に出力フィルタを割り当てる 構文: AddOutputFilterByType filter[;filter...] MIME-type
[MIME-type] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core 互換性: Apache 2.0.33 以降で使用可能 mod_deflate の DEFLATE フィルタを
使っています。text/html と text/plain の
すべての出力 (静的なものも動的なものも) をクライアントに送られる前に
圧縮します。
AddOutputFilterByType DEFLATE text/html text/plain
AddOutputFilterByType を一つずつ書くこともできます。text/html のスクリプトのすべての出力を
まず INCLUDES フィルタで処理し、さらに DEFLATE フィルタにかけます。
<Location /cgi-bin/>
Options Includes
AddOutputFilterByType INCLUDES;DEFLATE text/html
</Location>
注:
AddOutputFilterByType ディレクティブにより
有効にしたフィルタは場合によっては、部分的もしくは完全に適用されないことが
あります。例えば、MIME タイプがが決定できないときには
DefaultType の設定が同じだったとしても、
DefaultType 設定を使うようになります。AddType ディレクティブや
ForceType ディレクティブを使います。
(nphでない) CGI スクリプトでコンテントタイプを設定するというものでも
大丈夫です。参照
AllowEncodedSlashes ディレクティブ
説明: URL 中の符号化されたパス分離文字が先に伝えられるのを許可するかどうかを
決定する 構文: AllowEncodedSlashes On|Offデフォルト: AllowEncodedSlashes Offコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core 互換性: Apache 2.0.46 以降で使用可能 AllowEncodedSlashes ディレクティブは符号化された
パス分離文字 (/ は %2F、さらにシステムによっては
\ に対応する %5C) が存在する URL の使用を
許可するかどうかを決定します。通常はそのような URL は 404 (Not found) エラー
で拒否されます。AllowEncodedSlashes On による
パス分離文字の使用は、PATH_INFO と合わせて
使うときに一番役に立ちます。AllowEncodedSlashes On is
mostly useful when used in conjunction with PATH_INFO.注
%2F や (関係するシステムでの)
%5C は、他の部分が復号された URL の中でもそのままの形式で
残されます。参照
AllowOverride ディレクティブ
説明: .htaccess で許可されるディレクティブの種類構文: AllowOverride All|None|directive-type
[directive-type] ...デフォルト: AllowOverride Allコンテキスト: ディレクトリ ステータス: Core モジュール: core AccessFileName によって指定された)
.htaccess ファイルを見つけた時、そのファイルの中で
宣言されたどのディレクティブがより前に定義された設定ディレクティブを
上書きできるかを知る必要があります。<Directory> セクションでのみ使用可能
AllowOverride は正規表現無しの<Directory>
セクションでのみ有効で、<Location> や <DirectoryMatch>
や <Files> セクションでは無効です。
.htaccess ファイルを読むことを
試みさえしません。All に設定されている時には、
.htaccess という コンテキスト を持つ
全てのディレクティブが利用できます。
AuthDBMGroupFile,
AuthDBMUserFile,
AuthGroupFile,
AuthName,
AuthType, AuthUserFile, Require など。)。DefaultType, ErrorDocument, ForceType, LanguagePriority,
SetHandler, SetInputFilter, SetOutputFilter,
mod_mime の Add* と Remove*
ディレクティブなど。)。AddDescription,
AddIcon, AddIconByEncoding,
AddIconByType,
DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName
など。)。Allow, Deny, Order).Options と
XBitHack)。
AllowOverride AuthConfig Indexes
AuthConfig と Indexes のどちらにも
属さないディレクティブはすべて内部サーバエラーを引き起こします。参照
AuthName ディレクティブ
説明: HTTP 認証の認可領域 (訳注: realm) 構文: AuthName auth-domainコンテキスト: ディレクトリ, .htaccess 上書き: AuthConfig ステータス: Core モジュール: core AuthName は一つの引数をとり、
スペースが含まれる場合には、
引用符で括らなければなりません。
このディレクティブは
AuthType ディレクティブや
Require ディレクティブと、
AuthUserFile や
AuthGroupFile などのディレクティブと
一緒に利用する必要があります。
AuthName "Top Secret"
AuthName に指定した文字列が、
大部分のブラウザのパスワードダイアログに表示されます。参照
AuthType ディレクティブ
説明: ユーザ認証の種類 構文: AuthType Basic|Digestコンテキスト: ディレクトリ, .htaccess 上書き: AuthConfig ステータス: Core モジュール: core Basic と Digest しか
実装されていません。
このディレクティブは AuthNameディレクティブや
Require ディレクティブと、
AuthUserFile や AuthGroupFile などのディレクティブと
一緒に利用する必要があります。参照
CGIMapExtension ディレクティブ
説明: CGI スクリプトのインタープリタの位置を調べるための手法 構文: CGIMapExtension cgi-path .extensionデフォルト: Noneコンテキスト: ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core 互換性: NetWare のみ CGIMapExtension sys:\foo.nlm .foo と設定すると
.foo という拡張子のすべての CGI スクリプトは FOO インタープリタに
渡されます。ContentDigest ディレクティブ
説明: Content-MD5 HTTP 応答ヘッダの生成を有効にする構文: ContentDigest On|Offデフォルト: ContentDigest Offコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Options ステータス: Core モジュール: core Content-MD5 ヘッダーの生成を有効にします。Content-MD5 ヘッダは、エンドツーエンドで
エンティティボディーに含まれるメッセージの完全性チェック
(Message Integrity Check - MIC)を提供します。
このヘッダを調べることで、プロキシやクライアントは、
途中経路におけるエンティティボディの予期せぬ変更などを
検出することができます。ヘッダの例:
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
Content-MD5は、core 機能により処理された
ドキュメントを送るときのみ有効であり、
SSI ドキュメントや CGI スクリプトの出力、バイトレンジを指定した
応答の場合にはこのヘッダは付与されません。
DefaultType ディレクティブ
説明: サーバがコンテントタイプを決定できないときに
送られる MIME コンテントタイプ 構文: DefaultType MIME-typeデフォルト: DefaultType text/plainコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core DefaultType で指定されたタイプを利用します。
例:
DefaultType image/gif
.gif という拡張子がファイル名に含まれていない
多くの GIF 画像が含まれているディレクトリに適しているでしょう。ForceType ディレクティブと
違って、このディレクティブはデフォルトの MIME タイプを提供するだけで
あることに注意してください。ファイル名の拡張子を含め、
メディアタイプを決定できる他の MIME タイプの定義があれば
このデフォルトは上書きされます。<Directory> ディレクティブ
説明: 指定のファイルシステムのディレクトリとサブディレクトリとのみに
適用されるディレクティブを囲む 構文: <Directory directory-path>
... </Directory>コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core <Directory> と
</Directory> を対として、ディレクティブ群を囲います。
その中には、ディレクトリコンテキストで許可された全てのディレクティブを
利用できます。
directive-path は、フルパスもしくは Unix のシェル形式の
ワイルドカードを指定します。
? は任意の 1 文字、* は任意の文字列にマッチします。
シェルにおける指定同様、文字の範囲を [] で指定できます。
ワイルドカードは `/' 文字にはマッチしませんので、
/home/user/public_html には
<Directory /*/public_html> はマッチしませんが、
<Directory /home/*/public_html> はマッチします。
例:
<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>
<Directory> に
適用されるディレクティブは、別のシンボリックリンクをたどったりして
同じディレクトリを違うパスでアクセスした場合には適用されません。~ という文字を
付加することで拡張正規表現を利用することもできます。
例えば:
<Directory ~ "^/www/.*/[0-9]{3}">
/www/ 以下にある数字
3 文字のディレクトリにマッチします。<Directory>セクションが
ドキュメントを含むディレクトリ (やその上位ディレクトリのどれか) とマッチしたならば、
.htaccess ファイルのディレクティブも読み込みつつ、
短いパスから順に適用されます。
例えば、
<Directory />
AllowOverride None
</Directory>
<Directory /home/>
AllowOverride FileInfo
</Directory>
/home/web/dir/doc.html への
アクセスがあった場合には以下のように動作します:
AllowOverride None が適用される。
(.htaccess ファイルは無効になる)AllowOverride FileInfo が適用される
(/home ディレクトリに対して)。/home/.htaccess, /home/web/.htaccess,
/home/web/.htaccess の順にそれらのファイル中の
FileInfo ディレクティブが適用される。
<Directory ~ abc$>
# ... directives here ...
</Directory>
<Directory> と
.htaccess の適用が終わるまで考慮されません。
その後で、正規表現は /home/abc/public_html/abc にマッチし、
対応する <Directory> が適用されます。<Directory /> へのアクセスは
Allow from All になっていることに注意してください。
これは、URL からマップされたどのファイルでも Apache は送るということです。
これは以下のようにして変更することが推奨されています。
<Directory />
Order Deny,Allow
Deny from All
</Directory>
<Directory>
ディレクティブは入れ子にすることができず、
<Limit> や <LimitExcept> セクションの中にも
記述できません。参照
<DirectoryMatch> ディレクティブ
説明: 正規表現にマッチするファイルシステムのディレクトリと
サブディレクトリとのみに適用されるディレクティブを囲む 構文: <DirectoryMatch regex>
... </DirectoryMatch>コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core <Directory>
ディレクティブと同様に、<DirectoryMatch>
と </DirectoryMatch> は指定されたディレクトリと
そのサブディレクトリにのみ適用されるディレクティブ群を囲います。
しかし、このディレクティブは引数として正規表現をとります。例えば:
<DirectoryMatch "^/www/.*/[0-9]{3}">
参照
<Directory> と正規表現の指定が
適用される順番については <Directory>DocumentRoot ディレクティブ
説明: ウェブから見えるメインのドキュメントツリーになる
ディレクトリ 構文: DocumentRoot directory-pathデフォルト: DocumentRoot /usr/local/apache/htdocsコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core httpd がファイルを提供するディレクトリを設定します。
Alias のようなディレクティブにマッチしない場合には、
ドキュメントの (訳注:ファイルシステム上の) パスを生成するために、
リクエストされた URL のパス部分をドキュメントルートに付与します。
例:
DocumentRoot /usr/web
http://www.my.host.com/index.html へのアクセスがあれば
/usr/web/index.html が返されます。DocumentRoot は最後のスラッシュ無しで
指定する必要があります。参照
EnableMMAP ディレクティブ
説明: 配送中にファイルを読み込むためにメモリマッピングを
使うかどうか 構文: EnableMMAP On|Offデフォルト: EnableMMAP Onコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core httpd がメモリマッピングを使うかどうかを制御します。デフォルトでは、
例えば、mod_include を使って SSI ファイルを配送
するときのように、ファイルの途中のデータをアクセスする必要があるときには
Apache は OS がサポートしていればファイルをメモリにマップします。
httpd の
性能が落ちるものがあります。DocumentRoot
では、httpd がメモリマップしている間にファイルが削除されたり
短くなったりしたときに起こるセグメンテーションフォールトのために
httpd がクラッシュする可能性があります。
EnableMMAP Off
<Directory "/path-to-nfs-files">
EnableMMAP Off
</Directory>
EnableSendfile ディレクティブ
説明: ファイルのクライアントへの配送時にカーネルの sendfile サポートを
使うかどうか 構文: EnableSendfile On|Offデフォルト: EnableSendfile Onコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core 互換性: バージョン 2.0.44 以降で使用可能 httpd がカーネルの
sendfile サポートを使うかどうかを制御します。デフォルトでは、
例えば静的なファイルの配送のように、リクエストの処理にファイルの
途中のデータのアクセスを必要としないときには、Apache は OS が
サポートしていればファイルを読み込むことなく sendfile を使って
ファイルの内容を送ります。
DocumentRoot
(例えば NFS や SMB)
では、カーネルは自身のキャッシュを使ってネットワークからのファイルを
送ることができないことがあります。
EnableSendfile Off
<Directory "/path-to-nfs-files">
EnableSendfile Off
</Directory>
ErrorDocument ディレクティブ
説明: エラーが発生したときにサーバがクライアントに送るもの 構文: ErrorDocument error-code documentコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core 互換性: Apache 2.0 ではテキストをクウォートする構文が以前のバージョンから
変わっています。
ErrorDocumentディレクティブにより、
HTTP のレスポンスコードと、メッセージか URL を指定することで設定します。
Apache が問題もしくはエラーに関する追加情報を提供することがあります。
もしくは、ブラウザに表示されるメッセージを指定できます。
例:
ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today"
default を使って Apache に
ハードコードされている簡単なメッセージを指定することができます。
通常は必要ではありませんが、default を使うと
既存の ErrorDocument ディレクティブの設定を
継承するところで、Apache のハードコードされた簡単なメッセージに
戻すことができます。
ErrorDocument 404 /cgi-bin/bad_urls.pl
<Directory /web/docs>
ErrorDocument 404 default
</Directory>
http と付与した方法) を
ErrorDocument に指定するとき、
たとえ文書が同じサーバにあろうとも、ドキュメントがどこにあるかを通知するために、
Apache はリダイレクトをクライアントに送出するということに、注意してください。
これにはいろいろと関連して起こる問題があります。
中でも最も重要なのは、クライアントは元々のエラーステータスコードを受け取らず、
代わりにリダイレクトのステータスコードを受け取るということです。
これにより、ステータスコードを使って URL が有効であるかどうかを決定しようとする
ウェブロボットやその他クライアントを、混乱させるかもしれません。
さらに、ErrorDocument 401 にリモートの URL を指定すると、
クライアントは 401 というステータスコードを受け取らないため、
パスワードをユーザーに入力要求しなければならないことがわかりません。
従って、ErrorDocument 401 というディレクティブを使う場合は、
必ずローカルな文書を参照しなければなりません。参照
ErrorLog ディレクティブ
説明: サーバがエラーをログ収集する場所 構文: ErrorLog file-path|syslog[:facility]デフォルト: ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core ErrorLog ディレクティブは、
サーバに生じたさまざまなエラーを
記録する為のファイルの名前を設定します。
file-path が絶対パスでないときは、ServerRoot からの相対パスとみなされます。例
ErrorLog /var/log/httpd/error_log
例
ErrorLog "|/usr/local/bin/httpd_errors"
syslog と指定することによって、
システムがサポートしていれば syslogd(8) を利用したロギングが有効になります。
デフォルトでは、local7 ファシリティとなりますが、
syslog:facility といった形で記述することにより、
通常 syslog(1) のドキュメントで説明されているファシリティの一つを使うように
することができます。例
ErrorLog syslog:user
注
参照
FileETag ディレクティブ
説明: ETag HTTP 応答ヘッダを作成するために使用される
ファイルの属性 構文: FileETag component ...デフォルト: FileETag INode MTime Sizeコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core FileETag ディレクティブは
ドキュメントがファイルに基づいたものであるときに、
ETag (エンティティタグ) 応答ヘッダフィールドを作成するときに使用する
ファイルの属性を設定します。 (ETag の値はネットワークの帯域を節約するための
キャッシュの管理で使われます。) Apache 1.3.22 以前では、ETag の値は
常にファイルの inode, サイズ、最終修正時刻 (mtime) から作成
されていました。FileETag ディレクティブにより、これらのどれを使うかを
選ぶことができます。認識されるキーワードは:
と等価です。FileETag INode MTime SizeETag フィールドを
応答に付加しませんINode, MTime, Size キーワードには
+ や - を前に付けて
指定することもできます。この場合は、より広い範囲から継承された
デフォルトの設定に変更を加えるようになります。そのような接頭辞の
無いキーワードを指定すると、即座に継承した設定を無効にします。FileETag INode MTime Size があり、
サブディレクトリの設定に FileETag -INode があるときは、
そのサブディレクトリの設定は (設定が上書きされなければサブディレクトリの
サブディレクトリにも継承されます) FileETag MTime Size
と同じになります。<Files> ディレクティブ
説明: マッチするファイル名に適用されるディレクティブを囲む 構文: <Files filename> ... </Files>コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core <Files> ディレクティブは、
その中にあるディレクティブの適用範囲をファイル名で制限します。
<Directory> ディレクティブや <Location> ディレクティブと
同じような機能を持ちます。
これは、</Files> ディレクティブと対に
なっていなければなりません。
このセクション中のディレクティブは、ベース名 (ファイル名の最後の部分)
が指定されたファイル名にマッチするすべてのオブジェクトに適用されます。
<Files> セクションは
<Directory> セクションと
.htaccess が読み込まれた後、
<Location> セクションよりは先に
設定ファイルに現れた順に適用されます。
<Files> は、
<Directory> セクション内に
ネストさせることができ、
ファイルシステムの一部にのみ限定して適用させることができます。? は一つの文字、* は任意の文字列にマッチします。
~ という文字を付加することで拡張正規表現を使うこともできます。
例えば、
<Files ~ "\.(gif|jpe?g|png)$">
<FilesMatch> を使う方が
推奨されています。<Directory> と <Location> セクションとは異なり、
<Files>
は .htaccess ファイル内で利用することができます。
これにより、ユーザがファイル毎にアクセスの制御を行なうことができるように
なっています。参照
<FilesMatch> ディレクティブ
説明: 正規表現にマッチするファイル名に適用される
ディレクティブを囲む 構文: <FilesMatch regex> ... </FilesMatch>コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core <FilesMatch> ディレクティブは、
<Files>
ディレクティブ同様にその中にあるディレクティブの適用範囲をファイル名で制限します。ただし、
このディレクティブには正規表現を指定します。
例えば:
<FilesMatch "\.(gif|jpe?g|png)$">
参照
ForceType ディレクティブ
説明: すべてのマッチするファイルが指定の MIME コンテントタイプで
送られるようにする 構文: ForceType MIME-type|Noneコンテキスト: ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core 互換性: Apache 2.0 で core に移動 .htaccess や <Directory> セクション、
<Location> セクション、
<Files> セクションに
書かれた場合、このディレクティブはそこにあるすべてのファイルが
MIME-type
で指定されたコンテントタイプとして扱われるようにします。たとえば、
GIF ファイルばかりのディレクトリがあって、すべてのファイルを .gif
で終わらせたくはないときに、以下のものを使用します:
ForceType image/gif
DefaultType と違って
このディレクティブはメディアタイプを決めることができるかもしれない
ファイルの拡張子も含め、すべての MIME タイプの関連付けを
上書きすることに注意してください。None という値を使うことで ForceType の
設定を無効にできます:
# force all files to be image/gif:
<Location /images>
ForceType image/gif
</Location>
# but normal mime-type associations here:
<Location /images/mixed>
ForceType None
</Location>
HostnameLookups ディレクティブ
説明: クライアントの IP アドレスの DNS ルックアップを
有効にする 構文: HostnameLookups On|Off|Doubleデフォルト: HostnameLookups Offコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ ステータス: Core モジュール: core REMOTE_HOST 変数として渡します)。
Doubleを指定した場合、2 重の逆引きを行ないます。
つまり、逆引きの後に、その結果に対して正引きを行ないます。正引きの
結果の IP アドレスの中にオリジナルのアドレスと一致するものがなければ
なりません。("tcpwrappers" の用語では PARANOID と呼ばれています。)mod_access でホスト名によるアクセス
制御を行なう場合には、
設定の如何によらず 2 重の逆引きが実行されます。
これは、セキュリティを保つために必要です。
HostnameLookups Double を設定しない限り、
他の部分はこの 2 重逆引きの結果を使うことはできません。
例えば、HostnameLookups On と設定してある状態で、
ホスト名によるアクセス制限を行なったオブジェクトへの
リクエストを受けたとすると、2 重の逆引きが成功するか否かによらず、
REMOTE_HOST には通常の逆引き結果が渡されます。Off になっています。
ルックアップによる余計な遅延がなくなるため、
エンドユーザにとっても良いでしょう。
DNS のルックアップには、かなりの時間が必要となる場合が多く、
負荷の高いサイトではこのディレクティブは Off にすべきです。
なお、/support ディレクトリに含まれ、デフォルトでは
インストールディレクトリの bin サブディレクトリに
インストールされる logresolve ユーティリティにより、
Apache の動作とは別に、ログに残されている IP アドレスからホスト名を
ルックアップすることが可能です。IdentityCheck ディレクティブ
説明: リモートユーザの RFC1413 によるアイデンティティのロギングを
有効にする 構文: IdentityCheck On|Offデフォルト: IdentityCheck Offコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ ステータス: Core モジュール: core <IfDefine> ディレクティブ
説明: 起動時にテストが真であるときのみに処理されるディレクティブを
囲む 構文: <IfDefine [!]parameter-name> ...
</IfDefine>コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core <IfDefine test>...</IfDefine>
セクションは、
ディレクティブを条件付きで指定するために利用します。
<IfDefine> セクションに
含まれるディレクティブは、testが
定義されているときのみ処理されます。
もし test が定義されていなければ、
開始と終了の指定の間のディレクティブは無視されます。<IfDefine> セクションディレクティブに
指定する test は、
次の二つの形式のうちの一つをとります:
!parameter-namehttpd のコマンドラインに
-Dparameter- という形で指定すると定義されます。 <IfDefine> セクションは
入れ子にすることができ、複数のパラメータによるテストをするために使用できます。
例:
httpd -DReverseProxy ...
# httpd.conf
<IfDefine ReverseProxy>
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/libproxy.so
</IfDefine>
<IfModule> ディレクティブ
説明: モジュールの存在するかしないかに応じて処理される
ディレクティブを囲む 構文: <IfModule [!]module-name> ...
</IfModule>コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core <IfModule test>...</IfModule>
セクションは、モジュールが存在するときに処理されるディレクティブを
指定するために利用します。
<IfModule> セクションに
含まれるディレクティブは、test
で指定するモジュールが組み込まれているときのみ処理されます。
もし test が組み込まれていなければ、開始と終了の間のディレクティブ
は無視されます。<IfModule> セクションディレクティブに
指定する test は、
次の二つの形式のうちの一つをとります。
LoadModule を利用して
動的に読み込んだものの両方)、
開始と終了の間のディレクティブが処理されます。
後者の場合は逆で、module name が組み込まれていない
場合に処理されます。mod_rewrite.c です。
モジュールが複数のソースファイルから構成されている場合は、文字列
STANDARD20_MODULE_STUFF があるファイルの名前を
使ってください。<IfModule> セクションは
入れ子にすることが可能であり、
複数のモジュールのテストを行なうために使用できます。特定のモジュールの存在に関わらず動作する
設定ファイルの原本が必要なときにのみこのセクションを使用してください。
通常の動作では、ディレクティブを
<IfModule> セクションの中に
入れる必要はありません。Include ディレクティブ
説明: サーバ設定ファイル中から他の設定ファイルを取り込む 構文: Include file-path|directory-pathコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ ステータス: Core モジュール: core 互換性: ワイルドカードによるマッチは 2.0.41 以降で使用可能 fnmatch) のワイルドカード文字を使うことができます。
さらに、Include にディレクトリを指定した場合は、
ディレクトリとそのサブディレクトリ内の全てのファイルを
アルファベット順に読み込んで、設定ファイルとして処理します。
しかし、ディレクトリ全体を読み込むのはお勧めできません。
ふとしたことから httpd が読み込みに失敗するような
一時ファイルをディレクトリに残してしまうようなことがよくあるからです。ServerRoot ディレクトリからの
相対パスか、のどちらかです。
Include /usr/local/apache2/conf/ssl.conf
Include /usr/local/apache2/conf/vhosts/*.conf
ServerRoot からの相対パスの場合は:
Include conf/ssl.conf
Include conf/vhosts/*.conf
apachectl configtest を実行すると、設定をチェックしている時に
読み込まれたファイルのリストが表示されます:
root@host# apachectl configtest
Processing config file: /usr/local/apache2/conf/ssl.conf
Processing config file: /usr/local/apache2/conf/vhosts/vhost1.conf
Processing config file: /usr/local/apache2/conf/vhosts/vhost2.conf
Syntax OK
参照
KeepAlive ディレクティブ
説明: HTTP の持続的な接続を有効にする 構文: KeepAlive On|Offデフォルト: KeepAlive Onコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core KeepAlive On と設定します。参照
KeepAliveTimeout ディレクティブ
説明: 持続的な接続で次のリクエストが来るまでサーバが待つ時間 構文: KeepAliveTimeout secondsデフォルト: KeepAliveTimeout 15コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core Timeout ディレクティブによって
指定されたタイムアウト値が使われます。KeepAliveTimeout を大きな値に設定すると、
負荷の高いサーバにおいてはパフォーマンスの問題を引き起こす場合があります。
タイムアウトが長ければ長いほど、より多くのサーバプロセスが
活発でないクライアントからの接続の終了を待ち続けることになります。<Limit> ディレクティブ
説明: 囲いの中にあるアクセス制御の適用を特定の HTTP メソッドのみに
制限する 構文: <Limit method [method] ... > ...
</Limit>コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core <Limit> セクション内に
書くべきではありません。 <Limit> ディレクティブの
目的は、アクセス制御の範囲を
指定された HTTP メソッドに限定するためです。
それ以外のメソッドは、<Limit> で囲われたアクセス制御の
影響を受けません。
以下の例は、POST, PUT, DELETE のメソッドに対してのみアクセスの制御を行ない、
それ以外のメソッドについては制限しません:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
GET,
POST, PUT, DELETE,
CONNECT, OPTIONS,
PATCH, PROPFIND, PROPPATCH,
MKCOL, COPY, MOVE,
LOCK, UNLOCK. メソッド名は
大文字小文字を区別します。 GET を指定した場合には
HEAD リクエストにも制限がかかります。TRACE
メソッドに制限をかけることはできません。アクセス制御が目的の場合は
<Limit>
セクションの代わりに <LimitExcept> セクションを使用した方が良いでしょう。
<LimitExcept>
セクションでは不特定のメソッドに対しても防御できるからです。<LimitExcept> ディレクティブ
説明: 指定されたもの以外の HTTP メソッドにアクセス制御を
制限する 構文: <LimitExcept method [method] ... > ...
</LimitExcept>コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core <LimitExcept> と
</LimitExcept> は、引数に
含まれていない
HTTP のアクセスメソッドに適用するためのアクセス制御
ディレクティブを括るために利用します。
つまり、<Limit> セクションの反対の動作をし、
標準のメソッドと標準外や未認識のメソッドの場合の両方を設定できます。
<Limit> のドキュメントも
併せて参照してください。
<LimitExcept POST GET>
Require valid-user
</LimitExcept>
LimitInternalRecursion ディレクティブ
説明: 内部リダイレクトと入れ子になったサブリクエストの最大数を決定する 構文: LimitInternalRecursion number [number]デフォルト: LimitInternalRecursion 10コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core 互換性: Apache 2.0.47 以降で使用可能 Action ディレクティブを
使っているときに起こります。Action ディレクティブは
元々のリクエストを CGI スクリプトに内部リダイレクトを行ないます。
サブリクエストはいくつかの URI に対して、リクエストされたときに
何が起こるかを調べるための Apache の機構です。例えば、mod_dir
は DirectoryIndex ディレクティブ
がリストするファイルを調べるためにサブリクエストを使います。LimitInternalRecursion は内部リダイレクトや
サブリクエストが無限ループに陥ったときのサーバクラッシュを防ぎます。
普通、そのようなループは設定に失敗したときに発生します。例
LimitInternalRecursion 5
LimitRequestBody ディレクティブ
説明: クライアントから送られる HTTP リクエストのボディの
総量を制限する 構文: LimitRequestBody bytesデフォルト: LimitRequestBody 0コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core LimitRequestBody ディレクティブは、
ディレクティブが書かれたコンテキスト
(サーバ全体、ディレクトリ、ファイル、ロケーション) 内で
許容する HTTP リクエストメッセージボディのサイズに制限をかけることができます。
クライアントのリクエストがその制限値を越えていれば、
サーバはリクエストを処理せずにエラーを返します。
普通のリクエストメッセージボディのサイズは、リソースの種類や
許可されているメソッドによって大きく変わります。
CGI スクリプトは、よく情報を受信するために
メッセージボディを使います。
PUT メソッドの実装は、このディレクティブの値として
少なくともあるリソースに対してサーバが受け付けようとする
表現の大きさほどの値を必要とします。
LimitRequestBody 102400
LimitRequestFields ディレクティブ
説明: クライアントからの HTTP リクエストのヘッダフィールドの数を
制限する 構文: LimitRequestFields numberデフォルト: LimitRequestFields 100コンテキスト: サーバ設定ファイル ステータス: Core モジュール: core DEFAULT_LIMIT_REQUEST_FIELDS
によりコンパイル時に定義されます (配布時には 100 と指定されています)。
LimitRequestFields 50
LimitRequestFieldSize ディレクティブ
説明: クライアントからの HTTP リクエストのヘッダの
サイズを制限する 構文: LimitRequestFieldsize bytesデフォルト: LimitRequestFieldsize 8190コンテキスト: サーバ設定ファイル ステータス: Core モジュール: core DEFAULT_LIMIT_REQUEST_FIELDSIZE (配布時には 8192 と指定)
で指定された値までの数字で指定します。LimitRequestFieldSize ディレクティブは、
サーバのコンパイル時に指定したインプットバッファ容量以下に
HTTP リクエストヘッダの許容されるサイズを制限することができます。
サーバは、このディレクティブの値として、
通常のクライアントリクエストから送られた個々のヘッダフィールドに
十分足る大きさを必要とします。
普通のリクエストヘッダのサイズは、個々のクライアントにより大きく変わり、
詳細なコンテントネゴシエーションをするためのブラウザの設定までにも
影響されることがあります。
LimitRequestFieldSize 4094
通常はデフォルトから変更する必要はありません。
LimitRequestLine ディレクティブ
説明: クライアントからの HTTP リクエスト行のサイズを制限する 構文: LimitRequestLine bytesデフォルト: LimitRequestLine 8190コンテキスト: サーバ設定ファイル ステータス: Core モジュール: core DEFAULT_LIMIT_REQUEST_LINE (配布時には 8190 と指定)
で指定された値までの数字で指定します。LimitRequestLine ディレクティブにより、サーバ管理者は
サーバのコンパイル時に指定したインプットバッファ容量以下に
クライアントからの HTTP リクエスト行のサイズの制限を行なうことができます。
リクエスト行は、HTTPメソッド、URI、プロトコルバージョンから成っており、
LimitRequestLine はサーバへのリクエストに対して
許容するリクエスト URI の長さを制限することになります。
サーバは、GET リクエストのクエリ部分も含めて、リソースの名前が入るに足る
大きさを必要とします。
LimitRequestLine 4094
通常はデフォルトから変更する必要はありません。
LimitXMLRequestBody ディレクティブ
説明: XML 形式のリクエストのボディのサイズを制限する 構文: LimitXMLRequestBody bytesデフォルト: LimitXMLRequestBody 1000000コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core 0 を指定するとチェックを無効にします。
LimitXMLRequestBody 0
<Location> ディレクティブ
説明: 囲んだディレクティブをマッチする URL のみに適用 構文: <Location
URL-path|URL> ... </Location>コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core <Location> ディレクティブは、
URL により中に書かれたディレクティブの適用範囲を制限します。
<Directory>
ディレクティブと似ていて、
</Location> ディレクティブで終了する
サブセクションを開始します。
<Location> セクションは、
<Directory> セクションと
.htaccess の読み込みの後、
<Files> セクションを
適用した後に、設定ファイルに現れた順に処理されます。<Location> セクションは
完全にファイルシステムと関連せずに動作します。このことから導かれる
結果にはいつくか注意する点があります。最も重要なものは、
ファイルシステムの位置へのアクセス制御に <Location> ディレクティブを使うべきではない
ということです。複数の URL がファイルシステムの同じ位置にマップされる
可能がありますので、そのようなアクセス制御は回避されてしまう可能性が
あります。いつ
<Location> を使うか<Location> ディレクティブは
ファイルシステム外のコンテンツにディレクティブを適用するときに
使用してください。ファイルシステムに存在するコンテンツに対しては、
<Directory> と <Files> を使ってください。
例外は、<Location /> で、これはサーバ全体に対して
設定を適用する簡単な方法です。/path/ という、
接頭辞 http://servername を含まない形でマッチします。
プロキシリクエストの場合には、scheme://servername/path
という接頭辞を含む形でマッチし、接頭辞を含めて指定する必要があります。? は任意の一文字、* は任意の文字列にマッチします。 ~ という文字を追加することで、拡張正規表現を
利用することもできます。
例えば:
<Location ~ "/(extra|special)/data">
/extra/data か /special/data という文字列が
含まれている場合にマッチします。
<LocationMatch> ディレクティブは
<Location> の正規表現
版とまったく同じ動作をします。<Location> 機能は、SetHandler ディレクティブと
組合わせて利用すると特に便利です。
例えば、foo.com のブラウザからのみステータスの参照を有効にしたければ、
次のようにすれば良いでしょう。
<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>
/ (スラッシュ) に関する注
/home///foo は
/home/foo と同じいったように)
URL においては必ずしもそうなるわけではありません。
<LocationMatch>
ディレクティブや正規表現を利用した
<Location> ディレクティブで、
複数のスラッシュにマッチさせたいときには、、明示的に記述する
必要があります。<LocationMatch ^/abc> は、
/abc というリクエスト URL にマッチしますが、
//abc というリクエスト URL にはマッチしません。
(正規表現でない) <Location>
ディレクティブは、
proxy リクエストに対して利用する際には同様の振る舞いをしますが、
(正規表現でない) <Location> を proxy
でないリクエストに対して利用する際には、
一つのスラッシュで複数のスラッシュにマッチします。
例えば、<Location /abc/def> と指定し、
/abc//def というリクエストがあれば、
マッチすることになります。参照
<LocationMatch> ディレクティブ
説明: 囲んだディレクティブを正規表現にマッチする URL のみに
適用 構文: <LocationMatch
regex> ... </LocationMatch>コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core <LocationMatch> ディレクティブは、
<Location> と同じ様に
URL により中に書かれたディレクティブの適用範囲を制限します。
但し、引数は普通の文字列ではなく、正規表現となります。例えば、
<LocationMatch "/(extra|special)/data">
/extra/data か /special/data
という文字列が含まれている場合にマッチします。参照
LogLevel ディレクティブ
説明: ErrorLog の冗長性を制御する 構文: LogLevel levelデフォルト: LogLevel warnコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core LogLevel は、エラーログ (ErrorLog ディレクティブを
見てください) へ記録するメッセージの冗長性を調整します。
以下の level を指定でき、順に重要度が下がっていきます。
レベル
説明
例
emerg 緊急 - システムが利用できない
Child cannot open lock file. Exiting
(子プロセスがロックファイルを開けないため終了した)
alert 直ちに対処が必要
getpwuid: couldn't determine user name from uid
(getpwuid: UID からユーザ名を特定できなかった)
crit 致命的な状態
socket: Failed to get a socket, exiting child
(socket: ソケットが得られないため、子プロセスを終了させた)
error エラー
Premature end of script headers
(スクリプトのヘッダが足りないままで終わった)
warn 警告
child process 1234 did not exit, sending another SIGHUP
(子プロセス 1234 が終了しなかった。もう一度 SIGHUP を送る)
notice 普通だが、重要な情報
httpd: caught SIGBUS, attempting to dump core in ...
(httpd: SIGBUS シグナルを受け、... へコアダンプをした)
info 追加情報
"Server seems busy, (you may need to increase
StartServers, or Min/MaxSpareServers)..." (「サーバは負荷が高い、
(StartServers や Min/MaxSpareServers の値を増やす必要があるかも)」)
debug デバッグメッセージ
"Opening config file ..." (設定ファイルを開いている...)
LogLevel info に指定すると、
notice と warn も報告されます。crit 以上のレベルを指定することが推奨されます。
LogLevel notice
注
notice
レベルのメッセージは抑制されず、すべてログに出力されます。
しかし syslog を使用している場合は、
これは当てはまりません。MaxKeepAliveRequests ディレクティブ
説明: 持続的な接続上で許可されるリクエストの数 構文: MaxKeepAliveRequests numberデフォルト: MaxKeepAliveRequests 100コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core MaxKeepAliveRequests ディレクティブは、
KeepAlive が有効な場合に、
一回の接続で受け付け可能なリクエストの数を制限します。
0 に設定していれば、受け付けるリクエストは無制限になります。
この設定は、サーバ性能を向上させるために、大きな数値を指定すること勧めます。
MaxKeepAliveRequests 500
NameVirtualHost ディレクティブ
説明: 名前ベースのバーチャルホストのための IP アドレスを指定 構文: NameVirtualHost addr[:port]コンテキスト: サーバ設定ファイル ステータス: Core モジュール: core NameVirtualHost ディレクティブは、
名前ベースのバーチャルホストの設定を行ないたい場合に
必要となるものです。
NameVirtualHost 111.22.33.44
NameVirtualHost ディレクティブは、
名前ベースのバーチャルホストを
利用してリクエストを受け付ける IP アドレスを指定します。
これは、普通は名前ベースのバーチャルホストアドレスです。
ただし、ファイアーウォールや他のプロキシがリクエストを受け付け、
違う IP アドレスのサーバにフォワードするという場合は、
リクエストを提供したいマシン上の物理インターフェースの
IP アドレスを指定する必要があります。
複数のアドレスで複数の名前ベースのバーチャルホストを指定する場合は
各アドレスに対してディレクティブを書いてください。中
_default_ サーバも、
NameVirtualHost で指定した IP アドレスへのリクエスト
を処理することはありません (なぜか
NameVirtualHost を
指定したけどそのアドレスに VirtualHost を定義しなかった場合を除く)。
NameVirtualHost 111.22.33.44:8080
NameVirtualHost [2001:db8::a00:20ff:fea7:ccea]:8080
* を使います。
NameVirtualHost *
<VirtualHost> ディレクティブの引数<VirtualHost> ディレクティブの引数は NameVirtualHost ディレクティブの引数に正確に
合っている必要があることに注意してください。
NameVirtualHost 1.2.3.4
<VirtualHost 1.2.3.4>
# ...
</VirtualHost>
参照
Options ディレクティブ
説明: ディレクトリに対して使用可能な機能を設定する 構文: Options
[+|-]option [[+|-]option] ...デフォルト: Options Allコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Options ステータス: Core モジュール: core Options ディレクティブは、特定のディレクトリに対して
どの機能が使用可能かを制御します。Noneに指定すると、
特別な機能は全て無効になります。
また、以下の示す 1 個以上のものを指定できます。
AllMultiViews を除いた全ての機能が有効となります。
これがデフォルトです。ExecCGImod_cgi による CGI スクリプトの実行を許可します。FollowSymLinks<Directory> セクションに
マッチさせるための
パス名は変更されません。<Location> 内に
このオプションを指定しても無視されることに
注意してください。Includesmod_include が提供する SSI を有効にします。IncludesNOEXEC#exec コマンド と #exec CGI は無効になります。
ただし、#include virtual により、ScriptAlias されたディレクトリで
CGI を実行することは可能です。IndexesDirectoryIndex で指定したファイル (例えば、index.html) が
ディレクトリ内に無ければ、mod_autoindex が
ディレクトリ内の一覧を整形して返します。MultiViewsmod_negotiation による
コンテントネゴシエーション
された "MultiViews" を許可します。SymLinksIfOwnerMatch注
<Location> 内にこのオプションを
指定しても無視されます。Options が
適用可能な場合、
最も近いもの一つのみが適用され、他のものは無視されます。
複数の指定がマージされるわけではありません。(セクションのマージ方法を参照してください。)
しかし、すべての Options ディレクティブが + や - 付きで
指定された場合はオプションの値はマージされます。
+ を頭につければ現在の設定に加えられ、
- を付ければ現在の設定から削除されます。+ や - を利用しない場合は:
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options Includes
</Directory>
/web/docs/spec というディレクトリには、
Includes だけが適用されます。
しかし、2 番目の Options で + や - を利用してみると:
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>
/web/docs/spec というディレクトリには、 FollowSymLinks と
Includes が適用されます。注
-IncludesNOEXEC もしくは
-Includes を指定すると、
前の設定がどのようになっていようとも SSI は無効となります。All に
なります。Require ディレクティブ
説明: どの認証済みユーザがリソースをアクセスできるかを選択する 構文: Require entity-name [entity-name] ...コンテキスト: ディレクトリ, .htaccess 上書き: AuthConfig ステータス: Core モジュール: core
Require user userid [userid] ...Require group group-name [group-name] ...Require valid-userRequire は、正しく動作するためには AuthName 及び AuthType ディレクティブや、
(ユーザとグループを指定するために) AuthUserFile 及び AuthGroupFile
といったディレクティブと共に
指定する必要があります。
例えば:
AuthType Basic
AuthName "Restricted Directory"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin
<Limit> セクション内に
Require を
指定してください。参照
RLimitCPU ディレクティブ
説明: Apache の子プロセスから起動されたプロセスの CPU 消費量を
制限する 構文: RLimitCPU seconds|max [seconds|max]デフォルト: 未設定。オペレーティングシステムのデフォルトを使用コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core max のどちらかを指定することができます。
最大のリソースリミットを上げるためには、サーバを
root で実行するか起動されなければいけません。参照
RLimitMEM ディレクティブ
説明: Apache の子プロセスから起動されたプロセスのメモリ消費量を
制限する 構文: RLimitMEM bytes|max [bytes|max]デフォルト: 未設定。オペレーティングシステムのデフォルトを使用コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core max のどちらかを指定することができます。
最大のリソースリミットを上げるためには、サーバを
root で実行するか起動されなければいけません。参照
RLimitNPROC ディレクティブ
説明: Apache の子プロセスから起動されたプロセスが起動するプロセスの
数を制限する 構文: RLimitNPROC number|max [number|max]デフォルト: 未設定。オペレーティングシステムのデフォルトを使用コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core max のどちらかを指定することができます。
最大のリソースリミットを上げるためには、サーバを
root で実行するか起動されなければいけません。注
error_log 中の
cannot fork というメッセージにより
確認することができます。参照
Satisfy ディレクティブ
説明: ホストレベルのアクセス制御とユーザ認証との相互作用を指定 構文: Satisfy Any|Allデフォルト: Satisfy Allコンテキスト: ディレクトリ, .htaccess 上書き: AuthConfig ステータス: Core モジュール: core 互換性: バージョン 2.0.51 以降では <Limit> ディレクティブと <LimitExcept> ディレクティブの影響を受ける
Allow と
Require の両方が使われているときの
アクセスポリシーを設定します。パラメータは All か Any
です。このディレクティブはある場所へのアクセスがユーザ名/パスワード
とクライアントのホストのアドレスで制限されているときにのみ
役立ちます。デフォルトの動作 (All) はクライアントがアドレスによる
アクセス制限を満たし、かつ正しいユーザ名とパスワードを入力することを
要求します。Any では、クライアントはホストの制限を満たすか、
正しいユーザ名とパスワードの入力をするかをすればアクセスを許可されます。
これは、ある場所をパスワードで保護するけれど、特定のアドレスからの
クライアントにはパスワードの入力を要求せずにアクセスを許可する、
というようなときに使用できます。
Require valid-user
Allow from 192.168.1
Satisfy Any
<Limit> セクションと
<LimitExcept> セクションを使用することで
Satisfy ディレクティブが
適用されるメソッドを制限することが
できるようになりました。参照
ScriptInterpreterSource ディレクティブ
説明: CGI スクリプトのインタープリタの位置を調べるための手法 構文: ScriptInterpreterSource Registry|Registry-Strict|Scriptデフォルト: ScriptInterpreterSource Scriptコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core 互換性: Win32 のみ。
オプション Registry-Strict は Apache 2.0 以降で使用可能Script です。これはスクリプトの
shebang 行 (最初の行で #! から始まるもの)
に指されているインタープリタを使用します。Win32 ではその行は
以下の様になります。
#!C:/Perl/bin/perl.exe
PATH にある場合は単に:
#!perl
ScriptInterpreterSource Registry を指定すると、
スクリプトファイルの拡張子 (例えば、.pl) を
キーとして、Windows のレジストリツリー HKEY_CLASSES_ROOT
を検索するようになります。レジストリのサブキー
Shell\ExecCGI\Command か、それが存在しない場合は
Shell\Open\Command がスクリプトファイルを開くために
使われます。レジストリキーが見つからないときは、Apache は Script
オプションが指定されたときの動作に戻ります。セキュリティ
ScriptInterpreterSource Registry を ScriptAlias されたディレクトリで使うときは
注意してください。Apache はそのディレクトリ中のすべてのファイルを
実行しようとします。Registry という設定は通常は実行されない
ファイルに対して望ましくないプログラムの実行が発生する可能性があります。
例えば、ほとんどの Windows システムで、
.htm ファイルのデフォルトの「開く」コマンドは
Microsoft Internet Explorer を実行しますので、スクリプトに指定された
ディレクトリにある .htm ファイルへのリクエストはサーバの
バックグラウンドでブラウザを実行することになります。これは、一分内くらいで
システムをクラッシュさるための良い方法です。Registry-Strict は
Registry と同じことを行ないますが、サブキー
Shell\ExecCGI\Command のみを使います。
ExecCGI キーは普通に使われるキーではありません。Windows
レジストリに手動で設定する必要がありますので、システムでの偶発的なプログラムの
実行を防ぐことができます。ServerAdmin ディレクティブ
説明: サーバがクライアントに送るエラーメッセージに含める電子メールの
アドレス 構文: ServerAdmin email-addressコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core ServerAdmin は、クライアントに返すさまざまな
エラーメッセージ中に記述する、
電子メールアドレスを設定します。
ServerAdmin www-admin@foo.example.com
ServerAlias ディレクティブ
説明: リクエストを名前ベースのバーチャルホストにマッチさせているときに
使用されるホストの別名 構文: ServerAlias hostname [hostname] ...コンテキスト: バーチャルホスト ステータス: Core モジュール: core ServerAlias ディレクティブは、ネームベースのバーチャルホストにおいて
使用するホストの別名を指定します。
<VirtualHost *>
ServerName server.domain.com
ServerAlias server server2.domain.com server2
# ...
</VirtualHost>
参照
ServerName ディレクティブ
説明: サーバが自分自身を示すときに使うホスト名とポート 構文: ServerName fully-qualified-domain-name[:port]コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Core モジュール: core 互換性: このディレクティブはバージョン 2.0 ではバージョン 1.3 の
Port ディレクティブの機能も含みます。ServerName ディレクティブは、
サーバが自分自身を示すホスト名とポートを設定します。
これは、リダイレクトする URL を生成する際に利用されます。
例えば、ウェブサーバを動かしているマシンは simple.example.com
で、DNS のエイリアス www.example.com もあるときに、
ウェブサーバが後者として認識されて欲しいときは、以下のようにディレクティブを
使います。
ServerName www.example.com:80
ServerName が指定されていないときは、
サーバは IP アドレスから逆引きを行なうことでホスト名を知ろうとします。
ServerName にポートが指定されていないときは、
サーバはリクエストが来ている
ポートを使います。最高の信頼性と確実性をもたらすためには、
ServerName を使ってホスト名とポートを明示的に
指定してください。<VirtualHost> セクション内の
ServerName はこのバーチャルホストにマッチするために
何がリクエストの Host: ヘッダに現れる必要があるのかを指定します。mod_dir モジュールによるものなど)
が指定されたポートを使うか、クライアントのリクエストのポート番号を使うかを
決定する設定は UseCanonicalName
ディレクティブを参照してください。参照
ServerPath ディレクティブ
説明: 非互換のブラウザが名前ベースのバーチャルホストにアクセスしたときの
ための互換用 URL パス名 構文: ServerPath URL-pathコンテキスト: バーチャルホスト ステータス: Core モジュール: core ServerPath ディレクティブは、ネームベースのバーチャルホストにおいて利用する
互換用 URL パス名を設定します。参照
ServerRoot ディレクティブ
説明: インストールされたサーバのベースディレクトリ 構文: ServerRoot directory-pathデフォルト: ServerRoot /usr/local/apacheコンテキスト: サーバ設定ファイル ステータス: Core モジュール: core ServerRoot ディレクティブは、
サーバが存在するディレクトリを設定します。
通常、conf/ や logs/ といったサブディレクトリが
存在します。
また、他の設定ファイルにおける相対パスは、このディレクトリからとなります。例
ServerRoot /home/httpd
参照
httpd の -d
オプションServerRoot の権限を適切に設定する方法はセキュリティのこつServerSignature ディレクティブ
説明: サーバが生成するドキュメントのフッタを設定 構文: ServerSignature On|Off|EMailデフォルト: ServerSignature Offコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Core モジュール: core ServerSignature ディレクティブは、
サーバが生成するドキュメント
(エラーメッセージ、mod_proxy における FTP のディレクトリリスト、
mod_info の出力、等々)
の最下行に付与するフッタの設定を行ないます。
そのようなフッタ行を有効にしたい理由には、
プロキシが複数連なっている場合に、ユーザはどのサーバが返した
エラーメッセージかを知る手段がほとんど無いというものがあります。Off に設定をすると、フッタ行が抑制されます
(そして、Apache-1.2 以前と互換の動作をします)。
On に設定した場合は、単にドキュメントの中に、サーバのバージョン、
稼動中のバーチャルホストの ServerName の書かれた行を追加し、
EMail にした場合はさらに参照されたドキュメントに対する ServerAdmin を指す "mailto:" が追加されます。ServerSignature
ディレクティブにより表示される情報も制御します。参照
ServerTokens ディレクティブ
説明: Server HTTP 応答ヘッダを設定する 構文: ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Fullデフォルト: ServerTokens Fullコンテキスト: サーバ設定ファイル ステータス: Core モジュール: core Server
応答ヘッダ内に、サーバの一般的な OS 種別や、
コンパイルされて組み込まれているモジュールの情報を
含めるかどうかを指定します。
ServerTokens Prod[uctOnly]Server:
Apache といったように送ります。ServerTokens MajorServer:
Apache/2ServerTokens MinorServer:
Apache/2.0ServerTokens Min[imal]Server:
Apache/2.0.41 といったように送ります。ServerTokens OSServer: Apache/2.0.41
(Unix) といったように送ります。ServerTokens Full (もしくは未指定)Server: Apache/2.0.41
(Unix) PHP/4.2.2 MyMod/1.2 といったように送ります。ServerSignature
ディレクティブにより表示される情報も制御します。参照
SetHandler ディレクティブ
説明: マッチするファイルがハンドラで処理されるようにする 構文: SetHandler handler-name|Noneコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core 互換性: Apache 2.0 で core に移動 .htaccess や <Directory>
セクション、<Location>
セクションに書かれた場合、
このディレクティブはそこにあるすべてのファイルが
handler-name で指定されたハンドラで扱われることを強制します。例えば、拡張子に関わらず、
ディレクトリ全体がイメージマップファイルとして解析して欲しい場合には、
以下をそのディレクトリの .htaccess
ファイルに記述します:
SetHandler imap-file
http://servername/status
が指定されたときにサーバが状態報告をするようにしたいときは、以下を
httpd.conf に記述します:
<Location /status>
SetHandler server-status
</Location>
None という値を設定することで、
前の方の SetHandler で定義された設定を無効にすることが
できます。参照
SetInputFilter ディレクティブ
説明: クライアントのリクエストや POST の入力を処理するフィルタを設定する 構文: SetInputFilter filter[;filter...]コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core SetInputFilter ディレクティブはクライアントの
リクエストや POST の入力をサーバが受け取ったときに処理するフィルタを
設定します。これは AddInputFilter
ディレクティブを含め、他の場所で定義されているフィルタの設定に
追加されます。参照
SetOutputFilter ディレクティブ
説明: サーバの応答を処理するフィルタを設定する 構文: SetOutputFilter filter[;filter...]コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Core モジュール: core SetOutputFilter ディレクティブは
サーバの応答をクライアントに送り返される前に処理するフィルタを設定します。
これは AddOutputFilter
ディレクティブを含め、他の場所で定義されているフィルタの設定に
追加されます。/www/data/ ディレクトリのすべての
ファイルを SSI で処理します。
<Directory /www/data/>
SetOutputFilter INCLUDES
</Directory>
参照
TimeOut ディレクティブ
説明: 各イベントについて、リクエストを失敗させるまでにサーバが
待つ時間を設定 構文: TimeOut secondsデフォルト: TimeOut 300コンテキスト: サーバ設定ファイル ステータス: Core モジュール: core TimeOut ディレクティブは、現在のところ
以下の三つの待ち時間についての定義を行います:
UseCanonicalName ディレクティブ
説明: サーバが自分自身の名前とポートを決定する方法を設定する 構文: UseCanonicalName On|Off|Dnsデフォルト: UseCanonicalName Onコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ ステータス: Core モジュール: core UseCanonicalName On を使うと (1.3 より前の
すべてのバージョンでも) Apache は ServerName ディレクティブと Port
ディレクティブを使ってサーバの正式な名前を作成します。
この名前がすべての自己参照 URL で使われ、CGI の SERVER_NAME
と SERVER_PORT にも使われます。UseCanonicalName Off では Apache は
クライアントがホスト名とポートを提供した場合には自己参照 URL を
それらを元に作成します (提供されていない場合は上で定義されているように
正式な名前を使います)。
これらの値は名前ベースの
バーチャルホストを実装するのに使われているのと同じ値で、
同じクライアントから取得できる値です。CGI 変数 SERVER_NAME
と SERVER_PORT もクライアントから与えられた値から
作成されます。www の
ような短い名前でユーザがマシンに接続しているときです。
ユーザが短い名前を入力して、URL が最後のスラッシュ無しのディレクトリ
へのものであるときに、Apache はリクエストを
http://www.domain.com/splat/ へリダイレクトすることに
気付くでしょう。認証をするように設定していると、この場合
ユーザは 2 回認証をしなければならなくなります (www に
対して 1 回、www.domain.com に対してもう一回 --
より詳しい情報は この話題の
FAQ を参照してください)。
しかし、UseCanonicalName が Off になっていると、
Apache は htttp://www/splat/ にリダイレクトします。UseCanonicalName DNS は、
Host: ヘッダを提供しない古いクライアントをサポートした
大規模な IP ベースのバーチャルホスティングで使用されることを
意図しています。このオプションでは、Apache はクライアントが
接続した IP アドレスに DNS の逆引きを行なって自己参照 URL を
作成します。警告
SERVER_NAME に
関する仮定を行なっているときは、このオプションの設定で動作しなく
なるかもしれません。クライアントは実質的にはホスト名にとして
何でも望みの値を指定することができます。CGI が
SERVER_NAME のみを使って自己参照 URL を作成している
場合はどの設定を行なっても大丈夫なはずです。参照
<VirtualHost> ディレクティブ
説明: 特定のホスト名や IP アドレスのみに適用されるディレクティブを
囲む 構文: <VirtualHost
addr[:port] [addr[:port]]
...> ... </VirtualHost>コンテキスト: サーバ設定ファイル ステータス: Core モジュール: core <VirtualHost> 及び
</VirtualHost> は、
特定のバーチャルホストに対してのみ適用されるディレクティブ群を括る
ために使われます。
バーチャルホストコンテキストで許可される全てのディレクティブを指定可能です。
サーバが、指定されたバーチャルホストにあるドキュメントへの
リクエストを受け付けた場合、
<VirtualHost> セクションの中にある
ディレクティブが適用されます。
Addrは、次のものが利用できます:
NameVirtualHost * と共に使われる、
すべての IP アドレスにマッチする文字 *_default_例
<VirtualHost 10.1.2.3>
ServerAdmin webmaster@host.foo.com
DocumentRoot /www/docs/host.foo.com
ServerName host.foo.com
ErrorLog logs/host.foo.com-error_log
TransferLog logs/host.foo.com-access_log
</VirtualHost>
<VirtualHost [2001:db8::a00:20ff:fea7:ccea]>
ServerAdmin webmaster@host.example.com
DocumentRoot /www/docs/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
TransferLog logs/host.example.com-access_log
</VirtualHost>
ifconfig alias コマンドにより
達成できます)。:port といった形式で記述することにより、
マッチさせるポートを変更可能です。
この指定をしない場合には、主サーバ設定における
一番最後に Port で指定されたポートが
デフォルトとなります。
:* を指定することにより、
アドレス上の全てのポートにマッチします。(_default_ のときは
これを使うことが推奨されています。)注意点
<VirtualHost> は Apache が Listen する
IP アドレスには影響を与えません。
Listen を
使って Apache が正しいアドレスを listen するように設定する必要があります。_default_ を指定することができます。その場合は
そのバーチャルホストは他のバーチャルホストで明示的に挙げられていない
すべての IP アドレスにマッチします。_default_ バーチャルホストが無い
場合に IP がバーチャルホストで指定されたものにマッチしないときは、
VirtualHost セクションの外のすべての定義からなる「主」サーバ設定が
使われます。(ただし、NameVirtualHost ディレクティブにマッチする
すべての IP アドレスは「主」サーバ設定も _default_ バーチャルホストも
使わないことに注意してください。詳しくは ネームベースのバーチャルホスト を
参照してください。):port といった形式で記述することにより、
マッチさせるポートを変更可能です。
この指定をしない場合には、主サーバ設定における
一番最後に Listen で指定された
ポートがデフォルトとなります。
:* を指定することにより、
アドレス上の全てのポートにマッチします。(_default_ のときは
これを使うことが推奨されています。):port といった形式で記述することにより、
マッチさせるポートを変更可能です。
この指定をしない場合には、主サーバ設定における
一番最後に Port で指定されたポートが
デフォルトとなります。
:* を指定することにより、
アドレス上の全てのポートにマッチします。(_default_ のときは
これを使うことが推奨されています。)セキュリティ
参照
mod/directives.html 100644 0 0 65743 11074463036 12056 0 ustar 0 0
ディレクティブの解説に使われる用語
説明
構文
http://www.example.com/path/to/file.html
のように、
スキーム、ホスト名、パス名(省略可能)を含んでいる完全な
Uniform Resource Locator。/path/to/file.html のように、スキームと
ホスト名の後に続く url
の一部。url-path は
ファイルシステムからの視点ではなく、
ウェブからの視点でリソースを表現します。/usr/local/apache/htdocs/path/to/file.html
のように、
ルートディレクトリから始まるローカルのファイルシステム上のファイルへのパス。
通常、スラッシュで始まらない file-path は ServerRoot
からの相対パスとして 扱われます。/usr/local/apache/htdocs/path/to/
のように、
ルートディレクトリから始まるローカルのファイルシステムのディレクトリへの
パス。file.html のように、パス情報の付いていない
ファイル名。file.html.en
には二つの拡張子があります。.html と
.en です。Apache
のディレクティブでは、extension
はドット付きでも無しでも指定できます。さらに、extension
は 大文字小文字を区別しません。text/html のように、スラッシュで分離された
主フォーマットと副フォーマットによってファイルの形式を
表す方法です。
デフォルト
コンテキスト
httpd.conf,
srm.conf, access.conf)
内では使用できますが、
<VirtualHost> や
<Directory> の中では
使用できないことを示します。
.htaccessファイルでの使用は許可されていません。<VirtualHost>
の中で使用できることを示します。<Directory>,
<Location>,
<Files>
コンテナの中で、 Directory, Location, Files セクションの動作方法
で説明されている制限の下で使用できることを示します。.htaccess ファイル内で
使用可能であることを示します。 ただ、上書き
の設定によっては、処理されないかもしれません。サーバ設定ファイル、.htaccess" で有効だと
記されているディレクティブは httpd.conf
ファイルと .htaccess
ファイルとで有効ですが、 <Directory>
や <VirtualHost>
の中では使用できません。
上書き
.htaccess
ファイル中に
ディレクティブが現れたときに、それの処理を有効にするために
どの設定の上書きが必要かを示します。 ディレクティブの
コンテキスト
が、.htaccess
ファイル中では許可していない場合は、 この属性は
"適用不可" と書かれます。AllowOverride
ディレクティブによって有効にされ、
特定のスコープ(ディレクトリなど)と、
さらに下位のレベルの AllowOverride
で修正されない限り、 その配下に対して適用されます。
ディレクティブのドキュメントは取り得る上書きの名前も挙げます。
ステータス
モジュール
互換性
ディレクティブ一覧
mod/index.html 100644 0 0 27662 11074463036 11022 0 ustar 0 0
mod/leader.html 100644 0 0 13614 11074463036 11137 0 ustar 0 0
モジュール一覧
コア機能と MPM
worker
MPMworker MPM他のモジュール
ls コマンドや
Win32 の dir シェルコマンドに似た
ディレクトリインデックスを生成するmod_dav のためのファイルシステムプロバイダExpires と
Cache-Control HTTP ヘッダの生成mod_proxy extension for
CONNECT request handlingmod_proxymod_proxy
mod/mod_access.html 100644 0 0 42133 11074463036 12001 0 ustar 0 0
Apache MPM leader
Description: An experimental variant of the standard worker
MPMStatus: MPM ModuleIdentifier: mpm_leader_module SourceFile: leader.c Summary
Warning
worker MPM. It uses a Leader/Followers design pattern
to coordinate work among threads. For more info, see http://deuce.doc.wustl.edu/doc/pspdfs/lf.pdf.leader MPM, add
--with-mpm=leader to the configure
script's arguments when building the httpd.--enable-nonportable-atomics=yes to the
configure script's arguments. This will cause
APR to implement atomic operations
using efficient opcodes not available in older CPUs.
mod/mod_actions.html 100644 0 0 17703 11074463036 12205 0 ustar 0 0
Apache モジュール mod_access
This translation may be out of date. Check the
English version for recent changes.
説明: クライアントのホスト名、IP アドレス、その他のクライアント
のリクエストの特徴に基づいたアクセス制御機能を提供する ステータス: Base モジュール識別子: access_module ソースファイル: mod_access.c 互換性: 2.1 より前のバージョンのみで使用可能 概要
mod_access により提供されるディレクティブはサーバの特定の部分への
アクセスを制御するために <Directory>, <Files>, <Location>
と .htaccess ファイルで使用されます。クライアントのホスト名、IP
アドレスや 環境変数として取得された、その他のリクエストの特徴に基づいて
アクセス制御を行なうことができます。Allow と
Deny ディレクティブは
どのようなクライアントにアクセスを
許可する、しないかを指定するために使用されます。一方、
Order ディレクティブは
デフォルトのアクセス状態と、
Allow ディレクティブと
Deny
ディレクティブとのお互いへの影響の仕方を設定します。
Satisfy
ディレクティブを使用します。GET, PUT, POST など)
に適用されます。そして、ほとんどの場合これが望ましい動作です。
しかし、<Limit>
セクションの中にディレクティブを書くことで、
一部のメソッドにのみ制限をかけることもできます。Allow ディレクティブ
説明: サーバのある領域にアクセスできるホストを制御する 構文: Allow from
all|host|env=env-variable
[host|env=env-variable] ...コンテキスト: ディレクトリ, .htaccess 上書き: Limit ステータス: Base モジュール: mod_access Allow ディレクティブはどのホストが
サーバのある領域をアクセスできるかに影響を与えます。
アクセスはホスト名、IP アドレス、IP アドレスの範囲や、
環境変数として取得された、その他のクライアントのリクエストの
特徴によって制御することができます。from です。
それに続く引数は三つの違った形式があります。Allow from
all が指定されていれば、すべてのホストにアクセスを許可し、
アクセス制限は下で説明されているように、
Deny
ディレクティブと Order
ディレクティブの設定で決まります。
特定のホストやホスト群にのみサーバへのアクセスを許可するためには、
以下のどれかの形式で host を指定することができます:
例:
Allow from apache.org
foo.apache.org にはマッチしますが、
fooapache.org にはマッチしません。
この設定をすると、Apache は
HostnameLookups
の設定に関わらず、クライアントの IP アドレスに対して
二重の DNS の逆引きを行ないます。まず IP アドレスに対して DNS の
逆引きを行なってホスト名を得、そのホスト名に対して正引きを
行ない、元の IP アドレスと一致するかを調べます。DNS の正引きと
逆引きが無矛盾かつホスト名が一致するときにのみ
アクセスが許可されます。例:
Allow from 10.1.2.3
例:
Allow from 10.1
例:
Allow from 10.1.0.0/255.255.0.0
例:
Allow from 10.1.0.0/16
Allow from 2001:db8::a00:20ff:fea7:ccea
Allow from 2001:db8::a00:20ff:fea7:ccea/10
Allow ディレクティブの引数の三つ目の形式は、
環境変数
の存在によりアクセスの制御を行なえるようにするものです。
Allow from env=env-variable
が指定されていると、環境変数 env-variable
が存在した場合にリクエストはアクセスを許可されます。サーバは
mod_setenvif
のディレクティブにより、クライアントのリクエスト
の特徴に基づいて柔軟に環境変数を設定する機能を提供します。
ですから、このディレクティブはクライアントの
User-Agent (ブラウザの種類)、Referer
や他の HTTP リクエストのヘッダフィールドなどに基づいて
アクセス許可をするために使うことができます。
例:
SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
<Directory /docroot>
Order Deny,Allow
Deny from all
Allow from env=let_me_in
</Directory>
KnockKnock/2.0
で始まるブラウザのみがアクセスを許可され、
他のものはアクセスを拒否されます。Deny ディレクティブ
説明: サーバがアクセスを拒否するホストを制御する 構文: Deny from
all|host|env=env-variable
[host|env=env-variable] ...コンテキスト: ディレクトリ, .htaccess 上書き: Limit ステータス: Base モジュール: mod_access Deny ディレクティブの引数は Allow
ディレクティブとまったく同じです。Order ディレクティブ
説明: デフォルトのアクセス可能な状態と、 Allow と
Deny が評価される順番を制御する構文: Order orderingデフォルト: Order Deny,Allowコンテキスト: ディレクトリ, .htaccess 上書き: Limit ステータス: Base モジュール: mod_access Order ディレクティブはデフォルトのアクセスの状態と
Allow ディレクティブと
Deny
ディレクティブが評価される順番を制御します。
Ordering は以下のどれかです。
Deny,AllowDeny ディレクティブが
Allow
ディレクティブの前に評価されます。
アクセスはデフォルトで許可されます。Deny
ディレクティブに合わないか、Allow
ディレクティブに合うクライアントはアクセスを許可されます。Allow,DenyAllow
ディレクティブが Deny
ディレクティブの前に評価されます。
アクセスはデフォルトで拒否されます。Allow
ディレクティブに合わないか、Deny
ディレクティブに合うクライアントはアクセスを拒否されます。
Mutual-failureAllow のリストに現れて、
Deny
のリストに現れないホストのみがアクセスを許可されます。
この順番付けは Order Allow,Deny と同じ効果を持ち、
その設定の方が好ましいために非推奨となっています。Allow と
Deny 文は
全て評価されるということに注意してください。
Order Deny,Allow
Deny from all
Allow from apache.org
Order Allow,Deny
Allow from apache.org
Deny from foo.apache.org
Order が Deny,Allow
に変わっていれば、すべのホストにアクセスが許可されます。
これは、設定ファイル中の実際の順番に関わらず、
Allow from apache.org が最後に評価されて、
Deny from foo.apache.org を上書きするからです。
apache.org
ドメインにないホストも、デフォルトの状態が allow
に変化するために、アクセスを許可されます。
Order
ディレクティブはデフォルトのアクセスの状態に影響を与えるので、
Allow ディレクティブと
Deny
ディレクティブが無くても、サーバのアクセスに影響を与えることができます。
たとえば、
<Directory /www>
Order Allow,Deny
</Directory>
/www ディレクトリへのすべてのアクセスを拒否します。
Order
ディレクティブはサーバの設定処理の各段階でだけ
アクセスディレクティブの処理の順番を変更します。これは、たとえば、
Order ディレクティブの設定に関わらず、
<Location> セクションの
Allow ディレクティブや
Deny ディレクティブは、
Directory セクションや
.htaccess ファイルの Allow
ディレクティブや Deny
ディレクティブよりも常に後に評価されるということを意味します。
設定セクションのマージの詳細については、
Directory,Location, Files
セクションの動作方法 を参照してください。
mod/mod_alias.html 100644 0 0 52243 11074463036 11634 0 ustar 0 0
Apache モジュール mod_actions
説明: メディアタイプやリクエストメソッドに応じて
CGI スクリプトを実行する機能を提供 ステータス: Base モジュール識別子: actions_module ソースファイル: mod_actions.c 概要
Action
ディレクティブは特定のタイプのファイルをリクエストされた場合に
CGI スクリプトが実行されるようにします。Script
ディレクティブはリクエストで特定のメソッドが使用されたときに CGI
スクリプトが実行されるようにします。
これはファイルを処理するスクリプトの実行をずっと簡単にします。Action ディレクティブ
説明: 特定のハンドラやコンテントタイプに対して CGI を実行するように
設定 構文: Action action-type cgi-scriptコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_actions ScriptAlias や
AddHandler によって
CGI スクリプトに設定されたリソースへの URL-path です。
Action-type には
handler か MIME
コンテントタイプを指定できます。リクエストされたドキュメントの URL
とファイルのパスは標準 CGI 環境変数 PATH_INFO と PATH_TRANSLATED
を使って伝えられます。例
# Requests for files of a particular type:
Action image/gif /cgi-bin/images.cgi
# Files of a particular file extension
AddHandler my-file-type .xyz
Action my-file-type /cgi-bin/program.cgi
image/gif
のファイルへのリクエストは、そのファイルの代わりに指定されたスクリプト
/cgi-bin/images.cgi が呼ばれます。.xyz のファイルへのリクエストは、
そのファイルの代わりに指定されたスクリプト
/cgi-bin/program.cgi が呼ばれます。参照
Script ディレクティブ
説明: 特定のリクエストメソッドに対して CGI スクリプトを
実行するように設定 構文: Script method cgi-scriptコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ ステータス: Base モジュール: mod_actions ScriptAlias や
AddHandler によって
CGI スクリプトに設定されたリソースへの URL-path です。
リクエストされたドキュメントの URL とファイルのパスは標準 CGI
環境変数 PATH_INFO と PATH_TRANSLATED を使って伝えられます。
任意のメソッド名を使用することができます。
メソッド名は大文字小文字を区別します。ですから、
Script PUT と Script put
はまったく違った効果になります。
GET メソッドの Script は問合せ引数がある場合にのみ
(たとえば、foo.html?hi) 呼ばれるということにも注意してください。
そうでない場合は、リクエストは通常通り処理されます。例
# For <ISINDEX>-style searching
Script GET /cgi-bin/search
# A CGI PUT handler
Script PUT /~bob/put.cgi
mod/mod_asis.html 100644 0 0 12147 11074463036 11501 0 ustar 0 0
Apache モジュール mod_alias
This translation may be out of date. Check the
English version for recent changes.
説明: ホストファイルシステム上のいろいろな違う場所を
ドキュメントツリーにマップする機能と、
URL のリダイレクトを行なう機能を提供する ステータス: Base モジュール識別子: alias_module ソースファイル: mod_alias.c 概要
Alias
ディレクティブと ScriptAlias
ディレクティブは
URL とファイルシステムのパスをマップするために使用されます。これは
DocumentRoot
の下にないドキュメントをウェブのドキュメントツリーの一部として
送られるようにします。ScriptAlias
ディレクティブにはマップ先のディレクトリが CGI
スクリプトのみであることを示すという追加の効果があります。
Redirect ディレクティブは
クライアントに違った
URL に新しいリクエストを送るように指示します。これは、
リソースが新しい場所に移動したときによく使用されます。mod_alias は簡単な URL 操作向けに設計されています。
より複雑な操作、クエリーストリングの操作には、mod_rewrite
で提供されるツールを使用してください。ディレクティブ
トピック
参照
処理の順番
<VirtualHost> セクションの中のように) 複数の Alias や Redirect が
同じコンテキスト中に現れた場合は決まった順番で処理されます。Redirect か RedirectMatch にマッチするリクエストには
Alias は決して適用されません。次に、Alias と Redirect が設定ファイル中の
順番に適用され、最初にマッチしたものが優先されます。
Alias /foo/bar /baz
Alias /foo /gaq
/foo Alias が
常に /foo/bar Alias より先にマッチしますので、後者は
決して適用されることはありません。Alias ディレクティブ
説明: URL をファイルシステムの位置にマップする 構文: Alias URL-path
file-path|directory-pathコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_alias Alias ディレクティブはドキュメントを
ローカルファイルシステムの
DocumentRoot
以外の場所に保管することを可能にします。
URL の (% が復号された) パスが url-path で始まるものは
directory-filename
で始まるローカルファイルにマップされます。例
Alias /image /ftp/pub/image
Alias /icons/
/usr/local/apache/icons/ というものを使用している場合は、
/icons という url はエイリアスされません。<Directory>
セクションを追加する必要があるかもしれないことに注意してください。
エイリアスの展開は <Directory>
セクションを調べる前に行なわれますので、
エイリアスの行き先の <Directory> セクションのみ
効果があります。
(しかし、<Location>
セクションはエイリアスが処理される前に実行されますので、
こちらは適用されます。)Alias を
DocumentRoot
ディレクトリの外側に配置した場合は、行き先のディレクトリに対する
アクセス権限を明示的に制限しなければならないでしょう。例
Alias /image /ftp/pub/image
<Directory /ftp/pub/image>
Order allow,deny
Allow from all
</Directory>
AliasMatch ディレクティブ
説明: 正規表現を使って URL をファイルシステムの位置にマップする 構文: AliasMatch regex
file-path|directory-pathコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_alias Alias
とほとんど同じですが、簡単な先頭からのマッチを行なうのではなく、
標準正規表現を利用します。ここで指定された正規表現と URL のパス
が合うかどうかを調べ、合う場合は括弧で括られたマッチを
与えられた文字列で置き換え、それをファイル名として使用します。たとえば、
/icons ディレクトリを使う
ためには以下のようなものが使用できます:
AliasMatch ^/icons(.*) /usr/local/apache/icons$1
Redirect ディレクティブ
説明: クライアントが違う URL を取得するように外部へのリダイレクトを
送る 構文: Redirect [status] URL-path
URLコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_alias 例
Redirect /service http://foo2.bar.com/service
注意
<Directory>
セクションの中で使われていたとしても、URL-path
は相対パスではなく、完全な URL でなければなりません。
send_error_response
を見てください)。例
Redirect permanent /one http://example.com/two
Redirect 303 /three http://example.com/other
RedirectMatch ディレクティブ
説明: 現在の URL への正規表現のマッチにより
外部へのリダイレクトを送る 構文: RedirectMatch [status] regex
URLコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_alias Redirect
とほとんど同じですが、簡単な先頭からのマッチを行なうのではなく、
標準正規表現を利用します。ここで指定された正規表現と URL-path
が合うかどうかを調べ、合う場合は括弧で括られたマッチを
与えられた文字列で置き換え、それをファイル名として使用します。
たとえば、すべての GIF ファイルを別サーバの同様な名前の JPEG
ファイルにリダイレクトするには、以下のようなものを使います:
RedirectMatch (.*)\.gif$ http://www.anotherserver.com$1.jpg
RedirectPermanent ディレクティブ
説明: クライアントが違う URL を取得するように外部への永久的な
リダイレクトを送る 構文: RedirectPermanent URL-path URLコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_alias Redirect premanent とまったく同じです。RedirectTemp ディレクティブ
説明: クライアントが違う URL を取得するように外部への一時的な
リダイレクトを送る 構文: RedirectTemp URL-path URLコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_alias Redirect temp とまったく同じです。ScriptAlias ディレクティブ
説明: URL をファイルシステムの位置へマップし、マップ先を
CGI スクリプトに指定 構文: ScriptAlias URL-path
file-path|directory-pathコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_alias ScriptAlias ディレクティブは、対象ディレクトリに
mod_cgi の cgi-script
ハンドラで処理される CGI
スクリプトがあることを示す以外は
Alias
ディレクティブと同じ振る舞いをします。
URL の (% が復号された) パスが URL-path で始まるものは
ローカルのファイルシステムの
フルパスである二番目の引数にマップされます。例
ScriptAlias /cgi-bin/ /web/cgi-bin/
http://myserver/cgi-bin/foo
へのリクエストに対してサーバはスクリプト
/web/cgi-bin/foo を実行します。ScriptAliasMatch ディレクティブ
説明: URL を正規表現を使ってファイルシステムの位置へマップし、マップ先を
CGI スクリプトに指定 構文: ScriptAliasMatch regex
file-path|directory-pathコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_alias ScriptAlias
とほとんど同じですが、簡単な先頭からのマッチを行なうのではなく、
標準正規表現を利用します。ここで指定された正規表現と URL-path
が合うかどうかを調べ、合う場合は括弧で括られたマッチを
与えられた文字列で置き換え、それをファイル名として使用します。
たとえば、標準の /cgi-bin
を使用するようにするためには、以下のようなものを使います:
ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1
mod/mod_auth.html 100644 0 0 31131 11074463036 11475 0 ustar 0 0
Apache モジュール mod_asis
This translation may be out of date. Check the
English version for recent changes.
説明: 自分用の HTTP ヘッダの書かれているファイルを送信する ステータス: Base モジュール識別子: asis_module ソースファイル: mod_asis.c 概要
send-as-is
を提供します。このハンドラは通常の HTTP
ヘッダをほとんど追加することなくドキュメントを送信します。httpd/send-as-is のファイルも処理します。
使用法
send-as-is
ハンドラを例えば以下のように関連付けてください。AddHandler send-as-is asis.asis のすべてのファイルの内容は Apache
からクライアントへほとんど変更無く送られます。クライアントには
HTTP ヘッダが必要ですので、ファイルに書くことを忘れないでください。
Status: ヘッダも必要です。データは 3 桁の HTTP
応答コードと、その後にテキストメッセージが続いたものでなければなりません。
Status: 301 Now where did I leave that URL
Location: http://xyz.abc.com/foo/bar.html
Content-type: text/html
<html>
<head>
<title>Lame excuses'R'us</title>
</head>
<body>
<h1>Fred's exceptionally wonderful page has moved to
<a href="http://xyz.abc.com/foo/bar.html">Joe's</a>
site.
</h1>
</body>
</html>
注意
Date:
と Server: ヘッダを追加しますので、
それらがファイルに書かれていてはいけません。
サーバは Last-Modified ヘッダを追加しません。
おそらくはそうすべきでしょうけれど。
mod/mod_auth_anon.html 100644 0 0 33522 11074463036 12516 0 ustar 0 0
Apache モジュール mod_auth
This translation may be out of date. Check the
English version for recent changes.
説明: テキストファイルを用いたユーザ認証 ステータス: Base モジュール識別子: auth_module ソースファイル: mod_auth.c 互換性: 2.1 より前のバージョンでのみ使用可能 概要
mod_auth_dbm で提供されています。
また、HTTP ダイジェスト認証は mod_auth_digest
で提供されています。AuthAuthoritative ディレクティブ
説明: 認証と承認プロセスを、
より低いレベルのモジュールに移行させるかどうかを設定する 構文: AuthAuthoritative On|Offデフォルト: AuthAuthoritative Onコンテキスト: ディレクトリ, .htaccess 上書き: AuthConfig ステータス: Base モジュール: mod_auth AuthAuthoritative
ディレクティブで明示的に Off に設定すると、
与えられた認証ユーザ ID に対してユーザ ID がない
またはルールがない場合に、
認証と承認の両方のプロセスが、
より低いレベルのモジュール (Configuration と
modules.c ファイルで定義) に移行するようにできます。
ユーザ ID がある、かつまたは、ルールが指定されている場合は、
通常のパスワードとアクセスチェックが適用されて、
認証に失敗すると "Authentication Required" 応答が返されます。Require
ディレクティブが二つ以上のモジュールで現われたりした場合は、
一つ目のモジュールが認定を行って、AuthAuthoritative
の設定に関わらず、
アクセスは移行しません。mod_auth_dbm,
mod_auth_msql, mod_auth_anon
といったデータベースモジュールの一つと組み合わせることです。
これらのモジュールは多くのユーザ資格検査を提供してくれます。
しかし、少数の (管理者関連の) アクセスは
AuthUserFile
で良く保護された、より低レベルに移行するようにします。セキュリティ
AuthUserFile と
AuthGroupFile は、
ウェブサーバのドキュメントツリーの外側に保管する
ようにしてください。保護しようとしているディレクトリ以下には、
置かないで下さい。そうしないと
AuthUserFile と
AuthGroupFile
はダウンロードできてしまいます。AuthGroupFile ディレクティブ
説明: 認証に使用するユーザグループの一覧が格納されている、
テキストファイルの名前を設定する 構文: AuthGroupFile file-pathコンテキスト: ディレクトリ, .htaccess 上書き: AuthConfig ステータス: Base モジュール: mod_auth AuthGroupFile ディレクティブは、
認証に使用するユーザグループの一覧が格納されている、
テキストファイルの名前を設定します。
file-path はグループファイルへのパスです。
もし絶対パスでなければ、
ServerRoot
からの相対パスとして扱われます。例:
mygroup: bob joe anne
AuthDBMGroupFile
の方がずっと良い性能を発揮します。セキュリティ
AuthGroupFile は、
ウェブサーバのドキュメントツリーの外側に
保管するようにしてください。
保護しようとしているディレクトリ以下には、置かないで下さい。
そうしないと AuthGroupFile は
ダウンロードできてしまいます。AuthUserFile ディレクティブ
説明: 認証に使用するユーザとパスワードの一覧が格納されている、
テキストファイルの名前を設定する 構文: AuthUserFile file-pathコンテキスト: ディレクトリ, .htaccess 上書き: AuthConfig ステータス: Base モジュール: mod_auth AuthUserFile ディレクティブは、
ユーザ認証のためのユーザとパスワードの一覧を格納した
テキストファイルの名前を設定します。file-path
はユーザファイルへのパスです。
もし絶対パスでなければ
(つまり スラッシュで始まらないパスであれば)
、ServerRoot
からの相対パスとして扱われます。mod_auth は
パスワードの検証には最初の登録を使用します。src/support にある
htpasswd
ユーティリティで、このパスワードファイルをメインテナンスします。
詳細は man ページをご覧頂くとして、
簡単には:username で、Filename
というパスワードファイルを生成します。
次のコマンドを発行するとパスワードが要求されます:htpasswd -c Filename usernameFilename に、username2
を追加したり修正したりします:htpasswd Filename username2AuthDBMUserFile
を代わりに使ってください。セキュリティ
AuthUserFile
は、ウェブサーバのドキュメントツリーの外側に保管するようにしてください。
保護しようとしているディレクトリ以下には、置かないで下さい。
そうしないと AuthUserFile は
ダウンロードできてしまいます。
mod/mod_auth_dbm.html 100644 0 0 32450 11074463036 12324 0 ustar 0 0
Apache Module mod_auth_anon
Description: Allows "anonymous" user access to authenticated
areas Status: Extension ModuleIdentifier: auth_anon_module SourceFile: mod_auth_anon.c Compatibility: Available only in versions prior to 2.1 Summary
Directives
Anonymous Anonymous_Authoritative Anonymous_LogEmail Anonymous_MustGiveEmail Anonymous_NoUserID Anonymous_VerifyEmailTopics
Example
Anonymous_NoUserID)Anonymous_MustGiveEmail)Anonymous_VerifyEmail)anonymous guest www test
welcome and comparison is not case
sensitive. (Anonymous)Anonymous_LogEmail)Excerpt of httpd.conf:
Anonymous_NoUserID off
Anonymous_MustGiveEmail on
Anonymous_VerifyEmail on
Anonymous_LogEmail on
Anonymous anonymous guest www test welcome
AuthName "Use 'anonymous' & Email address for guest entry"
AuthType basic
# An
AuthUserFile/AuthDBUserFile/AuthDBMUserFile
# directive must be specified, or use
# Anonymous_Authoritative for public access.
# In the .htaccess for the public directory, add:
<Files *>
Order Deny,Allow
Allow from all
Require valid-user
</Files>
Anonymous Directive
Description: Specifies userIDs that are allowed access without
password verification Syntax: Anonymous user [user] ...Context: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon
I strongly suggest that the magic username
'anonymous' is always one of the allowed
userIDs.Example:
Anonymous anonymous "Not Registered" "I don't know"
Anonymous_Authoritative Directive
Description: Configures if authorization will fall-through
to other methods Syntax: Anonymous_Authoritative On|OffDefault: Anonymous_Authoritative OffContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon On, there is no fall-through to other
authentication methods. So if a userID does not match the values
specified in the Anonymous
directive, access is denied.Anonymous_LogEmail Directive
Description: Sets whether the password entered will be logged in the
error log Syntax: Anonymous_LogEmail On|OffDefault: Anonymous_LogEmail OnContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon On, the default, the 'password' entered
(which hopefully contains a sensible email address) is logged in
the error log.Anonymous_MustGiveEmail Directive
Description: Specifies whether blank passwords are allowed Syntax: Anonymous_MustGiveEmail On|OffDefault: Anonymous_MustGiveEmail OnContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon Anonymous_NoUserID Directive
Description: Sets whether the userID field may be empty Syntax: Anonymous_NoUserID On|OffDefault: Anonymous_NoUserID OffContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon On, users can leave the userID (and
perhaps the password field) empty. This can be very convenient for
MS-Explorer users who can just hit return or click directly on the
OK button; which seems a natural reaction.Anonymous_VerifyEmail Directive
Description: Sets whether to check the password field for a correctly
formatted email address Syntax: Anonymous_VerifyEmail On|OffDefault: Anonymous_VerifyEmail OffContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon On the 'password' entered is checked for
at least one '@' and a '.' to encourage users to enter valid email
addresses (see the above Anonymous_LogEmail).
mod/mod_auth_digest.html 100644 0 0 53657 11074463036 13055 0 ustar 0 0
Apache Module mod_auth_dbm
Description: Provides for user authentication using DBM
files Status: Extension ModuleIdentifier: auth_dbm_module SourceFile: mod_auth_dbm.c Compatibility: Available only in versions prior to 2.1 Summary
mod_auth.Directives
See also
AuthDBMAuthoritative Directive
Description: Sets whether authentication and authorization will be
passed on to lower level modules Syntax: AuthDBMAuthoritative On|OffDefault: AuthDBMAuthoritative OnContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_dbm AuthDBMAuthoritative
directive explicitly to Off allows for both
authentication and authorization to be passed on to lower level
modules (as defined in the modules.c files) if there
is no userID or rule matching the
supplied userID. If there is a userID and/or rule specified; the
usual password and access checks will be applied and a failure will
give an "Authentication Required" reply.Require
directive applies to more than one module; then the first module
will verify the credentials; and no access is passed on;
regardless of the AuthDBMAuthoritative
setting.mod_auth. Whereas this
DBM module supplies the bulk of the user credential checking; a
few (administrator) related accesses fall through to a lower
level with a well protected .htpasswd file.Security:
.htaccess file; and verify that this
is really what you want; Generally it is easier to just secure
a single .htpasswd file, than it is to secure a
database which might have more access interfaces.AuthDBMGroupFile Directive
Description: Sets the name of the database file containing the list
of user groups for authentication Syntax: AuthDBMGroupFile file-pathContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_dbm AuthDBMGroupFile directive sets the
name of a DBM file containing the list of user groups for user
authentication. File-path is the absolute path to the
group file.AuthDBMGroupFile is stored outside the
document tree of the web-server; do not put it in the
directory that it protects. Otherwise, clients will be able to
download the AuthDBMGroupFile unless
otherwise protected.
AuthDBMGroupFile /www/userbase
AuthDBMUserFile /www/userbase
Unix Crypt-ed Password:List of Groups[:(ignored)]
AuthDBMType Directive
Description: Sets the type of database file that is used to
store passwords Syntax: AuthDBMType default|SDBM|GDBM|NDBM|DBDefault: AuthDBMType defaultContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_dbm Compatibility: Available in version 2.0.30 and later. AuthDBMUserFile Directive
Description: Sets thename of a database file containing the list of users and
passwords for authentication Syntax: AuthDBMUserFile file-pathContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_dbm AuthDBMUserFile directive sets the
name of a DBM file containing the list of users and passwords for
user authentication. File-path is the absolute path to
the user file.Security:
AuthDBMUserFile is stored
outside the document tree of the web-server; do not put it in
the directory that it protects. Otherwise, clients will be able to
download the AuthDBMUserFile.dbmmanage is included with
Apache. This program can be used to create and update DBM
format password files for use with this module.
mod/mod_auth_ldap.html 100644 0 0 137753 11074463036 12536 0 ustar 0 0
Apache Module mod_auth_digest
Description: User authentication using MD5
Digest Authentication. Status: Experimental ModuleIdentifier: auth_digest_module SourceFile: mod_auth_digest.c Summary
Directives
AuthDigestAlgorithm AuthDigestDomain AuthDigestFile AuthDigestGroupFile AuthDigestNcCheck AuthDigestNonceFormat AuthDigestNonceLifetime AuthDigestQop AuthDigestShmemSizeTopics
See also
Using Digest Authentication
AuthType Digest and
AuthDigestFile instead
of the normal AuthType Basic and AuthUserFile; also, replace any AuthGroupFile with AuthDigestGroupFile. Then add a
AuthDigestDomain directive
containing at least the root URI(s) for this protection space.htdigest tool.Example:
<Location /private/>
AuthType Digest
AuthName "private area"
AuthDigestDomain /private/ http://mirror.my.dom/private2/
AuthDigestFile /web/auth/.digest_pw
Require valid-user
</Location>
Note
Working with MS Internet Explorer
GET requests with a query string were not RFC compliant.
There are a few ways to work around this issue.POST requests instead of
GET requests to pass data to your program. This method
is the simplest approach if your application can work with this
limitation.
AuthDigestEnableQueryStringHack environment variable.
If AuthDigestEnableQueryStringHack is set for the
request, Apache will take steps to work around the MSIE bug and
remove the query string from the digest comparison. Using this
method would look similar to the following.Using Digest Authentication with MSIE:
BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On
BrowserMatch
directive for more details on conditionally setting environment
variablesAuthDigestAlgorithm Directive
Description: Selects the algorithm used to calculate the challenge and
response hases in digest authentication Syntax: AuthDigestAlgorithm MD5|MD5-sessDefault: AuthDigestAlgorithm MD5Context: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_digest AuthDigestAlgorithm directive
selects the algorithm used to calculate the challenge and response
hashes.
MD5-sess is not correctly implemented yet.
AuthDigestDomain Directive
Description: URIs that are in the same protection space for digest
authentication Syntax: AuthDigestDomain URI [URI] ...Context: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_digest AuthDigestDomain directive allows
you to specify one or more URIs which are in the same protection
space (i.e. use the same realm and username/password info).
The specified URIs are prefixes, i.e. the client will assume
that all URIs "below" these are also protected by the same
username/password. The URIs may be either absolute URIs (i.e.
including a scheme, host, port, etc) or relative URIs.AuthDigestNcCheck is on.AuthDigestFile Directive
Description: Location of the text file containing the list
of users and encoded passwords for digest authentication Syntax: AuthDigestFile file-pathContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_digest AuthDigestFile directive sets the
name of a textual file containing the list of users and encoded
passwords for digest authentication. File-path is the
absolute path to the user file.htdigest utility found in
the support/ subdirectory of the Apache distribution.AuthDigestGroupFile Directive
Description: Name of the text file containing the list of groups
for digest authentication Syntax: AuthDigestGroupFile file-pathContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_digest AuthDigestGroupFile directive sets
the name of a textual file containing the list of groups and their
members (user names). File-path is the absolute path to
the group file.mygroup: bob joe anneSecurity:
AuthGroupFile is stored
outside the document tree of the web-server; do not put it in
the directory that it protects. Otherwise, clients may be able
to download the AuthGroupFile.AuthDigestNcCheck Directive
Description: Enables or disables checking of the nonce-count sent by the
server Syntax: AuthDigestNcCheck On|OffDefault: AuthDigestNcCheck OffContext: server config Status: Experimental Module: mod_auth_digest
Not implemented yet.
AuthDigestNonceFormat Directive
Description: Determines how the nonce is generated Syntax: AuthDigestNonceFormat formatContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_digest Not implemented yet.
AuthDigestNonceLifetime Directive
Description: How long the server nonce is valid Syntax: AuthDigestNonceLifetime secondsDefault: AuthDigestNonceLifetime 300Context: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_digest AuthDigestNonceLifetime directive
controls how long the server nonce is valid. When the client
contacts the server using an expired nonce the server will send
back a 401 with stale=true. If seconds is
greater than 0 then it specifies the amount of time for which the
nonce is valid; this should probably never be set to less than 10
seconds. If seconds is less than 0 then the nonce never
expires.
AuthDigestQop Directive
Description: Determines the quality-of-protection to use in digest
authentication Syntax: AuthDigestQop none|auth|auth-int [auth|auth-int]Default: AuthDigestQop authContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_digest AuthDigestQop directive determines
the quality-of-protection to use. auth will only do
authentication (username/password); auth-int is
authentication plus integrity checking (an MD5 hash of the entity
is also computed and checked); none will cause the module
to use the old RFC-2069 digest algorithm (which does not include
integrity checking). Both auth and auth-int may
be specified, in which the case the browser will choose which of
these to use. none should only be used if the browser for
some reason does not like the challenge it receives otherwise.
auth-int is not implemented yet.
AuthDigestShmemSize Directive
Description: The amount of shared memory to allocate for keeping track
of clients Syntax: AuthDigestShmemSize sizeDefault: AuthDigestShmemSize 1000Context: server config Status: Experimental Module: mod_auth_digest AuthDigestShmemSize directive defines
the amount of shared memory, that will be allocated at the server
startup for keeping track of clients. Note that the shared memory
segment cannot be set less than the space that is neccessary for
tracking at least one client. This value is dependant on your
system. If you want to find out the exact value, you may simply
set AuthDigestShmemSize to the value of
0 and read the error message after trying to start the
server.K or an M to
express your value as KBytes or MBytes. For example, the following
directives are all equivalent:
AuthDigestShmemSize 1048576
AuthDigestShmemSize 1024K
AuthDigestShmemSize 1M
mod/mod_autoindex.html 100644 0 0 136666 11074463036 12577 0 ustar 0 0
Apache Module mod_auth_ldap
Description: Allows an LDAP directory to be used to store the database
for HTTP Basic authentication. Status: Experimental ModuleIdentifier: auth_ldap_module SourceFile: mod_auth_ldap.c Compatibility: Available in version 2.0.41 and later Summary
mod_auth_ldap supports the following features:
Directives
AuthLDAPAuthoritative AuthLDAPBindDN AuthLDAPBindPassword AuthLDAPCharsetConfig AuthLDAPCompareDNOnServer AuthLDAPDereferenceAliases AuthLDAPEnabled AuthLDAPFrontPageHack AuthLDAPGroupAttribute AuthLDAPGroupAttributeIsDN AuthLDAPRemoteUserIsDN AuthLDAPUrlTopics
Contents Operation The Require Directives Examples Using TLS Using SSL Using Microsoft
FrontPage with mod_auth_ldapSee also
Operation
mod_auth_ldap
verifies that the user's credentials are valid. This also called
the search/bind phase. The second phase is
authorization, in which mod_auth_ldap determines
if the authenticated user is allowed access to the resource in
question. This is also known as the compare
phase.The Authentication
Phase
mod_auth_ldap
searches for an entry in the directory that matches the username
that the HTTP client passes. If a single unique match is found,
then mod_auth_ldap attempts to bind to the
directory server using the DN of the entry plus the password
provided by the HTTP client. Because it does a search, then a
bind, it is often referred to as the search/bind phase. Here are
the steps taken during the search/bind phase.
AuthLDAPURL directive with
the username passed by the HTTP client.
AuthLDAPURLSpecifies the LDAP server, the
base DN, the attribute to use in the search, as well as the
extra search filter to use.
AuthLDAPBindDNAn optional DN to bind with
during the search phase.
AuthLDAPBindPasswordAn optional password to bind
with during the search phase.
The Authorization
Phase
mod_auth_ldap
attempts to determine if the user is authorized to access the
resource. Many of these checks require
mod_auth_ldap to do a compare operation on the
LDAP server. This is why this phase is often referred to as the
compare phase. mod_auth_ldap accepts the
following Require
directives to determine if the credentials are acceptable:
Require
valid-user directive.Require user directive, and the
username in the directive matches the username passed by the
client.Require
dn directive, and the DN in the directive matches
the DN fetched from the LDAP directory.Require group directive, and
the DN fetched from the LDAP directory (or the username
passed by the client) occurs in the LDAP group.Require ldap-attribute
directive, and the attribute fetched from the LDAP directory
matches the given value.mod_auth_ldap uses the following directives during the
compare phase:
AuthLDAPURL The attribute specified in the
URL is used in compare operations for the
Require
user operation.
AuthLDAPCompareDNOnServerDetermines the behavior of the
Require dn directive.
AuthLDAPGroupAttributeDetermines the attribute to
use for comparisons in the
Require group
directive.
AuthLDAPGroupAttributeIsDNSpecifies whether to use the
user DN or the username when doing comparisons for the
Require group directive.
The Require Directives
Require
directives are used during the authorization phase to ensure that
a user is allowed to access a resource.Require
valid-user
mod_auth_ldap grants
access to any user that has successfully authenticated during the
search/bind phase.Require user
Require user directive specifies what
usernames can access the resource. Once
mod_auth_ldap has retrieved a unique DN from the
directory, it does an LDAP compare operation using the username
specified in the Require user to see if that username
is part of the just-fetched LDAP entry. Multiple users can be
granted access by putting multiple usernames on the line,
separated with spaces. If a username has a space in it, then it
must be surrounded with double quotes. Multiple users can also be
granted access by using multiple Require user
directives, with one user per line. For example, with a AuthLDAPURL of
ldap://ldap/o=Airius?cn (i.e., cn is
used for searches), the following Require directives could be used
to restrict access:
Require user "Barbara Jenson"
Require user "Fred User"
Require user "Joe Manager"
mod_auth_ldap handles this
directive, Barbara Jenson could sign on as Barbara
Jenson, Babs Jenson or any other cn that
she has in her LDAP entry. Only the single Require
user line is needed to support all values of the attribute
in the user's entry.uid attribute was used instead of the
cn attribute in the URL above, the above three lines
could be condensed toRequire user bjenson fuser jmanagerRequire group
dn: cn=Administrators, o=Airius
objectClass: groupOfUniqueNames
uniqueMember: cn=Barbara Jenson, o=Airius
uniqueMember: cn=Fred User, o=Airius
Require group cn=Administrators, o=AiriusAuthLDAPGroupAttribute and
AuthLDAPGroupAttributeIsDN
directives.Require dn
Require dn directive allows the administrator
to grant access based on distinguished names. It specifies a DN
that must match for access to be granted. If the distinguished
name that was retrieved from the directory server matches the
distinguished name in the Require dn, then
authorization is granted. Note: do not surround the distinguished
name with quotes.Require dn cn=Barbara Jenson, o=AiriusAuthLDAPCompareDNOnServer
directive.Require ldap-attribute
Require ldap-attribute directive allows the
administrator to grant access based on attributes of the authenticated
user in the LDAP directory. If the attribute in the directory
matches the value given in the configuration, access is granted.Require ldap-attribute employeeType=activeRequire ldap-attribute directives. The effect of listing
multiple attribute/values pairs is an OR operation. Access will be
granted if any of the listed attribute values match the value of a
corresponding attribute in the user object. If the value of the
attribute contains a space, only the value must be within double quotes.Require ldap-attribute city="San Jose" status=active
Examples
AuthLDAPURL ldap://ldap1.airius.com:389/ou=People, o=Airius?uid?sub?(objectClass=*)
Require valid-user
AuthLDAPURL ldap://ldap1.airius.com ldap2.airius.com/ou=People, o=Airius
Require valid-user
cn, because a search on cn
must return exactly one entry. That's why
this approach is not recommended: it's a better idea to
choose an attribute that is guaranteed unique in your
directory, such as uid.
AuthLDAPURL ldap://ldap.airius.com/ou=People, o=Airius?cn
Require valid-user
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid
Require group cn=Administrators, o=Airius
qpagePagerID. The example will grant access
only to people (authenticated via their UID) who have
alphanumeric pagers:
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(qpagePagerID=*)
Require valid-user
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(|(qpagePagerID=*)(uid=jmanager))
Require valid-user
fuser, the filter would look
like(&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))(&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))
Using TLS
mod_ldap directives LDAPTrustedCA and LDAPTrustedCAType.
Using SSL
mod_ldap directives LDAPTrustedCA and LDAPTrustedCAType.AuthLDAPURL
directive, instead of ldap://.
Using Microsoft
FrontPage with mod_auth_ldap
mod_auth module) to handle all
authentication. Unfortunately, it is not possible to just
change to LDAP authentication by adding the proper directives,
because it will break the Permissions forms in
the FrontPage client, which attempt to modify the standard
text-based authorization files..htaccess file
that gets created in the web
AuthLDAPURL "the url"
AuthLDAPAuthoritative off
AuthLDAPFrontPageHack on
AuthLDAPAuthoritative must be
off to allow mod_auth_ldap to decline group
authentication so that Apache will fall back to file
authentication for checking group membership. This allows the
FrontPage-managed group file to be used.How It Works
Require
valid-user directive to the .htaccess
files. If AuthLDAPFrontPageHack is not
on, the Require valid-user directive will succeed for
any user who is valid as far as LDAP is
concerned. This means that anybody who has an entry in
the LDAP directory is considered a valid user, whereas FrontPage
considers only those people in the local user file to be
valid. The purpose of the hack is to force Apache to consult the
local user file (which is managed by FrontPage) - instead of LDAP
- when handling the Require valid-user directive.Caveats
mod_auth user file.
The user ID is ideal for this.mod_auth in order to
use FrontPage support. This is because Apache will still use
the mod_auth group file for determine the extent of a
user's access to the FrontPage web..htaccess
files. Attempting to put them inside <Location> or <Directory> directives won't work. This
is because mod_auth_ldap has to be able to grab
the AuthUserFile
directive that is found in FrontPage .htaccess
files so that it knows where to look for the valid user list. If
the mod_auth_ldap directives aren't in the same
.htaccess file as the FrontPage directives, then
the hack won't work, because mod_auth_ldap will
never get a chance to process the .htaccess file,
and won't be able to find the FrontPage-managed user file.AuthLDAPAuthoritative Directive
Description: Prevent other authentication modules from
authenticating the user if this one fails Syntax: AuthLDAPAuthoritative on|offDefault: AuthLDAPAuthoritative onContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap off if this module should let other
authentication modules attempt to authenticate the user, should
authentication with this module fail. Control is only passed on
to lower modules if there is no DN or rule that matches the
supplied user name (as passed by the client).AuthLDAPBindDN Directive
Description: Optional DN to use in binding to the LDAP server Syntax: AuthLDAPBindDN distinguished-nameContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap will use
an anonymous bind.AuthLDAPBindPassword Directive
Description: Password used in conjuction with the bind DN Syntax: AuthLDAPBindPassword passwordContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap AuthLDAPBindDN and AuthLDAPBindPassword if you
absolutely need them to search the directory.AuthLDAPCharsetConfig Directive
Description: Language to charset conversion configuration file Syntax: AuthLDAPCharsetConfig file-pathContext: server config Status: Experimental Module: mod_auth_ldap AuthLDAPCharsetConfig directive sets the location
of the language to charset conversion configuration file. File-path is relative
to the ServerRoot. This file specifies
the list of language extensions to character sets.
Most administrators use the provided charset.conv
file, which associates common language extensions to character sets.
Language-Extension charset [Language-String] ...
#) are ignored.AuthLDAPCompareDNOnServer Directive
Description: Use the LDAP server to compare the DNs Syntax: AuthLDAPCompareDNOnServer on|offDefault: AuthLDAPCompareDNOnServer onContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap will use the LDAP
server to compare the DNs. This is the only foolproof way to
compare DNs. mod_auth_ldap will search the
directory for the DN specified with the Require dn directive, then,
retrieve the DN and compare it with the DN retrieved from the user
entry. If this directive is not set,
mod_auth_ldap simply does a string comparison. It
is possible to get false negatives with this approach, but it is
much faster. Note the mod_ldap cache can speed up
DN comparison in most situations.AuthLDAPDereferenceAliases Directive
Description: When will the module de-reference aliases Syntax: AuthLDAPDereferenceAliases never|searching|finding|alwaysDefault: AuthLDAPDereferenceAliases AlwaysContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap will
de-reference aliases during LDAP operations. The default is
always.AuthLDAPEnabled Directive
Description: Turn on or off LDAP authentication Syntax: AuthLDAPEnabled on|offDefault: AuthLDAPEnabled onContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap off to disable
mod_auth_ldap in certain directories. This is
useful if you have mod_auth_ldap enabled at or
near the top of your tree, but want to disable it completely in
certain locations.AuthLDAPFrontPageHack Directive
Description: Allow LDAP authentication to work with MS FrontPage Syntax: AuthLDAPFrontPageHack on|offDefault: AuthLDAPFrontPageHack offContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap.AuthLDAPGroupAttribute Directive
Description: LDAP attributes used to check for group membership Syntax: AuthLDAPGroupAttribute attributeContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap uses the member and
uniquemember attributes.AuthLDAPGroupAttributeIsDN Directive
Description: Use the DN of the client username when checking for
group membership Syntax: AuthLDAPGroupAttributeIsDN on|offDefault: AuthLDAPGroupAttributeIsDN onContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap on, this directive says to use the
distinguished name of the client username when checking for group
membership. Otherwise, the username will be used. For example,
assume that the client sent the username bjenson,
which corresponds to the LDAP DN cn=Babs Jenson,
o=Airius. If this directive is set,
mod_auth_ldap will check if the group has
cn=Babs Jenson, o=Airius as a member. If this
directive is not set, then mod_auth_ldap will
check if the group has bjenson as a member.AuthLDAPRemoteUserIsDN Directive
Description: Use the DN of the client username to set the REMOTE_USER
environment variable Syntax: AuthLDAPRemoteUserIsDN on|offDefault: AuthLDAPRemoteUserIsDN offContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap REMOTE_USER environment variable will be set to the full
distinguished name of the authenticated user, rather than just
the username that was passed by the client. It is turned off by
default.AuthLDAPUrl Directive
Description: URL specifying the LDAP search parameters Syntax: AuthLDAPUrl urlContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap ldap://host:port/basedn?attribute?scope?filter
ldap. For secure LDAP, use ldaps
instead. Secure LDAP is only available if Apache was linked
to an LDAP library with SSL support.localhost:389 for ldap, and
localhost:636 for ldaps). To
specify multiple, redundant LDAP servers, just list all
servers, separated by spaces. mod_auth_ldap
will try connecting to each server in turn, until it makes a
successful connection.httpd process, or until the LDAP server goes
down.mod_auth_ldap will attempt to
re-connect, starting with the primary server, and trying
each redundant server in turn. Note that this is different
than a true round-robin search.uid. It's a good
idea to choose an attribute that will be unique across all
entries in the subtree you will be using.one or
sub. Note that a scope of base is
also supported by RFC 2255, but is not supported by this
module. If the scope is not provided, or if base scope
is specified, the default is to use a scope of
sub.(objectClass=*), which
will search for all objects in the tree. Filters are
limited to approximately 8000 characters (the definition of
MAX_STRING_LEN in the Apache source code). This
should be than sufficient for any application.(&(filter)(attribute=username)).ldap://ldap.airius.com/o=Airius?cn?sub?(posixid=*). When
a client attempts to connect using a username of Babs
Jenson, the resulting search filter will be
(&(posixid=*)(cn=Babs Jenson)).AuthLDAPURL URLs.
mod/mod_cache.html 100644 0 0 62231 11074463036 11604 0 ustar 0 0
Apache モジュール mod_autoindex
This translation may be out of date. Check the
English version for recent changes.
説明: Unix の ls コマンドや
Win32 の dir シェルコマンドに似た
ディレクトリインデックスを生成するステータス: Base モジュール識別子: autoindex_module ソースファイル: mod_autoindex.c 概要
index.html と呼ばれる
ユーザによって書かれたファイル。
DirectoryIndex
ディレクティブでこのファイル名を設定します。
これは mod_dir で制御されます。AddIcon, AddIconByEncoding と
AddIconByType
を使うことで、様々なファイルタイプに対してアイコン一覧を
セットします。つまり、リストされたファイル毎に、
ファイルにマッチした一番最初のアイコンが表示されます。
これらは mod_autoindex で制御されます。Options +Indexes
を使うことで有効になります。詳細については、
Options
ディレクティブをご覧下さい。FancyIndexingオプションが
IndexOptions
ディレクティブに与えられているならば、
列の先頭は表示の順番を制御するリンクになります。
先頭のリンクを選択すると、一覧は再生成されて
その列の値でソートされます。
同じ先頭を続けて選択すると、交互に昇順と降順とになります。
これらの列の先頭のリンクは、
IndexOptions
ディレクティブの
SuppressColumnSorting
オプションで消すことができます。ディレクティブ
AddAlt AddAltByEncoding AddAltByType AddDescription AddIcon AddIconByEncoding AddIconByType DefaultIcon HeaderName IndexIgnore IndexOptions IndexOrderDefault ReadmeNameトピック
Autoindex リクエストクエリー引数
IndexOptions
IgnoreClient が導入されました。
C=N は、ファイル名でソートします。C=M は、更新日時、
ディレクトリ、ファイル名の順でソートします。C=S は、サイズ、
ディレクトリ、ファイル名の順でソートします。C=D は、説明、
ディレクトリ、ファイル名の順でソートします。O=A は、昇順で表をソートします。O=D は、降順で表をソートします。F=0 は、単純な表の書式にします。
(FancyIndex ではありません。)F=1 は、FancyIndex
表示の表の書式にします。F=2 は、表を HTML
のテーブルを使った FancyIndex の書式にします。V=0
は、バージョンによるソートを無効にします。V=1
は、バージョンによるソートを有効にします。P=pattern
は、与えられた pattern
に適合したファイルのみを表示します。IndexIgnore
ディレクティブが処理された後に検査され、
ファイル名全てが、他の autoindex
リスト処理と同様の判定基準下に置かれ続ける
ことに注意してください。
mod_autoindex のクエリー引数パーサ (解析) は、
認識不能なオプションにぶつかると即座に停止します。
クエリー引数は上の表に従って
正しい形式になっていなければなりません。
<form action="" method="get">
Show me a <select name="F">
<option value="0"> Plain list</option>
<option value="1" selected="selected"> Fancy list</option>
<option value="2"> Table list</option>
</select>
Sorted by <select name="C">
<option value="N" selected="selected"> Name</option>
<option value="M"> Date Modified</option>
<option value="S"> Size</option>
<option value="D"> Description</option>
</select>
<select name="O">
<option value="A" selected="selected"> Ascending</option>
<option value="D"> Descending</option>
</select>
<select name="V">
<option value="0" selected="selected"> in Normal order</option>
<option value="1"> in Version order</option>
</select>
Matching <input type="text" name="P" value="*" />
<input type="submit" name="X" value="Go" />
</form>
AddAlt ディレクティブ
説明: アイコンの代わりに
表示される、ファイル名で選択された代替テキスト 構文: AddAlt string file [file] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex AddAlt は、FancyIndexing
において、アイコンの代わりに表示する代替テキストを提供します。
file は、説明するファイルのファイル拡張子、
ファイル名の一部、ワイルドカード表現、完全なファイル名の
どれかになります。
string に空白がある場合は引用符 ("
か ') で囲む必要があります。
この文字列は、クライアントが画像を表示できない場合や
画像のロードを無効にしている場合や
アイコンの取得に失敗したときに表示されます。例
AddAlt "PDF file" *.pdf
AddAlt Compressed *.gz *.zip *.Z
AddAltByEncoding ディレクティブ
説明: アイコンの代わりに表示される、MIME 符号化方法で選択された
代替テキスト 構文: AddAltByEncoding string MIME-encoding
[MIME-encoding] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex AddAltByEncoding は、
FancyIndexing
において、アイコンの代わりに表示する代替文字列を提供します。
MIME-encoding は有効な符号化、例えば
x-compress
です。
string に空白があるときは、引用符 (" か
') で囲む必要があります。
この文字列は、クライアントが画像を表示できない場合や
画像のロードを無効にしている場合や
アイコンの取得に失敗したときに表示されます。例
AddAltByEncoding gzip x-gzip
AddAltByType ディレクティブ
説明: アイコンの代わりに
表示される、MIME タイプで選択された代替テキスト 構文: AddAltByType string MIME-type
[MIME-type] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex AddAltByType は、
FancyIndexing
において、アイコンの代わりに表示する代替文字列を設定します。
MIME-type は有効なタイプ、例えば
text/html
です。
string に空白があるときは、引用符 (" か
') で囲む必要があります。
この文字列は、クライアントが画像を表示できない場合や
画像のロードを無効にしている場合や
アイコンの取得に失敗したときに表示されます。例
AddAltByType 'plain text' text/plain
AddDescription ディレクティブ
説明: ファイルに対して表示する説明 構文: AddDescription string file [file] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex FancyIndexing
において、ファイルに対して表示する説明を設定します。
file は説明するファイルのファイル拡張子、
ファイル名の一部、ワイルドカード表現、完全なファイル名の
どれかになります。
string は二重引用符 (") で囲まれます。例
AddDescription "The planet Mars" /web/pics/mars.gif
IndexOptions SuppressIcon
オプションで 6 バイト追加、
IndexOptions SuppressSize
オプションで 7 バイト追加、
IndexOptions SuppressLastModified
オプションで 19 バイト追加されます。
ですから、デフォルトの説明コラムの最大幅は
55 バイトになります。IndexOptions
のキーワードをご覧下さい。警告
AddDescription
で定義された説明テキストは、タグや文字列といった
HTML マークアップを含むことができます。
もし、説明コラムの幅によってタグ付けされた要素が丸め込まれた
(太字の語句の最後が切れるといった) 場合、
出力結果は、ディレクトリ一覧の残りの部分に影響を与えるでしょう。AddIcon ディレクティブ
説明: ファイルに表示するアイコンを名前で選択 構文: AddIcon icon name
[name] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex FancyIndexing
において、
name で終わるファイルの隣に表示するアイコンを設定します。
icon は、(% でエスケープされた) アイコンへの相対 URL
か、他の書式 (alttext, url) です。
ここで alttext
は、非グラフィカルブラウザ向けにアイコンに付けられたテキストタグです。
^^DIRECTORY^^
か、空白行に対応する ^^BLANKICON^^ (一覧が正しく表示されるために) か、
ファイル拡張子か、ワイルドカード表現か、ファイル名の一部か
完全なファイル名です。例
AddIcon (IMG,/icons/image.xbm) .gif .jpg .xbm
AddIcon /icons/dir.xbm ^^DIRECTORY^^
AddIcon /icons/backup.xbm *~
AddIcon
より
AddIconByType
を優先的に使うべきでしょう。AddIconByEncoding ディレクティブ
説明: ファイルに表示するアイコンを MIME
符号化方法で選択 構文: AddIconByEncoding icon MIME-encoding
[MIME-encoding] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex FancyIndexing
において、ファイルの隣に表示するアイコンを設定します。
icon は、(% でエスケープされた) アイコンへの相対 URL
か、他の書式 (alttext, url) です。
ここで alttext
は、非グラフィカルブラウザ向けにアイコンに付けられたテキストタグです。
例
AddIconByEncoding /icons/compress.xbm x-compress
AddIconByType ディレクティブ
説明: ファイルの隣に表示するアイコンを
MIME タイプによって選択 構文: AddIconByType icon MIME-type
[MIME-type] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex FancyIndexing
において、ファイルの隣に表示するアイコンを設定します。
icon は、(% でエスケープされた) アイコンへの相対 URL
か、他の書式 (alttext, url) です。
ここで alttext
は、非グラフィカルブラウザ向けにアイコンに付けられたテキストタグです。
例
AddIconByType (IMG,/icons/image.xbm) image/*
DefaultIcon ディレクティブ
説明: 特定のアイコンが何も設定されていない時に
ファイルに表示するアイコン 構文: DefaultIcon url-pathコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex FancyIndexing
において、
特定のアイコンがない場合にファイルに表示するアイコンを設定します。
url-path は、(% でエスケープされた) アイコンへの相対 URL
です。例
DefaultIcon /icon/unknown.xbm
HeaderName ディレクティブ
説明:
インデックス一覧の先頭に挿入されるファイルの名前 構文: HeaderName filenameコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex HeaderName
ディレクティブは、
インデックス一覧の先頭に挿入するファイルの名前を設定します。
Filename は取り込むファイルの名前です。例
HeaderName HEADER.html
ReadmeName
も両方とも現在は、filename
をインデックスされているディレクトリに用いられた URI
に対する相対 URI パスとして扱います。
filename がスラッシュで始まる場合は、
DocumentRoot
からの相対パスとなります。例
HeaderName /include/HEADER.html
text/*"
(例えば、text/html,
text/plain 等です。)
のドキュメントとして解決
されなければなりません。これはつまり、
もし CGI スクリプトの実際のファイルタイプが
次のディレクティブのようにして実際の出力とは異なって
text/html としてマークされている場合、
filename
は CGI スクリプトを参照するかも知れない、
ということを意味します:
AddType text/html .cgi
Options MultiViews が
有効になっている場合は、
コンテントネゴシエーション
が行なわれます。
もし filename が (CGI スクリプトでない) 静的な
text/html ドキュメントで解決され、
options
Includes か IncludesNOEXEC
が有効になっている場合は、
ファイルはサーバーサイドインクルードで処理されます
(mod_include ドキュメントを参照して下さい)。HeaderName で指定されたファイルが
HTML ドキュメントの開始部分 (<html>, <head>,
等) を含んでいたら、
IndexOptions
+SuppressHTMLPreamble
を設定して、これらのタグが繰り返されないようにしたいと思うでしょう。IndexIgnore ディレクティブ
説明: ディレクトリ一覧を行なう際に無視すべき
ファイルリストに追加 構文: IndexIgnore file [file] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex IndexIgnore ディレクティブは、
ディレクトリの一覧を行う際に無視すべきファイルリストに追加します。
file は、
シェル形式のワイルドカード表現か完全なファイル名です。
IndexIgnore が複数ある場合は、無視するリストに追加が行われ、
置換は行われません。デフォルトではリストには .
(カレントディレクトリ) が含まれています。
IndexIgnore README .htaccess *.bak *~
IndexOptions ディレクティブ
説明: ディレクトリインデックスの様々な設定項目
構文: IndexOptions [+|-]option [[+|-]option] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex IndexOptions
は、ディレクトリインデックスの挙動を指定します。
option は次のどれかです:
DescriptionWidth
キーワードは説明コラムの幅を文字数で指定することができます。-DescriptionWidth (または非設定) で、
mod_autoindex が最適な幅を計算するようにできます。DescriptionWidth=n
で、コラム幅を n バイトに固定します。DescriptionWidth=*
は、最長の説明に合わせて必要な長さまでコラムを延ばします。AddDescription
セクションをお読み下さい。FoldersFirst が有効になっている場合は、
サブディレクトリ Zed はサブディレクトリ
Beta よりも前にリストされ、通常のファイル
Gamma や Alpha
よりも前にリストされます。このオプションは
FancyIndexing
も有効になっているときにのみ、効果があります。img
タグに height と width
属性を取り込むようになります。
これによって、イメージ全てをロードし終わるまで待たなくても、
ブラウザはページレイアウトをあらかじめ計算することができます。
このオプションに何も値が与えられなければ、Apache
ソフトウェアで提供されているアイコンの標準の高さが
デフォルトなります。IconHeight とともに使われている場合は、
サーバはファイルアイコンのための img
タグに height と width
属性を取り込むようになります。
これによって、イメージ全てをロードし終わるまで待たなくても、
ブラウザはページレイアウトをあらかじめ計算することができます。
このオプションに何も値が与えられなければ、Apache
ソフトウェアで提供されているアイコンの標準の高さが
デフォルトなります。mod_autoindex は、
クライアントからの全てのクエリー変数を無視するようになります。
これはソート順も含みます。
(つまり SuppressColumnSorting
を暗に意味します。)NameWidth キーワードでファイル名コラムの幅をバイト数で
指定できます。-NameWidth (または非設定) で、
mod_autoindex が最適な幅を計算するようにできます。NameWidth=n
で、コラム幅を n バイトに固定します。NameWidth=*
は、必要な長さまでコラムを延ばします。AddDescription
で説明が与えられていなければ、
httpd は title タグの値を読むためにドキュメントを読み始めます。
これは CPU や disk に負荷をかけます。AddDescription
をご覧下さい。また、説明のコラムサイズを制限する
DescriptionWidth
インデックスオプションもご覧下さい。HeaderName
ディレクティブで指定したファイルを
ディレクトリが実際に含んでいれば、標準的な HTML プリアンブル
(<html>, <head>, 等) の後に、
モジュールはファイルの中身をインクルードします。
SuppressHTMLPreamble オプションは、
この挙動を無効にできて、
モジュールがヘッダーファイルの中身から表示を始めます。
この場合、ヘッダーファイルは正しい HTML
命令を含んでいなければなりません。
ヘッダーファイルが存在しない場合は、プリアンブルは通常通り
生成されます。SuppressIcon と SuppressRules
と組合わせることによって正しい HTML 3.2 の出力が得られます。
正しい HTML 3.2 出力は、最終規格において img と hr
が pre ブロックに入る (FancyIndexing 一覧で書式に使われています)
ことを禁止しています。hr タグ) を消去します。
SuppressIcon と SuppressRules
と組合わせることによって正しい HTML 3.2 の出力が得られます。
正しい HTML 3.2 出力は、最終規格において img と hr
が pre ブロックに入る (FancyIndexing 一覧で書式に使われています)
ことを禁止しています。HEAD リクエストを行うことによって、
ファイル一覧の変化を追跡することができるようになります。
いくつかのオペレーティングシステムは、新規ファイルや
移動ファイルは正しく追跡するけれども、
ディレクトリ中のファイルのサイズや日付は追跡ないということに
注意してください。
既に存在するファイルのサイズや日付のスタンプが変化しても、
全ての Unix プラットホームでは、
最終更新日ヘッダーを更新しません。
もしこれが重要であれば、
このオプションを無効のままにしてください。VersionSort キーワードはバージョン番号を含んだファイルが
自然な方法でソートされるようにします。
文字列は通常通りソートされ、
それ以外の、説明や名前中の数となる部分文字列は
その数値で比較されます。
例:
foo-1.7
foo-1.7.2
foo-1.7.12
foo-1.8.2
foo-1.8.2a
foo-1.12
foo-1.001
foo-1.002
foo-1.030
foo-1.04
XHTML キーワードを指定すると、mod_autoindex
は HTML 3.2 の代わりに XHTML 1.0 のコードを出力するようになります。IndexOptions
ディレクティブの扱いで幾つかの大きな変化が導入されました。
特に、
IndexOptions
ディレクティブは、現在では一つにマージされます。
上の例の結果は、
<Directory /foo>
IndexOptions HTMLTable
IndexOptions SuppressColumnsorting
</Directory>
IndexOptions HTMLTable SuppressColumnsorting
IndexOptions
の設定 (これは上流のディレクトリを受け継ぎます)
に対して適応されます。
しかしながら、接頭辞の付かないキーワードが処理された場合は、
受け継いだオプション全てとそれまで出会った増減設定全てが
消去されます。次の例を考えてみてください:
IndexOptions +ScanHTMLTitles -IconsAreLinks FancyIndexing
IndexOptions +SuppressSize
IndexOptions FancyIndexing +SuppressSize
と同一です。
接頭辞の付かない FancyIndexing
でそれ以前の増減キーワードを無効にされて、
その後の累積が始まるからです。IndexOptions
をあるディレクトリで設定することによって
継承した設定を消去して、+ や -
接頭辞の付かないキーワードで設定してください。IndexOrderDefault ディレクティブ
説明:
ディレクトリインデックスの標準の順番付けを設定 構文: IndexOrderDefault Ascending|Descending
Name|Date|Size|Descriptionデフォルト: IndexOrderDefault Ascending Nameコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex IndexOrderDefault ディレクティブは
FancyIndexing
インデックスオプションと併せて用いれれます。
デフォルトでは、FancyIndexing
のディレクトリ一覧はファイル名の昇順で表示されます。
IndexOrderDefault
で、初期状態の表示順番を変えることができます。IndexOrderDefault
は二つの引数をとります。一つ目はソートの方向を指示する
Ascending か Descending のいずれかです。
二つ目の引数は Name, Date,
Size か Description
のいずれか一つのキーワードであって、プライマリキーを指定します。
二つ目のキーは常にファイル名の昇順になります。SuppressColumnSorting
インデックスオプションとを組み合わせることで、
ディレクトリ一覧をある特定の順番でのみ表示するようにできます。
これは、
クライアントが別の順番でディレクトリ一覧をリクエストすることを防ぎます。ReadmeName ディレクティブ
説明: インデックス一覧の最後に挿入されるファイルの名前 構文: ReadmeName filenameコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_autoindex ReadmeName ディレクティブは、
インデックスの終わりに付け加えられるファイルの名前を設定します。
filename は挿入するファイルの名前で、
一覧の行われている位置から相対的なものとして解釈されます。
filename がスラッシュで始まる場合は、
DocumentRoot
からの相対パスとなります。例
ReadmeName FOOTER.html
例 2
ReadmeName /include/FOOTER.html
HeaderName
もご覧下さい。
mod/mod_cern_meta.html 100644 0 0 16652 11074463036 12504 0 ustar 0 0
Apache Module mod_cache
Description: Content cache keyed to URIs. Status: Experimental ModuleIdentifier: cache_module SourceFile: mod_cache.c Summary
This module is experimental. Documentation is still under development...
mod_cache implements an RFC 2616 compliant HTTP
content cache that can be used to cache either local or proxied content.
mod_cache requires the services of one or more storage
management modules. Two storage management modules are included in
the base Apache distribution:
mod_disk_cachemod_mem_cachemod_mem_cache can be configured to operate in two
modes: caching open file descriptors or caching objects in heap storage.
mod_mem_cache can be used to cache locally generated content
or to cache backend server content for mod_proxy when
configured using ProxyPass
(aka reverse proxy)Directives
CacheDefaultExpire CacheDisable CacheEnable CacheForceCompletion CacheIgnoreCacheControl CacheIgnoreHeaders CacheIgnoreNoLastMod CacheLastModifiedFactor CacheMaxExpireTopics
Related Modules and Directives
Related Modules Related Directives
Sample Configuration
Sample httpd.conf
#
# Sample Cache Configuration
#
LoadModule cache_module modules/mod_cache.so
<IfModule mod_cache.c>
#LoadModule disk_cache_module modules/mod_disk_cache.so
<IfModule mod_disk_cache.c>
CacheRoot c:/cacheroot
CacheSize 256
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
</IfModule>
LoadModule mem_cache_module modules/mod_mem_cache.so
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 4096
MCacheMaxObjectCount 100
MCacheMinObjectSize 1
MCacheMaxObjectSize 2048
</IfModule>
</IfModule>
CacheDefaultExpire Directive
Description: The default duration to cache a document when no expiry date is specified. Syntax: CacheDefaultExpire secondsDefault: CacheDefaultExpire 3600 (one hour)Context: server config, virtual host Status: Experimental Module: mod_cache CacheDefaultExpire directive specifies a default time,
in seconds, to cache a document if neither an expiry date nor last-modified date are provided
with the document. The value specified with the CacheMaxExpire
directive does not override this setting.
CacheDefaultExpire 86400
CacheDisable Directive
Description: Disable caching of specified URLs Syntax: CacheDisable url-stringContext: server config, virtual host Status: Experimental Module: mod_cache CacheDisable directive instructs
mod_cache to not cache urls at or below
url-string.Example
CacheDisable /local_files
CacheEnable Directive
Description: Enable caching of specified URLs using a specified storage
manager Syntax: CacheEnable cache_type url-stringContext: server config, virtual host Status: Experimental Module: mod_cache CacheEnable directive instructs
mod_cache to cache urls at or below
url-string. The cache storage manager is specified with the
cache_type argument. cache_type mem
instructs mod_cache to use the memory based storage
manager implemented by mod_mem_cache.
cache_type disk instructs
mod_cache to use the disk based storage manager
implemented by mod_disk_cache.
cache_type fd instructs
mod_cache to use the file descriptor cache implemented
by mod_mem_cache.CacheEnable directives (as in the example below),
each possible storage manager will be run until the first one that
actually processes the request. The order in which the storage managers are
run is determined by the order of the CacheEnable
directives in the configuration file.
CacheEnable mem /manual
CacheEnable fd /images
CacheEnable disk /
CacheForceCompletion Directive
Description: Percentage of document served, after which the server
will complete caching the file even if the request is cancelled. Syntax: CacheForceCompletion PercentageDefault: CacheForceCompletion 60Context: server config, virtual host Status: Experimental Module: mod_cache CacheForceCompletion directive specifies a
threshold beyond which the document will continue to be cached to
completion, even if the request is cancelled.1 and 100. A value of 0
specifies that the default be used. A value of 100
will only cache documents that are served in their entirety. A value
between 60 and 90 is recommended.
CacheForceCompletion 80
Note:
This feature is currently not implemented.
CacheIgnoreCacheControl Directive
Description: Ignore the fact that the client requested the content not be
cached. Syntax: CacheIgnoreCacheControl On|OffDefault: CacheIgnoreCacheControl OffContext: server config, virtual host Status: Experimental Module: mod_cache CacheIgnoreCacheControl directive allows this behavior to be overridden.
CacheIgnoreCacheControl On tells the server to attempt to cache the document
even if it contains no-cache or no-store header values. Documents requiring authorization will
never be cached.
CacheIgnoreCacheControl On
CacheIgnoreHeaders Directive
Description: Do not store the given HTTP header(s) in the cache.
Syntax: CacheIgnoreHeaders header-string [header-string] ...Default: CacheIgnoreHeaders NoneContext: server config, virtual host Status: Experimental Module: mod_cache CacheIgnoreHeaders:
ConnectionKeep-AliveProxy-AuthenticateProxy-AuthorizationTETrailersTransfer-EncodingUpgradeCacheIgnoreHeaders specifies additional HTTP
headers that should not to be stored in the cache. For example, it makes
sense in some cases to prevent cookies from being stored in the cache.CacheIgnoreHeaders takes a space separated list
of HTTP headers that should not be stored in the cache. If only hop-by-hop
headers not should be stored in the cache (the RFC 2616 compliant
behaviour), CacheIgnoreHeaders can be set to
None.Example 1
CacheIgnoreHeaders Set-Cookie
Example 2
CacheIgnoreHeaders None
Warning:
If headers like Expires which are needed for proper cache
management are not stored due to a
CacheIgnoreHeaders setting, the behaviour of
mod_cache is undefined.
CacheIgnoreNoLastMod Directive
Description: Ignore the fact that a response has no Last Modified
header. Syntax: CacheIgnoreNoLastMod On|OffDefault: CacheIgnoreNoLastMod OffContext: server config, virtual host Status: Experimental Module: mod_cache mod_include processing for example) or not provided
at all. The CacheIgnoreNoLastMod directive
provides a way to specify that documents without last-modified dates
should be considered for caching, even without a last-modified date.
If neither a last-modified date nor an expiry date are provided with
the document then the value specified by the
CacheDefaultExpire directive will be used to
generate an expiration date.
CacheIgnoreNoLastMod On
CacheLastModifiedFactor Directive
Description: The factor used to compute an expiry date based on the
LastModified date. Syntax: CacheLastModifiedFactor floatDefault: CacheLastModifiedFactor 0.1Context: server config, virtual host Status: Experimental Module: mod_cache CacheLastModifiedFactor directive specifies a
factor to be used in the generation of this expiry date
according to the following formula:
expiry-period = time-since-last-modified-date * factor
expiry-date = current-date + expiry-period
For example, if the document was last modified 10 hours ago, and
factor is 0.1 then the expiry-period will be set to
10*0.1 = 1 hour. If the current time was 3:00pm then the computed
expiry-date would be 3:00pm + 1hour = 4:00pm.
If the expiry-period would be longer than that set by
CacheMaxExpire, then the latter takes
precedence.
CacheLastModifiedFactor 0.5
CacheMaxExpire Directive
Description: The maximum time in seconds to cache a document Syntax: CacheMaxExpire secondsDefault: CacheMaxExpire 86400 (one day)Context: server config, virtual host Status: Experimental Module: mod_cache CacheMaxExpire directive specifies the maximum number of
seconds for which cachable HTTP documents will be retained without checking the origin
server. Thus, documents will be out of date at most this number of seconds. This maximum
value is enforced even if an expiry date was supplied with the document.
CacheMaxExpire 604800
mod/mod_cgi.html 100644 0 0 33204 11074463036 11301 0 ustar 0 0
Apache Module mod_cern_meta
Description: CERN httpd metafile semantics Status: Extension ModuleIdentifier: cern_meta_module SourceFile: mod_cern_meta.c Summary
MetaDir Directive
Description: Name of the directory to find CERN-style meta information
files Syntax: MetaDir directoryDefault: MetaDir .webContext: server config, virtual host, directory, .htaccess Override: Indexes Status: Extension Module: mod_cern_meta ." to look in the same directory
as the file:MetaDir .MetaDir .metaMetaFiles Directive
Description: Activates CERN meta-file processing Syntax: MetaFiles on|offDefault: MetaFiles offContext: server config, virtual host, directory, .htaccess Override: Indexes Status: Extension Module: mod_cern_meta MetaSuffix Directive
Description: File name suffix for the file containg CERN-style
meta information Syntax: MetaSuffix suffixDefault: MetaSuffix .metaContext: server config, virtual host, directory, .htaccess Override: Indexes Status: Extension Module: mod_cern_meta DOCUMENT_ROOT/somedir/index.html to look in
DOCUMENT_ROOT/somedir/.web/index.html.meta and
will use its contents to generate additional MIME header
information.Example:
MetaSuffix .meta
mod/mod_cgid.html 100644 0 0 13506 11074463036 11450 0 ustar 0 0
Apache モジュール mod_cgi
説明: CGI スクリプトの実行 ステータス: Base モジュール識別子: cgi_module ソースファイル: mod_cgi.c 概要
application/x-httpd-cgi
であるか、ハンドラ cgi-script (Apache 1.1 以降)
が指定されているファイルは CGI スクリプトとして扱われ、
サーバにより実行され、その出力がクライアントに返されます。
ファイルは、AddType
ディレクティブに指定された 拡張子を名前に含むか、
ScriptAlias
ディレクトリに存在することによりこのタイプになります。DOCUMENT_ROOT
と呼ばれる変数を環境に追加します。この変数は
DocumentRoot
の値を保持します。mod_cgid を使う必要があります。
ユーザレベルではこの二つのモジュールは本質的には同一です。ディレクティブ
トピック
参照
CGI 環境変数
AcceptPathInfo ディレクティブが明示的に off
に設定されている場合は設定されません。デフォルトの、
AcceptPathInfo が
指定されていないときの振る舞いでは、mod_cgi はパス情報
(URI のスクリプトのファイル名の後に続く /more/path/info) を
受け付けますが、コアはサーバはパス情報のあるリクエストに
対して 404 NOT FOUND エラーを返します。AcceptPathInfo
ディレクティブを
省略すると、mod_cgi へのリクエストに対して
On を
設定したのと同じ効果になります。HostnameLookups
が on (デフォルトでは off です)
で、アクセスしているホストのアドレスの DNS
の逆引きが実際にホスト名を見つけたときにのみ設定されます。IdentityCheck
が on に設定されていて、アクセスしているホストが
ident プロトコルをサポートしているときにのみ設定されます。
これは簡単に偽ることができ、クライアントとサーバの間に
プロキシがあればまったく役に立たないので、
この変数の値は信用できないということに注意してください。
CGI のデバッグ
CGI ログファイルの書式
%% [time] request-line
%% HTTP-status CGI-script-filename
%%error
error-message
%request
受け取ったすべての HTTP リクエストヘッダ
(もしあれば) POST や PUT の中身
%response
CGI スクリプトにより出力されたすべてのヘッダ
%stdout
CGI 標準出力
%stderr
CGI 標準エラー
ScriptLog ディレクティブ
説明: CGI スクリプトのエラーログファイルの場所 構文: ScriptLog file-pathコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_cgi, mod_cgidScriptLog ディレクティブは CGI スクリプトの
エラーログファイルを設定します。ScriptLog が
設定されていないときは、
エラーログは作成されません。設定されているときは、CGI
のエラーはすべて引数として与えられているファイル名にログされます。
相対パスで指定されているときは、
ServerRootからの相対パスとして
扱われます。例
ScriptLog logs/cgi_log
User ディレクティブで指定された
ユーザです。これは、スクリプトログが書かれるディレクトリがそのユーザで
書き込み可能か、スクリプトファイルが手動で作成され、そのユーザで
書き込み可能になっている必要があるということです。スクリプトログを
アクセスログなどのためのログディレクトリに書かれるようにしたときは、
そのディレクトリを子プロセスを実行しているユーザの権限で
書き込み可能にはしないようにしてください。ScriptLogBuffer ディレクティブ
説明: スクリプトログに記録される PUT や POST リクエストの内容の上限 構文: ScriptLogBuffer bytesデフォルト: ScriptLogBuffer 1024コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_cgi, mod_cgidScriptLogLength ディレクティブ
説明: CGI スクリプトのログファイルの大きさの上限 構文: ScriptLogLength bytesデフォルト: ScriptLogLength 10385760コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_cgi, mod_cgidScriptLogLength は CGI スクリプトのログファイル
の大きさを制限するために使用することができます。ログファイルは
CGI のエラー毎に大量の情報 (リクエストのすべてのヘッダ、
すべての出力)をログしますので、すぐに大きなファイルになります。
この大きさの制限がないことによる問題を防ぐために、
このディレクティブを使って CGI のログファイルの
最大のファイルサイズを設定することができます。
ファイルがこの大きさを超えた場合は、それ以上は書き込まれません。
mod/mod_charset_lite.html 100644 0 0 27267 11074463036 13221 0 ustar 0 0
Apache モジュール mod_cgid
説明: 外部 CGI デーモンを使った CGI スクリプトの実行 ステータス: Base モジュール識別子: cgid_module ソースファイル: mod_cgid.c 互換性: Unix のスレッド MPM のみ 概要
ScriptSock ディレクティブを除いては、
mod_cgid は mod_cgi と同様の
動作をします。Apache と CGI に関する詳細は
mod_cgi の概要を読んでください。mod_cgid
は子プロセスを fork して CGI スクリプトを実行するための
外部デーモンを実行します。
主サーバは unix ドメインソケットを使ってこのデーモンと通信します。mod_cgi の代わりに必ずこのモジュールが使用されます。
ユーザのレベルではこのモジュールの設定と動作は mod_cgi
とまったく同じです。唯一の例外は ScriptSock ディレクティブの
追加で、このディレクティブは CGI デーモンとの通信用のソケットの名前を
指定します。ScriptSock ディレクティブ
説明: CGI デーモンとの通信に使われるソケットの名前 構文: ScriptSock file-pathデフォルト: ScriptSock logs/cgisockコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_cgid 例
ScriptSock /var/run/cgid.sock
mod/mod_dav.html 100644 0 0 36010 11074463036 11307 0 ustar 0 0
Apache Module mod_charset_lite
Description: Specify character set translation or recoding Status: Experimental ModuleIdentifier: charset_lite_module SourceFile: mod_charset_lite.c Summary
mod_charset_lite configuration to ensure that it
performs the desired function.mod_charset_lite allows the administrator to
specify the source character set of objects as well as the
character set they should be translated into before sending to the
client. mod_charset_lite does not translate the
data itself but instead tells Apache what translation to
perform. mod_charset_lite is applicable to EBCDIC
and ASCII host environments. In an EBCDIC environment, Apache
normally translates text content from the code page of the Apache
process locale to ISO-8859-1. mod_charset_lite
can be used to specify that a different translation is to be
performed. In an ASCII environment, Apache normally performs no
translation, so mod_charset_lite is needed in
order for any translation to take place.mod_charset.
Common Problems
Invalid character set names
CharsetSourceEnc and
CharsetDefault
must be acceptable to the translation mechanism used by APR on the
system where mod_charset_lite is deployed. These
character set names are not standardized and are usually not the
same as the corresponding values used in http headers. Currently,
APR can only use iconv(3), so you can easily test your character
set names using the iconv(1) program, as follows:
iconv -f charsetsourceenc-value -t charsetdefault-value
Mismatch between character set of content and translation
rules
CharsetDefault Directive
Description: Charset to translate into Syntax: CharsetDefault charsetContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Experimental Module: mod_charset_lite CharsetDefault directive specifies the
charset that content in the associated container should be
translated to.Example
<Directory /export/home/trawick/apacheinst/htdocs/convert>
CharsetSourceEnc UTF-16BE
CharsetDefault ISO-8859-1
</Directory>
CharsetOptions Directive
Description: Configures charset translation behavior Syntax: CharsetOptions option [option] ...Default: CharsetOptions DebugLevel=0 NoImplicitAddContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Experimental Module: mod_charset_lite CharsetOptions directive configures certain
behaviors of mod_charset_lite. Option can
be one of
DebugLevel=nDebugLevel keyword allows you to specify
the level of debug messages generated by
mod_charset_lite. By default, no messages are
generated. This is equivalent to DebugLevel=0.
With higher numbers, more debug messages are generated, and
server performance will be degraded. The actual meanings of
the numeric values are described with the definitions of the
DBGLVL_ constants near the beginning of
mod_charset_lite.c.ImplicitAdd | NoImplicitAddImplicitAdd keyword specifies that
mod_charset_lite should implicitly insert its
filter when the configuration specifies that the character
set of content should be translated. If the filter chain is
explicitly configured using the AddOutputFilter directive, NoImplicitAdd
should be specified so that mod_charset_lite
doesn't add its filter.CharsetSourceEnc Directive
Description: Source charset of files Syntax: CharsetSourceEnc charsetContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Experimental Module: mod_charset_lite CharsetSourceEnc directive specifies the
source charset of files in the associated container.Example
<Directory /export/home/trawick/apacheinst/htdocs/convert>
CharsetSourceEnc UTF-16BE
CharsetDefault ISO-8859-1
</Directory>
mod/mod_dav_fs.html 100644 0 0 11456 11074463036 12006 0 ustar 0 0
Apache モジュール mod_dav
説明: 分散オーサリングとバージョン管理
(WebDAV) 機能 ステータス: Extension モジュール識別子: dav_module ソースファイル: mod_dav.c 概要
ディレクティブ
トピック
参照
Enabling WebDAV
httpd.conf
ファイル中のコンテナに次を加えます:Dav Onmod_dav_fs
モジュールで実装されています。ですから、このモジュールはコンパイル時に
サーバに組み込まれているか、あるいは
LoadModule
を使用して実行時にロードされている必要があります。DavLockDB ディレクティブを使って
httd.conf ファイルのグローバルセクションに指定されている
必要があります。
DavLockDB /usr/local/apache2/var/DavLock
User と Group に書き込み権限がある必要があります。<Limit>
節を <Location>
ディレクティブ内部に追加して、DAV が有効な場所への
アクセスを制限することもできます。DAV クライアントが
一度のリクエストで送信できる最大バイト数を指定したいときは、
LimitXMLRequestBody
ディレクティブを使用する必要があります。「通常の」
LimitRequestBody
ディレクティブは DAV リクエストに対しては効力を持ちません。完全な例
DavLockDB /usr/local/apache2/var/DavLock
<Location /foo>
Dav On
AuthType Basic
AuthName DAV
AuthUserFile user.passwd
<LimitExcept GET OPTIONS>
require user admin
</LimitExcept>
</Location>
mod_dav は Greg Stein さんの Apache 1.3 用の mod_dav に
由来するものです。そのサイトからより多くの情報を手に入れることができます。
セキュリティの問題
mod_dav を使用する
前に、サーバが安全であることを特に注意して確認しなければなりません。mod_auth_digest モジュールで提供される HTTP
ダイジェスト認証を用いるべきです。WebDAV クライアントのほとんどは
この認証方法に対応しています。代わりに、SSL が
有効なコネクションを通した基本認証を使うこともできます。mod_dav がファイルを操作できるようにするためには、
管理下のディレクトリとファイルとに Apache が実行されている User と Group で書き込み可能である必要があります。
新しく作成されるファイルもこの User
と Group に所有される
ことになります。この理由から、そのアカウントへのアクセスを制御することは
重要です。DAV リポジトリは Apache 専用のものだとみなされています。
Apache 以外の方法でファイルを修正すること (例えば FTP やファイルシステム
用のツールなどを使って) は許可されていません。mod_dav はいろいろな種類のサービス拒否攻撃にさらされる
かもしれません。LimitXMLRequestBody ディレクティブを使うと
大きな DAV リクエストを解析するときに消費されるメモリの量を制限することが
できます。DavDepthInfinity ディレクティブは
PROPFIND リクエストが巨大リポジトリで大量のメモリを消費するのを
防ぐことができます。他のサービス拒否攻撃には単純に使用可能なディスク領域を
多くの大きなファイルで埋めてしまうんものがあります。これを直接防ぐ方法は
Apache にはありませんので、信用できないユーザに DAV アクセスを提供するのは
避けた方が良いでしょう。
複雑な設定
mod_dav を使って動的なファイル
(PHP スクリプト、CGI スクリプトなど) を操作したいというものがあります。
これの実現は、GET リクエストはスクリプトの内容をダウンロードさせる
代わりに、スクリプトを常に実行させてしまうので難しくなっています。
これを回避する方法には、二つの違う URL を同じコンテンツにマップし、
一つはスクリプトを実行させ、もう一つはダウンロードさせたり、DAV から
操作されたりするように設定するというものがあります。
Alias /phparea /home/gstein/php_files
Alias /php-source /home/gstein/php_files
<Location /php-source>
DAV On
ForceType text/plain
</Location>
http://example.com/phparea を PHP スクリプトの
出力をアクセスするために使うことができ、
http://example.com/php-source を DAV クライアントによる
が操作のために使うことができます。Dav ディレクティブ
説明: WebDAV HTTP メソッドを有効にします 構文: Dav On|Off|provider-nameデフォルト: Dav Offコンテキスト: ディレクトリ ステータス: Extension モジュール: mod_dav
<Location /foo>
Dav On
</Location>
On という指定は実際には mod_dav_fs
で提供されているデフォルトのプロバイダ、filesystem
へのエイリアスになっています。一度あるロケーションで DAV
を有効にした後は、そのサブロケーションで無効化することはできない
ということに注意してください。完全な設定例は上記のセクション をご覧下さい。
サーバのセキュリティが確保できるまで WebDAV を有効にしないでください。
そうしなければ誰でもそのサーバでファイルを配布することができるように
なってしまいます。
DavDepthInfinity ディレクティブ
説明: PROPFIND, Depth: Infinity リクエストを許可します 構文: DavDepthInfinity on|offデフォルト: DavDepthInfinity offコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ ステータス: Extension モジュール: mod_dav PROPFIND リクエストを処理できるようにするには、
DavDepthInfinity
ディレクティブを使います。このタイプのリクエストは
denial-of-service アタックとなりうるので、
デフォルトでは許可されていません。DavMinTimeout ディレクティブ
説明: サーバが DAV リソースのロックを維持する最小時間です。
構文: DavMinTimeout secondsデフォルト: DavMinTimeout 0コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ ステータス: Extension モジュール: mod_dav DavMinTimeout
ディレクティブを使います。
マイクロソフトのウェブフォルダのデフォルトでは 120 秒ですが；
ネットワークの遅延のせいでクライアントがロックを失うのを減らすために、
DavMinTimeout を使って
これをもっと大きな値 (例えば 600 秒) に上書きできます。例
<Location /MSWord>
DavMinTimeout 600
</Location>
mod/mod_deflate.html 100644 0 0 45673 11074463036 12160 0 ustar 0 0
Apache モジュール mod_dav_fs
説明: mod_dav のためのファイルシステムプロバイダステータス: Extension モジュール識別子: dav_fs_module ソースファイル: mod_dav_fs.c 概要
mod_dav
のサービスを必要とします。mod_dav
のサポートモジュールとして動作し、サーバファイルシステム上に
位置するリソースへのアクセスを提供します。このプロバイダの正式な名前は
filesystem です。mod_dav
バックエンドプロバイダは Dav
ディレクティブを使用して起動されます。例
Dav filesystem
filesystem は mod_dav
のデフォルトプロバイダになっていますから、代わりに単に
On と指定することもできます。DavLockDB ディレクティブ
説明: DAV ロックデータベースの位置 構文: DavLockDB file-pathコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Extension モジュール: mod_dav_fs DavLockDB
を使います。パスが絶対パスでなければ、ServerRoot からの相対パスと解釈されます。
mod_dav_fs 実装では、ユーザロックを
追跡するために SDBM データベースを使います。例
DavLockDB logs/DavLock
mod/mod_dir.html 100644 0 0 23443 11074463036 11321 0 ustar 0 0
Apache モジュール mod_deflate
説明: クライアントへ送られる前にコンテンツを圧縮する ステータス: Extension モジュール識別子: deflate_module ソースファイル: mod_deflate.c 概要
mod_deflate モジュールは DEFLATE
出力フィルタを提供します。これはサーバからの出力を、ネットワークを
通してクライアントに送る前に圧縮することを可能にします。ディレクティブ
トピック
参照
サンプル設定
数タイプのみ圧縮する
AddOutputFilterByType DEFLATE text/html text/plain text/xml
画像以外全て圧縮する
<Location />
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
# BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</Location>
圧縮を有効にする
Output Compression
DEFLATE フィルタ
により実装されています。以下のディレクティブはそのディレクティブのある
コンテナ中のドキュメントを圧縮するようにします:
SetOutputFilter DEFLATE
gzip-only-text/html
ノートを 1 にして、html ファイルに対してのみ
圧縮が働くようにした方がよいかもしれません (以下参照)
この値を 1 以外の値に設定した場合は無視されます。AddOutputFilterByType
ディレクティブを使用します。次に Apache のドキュメントの html
ファイルのみの圧縮を有効にする例を示します。
<Directory "/your-server-root/manual">
AddOutputFilterByType DEFLATE text/html
</Directory>
BrowserMatch
ディレクティブを使用して、特定のブラウザに no-gzip
ノートをセットし、圧縮が行なわれないようにします。
no-gzip と gzip-only-text/html
を組み合わせることで上手く対処できます。
この場合、前者が後者をオーバーライドします。
上記の設定例の抜粋を
次に示しますのでご覧下さい。
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
User-Agent 文字列から Netscape Navigator
4.x であるかどうかを調べます。これらのバージョンでは、
text/html 以外のタイプの圧縮を扱うことができません。
4.06, 4.07, 4.08 は html ファイルの伸張にも問題を抱えています。
ですからこれらに対しては、完全に deflate フィルタをオフにします。BrowserMatch
ディレクティブで、推測したユーザーエージェントを修正します。
なぜなら Microsoft Internet Explorer も "Mozilla/4" と特定されますが、
これらは実際には圧縮を扱うことができるからです。
User-Agent ヘッダを "MSIE"
(\b は「単語の境界」を意味します) の追加文字で検査して、
これ以前に設定した制限を再び解除します。注
DEFLATE フィルタは必ず、PHP や SSI といった RESOURCE
フィルタの後になります。
DEFLATE フィルタは内部的なサブリクエストを関知しません。
入力の伸張
mod_deflate モジュールは、gzip
で圧縮されたリクエスト本体を伸張するフィルタも提供しています。
この機能を有効にするには、SetInputFilter
か AddInputFilter を使用して、
DEFLATE フィルタを入力フィルタチェインに組み込みます。
例えば次のようになります。
<Location /dav-area>
SetInputFilter DEFLATE
</Location>
Content-Encoding: gzip
ヘッダを含むリクエストが来ると、本体は自動的に伸張されます。
gzip リクエスト本体を送信するブラウザはあまりありません。
しかし、例えば WebDAV
クライアントの幾つかなど、特別なアプリケーションでリクエストの
圧縮を実際にサポートしているものもあります。Content-Length に関する注意
Content-Length
ヘッダを信用しないでください。Content-Length ヘッダは、
クライアントから送信されるデータの長さを反映しているのであって、
伸張されたデータストリームのバイトカウントではありません。
Proxy サーバでの扱い
mod_deflate モジュールは Vary: Accept-Encoding
HTTP 応答ヘッダを送信して、適切な Accept-Encoding
リクエストヘッダを送信するクライアントに対してのみ、
プロクシサーバがキャッシュした応答を送信するように注意を喚起します。
このようにして、圧縮を扱うことのできないクライアントに
圧縮された内容が送られることのないようにします。User-Agent
ヘッダなどに依存している場合、手動で Vary ヘッダを設定して、
追加の制限についてプロクシサーバに注意を行なう必要があります。
例えば User-Agent に依存して DEFLATE
を追加する典型的な設定では、次のように追加することになります。
Header append Vary User-Agent
Vary ヘッダを * に設定する必要があります。
このようにすると、仕様に準拠したプロクシはキャッシュを全く行なわなくなります。例
Header set Vary *
DeflateBufferSize ディレクティブ
説明: zlib が一度に圧縮する塊の大きさ 構文: DeflateBufferSize valueデフォルト: DeflateBufferSize 8096コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Extension モジュール: mod_deflate DeflateBufferSize ディレクティブは
zlib が一度に圧縮する塊の大きさをバイト単位で指定します。DeflateCompressionLevel ディレクティブ
説明: 出力に対して行なう圧縮の程度 構文: DeflateCompressionLevel valueデフォルト: Zlib のデフォルトコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Extension モジュール: mod_deflate 互換性: This directive is available since Apache 2.0.45 DeflateCompressionLevel ディレクティブは
圧縮の程度を設定します。大きな値では、より圧縮が行なわれますが、
CPU 資源を消費します。DeflateFilterNote ディレクティブ
説明: ロギング用に圧縮比をメモに追加 構文: DeflateFilterNote [type] notenameコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Extension モジュール: mod_deflate 互換性: type is available since Apache 2.0.45 DeflateFilterNote ディレクティブは
圧縮比に関するメモがリクエストに付加されることを指定します。
メモ (note) の名前はディレクティブに指定された値です。
メモはアクセスログに
値を記録し、統計を取る目的にも使えます。例
DeflateFilterNote ratio
LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate
CustomLog logs/deflate_log deflate
InputOutputRatio出力 / 入力 * 100) をメモに保存する。
type 引数を省略した場合は、これがデフォルトとなります。精密なログ採取
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
CustomLog logs/deflate_log deflate
参照
DeflateMemLevel ディレクティブ
説明: zlib が圧縮に使うメモリのレベルを指定 構文: DeflateMemLevel valueデフォルト: DeflateMemLevel 9コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Extension モジュール: mod_deflate DeflateMemLevel ディレクティブは
zlib が圧縮に使うメモリのレベルを設定します (1 から 9 の間の値)。
(訳注: 2 を底とする対数の値になります。
8 程度が良いでしょう。)DeflateWindowSize ディレクティブ
説明: Zlib の圧縮用ウィンドウの大きさ 構文: DeflateWindowSize valueデフォルト: DeflateWindowSize 15コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Extension モジュール: mod_deflate DeflateWindowSize ディレクティブは
zlib の圧縮用ウィンドウ (訳注: zlib で使用される履歴バッファ)
の大きさを指定します (1 から 15 の間の値)。
一般的に大きなウィンドウサイズを使用すると圧縮率が向上します。
(訳注: 2 を底とする対数の値になります。
8 から 15 にするのが良いでしょう。)
mod/mod_disk_cache.html 100644 0 0 52334 11074463036 12621 0 ustar 0 0
Apache モジュール mod_dir
This translation may be out of date. Check the
English version for recent changes.
説明: 「最後のスラッシュ」のリダイレクトと、ディレクトリの
インデックスファイルを扱う機能を提供する ステータス: Base モジュール識別子: dir_module ソースファイル: mod_dir.c 概要
index.html というファイル名を使います。このファイル名は、
DirectoryIndex ディレクティブで
指定することができます。この機能は mod_dir
モジュールで提供されます。mod_autoindex
モジュールにより提供されます。http://servername/foo/dirname という URL
へのリクエストがあった際に、dirname
というディレクトリがあれば、「最後にスラッシュをつけた形」の URL
へのリダイレクトを送出します。
ディレクトリへのアクセスはスラッシュで終わっている必要があり、
mod_dir は、http://servername/foo/dirname/
へのリダイレクトを送出することになります。ディレクティブ
DirectoryIndex ディレクティブ
説明: クライアントがディレクトリをリクエストしたときに調べる
リソースのリスト 構文: DirectoryIndex
local-url [local-url] ...デフォルト: DirectoryIndex index.htmlコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_dir DirectoryIndex ディレクティブで設定します。
Local-url
は、リクエストされたディレクトリに対応する、サーバ上のドキュメントの
(% エンコードされた) URL で、普通はディレクトリ中のファイルの名前です。
複数の URL が設定された場合には、最初に見つかったものを返します。
それらが見つからず、Indexes
オプションがセットされている場合、ディレクトリのリストを生成します。
例
DirectoryIndex index.html
http://myserver/docs/ へのアクセスがあり、
http://myserver/docs/index.html
が存在すれば、この URL が返されます。
もし存在しなければ、ディレクトリのリストが返されます。
DirectoryIndex index.html index.txt /cgi-bin/index.pl
index.html と index.txt
のどちらもディレクトリ内に存在しない場合、CGI スクリプト
/cgi-bin/index.pl が実行されます。DirectorySlash ディレクティブ
説明: パス末尾のスラッシュでリダイレクトするかどうかのオンオフをトグルさせる 構文: DirectorySlash On|Offデフォルト: DirectorySlash Onコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Base モジュール: mod_dir 互換性: 2.0.51 以降 mod_dir が調整するべきかどうかを
DirectorySlash
ディレクティブで設定します。mod_dir
は、末尾にスラッシュを付加した上で同じリソースにリダイレクトさせます。
この挙動には幾つか理由があります:
mod_autoindex が期待通りに動く。mod_autoindex
の生成するリンクはパスを出力しませんので、スラッシュがない場合は間違ったパスを
指してしまうことになります。DirectoryIndex は、
末尾にスラッシュがついているリクエストについてのみ評価される。
# see security warning below!
<Location /some/path>
DirectorySlash Off
SetHandler some-handler
</Location>
セキュリティ警告
mod_autoindex が有効 (Options +Indexes) で、
DirectoryIndex が有効なリソース (例えば
index.html) を指していて、また、要求のあった URL に特別な
ハンドラが設定されていない場合を考えてみてください。
この場合末尾にスラッシュのついているリクエストに対しては index.html
ファイルが返されます。しかしスラッシュのないリクエストに対しては、
ディレクトリの内容一覧を返してしまいます。
mod/mod_dumpio.html 100644 0 0 13534 11074463036 12040 0 ustar 0 0
Apache Module mod_disk_cache
Description: Content cache storage manager keyed to URIs Status: Experimental ModuleIdentifier: disk_cache_module SourceFile: mod_disk_cache.c Summary
This module is experimental. Documentation is still under development...
mod_disk_cache implements a disk based storage
manager. It is primarily of use in conjunction with
mod_proxy.Note:
mod_disk_cache requires the services of
mod_cache.Directives
CacheDirLength Directive
Description: The number of characters in subdirectory names Syntax: CacheDirLength lengthDefault: CacheDirLength 2Context: server config, virtual host Status: Experimental Module: mod_disk_cache CacheDirLength directive sets the number
of characters for each subdirectory name in the cache hierarchy.
CacheDirLevels* CacheDirLength
must not be higher than 20.
CacheDirLength 4
CacheDirLevels Directive
Description: The number of levels of subdirectories in the
cache. Syntax: CacheDirLevels levelsDefault: CacheDirLevels 3Context: server config, virtual host Status: Experimental Module: mod_disk_cache CacheDirLevels directive sets the number
of subdirectory levels in the cache. Cached data will be saved this
many directory levels below the CacheRoot directory.
CacheDirLevels*
CacheDirLength must
not be higher than 20.
CacheDirLevels 5
CacheExpiryCheck Directive
Description: Indicates if the cache observes Expires dates when seeking
files Syntax: CacheExpiryCheck On|OffDefault: CacheExpiryCheck OnContext: server config, virtual host Status: Experimental Module: mod_disk_cache
CacheExpiryCheck Off
The
CacheExpiryCheck directive is currently
not implemented.
CacheGcClean Directive
Description: The time to retain unchanged cached files that match a
URL Syntax: CacheGcClean hours url-stringDefault: CacheGcClean ?Context: server config, virtual host Status: Experimental Module: mod_disk_cache
CacheGcClean 12 /daily_scripts
The
CacheGcClean directive is currently
not implemented.
CacheGcDaily Directive
Description: The recurring time each day for garbage collection to be run.
(24 hour clock) Syntax: CacheGcDaily timeDefault: CacheGcDaily ?Context: server config, virtual host Status: Experimental Module: mod_disk_cache
CacheGcDaily 23:59
The
CacheGcDaily directive is currently
not implemented.
CacheGcInterval Directive
Description: The interval between garbage collection attempts. Syntax: CacheGcInterval hoursContext: server config, virtual host Status: Experimental Module: mod_disk_cache CacheGcInterval directive specifies the
number of hours to wait between attempts to free up disk space.
CacheGcInterval 24
The
CacheGcInterval directive is currently
not implemented.
CacheGcMemUsage Directive
Description: The maximum kilobytes of memory used for garbage
collection Syntax: CacheGcMemUsage KBytesDefault: CacheGcMemUsage ?Context: server config, virtual host Status: Experimental Module: mod_disk_cache
CacheGcMemUsage 16
The
CacheGcMemUsage directive is currently
not implemented.
CacheGcUnused Directive
Description: The time to retain unreferenced cached files that match a
URL. Syntax: CacheGcUnused hours url-stringDefault: CacheGcUnused ?Context: server config, virtual host Status: Experimental Module: mod_disk_cache
CacheGcUnused 12 /local_images
The
CacheGcUnused directive is currently
not implemented.
CacheMaxFileSize Directive
Description: The maximum size (in bytes) of a document to be placed in the
cache Syntax: CacheMaxFileSize bytesDefault: CacheMaxFileSize 1000000Context: server config, virtual host Status: Experimental Module: mod_disk_cache CacheMaxFileSize directive sets the
maximum size, in bytes, for a document to be considered for storage in
the cache.
CacheMaxFileSize 64000
CacheMinFileSize Directive
Description: The minimum size (in bytes) of a document to be placed in the
cache Syntax: CacheMinFileSize bytesDefault: CacheMinFileSize 1Context: server config, virtual host Status: Experimental Module: mod_disk_cache CacheMinFileSize directive sets the
minimum size, in bytes, for a document to be considered for storage
in the cache.
CacheMinFileSize 64
CacheRoot Directive
Description: The directory root under which cache files are
stored Syntax: CacheRoot directoryContext: server config, virtual host Status: Experimental Module: mod_disk_cache CacheRoot directive defines the name of
the directory on the disk to contain cache files. If the mod_disk_cache module has been loaded or compiled in to the
Apache server, this directive must be defined. Failing to
provide a value for CacheRoot will result in
a configuration file processing error. The CacheDirLevels and CacheDirLength directives define
the structure of the directories under the specified root directory.
CacheRoot c:/cacheroot
CacheSize Directive
Description: The maximum amount of disk space that will be used by the
cache in KBytes Syntax: CacheSize KBytesDefault: CacheSize 1000000Context: server config, virtual host Status: Experimental Module: mod_disk_cache CacheSize directive sets the desired
disk space usage of the cache, in KBytes (1024-byte units). This
directive does not put a hard limit on the size of the cache. The
garbage collector will delete files until the usage is at or below the
settings. Always use a value that is lower than the available disk
space.
CacheSize 5000000
CacheTimeMargin Directive
Description: The minimum time margin to cache a document Syntax: CacheTimeMargin ?Default: CacheTimeMargin ?Context: server config, virtual host Status: Experimental Module: mod_disk_cache
CacheTimeMargin X
The
CacheTimeMargin directive is currently
not implemented.
mod/mod_echo.html 100644 0 0 7503 11074463036 11440 0 ustar 0 0
Apache Module mod_dumpio
Description: Dumps all I/O to error log as desired. Status: Experimental ModuleIdentifier: dumpio_module SourceFile: mod_dumpio.c Summary
mod_dumpio allows for the logging of
all input received by Apache and/or all output sent by
Apache to be logged (dumped) to the error.log file.
Enabling dumpio Support
LogLevel must be set to debug.DumpIOInput Directive
Description: Dump all input data to the error log Syntax: DumpIOInput On|OffDefault: DumpIOInput OffContext: server config Status: Experimental Module: mod_dumpio Compatibility: DumpIOInput is only available in Apache 2.0.53 and
later. Example
DumpIOInput On
DumpIOOutput Directive
Description: Dump all output data to the error log Syntax: DumpIOOutput On|OffDefault: DumpIOOutput OffContext: server config Status: Experimental Module: mod_dumpio Compatibility: DumpIOOutput is only available in Apache 2.0.53 and
later. Example
DumpIOOutput On
mod/mod_env.html 100644 0 0 14522 11074463036 11331 0 ustar 0 0
Apache モジュール mod_echo
説明: プロトコルモジュールの概要を示すための単純なエコーサーバ
ステータス: Experimental モジュール識別子: echo_module ソースファイル: mod_echo.c 互換性: Apache 2.0 以降 概要
ディレクティブ
mod/mod_example.html 100644 0 0 16267 11074463036 12204 0 ustar 0 0
Apache モジュール mod_env
This translation may be out of date. Check the
English version for recent changes.
説明: CGI スクリプト及び SSI
ページに渡される環境変数を変更する機能を提供する ステータス: Base モジュール識別子: env_module ソースファイル: mod_env.c 概要
PassEnv ディレクティブ
説明: シェルからの環境変数を渡す 構文: PassEnv env-variable [env-variable]
...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_env 例
PassEnv LD_LIBRARY_PATH
SetEnv ディレクティブ
説明: 環境変数を設定する 構文: SetEnv env-variable valueコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_env 例
SetEnv SPECIAL_PATH /foo/bin
mod/mod_expires.html 100644 0 0 30450 11074463036 12216 0 ustar 0 0
Apache Module mod_example
Description: Illustrates the Apache module API Status: Experimental ModuleIdentifier: example_module SourceFile: mod_example.c Summary
This document has not been updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care.
src/modules/example directory
under the Apache distribution directory tree are provided as an
example to those that wish to write modules that use the Apache
API.mod_example.c, which
illustrates all the different callback mechanisms and call
syntaxes. By no means does an add-on module need to include
routines for all of the callbacks - quite the contrary!
Compiling the example module
src/Configuration file.
If there isn't one, add it; it should look like this:
AddModule modules/example/mod_example.o
src/Configure script
("cd src; ./Configure"). This will
build the Makefile for the server itself, and update the
src/modules/Makefile for any additional modules
you have requested from beneath that subdirectory.make" in the
src directory).
mkdir src/modules/mymodulecp src/modules/example/*
src/modules/mymodule
Using the
mod_example Modulesrm.conf file:
<Location /example-info>
SetHandler example-handler
</Location>
.htaccess file
and then request the file "test.example" from that location:
AddHandler example-handler .example
Example Directive
Description: Demonstration directive to illustrate the Apache module
API Syntax: ExampleContext: server config, virtual host, directory, .htaccess Status: Experimental Module: mod_example Example directive just sets a demonstration
flag which the example module's content handler displays. It
takes no arguments. If you browse to an URL to which the
example content-handler applies, you will get a display of the
routines within the module and how and in what order they were
called to service the document request. The effect of this
directive one can observe under the point "Example
directive declared here: YES/NO".
mod/mod_ext_filter.html 100644 0 0 41404 11074463036 12705 0 ustar 0 0
Apache モジュール mod_expires
説明: ユーザの指定した基準に基づいた Expires と
Cache-Control HTTP ヘッダの生成ステータス: Extension モジュール識別子: expires_module ソースファイル: mod_expires.c 概要
Expires HTTP ヘッダ
と Cache-Control ヘッダの max-age ディレクティブの
設定を制御します。元のファイルが作成された時刻または
クライアントのアクセス時刻のどちらかに基づいて期限切れ日を
設定することができます。max-age 以外 (RFC
2616 section 14.9 参照) の Cache-Control のディレクティブを
操作するには Header ディレクティブを
使うことができます。
代替期間指定構文
ExpiresDefault ディレクティブと
ExpiresByType ディレクティブは
以下のより読み易い構文を使って定義することができます:
ExpiresDefault "<base> [plus] {<num>
<type>}*"
ExpiresByType type/encoding "<base> [plus]
{<num> <type>}*"
accessnow ('access' と等価)modificationplus キーワードは省略可能です。<num>
は (atoi() が受け付ける) 整数値、
<type> は以下のどれかです:
yearsmonthsweeksdayshoursminutesseconds
ExpiresDefault "access plus 1 month"
ExpiresDefault "access plus 4 weeks"
ExpiresDefault "access plus 30 days"
ExpiresByType text/html "access plus 1 month 15
days 2 hours"
ExpiresByType image/gif "modification plus 5 hours 3
minutes"
ExpiresActive ディレクティブ
説明: Expires ヘッダの生成を有効にする構文: ExpiresActive On|Offコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Extension モジュール: mod_expires Expires と Cache-Controlヘッダを
有効にするか無効にするかを決めます。
(例えば、.htaccess ファイルではそのディレクトリの
文書のみに適用されるということです。) Off に
設定された場合は対応領域でそれらのヘッダは
生成されません (.htaccess がサーバ設定ファイルの設定を
上書きする、というような下位レベルでの上書きがされていなければ)。
On に設定されていれば、ヘッダは ExpiresByType ディレクティブと
ExpiresDefault ディレクティブ
の基準に従って文書にヘッダを追加します (各ディレクティブ参照)。Expires と
Cache-Control ヘッダの存在を
保証するわけではないことに注意してください。基準が満たされて
いない場合はヘッダは追加されず、結果としてこのディレクティブが
指定されていなかったかのようにさえ見えることになります。ExpiresByType ディレクティブ
説明: MIME タイプによって設定される Expires ヘッダの値構文: ExpiresByType MIME-type
<code>secondsコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Extension モジュール: mod_expires text/html)
に対して生成される Expires ヘッダと Cache-Control
ヘッダの max-age ディレクティブの値を定義します。
二つ目の引数は期限切れの日時を生成するための基準時刻に追加される
秒数を設定します。Cache-Control:
max-age は期限切れの時刻からリクエスト時刻を引いたものを秒で
表すことで生成されます。<code>
によって指定します。M は基準時刻として
ファイルの最終修正時刻をという意味で、A はクライアントの
アクセス時刻を使うという意味になります。M が使用された場合は、
すべてのキャッシュにある現在のドキュメントキャッシュは同時に期限が
切れます。これは同じ URL に毎週常に置かれる報せのようなものには
非常に有効です。A が使用された場合は、期限切れの
時間は各クライアントよって異なります。これはあまり変更されない
画像ファイルなど、特に関連するドキュメント群がすべて同じ画像を
参照するとき (すなわち画像が比較的短い期間内に繰り返し
アクセスされるとき) に有効です。例:
# enable expirations
ExpiresActive On
# expire GIF images after a month in the client's cache
ExpiresByType image/gif A2592000
# HTML documents are good for a week from the
# time they were changed
ExpiresByType text/html M604800
ExpiresActive On が指定されている
ときのみ有効であることに注意してください。これは、
指定された MIME タイプに対してのみ ExpiresDefault ディレクティブで
設定された期限切れ期日を上書きします。ExpiresDefault ディレクティブ
説明: 期限切れ期日を計算するデフォルトアルゴリズム 構文: ExpiresDefault <code>secondsコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Indexes ステータス: Extension モジュール: mod_expires ExpiresByType ディレクティブによって
タイプ毎に上書きすることができます。引数の構文はそのディレクティブの
説明を参照してください。また、代替構文も
参照してください。
mod/mod_file_cache.html 100644 0 0 27711 11074463036 12607 0 ustar 0 0
Apache Module mod_ext_filter
Description: Pass the response body through an external program before
delivery to the client Status: Extension ModuleIdentifier: ext_filter_module SourceFile: mod_ext_filter.c Summary
mod_ext_filter presents a simple and familiar
programming model for filters. With
this module, a program which reads from stdin and writes to stdout
(i.e., a Unix-style filter command) can be a filter for
Apache. This filtering mechanism is much slower than using a
filter which is specially written for the Apache API and runs
inside of the Apache server process, but it does have the
following benefits:
mod_ext_filter can be used as
a prototype environment for filters.
Examples
Generating HTML from some other type of response
# mod_ext_filter directive to define a filter
# to HTML-ize text/c files using the external
# program /usr/bin/enscript, with the type of
# the result set to text/html
ExtFilterDefine c-to-html mode=output \
intype=text/c outtype=text/html \
cmd="/usr/bin/enscript --color -W html -Ec -o - -"
<Directory "/export/home/trawick/apacheinst/htdocs/c">
# core directive to cause the new filter to
# be run on output
SetOutputFilter c-to-html
# mod_mime directive to set the type of .c
# files to text/c
AddType text/c .c
# mod_ext_filter directive to set the debug
# level just high enough to see a log message
# per request showing the configuration in force
ExtFilterOptions DebugLevel=1
</Directory>
Implementing a content encoding filter
mod_deflate for a practical
implementation.
# mod_ext_filter directive to define the external filter
ExtFilterDefine gzip mode=output cmd=/bin/gzip
<Location /gzipped>
# core directive to cause the gzip filter to be
# run on output
SetOutputFilter gzip
# mod_header directive to add
# "Content-Encoding: gzip" header field
Header set Content-Encoding gzip
</Location>
Slowing down the server
# mod_ext_filter directive to define a filter
# which runs everything through cat; cat doesn't
# modify anything; it just introduces extra pathlength
# and consumes more resources
ExtFilterDefine slowdown mode=output cmd=/bin/cat \
preservescontentlength
<Location />
# core directive to cause the slowdown filter to
# be run several times on output
#
SetOutputFilter slowdown;slowdown;slowdown
</Location>
Using sed to replace text in the response
# mod_ext_filter directive to define a filter which
# replaces text in the response
#
ExtFilterDefine fixtext mode=output intype=text/html \
cmd="/bin/sed s/verdana/arial/g"
<Location />
# core directive to cause the fixtext filter to
# be run on output
SetOutputFilter fixtext
</Location>
Tracing another filter
# Trace the data read and written by mod_deflate
# for a particular client (IP 192.168.1.31)
# experiencing compression problems.
# This filter will trace what goes into mod_deflate.
ExtFilterDefine tracebefore \
cmd="/bin/tracefilter.pl /tmp/tracebefore" \
EnableEnv=trace_this_client
# This filter will trace what goes after mod_deflate.
# Note that without the ftype parameter, the default
# filter type of AP_FTYPE_RESOURCE would cause the
# filter to be placed *before* mod_deflate in the filter
# chain. Giving it a numeric value slightly higher than
# AP_FTYPE_CONTENT_SET will ensure that it is placed
# after mod_deflate.
ExtFilterDefine traceafter \
cmd="/bin/tracefilter.pl /tmp/traceafter" \
EnableEnv=trace_this_client ftype=21
<Directory /usr/local/docs>
SetEnvIf Remote_Addr 192.168.1.31 trace_this_client
SetOutputFilter tracebefore;deflate;traceafter
</Directory>
Here is the filter which traces the data:
#!/usr/local/bin/perl -w
use strict;
open(SAVE, ">$ARGV[0]")
or die "can't open $ARGV[0]: $?";
while (<STDIN>) {
print SAVE $_;
print $_;
}
close(SAVE);
ExtFilterDefine Directive
Description: Define an external filter Syntax: ExtFilterDefine filtername parametersContext: server config Status: Extension Module: mod_ext_filter ExtFilterDefine directive defines the
characteristics of an external filter, including the program to
run and its arguments.cmd=. These parameters
are:
cmd=cmdlinecmd= keyword allows you to specify the
external command to run. If there are arguments after the
program name, the command line should be surrounded in
quotation marks (e.g., cmd="/bin/mypgm
arg1 arg2". Normal shell quoting is
not necessary since the program is run directly, bypassing the shell.
Program arguments are blank-delimited. A backslash can be used to
escape blanks which should be part of a program argument. Any
backslashes which are part of the argument must be escaped with
backslash themselves. In addition to the standard CGI environment
variables, DOCUMENT_URI, DOCUMENT_PATH_INFO, and
QUERY_STRING_UNESCAPED will also be set for the program.mode=modemode should be output for now (the
default). In the future, mode=input will be used to
specify a filter for request bodies.intype=imtintype= is
specified, the filter will be disabled for documents of other
types.outtype=imtPreservesContentLengthPreservesContentLength keyword specifies
that the filter preserves the content length. This is not the
default, as most filters change the content length. In the
event that the filter doesn't modify the length, this keyword
should be specified.ftype=filtertypedisableenv=envenableenv=envExtFilterOptions Directive
Description: Configure mod_ext_filter optionsSyntax: ExtFilterOptions option [option] ...Default: ExtFilterOptions DebugLevel=0 NoLogStderrContext: directory Status: Extension Module: mod_ext_filter ExtFilterOptions directive specifies
special processing options for mod_ext_filter.
Option can be one of
DebugLevel=nDebugLevel keyword allows you to specify
the level of debug messages generated by
mod_ext_filter. By default, no debug messages
are generated. This is equivalent to
DebugLevel=0. With higher numbers, more debug
messages are generated, and server performance will be
degraded. The actual meanings of the numeric values are
described with the definitions of the DBGLVL_ constants
near the beginning of mod_ext_filter.c.
LogLevel should be used to cause debug messages to
be stored in the Apache error log.LogStderr | NoLogStderrLogStderr keyword specifies that
messages written to standard error by the external filter
program will be saved in the Apache error log.
NoLogStderr disables this feature.Example
ExtFilterOptions LogStderr DebugLevel=0
mod_ext_filter.
mod/mod_headers.html 100644 0 0 37122 11074463036 12155 0 ustar 0 0
Apache Module mod_file_cache
Description: Caches a static list of files in memory Status: Experimental ModuleIdentifier: file_cache_module SourceFile: mod_file_cache.c Summary
This module should be used with care. You can easily create a broken
site using
mod_file_cache, so read this document
carefully.
mod_file_cache provides two techniques for caching
frequently requested static files. Through configuration
directives, you can direct mod_file_cache to either
open then mmap() a file, or to pre-open a file and save
the file's open file handle. Both techniques reduce server
load when processing requests for these files by doing part of the work
(specifically, the file I/O) for serving the file when the
server is started rather than during each request.mod_mmap_static module in Apache 1.3.
Using mod_file_cache
mod_file_cache caches a list of statically
configured files via MMapFile or CacheFile directives in the main server configuration.MMapStatic directive, while
other platforms, like AIX, support both. You will receive an error
message in the server error log if you attempt to use an
unsupported directive. If given an unsupported directive, the
server will start but the file will not be cached. On platforms
that support both directives, you should experiment with both to
see which works best for you.MMapFile Directive
MMapFile
directive of mod_file_cache maps a list of
statically configured files into memory through the system call
mmap(). This system call is available on most modern
Unix derivates, but not on all. There are sometimes system-specific
limits on the size and number of files that can be
mmap()ed, experimentation is probably the easiest way
to find out.mmap()ing is done once at server start or
restart, only. So whenever one of the mapped files changes on the
filesystem you have to restart the server (see the Stopping and Restarting documentation).
To reiterate that point: if the files are modified in place
without restarting the server you may end up serving requests that
are completely bogus. You should update files by unlinking the old
copy and putting a new copy in place. Most tools such as
rdist and mv do this. The reason why this
modules doesn't take care of changes to the files is that this check
would need an extra stat() every time which is a waste
and against the intent of I/O reduction.CacheFile Directive
CacheFile
directive of mod_file_cache opens an active
handle or file descriptor to the file (or files)
listed in the configuration directive and places these open file
handles in the cache. When the file is requested, the server
retrieves the handle from the cache and passes it to the
sendfile() (or TransmitFile() on Windows),
socket API.rdist and
mv do this.Note
Include directive, and consider
this command:
find /www/htdocs -type f -print \
| sed -e 's/.*/mmapfile &/' > /www/conf/mmap.conf
CacheFile Directive
Description: Cache a list of file handles at startup time Syntax: CacheFile file-path [file-path] ...Context: server config Status: Experimental Module: mod_file_cache CacheFile directive opens handles to
one or more files (given as whitespace separated arguments) and
places these handles into the cache at server startup
time. Handles to cached files are automatically closed on a server
shutdown. When the files have changed on the filesystem, the
server should be restarted to to re-cache them.stat() system
calls which is not acceptable. This module may or may not work
with filenames rewritten by mod_alias or
mod_rewrite.Example
CacheFile /usr/local/apache/htdocs/index.html
MMapFile Directive
Description: Map a list of files into memory at startup time Syntax: MMapFile file-path [file-path] ...Context: server config Status: Experimental Module: mod_file_cache MMapFile directive maps one or more files
(given as whitespace separated arguments) into memory at server
startup time. They are automatically unmapped on a server
shutdown. When the files have changed on the filesystem at
least a HUP or USR1 signal should be send to
the server to re-mmap() them.stat() system
calls which is not acceptable. This module may or may not work
with filenames rewritten by mod_alias or
mod_rewrite.Example
MMapFile /usr/local/apache/htdocs/index.html
mod/mod_imap.html 100644 0 0 42674 11074463036 11500 0 ustar 0 0
Apache Module mod_headers
Description: Customization of HTTP request and response
headers Status: Extension ModuleIdentifier: headers_module SourceFile: mod_headers.c Compatibility: RequestHeader
is available only in Apache 2.0Summary
Order of Processing
mod_headers can occur
almost anywhere within the server configuration. They are valid in the
main server config and virtual host sections, inside
<Directory>,
<Location> and
<Files> sections,
and within .htaccess files.
<Directory> sections and
.htaccess<Files><Location>
RequestHeader append MirrorID "mirror 12"
RequestHeader unset MirrorID
MirrorID header is not set. If
reversed, the MirrorID header is set to "mirror 12".
Examples
Header echo ^TS
MyHeader, to the response including a
timestamp for when the request was received and how long it
took to begin serving the request. This header can be used by
the client to intuit load on the server or in isolating
bottlenecks between the client and the server.
Header add MyHeader "%D %t"
MyHeader: D=3775428 t=991424704447256
Header add MyHeader "Hello Joe. It took %D microseconds \
for Apache to serve this request."
MyHeader: Hello Joe. It took D=3775428 microseconds for Apache
to serve this request.
MyHeader on the response if and
only if header "MyRequestHeader" is present on the request. This
is useful for constructing headers in response to some client
stimulus. Note that this example requires the services of the
mod_setenvif module.
SetEnvIf MyRequestHeader value HAVE_MyRequestHeader
Header add MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
MyRequestHeader: value is present on
the HTTP request, the response will contain the following header:
MyHeader: D=3775428 t=991424704447256 mytext
Header Directive
Description: Configure HTTP response headers Syntax: Header [condition] set|append|add|unset|echo
header [value] [env=[!]variable]Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_headers Compatibility: Condition is available in version 2.0.51 and
later onsuccess
or always. It determines, which internal header table should be
operated on. onsuccess stands for 2xx
status codes and always for all status codes (including
2xx). Especially if you want to unset headers
set by certain modules, you should try out, which table is affected.
setappendaddunsetechoset, append, add
and unset. The header name for echo
is case sensitive and may be a regular expression.add, append and set a
value is specified as the third argument. If value
contains spaces, it should be surrounded by doublequotes.
value may be a character string, a string containing format
specifiers or a combination of both. The following format specifiers
are supported in value:
%tThe time the request was received in Universal Coordinated Time
since the epoch (Jan. 1, 1970) measured in microseconds. The value
is preceded by t=.%DThe time from when the request was received to the time the
headers are sent on the wire. This is a measure of the duration
of the request. The value is preceded by D=.%{FOOBAR}eThe contents of the environment
variable FOOBAR.Header directive is used with the
add, append, or set
argument, a fourth argument may be used to specify conditions
under which the action will be taken. If the environment variable specified in the
env=... argument exists (or if the environment
variable does not exist and env=!... is specified)
then the action specified by the Header directive
will take effect. Otherwise, the directive will have no effect
on the request.Header directives are processed just
before the response is sent to the network. These means that it is
possible to set and/or override most headers, except for those headers
added by the header filter.RequestHeader Directive
Description: Configure HTTP request headers Syntax: RequestHeader set|append|add|unset header
[value [env=[!]variable]]Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_headers
setappendaddappend should be
used instead.unsetadd, append and
set a value is given as the third argument. If
value contains spaces, it should be surrounded by double
quotes. For unset, no value should be given.RequestHeader directive is used with the
add, append, or set
argument, a fourth argument may be used to specify conditions
under which the action will be taken. If the environment variable specified in the
env=... argument exists (or if the environment
variable does not exist and env=!... is specified)
then the action specified by the RequestHeader directive
will take effect. Otherwise, the directive will have no effect
on the request.RequestHeader directive is processed
just before the request is run by its handler in the fixup phase.
This should allow headers generated by the browser, or by Apache
input filters to be overridden or modified.
mod/mod_include.html 100644 0 0 112515 11074463036 12205 0 ustar 0 0
Apache Module mod_imap
Description: Server-side imagemap processing Status: Base ModuleIdentifier: imap_module SourceFile: mod_imap.c Summary
.map files, thereby
replacing the functionality of the imagemap CGI
program. Any directory or document type configured to use the
handler imap-file (using either
AddHandler or
SetHandler)
will be processed by this module..map as imagemap files:AddHandler imap-file mapAddType application/x-httpd-imap mapDirectives
Topics
New Features
<base> assignment through a new map
directive base.imagemap.conf file.
Imagemap File
directive value [x,y ...]
directive value "Menu text" [x,y
...]
directive value x,y ... "Menu text"
base,
default, poly, circle,
rect, or point. The value is an
absolute or relative URL, or one of the special values listed
below. The coordinates are x,y
pairs separated by whitespace. The quoted text is used as the text of
the link if a imagemap menu is generated. Lines beginning with '#' are
comments.Imagemap File Directives
base Directive<base href="value">
. The non-absolute URLs of the map-file are taken relative
to this value. The base directive overrides
ImapBase as set in a
.htaccess file or in the server configuration files.
In the absence of an ImapBase configuration
directive, base defaults to
http://server_name/.base_uri is synonymous with base.
Note that a trailing slash on the URL is significant.default Directivepoly, circle or
rect directives, and there are no
point directives. Defaults to nocontent
in the absence of an ImapDefault configuration setting, causing a status
code of 204 No Content to be returned. The client
should keep the same page displayed.poly Directivecirclerect Directivepoint Directivedefault will not be
followed if a point directive is present and
valid coordinates are given.Values
base value.base itself will not resolved according to the
current value. A statement base mailto: will
work properly, though.mapImapMenu is set to
none.menumap.refererhttp://servername/ if no Referer:
header was present.nocontent204 No Content,
telling the client to keep the same page displayed. Valid for
all but base.error500 Server Error. Valid for all
but base, but sort of silly for anything but
default.Coordinates
0,0 200,2000,0, it is as if no coordinate had been
selected.Quoted Text
"Menu Text"
<a href="http://foo.com/">Menu text</a>
<a href="http://foo.com/">http://foo.com</a>
".
Example Mapfile
#Comments are printed in a 'formatted' or 'semiformatted' menu.
#And can contain html tags. <hr>
base referer
poly map "Could I have a menu, please?" 0,0 0,10 10,10 10,0
rect .. 0,0 77,27 "the directory of the referer"
circle http://www.inetnebr.com/lincoln/feedback/ 195,0 305,27
rect another_file "in same directory as referer" 306,0 419,27
point http://www.zyzzyva.com/ 100,100
point http://www.tripod.com/ 200,200
rect mailto:nate@tripod.com 100,150 200,0 "Bugs?"
Referencing your mapfile
HTML example
<a href="/maps/imagemap1.map">
<img ismap src="/images/imagemap1.gif">
</a>
XHTML example
<a href="/maps/imagemap1.map">
<img ismap="ismap" src="/images/imagemap1.gif" />
</a>
ImapBase Directive
Description: Default base for imagemap filesSyntax: ImapBase map|referer|URLDefault: ImapBase http://servername/Context: server config, virtual host, directory, .htaccess Override: Indexes Status: Base Module: mod_imap ImapBase directive sets the default
base used in the imagemap files. Its value is
overridden by a base directive within the imagemap
file. If not present, the base defaults to
http://servername/.See also
ImapDefault Directive
Description: Default action when an imagemap is called with coordinates
that are not explicitly mapped Syntax: ImapDefault error|nocontent|map|referer|URLDefault: ImapDefault nocontentContext: server config, virtual host, directory, .htaccess Override: Indexes Status: Base Module: mod_imap ImapDefault directive sets the default
default used in the imagemap files. Its value is
overridden by a default directive within the
imagemap file. If not present, the default action
is nocontent, which means that a 204 No
Content is sent to the client. In this case, the client
should continue to display the original page.ImapMenu Directive
Description: Action if no coordinates are given when calling
an imagemap Syntax: ImapMenu none|formatted|semiformatted|unformattedContext: server config, virtual host, directory, .htaccess Override: Indexes Status: Base Module: mod_imap ImapMenu directive determines the
action taken if an imagemap file is called without valid
coordinates.
nonenone, no menu is generated,
and the default action is performed.formattedformatted menu is the simplest menu.
Comments in the imagemap file are ignored. A level one header
is printed, then an hrule, then the links each on a separate
line. The menu has a consistent, plain look close to that of
a directory listing.semiformattedsemiformatted menu, comments are
printed where they occur in the imagemap file. Blank lines
are turned into HTML breaks. No header or hrule is printed,
but otherwise the menu is the same as a
formatted menu.unformatted
mod/mod_info.html 100644 0 0 13746 11074463036 11503 0 ustar 0 0
Apache モジュール mod_include
This translation may be out of date. Check the
English version for recent changes.
説明: サーバがパースする html ドキュメント (Server Side Includes) ステータス: Base モジュール識別子: include_module ソースファイル: mod_include.c 互換性: Apache 2.0 から出力フィルタとして実装されました。 概要
ディレクティブ
トピック
参照
Server-Side Includes を有効にする
INCLUDES
フィルタ により実装されています。
Server-side include のディレクティブを含むドキュメントの拡張子が
.shtml の場合、以下のディレクティブでは Apache がそれらを
パースして、その結果できるドキュメントに text/html の
MIME タイプを割り当てます:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
<Directory> セクションで指定しますが、
AllowOverride Options
が設定されていると、.htaccess ファイルに書くこともできます):
Options +Includes
server-parsed
ハンドラ も INCLUDES フィルタを
有効にします。MIME タイプ text/x-server-parsed-html や
text/x-server-parsed-html3 のドキュメントに対しても
Apache は INCLUDES フィルタを有効にします (出力されるものは
MIME タイプ text/html になります)。
サーバサイドインクルード (SSI) での PATH_INFO
PATH_INFO
(後続のパス名情報)
付きのリクエストを受け入れなくなりました。AcceptPathInfo ディレクティブで
PATH_INFO 付きのリクエストを受け入れるようにサーバを
設定できます。
基本要素
<!--#element attribute=value
attribute=value ... -->
-->)
の前には、SSI の句の一部だと解釈されないようにするために空白を
入れてください。最初の <!--# はまとめて一つの
句で、空白をふくんではいけないこと注意してください。
要素 説明 configconfigure output formats echoprint variables execexecute external programs fsizeprint size of a file flastmodprint last modification time of a file includeinclude a file printenvprint all available variables setset a value of a variable mod_include 以外のモジュールで
定義されることもあります。実際、
exec 要素は
mod_cgi で提供されていて、このモジュールが
ロードされる場合にのみ利用可能となります。config 要素
errmsgSSIErrorMsg
ディレクティブを上書きします。sizefmtbytesか、Kb や Mb を優先的に使用する
abbrec (例えば 1024 バイトは "1K" と表示されます)
です。timefmtstrftime(3) ライブラリルーチンが
日時をプリントする際に用いられます。echo 要素
SSIUndefinedEcho ディレクティブで
決定される結果となります。日付はその時点での timefmt に従って
表示されます。属性は次の通りです。
varencodingnone に設定されていると、エンコードは行なわれません。
url に設定されていると、URL エンコード (%-エンコードとも
呼ばれています。これはリンク等の URL の使用に適切です) が
行なわれます。echo 要素の開始時は、デフォルトは
entity に設定されています。これはエンティティエンコード
(段落やテキストなどのブロックレベルの HTML エレメントのコンテキストに
適しています) を行ないます。これは encoding 属性
を加えることで変更できます。変更は次の encoding 属性か、
要素の終了まで効力を持ちます。encoding 属性はエンコードの変更をしたい var
の前に ある必要があることに注意してください。
また、ISO-8859-1 エンコーディングで
定義されている特別な文字だけがエンコードされます。
別の文字のエンコーディングの場合は、このエンコーディングは
望みの結果にならないかもしれません。
クロスサイトスクリプティングの問題を避けるために、
常にユーザからのデータをエンコードすべきです。
exec 要素
exec コマンドは指定されたシェルコマンドや CGI スクリプトを
実行します。mod_cgi がサーバに組み込まれているいなければ
なりません。Option
IncludesNOEXEC はこのコマンドを無効にします。
使用可能な属性は次の通りです。
cgiScriptAlias
や Option ExecCGI
によって) CGI スクリプトの使用が許可されている必要があります。PATH_INFO とクエリー文字列 (QUERY_STRING) が渡されます。
これらは URL パスとして特定できないものです。
スクリプトは標準 CGI 環境に加えて、include 変数を
使用することができます。例
<!--#exec cgi="/cgi-bin/example.cgi" -->
Location: ヘッダを返すと、
HTML のアンカー (訳注：リンク) に変換されます。exec cgi よりも、
include virtual
の方を使うようにしてください。特に、CGI への追加の引数を
クエリー文字列を使って渡すことは exec cgi は
できませんが、include virtual は以下のようにして
可能です。
<!--#include virtual="/cgi-bin/example.cgi?argument=value" -->
cmd/bin/sh を使って
実行します。コマンドは通常の CGI 変数に加えて include 変数も使うことができます。#include
virtual を使う方が #exec cgi や #exec
cmd を使うよりも良いです。前者 (#include virtual)
は標準の Apache のサブリクエスト機構を使ってファイルやスクリプトの
出力を取り込みます。
こちらの方がよくテストされメンテナンスされた方法です。exec ディレクティブのコマンドに
引数を渡したり、コマンドに空白を入れることはできません。
ですから、以下のものは unix の suexec でない設定では動作しますが、
Win32 や suexec を使っている unix では期待した結果にはなりません:
<!--#exec cmd="perl /path/to/perlscript arg1 arg2" -->
fsize 要素
sizefmt の
書式指定に基づいて出力します。属性は次の通りです。
filevirtualflastmod 要素
timefmt 書式指定に従って表示します。
指定可能な属性は fsize コマンドと同じです。include 要素
IncludesNOEXEC
が設定されている場合、text MIME タイプ (text/plain,
text/html 等) のドキュメントのみインクルードが行なわれます。
その他の場合は、クエリー文字列も含め、コマンドで指定された
完全な URL を使って普通に CGI スクリプトが呼び出されます。
file../ を含んでいたり、絶対パスを指定したりはできません。
ですから、ドキュメントルートの外にあるファイルや、ディレクトリ構造で
上位にあるファイルを挿入することはできません。
常にこの属性よりは、virtual 属性を使うようにしてください。
virtual
<!--#include virtual="/cgi-bin/example.cgi?argument=value" -->
include virtual の方が exec cgi よりも
好ましい方法です。printenv 要素
echo 要素を参照)
されるようになりました。属性はありません。例
<!--#printenv -->
set 要素
varvalue例
<!--#set var="category" value="help" -->
Include 変数
echo コマンドや、
if や elif, それにドキュメントから呼び出される
すべてのプログラムから使用できる変数があります。
DATE_GMTDATE_LOCALDOCUMENT_NAMEDOCUMENT_URILAST_MODIFIEDQUERY_STRING_UNESCAPED&
といった特殊文字にはバックスラッシュが直前に置かれます)。
変数置換
config,
exec, flastmod, fsize,
include, echo, set の
各ディレクティブと、条件分岐用のオペレータへの引数があります。
ドル記号はバックスラッシュを使うことで使うことができます:
<!--#if expr="$a = \$test" -->
<!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" -->
REMOTE_HOST が
"X" で REQUEST_METHOD が
"Y" のときに変数 Zed を "X_Y"
に設定します。DOCUMENT_URI が /foo/file.html
のときに "in foo" を、/bar/file.html のときに "in bar" を、
どちらでもないときには "in neither" を表示します。
<!--#if expr='"$DOCUMENT_URI" = "/foo/file.html"' -->
in foo
<!--#elif expr='"$DOCUMENT_URI" = "/bar/file.html"' -->
in bar
<!--#else -->
in neither
<!--#endif -->
フロー制御要素
<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->
if 要素はプログラミング言語の
if 文と同じように動作します。条件が評価され、結果が真であれば次の
elif か else か endif
要素までの文字列が出力に挿入されます。elif や else 文は test_condition
が偽のときにテキストを出力に挿入するために使われます。
これらの要素はあってもなくても構いません。endif 要素は if
要素を終了させます。この要素は必須です。
stringstring1 = string2
string1 == string2
string1 != string2/string/
という形式であれば、正規表現として比較されます。正規表現は
PCRE エンジンで実装されていて、
perl 5 と同じ構文を使用します。
== は単に = の別名で、まったく同じ動作を
します。= または ==) の場合は、
正規表現でグループ分けされたパーツをキャプチャすることができます。
キャプチャされた部分は特殊変数 $1 .. $9
に格納されます。例
<!--#if expr="$QUERY_STRING = /^sid=([a-zA-Z0-9]+)/" -->
<!--#set var="session" value="$1" -->
<!--#endif -->
string1 < string2
string1 <= string2
string1 > string2
string1 >= string2strcmp(3) を使用)
ことに注意してください。ですから、文字列 "100" は "20"
よりも小さいことになります。( test_condition )! test_conditiontest_condition1 &&
test_condition2test_condition1 ||
test_condition2
<!--#if expr="$a = test1 && $b = test2" -->
<!--#if expr="($a = test1) && ($b = test2)" -->
&& と ||
は同じ優先度です。
これらのオペレータで一方により強い優先度をつけたい場合には、
括弧を使う必要があります。'string'
のように。引用符で囲まれていない文字列には空白 (スペースとタブ)
を含めることはできません。それらは変数などの句を分離するために
使われているからです。複数の文字列が続いているときは、
空白を間に入れて一つにくっつけられます。ですから、string1 string2 は string1 string2 になります。
また、
'string1 string2' は string1 string2
になります。SSIEndTag ディレクティブ
説明: include 要素を終了させる文字列 構文: SSIEndTag tagデフォルト: SSIEndTag "-->"コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_include 互換性: 2.0.30 以降で利用可能 mod_include が探す、
include 要素の終了を示す文字列を変更します。例
SSIEndTag "%>"
参照
SSIErrorMsg ディレクティブ
説明: SSI のエラーがあったときに表示されるエラーメッセージ 構文: SSIErrorMsg messageデフォルト: SSIErrorMsg "[an error occurred while processing this
directive]"コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Base モジュール: mod_include 互換性: バージョン 2.0.30 以降で使用可能 SSIErrorMsg ディレクティブは mod_include
がエラーが起こったときに表示するメッセージを変更します。プロダクションサーバでは
メッセージがユーザに表示されないようにするために
デフォルトエラーメッセージを "<!-- Error -->"
に変えるというようなことを考えるかもしれません。<!--#config
errmsg=message --> 要素と同じ効果になります。例
SSIErrorMsg "<!-- Error -->"
SSIStartTag ディレクティブ
説明: include 要素を開始する文字列 構文: SSIStartTag tagデフォルト: SSIStartTag "<!--#"コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_include 互換性: バージョン 2.0.30 以降で使用可能 mod_include が探す、include
要素の開始を示す文字列を変更します。例
SSIStartTag "<%"
SSIEndTag "%>"
SSIEndTag を併せて使うと、
下に示す例のように SSI ディレクティブを使えます:違う開始と終了のタグを使った SSI ディレクティブ
<%printenv %>
参照
SSITimeFormat ディレクティブ
説明: 日付けを現す文字列の書式を設定する 構文: SSITimeFormat formatstringデフォルト: SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: All ステータス: Base モジュール: mod_include 互換性: 2.0.30 以降で使用可能 DATE 環境変数を echo して日付を現す文字列が
表示されるときの書式を変更します。formatstring は
C 標準ライブラリの strftime(3) と同じ形式です。<!--#config
timefmt=formatstring --> 要素と同じ効果になります。例
SSITimeFormat "%R, %B %d, %Y"
SSIUndefinedEcho ディレクティブ
説明: 未定義の変数が echo されたときに表示される文字列 構文: SSIUndefinedEcho stringデフォルト: SSIUndefinedEcho "(none)"コンテキスト: サーバ設定ファイル, バーチャルホスト 上書き: All ステータス: Base モジュール: mod_include 互換性: 2.0.34 以降で利用可能 mod_include
が表示する文字列を変更します。例
SSIUndefinedEcho "<!-- undef -->"
XBitHack ディレクティブ
説明: 実行ビットが設定されたファイルの SSI ディレクティブを
解析する 構文: XBitHack on|off|fullデフォルト: XBitHack offコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Options ステータス: Base モジュール: mod_include XBitHack ディレクティブは通常の HTML
ドキュメントの解析を制御します。このディレクティブは MIME タイプ
text/html と関連付けられているファイルにのみ影響します。
XBitHack は以下の値をとることができます。
offontext/html
ファイルは全てサーバで解析する html ドキュメントとして扱われます。fullon と同様ですが、グループ実行ビットもテストします。
もしそれが設定されていれば、返されるファイルの Last-modified の
日付をファイルの最終修正時刻にします。それが設定されていないときは、
last-modified の日付は送られません。このビットを設定すると、
クライアントやプロキシがリクエストをキャッシュできるようになります。
注意 他の CGI を
#include
するかもしれないものや、各アクセスに対して違う出力を生成する
(もしくは後のリクエストで変わるかもしれないもの)
すべての SSI スクリプトに対してグループ実行ビットが
設定されていないことを確認できない場合は、full は使わない方が良い
でしょう。
mod/mod_isapi.html 100644 0 0 47712 11074463036 11655 0 ustar 0 0
Apache モジュール mod_info
This translation may be out of date. Check the
English version for recent changes.
説明: サーバの設定の包括的な概観を提供する ステータス: Extension モジュール識別子: info_module ソースファイル: mod_info.c 概要
mod_info を設定するには、以下を httpd.conf
ファイルに加えます。
<Location /server-info>
SetHandler server-info
</Location>
<Location>
ディレクティブの中に <Limit>
節を入れるとよいかもしれません。http://your.host.dom/server-info
をアクセスすることでサーバの情報を得られるようになります。
User
ディレクティブを参照してください)。
でなければ、ディレクティブの設定は表示されません。mod_info
がサーバに組み込まれている場合は、ディレクトリ毎のファイル
(例えば、.htaccess) を含むすべての設定ファイルで
ハンドラを使用可能であるということにも注意してください。
これは、あなたのサイトではセキュリティに関連した問題があるかもしれません。
ディレクティブ
AddModuleInfo ディレクティブ
説明: server-info ハンドラにより表示されるモジュールの情報に
追加の情報を付け加える 構文: AddModuleInfo module-name stringコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Extension モジュール: mod_info 互換性: Apache 1.3 以降
AddModuleInfo mod_authn_file.c 'See <a \
href="http://www.apache.org/docs/2.0/mod/mod_authn_file.html">\
http://www.apache.org/docs/2.0/mod/mod_authn_file.html</a>'
mod/mod_ldap.html 100644 0 0 57001 11074463036 11460 0 ustar 0 0
Apache Module mod_isapi
Description: ISAPI Extensions within Apache for Windows Status: Base ModuleIdentifier: isapi_module SourceFile: mod_isapi.c Compatibility: Win32 only Summary
Directives
ISAPIAppendLogToErrors ISAPIAppendLogToQuery ISAPICacheFile ISAPIFakeAsync ISAPILogNotSupported ISAPIReadAheadBufferTopics
Usage
AddHandler directive to
associate ISAPI files with the isapi-handler handler, and map
it to them with their file extensions. To enable any .dll file to be
processed as an ISAPI extension, edit the httpd.conf file and add the
following line:
AddHandler isapi-handler .dll
In versions of the Apache server prior to 2.0.37, use
isapi-isa instead of isapi-handler. The new
handler name is not available prior to version 2.0.37. For compatibility,
configurations may continue using isapi-isa through all
versions of Apache prior to 2.3.0.
ISAPICacheFile c:/WebWork/Scripts/ISAPI/mytest.dll
Options ExecCGI must be set for the
directory that contains the ISAPI .dll file.mod_isapi.
Additional Notes
ISAPILogNotSupported
Off exists to quiet this noise.ISAPICacheFile directive is specified.
This is inefficient, but Apache's memory model makes this the
most effective method. Many ISAPI modules are subtly
incompatible with the Apache server, and unloading these
modules helps to ensure the stability of the server.
Programmer's Journal
mod_isapi
modules, you must limit your calls to ServerSupportFunction
to the following directives:
HSE_REQ_SEND_URL_REDIRECT_RESP
This must be a fully qualified URL (e.g.
http://server/location).HSE_REQ_SEND_URL
This cannot be a fully qualified URL, you are not allowed to
pass the protocol or a server name (e.g. simply
/location).
This redirection is handled by the server, not the
browser.
Warning
HSE_REQ_SEND_URL functions. Apache continues to treat
them as two distinct functions with different requirements
and behaviors.HSE_REQ_SEND_RESPONSE_HEADERHSE_REQ_DONE_WITH_SESSIONHSE_REQ_MAP_URL_TO_PATHHSE_APPEND_LOG_PARAMETER
\"%{isapi-parameter}n\" component in a
CustomLog
directive%q log component with the
ISAPIAppendLogToQuery
On directiveISAPIAppendLogToErrors On directive%{isapi-parameter}n component,
is always available and preferred.HSE_REQ_IS_KEEP_CONNHSE_REQ_SEND_RESPONSE_HEADER_EXfKeepConn
flag is ignored.HSE_REQ_IS_CONNECTEDFALSE to any unsupported call to
ServerSupportFunction, and sets the
GetLastError value to
ERROR_INVALID_PARAMETER.ReadClient retrieves the request body exceeding the
initial buffer (defined by ISAPIReadAheadBuffer). Based on the
ISAPIReadAheadBuffer setting (number of bytes
to buffer prior to calling the ISAPI handler) shorter requests are sent
complete to the extension when it is invoked. If the request is
longer, the ISAPI extension must use ReadClient to
retrieve the remaining request body.WriteClient is supported, but only with the
HSE_IO_SYNC flag or no option flag (value of
0). Any other WriteClient request
will be rejected with a return value of FALSE, and a
GetLastError value of
ERROR_INVALID_PARAMETER.GetServerVariable is supported, although extended server
variables do not exist (as defined by other servers.) All the
usual Apache CGI environment variables are available from
GetServerVariable, as well as the ALL_HTTP
and ALL_RAW values.mod_isapi supports additional
features introduced in later versions of the ISAPI specification,
as well as limited emulation of async I/O and the
TransmitFile semantics. Apache also supports preloading
ISAPI .dlls for performance, neither of which were not available under
Apache 1.3 mod_isapi.ISAPIAppendLogToErrors Directive
Description: Record HSE_APPEND_LOG_PARAMETER requests from
ISAPI extensions to the error logSyntax: ISAPIAppendLogToErrors on|offDefault: ISAPIAppendLogToErrors offContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_isapi HSE_APPEND_LOG_PARAMETER requests from ISAPI
extensions to the server error log.ISAPIAppendLogToQuery Directive
Description: Record HSE_APPEND_LOG_PARAMETER requests from
ISAPI extensions to the query fieldSyntax: ISAPIAppendLogToQuery on|offDefault: ISAPIAppendLogToQuery onContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_isapi HSE_APPEND_LOG_PARAMETER requests from ISAPI
extensions to the query field (appended to the CustomLog %q
component).ISAPICacheFile Directive
Description: ISAPI .dll files to be loaded at startup Syntax: ISAPICacheFile file-path [file-path]
...Context: server config, virtual host Status: Base Module: mod_isapi ServerRoot.ISAPIFakeAsync Directive
Description: Fake asynchronous support for ISAPI callbacks Syntax: ISAPIFakeAsync on|offDefault: ISAPIFakeAsync offContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_isapi ISAPILogNotSupported Directive
Description: Log unsupported feature requests from ISAPI
extensions Syntax: ISAPILogNotSupported on|offDefault: ISAPILogNotSupported offContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_isapi ISAPIReadAheadBuffer Directive
Description: Size of the Read Ahead Buffer sent to ISAPI
extensions Syntax: ISAPIReadAheadBuffer sizeDefault: ISAPIReadAheadBuffer 49152Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_isapi ReadClient callback; some
ISAPI extensions may not support the ReadClient function.
Refer questions to the ISAPI extension's author.
mod/mod_log_config.html 100644 0 0 56022 11074463036 12650 0 ustar 0 0
Apache Module mod_ldap
Description: LDAP connection pooling and result caching services for use
by other LDAP modules Status: Experimental ModuleIdentifier: ldap_module SourceFile: util_ldap.c Compatibility: Available in version 2.0.41 and later Summary
--with-ldap
flag to the configure script when building
Apache.mod_ldap be linked
with one of the following LDAP SDKs:
OpenLDAP SDK (both 1.x and 2.x),
Novell LDAP SDK or the
iPlanet(Netscape) SDK.Directives
LDAPCacheEntries LDAPCacheTTL LDAPConnectionTimeout LDAPOpCacheEntries LDAPOpCacheTTL LDAPSharedCacheFile LDAPSharedCacheSize LDAPTrustedCA LDAPTrustedCATypeTopics
Example Configuration
mod_ldap to increase the performance of HTTP Basic
authentication provided by mod_auth_ldap.
# Enable the LDAP connection pool and shared
# memory cache. Enable the LDAP cache status
# handler. Requires that mod_ldap and mod_auth_ldap
# be loaded. Change the "yourdomain.example.com" to
# match your domain.
LDAPSharedCacheSize 200000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600
<Location /ldap-status>
SetHandler ldap-status
Order deny,allow
Deny from all
Allow from yourdomain.example.com
AuthLDAPEnabled on
AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one
AuthLDAPAuthoritative on
Require valid-user
</Location>
LDAP Connection Pool
LDAP Cache
mod_ldap uses an aggressive
caching strategy to minimize the number of times that the LDAP
server must be contacted. Caching can easily double or triple
the throughput of Apache when it is serving pages protected
with mod_auth_ldap. In addition, the load on the LDAP server
will be significantly decreased.mod_ldap supports two types of LDAP caching during
the search/bind phase with a search/bind cache and
during the compare phase with two operation
caches. Each LDAP URL that is used by the server has
its own set of these three caches.The Search/Bind Cache
mod_ldap stores the username, the DN
retrieved, the password used to bind, and the time of the bind
in the cache. Whenever a new connection is initiated with the
same username, mod_ldap compares the password
of the new connection with the password in the cache. If the
passwords match, and if the cached entry is not too old,
mod_ldap bypasses the search/bind phase.LDAPCacheEntries and LDAPCacheTTL directives.Operation Caches
mod_ldap uses two operation caches
to cache the compare operations. The first compare cache is
used to cache the results of compares done to test for LDAP
group membership. The second compare cache is used to cache
the results of comparisons done between distinguished
names.LDAPOpCacheEntries
and LDAPOpCacheTTL
directives.Monitoring the Cache
mod_ldap has a content handler that allows
administrators to monitor the cache performance. The name of
the content handler is ldap-status, so the
following directives could be used to access the
mod_ldap cache information:
<Location /server/cache-info>
SetHandler ldap-status
</Location>
http://servername/cache-info,
the administrator can get a status report of every cache that is used
by mod_ldap cache. Note that if Apache does not
support shared memory, then each httpd instance has its
own cache, so reloading the URL will result in different
information each time, depending on which httpd
instance processes the request.
Using SSL
LDAPTrustedCA and
LDAPTrustedCAType. These directives specify the certificate
file or database and the certificate type. Whenever the LDAP url
includes ldaps://, mod_ldap will establish
a secure connection to the LDAP server.
# Establish an SSL LDAP connection. Requires that
# mod_ldap and mod_auth_ldap be loaded. Change the
# "yourdomain.example.com" to match your domain.
LDAPTrustedCA /certs/certfile.der
LDAPTrustedCAType DER_FILE
<Location /ldap-status>
SetHandler ldap-status
Order deny,allow
Deny from all
Allow from yourdomain.example.com
AuthLDAPEnabled on
AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one
AuthLDAPAuthoritative on
Require valid-user
</Location>
mod_ldap is linked against the
Netscape/iPlanet LDAP SDK, it will not talk to any SSL server
unless that server has a certificate signed by a known Certificate
Authority. As part of the configuration
mod_ldap needs to be told where it can find
a database containing the known CAs. This database is in the same
format as Netscape Communicator's cert7.db
database. The easiest way to get this file is to start up a fresh
copy of Netscape, and grab the resulting
$HOME/.netscape/cert7.db file.LDAPCacheEntries Directive
Description: Maximum number of entries in the primary LDAP cache Syntax: LDAPCacheEntries numberDefault: LDAPCacheEntries 1024Context: server config Status: Experimental Module: mod_ldap LDAPCacheTTL Directive
Description: Time that cached items remain valid Syntax: LDAPCacheTTL secondsDefault: LDAPCacheTTL 600Context: server config Status: Experimental Module: mod_ldap LDAPConnectionTimeout Directive
Description: Specifies the socket connection timeout in seconds Syntax: LDAPConnectionTimeout secondsContext: server config Status: Experimental Module: mod_ldap LDAPOpCacheEntries Directive
Description: Number of entries used to cache LDAP compare
operations Syntax: LDAPOpCacheEntries numberDefault: LDAPOpCacheEntries 1024Context: server config Status: Experimental Module: mod_ldap mod_ldap
will use to cache LDAP compare operations. The default is 1024
entries. Setting it to 0 disables operation caching.LDAPOpCacheTTL Directive
Description: Time that entries in the operation cache remain
valid Syntax: LDAPOpCacheTTL secondsDefault: LDAPOpCacheTTL 600Context: server config Status: Experimental Module: mod_ldap LDAPSharedCacheFile Directive
Description: Sets the shared memory cache file Syntax: LDAPSharedCacheFile directory-path/filenameContext: server config Status: Experimental Module: mod_ldap LDAPSharedCacheSize Directive
Description: Size in bytes of the shared-memory cache Syntax: LDAPSharedCacheSize bytesDefault: LDAPSharedCacheSize 102400Context: server config Status: Experimental Module: mod_ldap LDAPTrustedCA Directive
Description: Sets the file containing the trusted Certificate Authority certificate or database Syntax: LDAPTrustedCA directory-path/filenameContext: server config Status: Experimental Module: mod_ldap mod_ldap should use when establishing an SSL
connection to an LDAP server. If using the Netscape/iPlanet Directory
SDK, the file name should be cert7.db.LDAPTrustedCAType Directive
Description: Specifies the type of the Certificate Authority file Syntax: LDAPTrustedCAType typeContext: server config Status: Experimental Module: mod_ldap
DER_FILE - file in binary DER format
BASE64_FILE - file in Base64 format
CERT7_DB_PATH - Netscape certificate database file ")
mod/mod_log_forensic.html 100644 0 0 22525 11074463036 13214 0 ustar 0 0
Apache モジュール mod_log_config
This translation may be out of date. Check the
English version for recent changes.
説明: サーバへのリクエストのロギング ステータス: Base モジュール識別子: log_config_module ソースファイル: mod_log_config.c 概要
TransferLog,
新しい書式を 定義する LogFormat,
ログファイルと 書式を一度に定義する CustomLog です。
各リクエストが複数回ログ収集されるようにするために
TransferLog ディレクティブと
CustomLog
ディレクティブは複数回使用することができます。
カスタムログ書式
LogFormat ディレクティブと
CustomLog
ディレクティブの書式を指定する引数は文字列です。この文字列を使ってそれぞれの
リクエストがログファイルにログ収集されます。その文字列には
ログファイルにそのまま
書かれる文字列や、それぞれ改行とタブを現す C 言語
形式の制御文字 "\n" と "\t"
とを含めることができます。そのまま出力させたい引用符とバックスラッシュは
バックスラッシュでエスケープする必要があります。%"
ディレクティブを書式の文字列に書くことで
ログ収集されます。"%"
ディレクティブはログファイル中では以下のような
値で置換されます:フォーマット文字列
説明 %%パーセント記号 (Apache 2.0.44 以降) %...aリモート IP アドレス %...Aローカル IP アドレス %...BHTTP ヘッダ以外の送られたバイト数 %...bHTTP ヘッダ以外の送られたバイト数。CLF 書式。
すなわち、1 バイトも送られなかったときは 0 ではなく、
' -' になる%...{Foobar}Cサーバに送られたリクエスト中のクッキー Foobar の値 %...Dリクエストを処理するのにかかった時間、ミリ秒単位 %...{FOOBAR}e環境変数 FOOBAR の内容 %...fファイル名 %...hリモートホスト %...Hリクエストプロトコル %...{Foobar}iサーバに送られたリクエストの Foobar:
ヘッダの内容%...l(identd からもし提供されていれば) リモートログ名。
これは
IdentityCheck
ディレクティブが On に設定されていない限り、
- になります。%...mリクエストメソッド %...{Foobar}n他のモジュールからのメモ Foobar の内容 %...{Foobar}o応答の Foobar: ヘッダの内容%...pリクエストを扱っているサーバの正式なポート %...Pリクエストを扱った子プロセスのプロセス ID %...{format}Pリクエストを扱ったワーカーのプロセス ID かスレッド ID。
format として有効な値は pid と tid
(Apache 2.0.46 以降)
%...q問い合せ文字列 (存在する場合は前に ? が追加される。
そうでない場合は空文字列)%...rリクエストの最初の行 %...sステータス。内部でリダイレクトされたリクエストは、元々の
リクエストのステータス --- 最後のステータスは %...>s
%...t時刻。CLF の時刻の書式 (標準の英語の書式) %...{format}tformat で与えられた書式による時刻。format は
strftime (3) の
書式である必要がある。(地域化されている可能性がある)%...Tリクエストを扱うのにかかった時間、秒単位 %...uリモートユーザ (認証によるもの。ステータス ( %s) が
401 のときは意味がないものである可能性がある)
%...Uリクエストされた URL パス。クエリ文字列は含まない %...vリクエストを扱っているサーバの正式な ServerName%...VUseCanonicalName の設定によるサーバ名%...X応答が完了したときの接続ステータス:
X =応答が完了する前に接続が異常終了 + =応答が送られた後に接続を持続することが可能 - = 応答が送られた後に接続が切られる %...c に割り当てられて
いましたが、これは歴史的に ssl が使用している
%...{var}c
構文と衝突していました。)%...Iリクエストとヘッダを含む、受け取ったバイト数。
0 にはならない。
これを使用するためには mod_logio が必要%...Oヘッダを含む、送信したバイト数。0 にはならない。
これを使用するためには mod_logio が必要"%h %u %r %s %b" のように)、
その項目を含めるかどうかの条件 (もし条件に合わなかったときは
その項目は "-" になります) にすることができます。条件の形式は
HTTP ステータスコードのリストで、前に "!" を付けることもできます。
ですから、"%400,501{User-agent}i" は 400 エラーと 501 エラー
(Bad Request と Not Implemented) のときのみ User-agent:
をログ収集します。
"%!200,304,302{Referer}i" は普通のステータスを返さなかった
すべてのリクエストで Referer: をログ収集します。% ディレクティブの
%s, %U, %T, %D, %r は元のリクエストを、他は最終的なリクエストを
使用します。例えば、リクエストの最終ステータスを記録するには
%>s を、内部的に認証されていないリソースへリダイレクトされた
リクエストで元のリクエストで認証されたユーザを記録するためには
%<u を使うことができます。%...r, %...i,
%...o の文字列は
エスケープされていなかったことに
注意してください。これは主に Common Log Format からの要求によるものです。
これは、クライアントがログに制御文字を挿入することができるということで、
生のログファイルを扱うときには非常に注意が必要でした。\xhh という
文字列でエスケープされるようになりました。ここで、hh は
そのままのバイトの値の 16 進での値です。この規則の例外には、
バックスラッシュを使ってエスケープされる " と \ と、
C 形式の表記法が使われる空白文字 (\n, \t など) が
あります。
"%h %l %u %t \"%r\" %>s %b""%v %h %l %u %t \"%r\" %>s %b""%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-agent}i\"""%{Referer}i -> %U""%{User-agent}i"%v と %p にはそれぞれ、
リクエストを扱っているサーバの正規化された
ServerName と Listen が使われるということに注意してください。
これは UseCanonicalName の
設定に関わらず、常にそうなります。そうしないとどの
ホストが実際にリクエストを扱ったのかを知るために、
ログ解析プログラムがバーチャルホストのマッチングをとるアルゴリズム全体を
再実装しなければならなくなるからです。
セキュリティに関して
CookieLog ディレクティブ
説明: クッキングのロギングのためのファイル名を設定する 構文: CookieLog filenameコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_log_config 互換性: このディレクティブは非推奨 CookieLog
ディレクティブはクッキーのロギングのためのファイル名を
設定します。filename は ServerRoot
からの相対パスです。このディレクティブは mod_cookies との互換性のためだけに
存在し、使用は推奨されていません。CustomLog ディレクティブ
説明: ログファイルの名前と書式を設定する 構文: CustomLog file|pipe
format|nickname
[env=[!]environment-variable]コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_log_config CustomLog ディレクティブはサーバへのリクエストを
ログ収集するために使われます。ログの書式が指定され、
環境変数を使ってロギングが条件に応じて行なわれるようにすることもできます。
ServerRoot
からの相対パスで表されるファイル名。|" と、その後に標準入力からログの
情報を受けとるプログラムへのパスが続いたもの。
セキュリティ
注
LogFormat ディレクティブにより
定義された nickname か、ログの書式
のところで説明されている、明示的な format 文字列の
どちらかを指定することができます。
# CustomLog with format nickname
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
# CustomLog with explicit format string
CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b"
env=!name' 文が使われたときは
設定されていない場合)、リクエストがログ収集されます。mod_setenvif モジュールと
mod_rewrite モジュールの両方もしくは
片方を用いてリクエストごとに設定することができます。
例えば、サーバにあるすべての GIF 画像へのリクエストを別のログファイル
には記録したいけれど、メインログには記録したくない、というときは
以下のものを使うことができます:
SetEnvIf Request_URI \.gif$ gif-image
CustomLog gif-requests.log common env=gif-image
CustomLog nongif-requests.log common env=!gif-image
LogFormat ディレクティブ
説明: ログファイルで使用する書式を設定する 構文: LogFormat format|nickname
[nickname]デフォルト: LogFormat "%h %l %u %t \"%r\" %>s %b"コンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_log_config LogFormat ディレクティブは二つの形式のどちらかを
とることができます。最初の形式では一つの引数のみが指定され、
続く TransferLog
で指定されたログで使われるログの書式を設定します。この単独の引数では
上のカスタムログ書式で説明されているように
format を明示的に指定することができます。
もしくは、下で説明されているように前に LogFormat
ディレクティブで定義されたログの書式を nicknameを使って
参照することもできます。LogFormat ディレクティブの二つめの形式は
format に nickname を与えます。
フォーマット文字列全体を再び書くかわりに、
この nickname を続きの LogFormat ディレクティブや
CustomLog ディレクティブで使うことができます。
Nickname を定義する LogFormat ディレクティブは
他には何もしません -- すなわち、ニックネームを定義
するだけで、実際に書式を適用してデフォルトにするということは行ないません。
ですから、これは続く TransferLog
ディレクティブには影響を与えません。
さらに、LogFormat ディレクティブは既存の nickname を
使って別の nickname を定義することはできません。Nickname には
パーセント記号 (%) が含まれていてはいけないことにも注意
してください。例
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
TransferLog ディレクティブ
説明: ログファイルの位置を指定 構文: TransferLog file|pipeコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_log_config CustomLog と全く同じ引数と効果があります。
直接ログ書式を指定する代わりに、ログの書式はそこまでで一番最後に指定された
ニックネームを定義しない
LogFormat ディレクティブ
で定義されたものを使います。
もし他の書式が全く指定されていないときは Common Log Format
が使われます。例
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog logs/access_log
mod/mod_logio.html 100644 0 0 10212 11074463036 11642 0 ustar 0 0
Apache Module mod_log_forensic
Description: Forensic Logging of the requests made to the server Status: Extension ModuleIdentifier: log_forensic_module SourceFile: mod_log_forensic.c Compatibility: Available in version 2.0.50 and later Summary
CoreDumpDirectory
configuration).check_forensic script, which can be found in the
distribution's support directory, may be helpful in evaluating the
forensic log output.
This module was backported from version 2.1 which uses a more powerful
APR version in order to generate the forensic IDs. If you want to run
mod_log_forensic in version 2.0, you need to include
mod_unique_id as well.
Directives
Topics
See also
Forensic Log Format
%{forensic-id}n format string. If you're using
mod_unique_id, its generated ID will be used.|). A sample line
looks like the following (all on one line):
+yQtJf8CoAB4AAFNXBIEAAAAA|GET /manual/de/images/down.gif
HTTP/1.1|Host:localhost%3a8080|User-Agent:Mozilla/5.0 (X11;
U; Linux i686; en-US; rv%3a1.6) Gecko/20040216
Firefox/0.8|Accept:image/png, etc...
-yQtJf8CoAB4AAFNXBIEAAAAA
check_forensic script takes as its argument the name
of the logfile. It looks for those +/- ID pairs
and complains if a request was not completed.
Security Considerations
ForensicLog Directive
Description: Sets filename of the forensic log Syntax: ForensicLog filename|pipeContext: server config, virtual host Status: Extension Module: mod_log_forensic ForensicLog directive is used to
log requests to the server for forensic analysis. Each log entry
is assigned a unique ID which can be associated with the request
using the normal CustomLog
directive. mod_log_forensic takes the unique ID from
mod_unique_id, so you need to load this module as well.
(This requirement will not be necessary in version 2.1 and later, because
of a more powerful APR version.) The ID token is attached to the request
under the name forensic-id, which can be added to the
transfer log using the %{forensic-id}n format string.
ServerRoot.|", followed by the path
to a program to receive the log information on its standard
input. The program name can be specified relative to the ServerRoot directive.
Security:
httpd. This will be root if the server was
started by root; be sure that the program is secure or switches to a
less privileged user.Note
mod/mod_mem_cache.html 100644 0 0 35256 11074463036 12451 0 ustar 0 0
Apache モジュール mod_logio
説明: リクエスト毎に入力バイト数と出力バイト数とをロギング ステータス: Extension モジュール識別子: logio_module ソースファイル: mod_logio.c 概要
mod_log_config モジュールが
必要です。
カスタムログ書式
%" ディレクティブを
入れることでログ収集されます:フォーマット文字列
説明 %...Iリクエストとヘッダを含む、受け取ったバイト数。
0 にはならない。 %...Oヘッダを含む、送信したバイト数。0 にはならない。
"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-agent}i\" %I %O"
mod/mod_mime.html 100644 0 0 156334 11074463036 11520 0 ustar 0 0
Apache モジュール mod_mem_cache
説明: URI をキーにしたコンテンツのキャッシュ ステータス: Experimental モジュール識別子: mem_cache_module ソースファイル: mod_mem_cache.c 概要
これは実験的なモジュールです。文書もまだ開発中です...
mod_cache を必要とします。
これは mod_cache のサポートモジュールとして
動作し、メモリを使用したストレージ管理機構を提供します。
mod_mem_cache は二つのモードのどちらかで動作するように
設定できます: ファイル記述子のキャッシュかヒープ中のオブジェクトの
キャッシュです。ローカルで生成されたコンテンツに対してキャッシュするときや、
mod_proxy を使って ProxyPass (つまりリバースプロキシ向け) に設定したときのバックエンドサーバのコンテンツに対して
キャッシュをするときに、たいへん効果的です。ディレクティブ
MCacheMaxObjectCount MCacheMaxObjectSize MCacheMaxStreamingBuffer MCacheMinObjectSize MCacheRemovalAlgorithm MCacheSize参照
MCacheMaxObjectCount ディレクティブ
説明: キャッシュに保管されるオブジェクトの最大数 構文: MCacheMaxObjectCount valueデフォルト: MCacheMaxObjectCount 1009コンテキスト: サーバ設定ファイル ステータス: Experimental モジュール: mod_mem_cache MCacheMaxObjectCount ディレクティブは
キャッシュされるオブジェクトの最大数を指定します。
この値はハッシュテーブルを作成するときに使われます。
新しいオブジェクトを挿入するときに、オブジェクトの最大数に
達してしまっているとき、新しいオブジェクトをキャッシュできるように、
オブジェクトを一つ消去します。オブジェクトは
MCacheRemovalAlgorithm
で指定されたアルゴリズムに従って削除されます。例
MCacheMaxObjectCount 13001
MCacheMaxObjectSize ディレクティブ
説明: キャッシュに保管できるドキュメントの最大サイズ (バイト) 構文: MCacheMaxObjectSize bytesデフォルト: MCacheMaxObjectSize 10000コンテキスト: サーバ設定ファイル ステータス: Experimental モジュール: mod_mem_cache MCacheMaxObjectSize はドキュメントを
キャッシュするかどうかを判定する、最大のサイズをバイト数で設定します。例
MCacheMaxObjectSize 6400000
注
MCacheMaxObjectSize の値は MCacheMinObjectSize
で指定した値よりも大きくなければなりません。MCacheMaxStreamingBuffer ディレクティブ
説明: ストリームされている応答をキャッシュ不能と決定するまでに
メモリにバッファする最大量 構文: MCacheMaxStreamingBuffer size_in_bytesデフォルト: MCacheMaxStreamingBuffer of 100000 か MCacheMaxObjectSize の少い方コンテキスト: サーバ設定ファイル ステータス: Experimental モジュール: mod_mem_cache MCacheMaxStreamingBuffer ディレクティブは、
サイズが大きすぎてキャッシュできないと判断するまでの、
ストリーム応答のバッファのための最大バイト数を指定します。
ストリーム応答とは、コンテンツの全体がすぐには得られず、
Content-Length がわからない応答を指します。
ストリーム応答を行なうようなものにはプロキシされた応答や、
CGI スクリプトの出力などがあります。デフォルトではストリームの応答は
Content-Length がない限りキャッシュされません。
このような動作になっている理由は、結局キャッシュに収まりきらないと
判断することになってしまうような、サイズの大きな応答のバッファリングに、
大量のメモリが消費されるのを避けるためです。
MCacheMaxStreamingBuffer ディレクティブを使うと、
Content-Length を含まない応答に対して指定された最大量まで
バッファするようにできます。バッファを使い切ると、バッファ中の
コンテンツは捨てられ、キャッシュ動作を中止します。注:
MCacheMaxStreamingBuffer に非零の値を
使っても、クライアントへの応答の転送に特に遅延は発生しません。
mod_mem_cache はストリームコンテンツの断片を
バッファにコピーした後、即座に、その部分をクライアントへの配送の
次段の出力フィルタに送ります。
# Enable caching of streamed responses up to 64KB:
MCacheMaxStreamingBuffer 65536
MCacheMinObjectSize ディレクティブ
説明: キャッシュに保管されるドキュメントの最小サイズ (バイト) 構文: MCacheMinObjectSize bytesデフォルト: MCacheMinObjectSize 0コンテキスト: サーバ設定ファイル ステータス: Experimental モジュール: mod_mem_cache MCacheMinObjectSize ディレクティブは、ドキュメントを
キャッシュするかどうかを判定する、最小のサイズをバイト数で設定します。例
MCacheMinObjectSize 10000
MCacheRemovalAlgorithm ディレクティブ
説明: キャッシュから削除するドキュメントを選ぶためのアルゴリズム 構文: MCacheRemovalAlgorithm LRU|GDSFデフォルト: MCacheRemovalAlgorithm GDSFコンテキスト: サーバ設定ファイル ステータス: Experimental モジュール: mod_mem_cache MCacheRemovalAlgorithm ディレクティブは、
キャッシュから削除するドキュメントを選択するためのアルゴリズムを
指定します。選択肢は二つあります:
LRU (Least Recently Used)LRU 一番長くアクセスされていないドキュメントを削除します。
GDSF (GreadyDual-Size)GDSF はキャッシュミスのコストとドキュメントのサイズをもとに、
ドキュメントのキャッシュに対して優先度をつけます。
優先度の一番低いドキュメントが最初に削除されます。例
MCacheRemovalAlgorithm GDSF
MCacheRemovalAlgorithm LRU
MCacheSize ディレクティブ
説明: キャッシュに使われるメモリの最大量をキロバイト単位で指定 構文: MCacheSize KBytesデフォルト: MCacheSize 100コンテキスト: サーバ設定ファイル ステータス: Experimental モジュール: mod_mem_cache MCacheSize ディレクティブはキャッシュに
使われるメモリの大きさをキロバイト (1024 バイト単位) で設定します。
新しいオブジェクトをキャッシュに挿入することになり、オブジェクトの
サイズが残りのメモリより大きい場合は、その新しいオブジェクトの挿入が
可能になるまで、古いオブジェクトが削除されていきます。
オブジェクトは MCacheRemovalAlgorithm
で指定したアルゴリズムに従って削除されます。例
MCacheSize 700000
注
MCacheSize の値は MCacheMaxObjectSize ディレクティブで指定した値より
大きくなければなりません。
mod/mod_mime_magic.html 100644 0 0 32242 11074463036 12627 0 ustar 0 0
Apache モジュール mod_mime
This translation may be out of date. Check the
English version for recent changes.
説明: リクエストされたファイルの拡張子とファイルの振る舞い
(ハンドラとフィルタ)、内容 (MIME タイプ、言語、文字セット、エンコーディング)
とを関連付ける ステータス: ベース モジュール識別子: mime_module ソースファイル: mod_mime.c 概要
mod_negotiation
をご覧下さい。AddCharset ディレクティブ、
AddEncoding ディレクティブ、
AddHandler ディレクティブ、
AddLanguage ディレクティブ、
AddType ディレクティブはすべて、
ファイルの拡張子をメタ情報にマップするために使用されます。
それぞれ、ドキュメントの文字セット (訳注: charset)、content-encoding,
content-language, MIME タイプ (content-type) を設定します。
TypesConfig ディレクティブは拡張子を
MIME タイプにマップするファイルを指定するために使用されます。mod_mime はコンテンツを作成、処理する
ハンドラ と フィルタ
を設定することができます。AddHandler ディレクティブ、AddOutputFilter ディレクティブ、AddInputFilter ディレクティブは
ドキュメントを扱うモジュールやスクリプトを制御します。
MultiviewsMatch ディレクティブは
これらのディレクティブが指定したファイルの拡張子を
mod_negotiation が Multiviews のマッチをとるときに
考慮するようにできます。mod_mime はメタ情報をファイル名と関連付けますが、
core サーバにはあるコンテナ
(たとえば, <Location>, <Directory>, <Files>) の中のすべてのファイルを特定の
メタ情報と関連付けるディレクティブがあります。これらのディレクティブには
ForceType, SetHandler, SetInputFilter, SetOutputFilter があります。
コアのディレクティブは mod_mime により定義された
ファイル名の拡張子のマッピングすべてを上書きします。Last-Modified
ヘッダの値は変わらないことに注意してください。ですから、
それらを変更した場合は、クライアントやプロキシで以前にキャッシュされた
コピーがそのときのヘッダとともに使われる可能性があります。
メタ情報 (言語、コンテントタイプ、文字セット、エンコーディング) を
変更したときは、すべての訪問者が正しいコンテントヘッダを
受け取るように、影響を受けるファイルに 'touch' コマンドを実行する
(最終更新日を更新する) 必要があるかもしれません。ディレクティブ
AddCharset AddEncoding AddHandler AddInputFilter AddLanguage AddOutputFilter AddType DefaultLanguage ModMimeUsePathInfo MultiviewsMatch RemoveCharset RemoveEncoding RemoveHandler RemoveInputFilter RemoveLanguage RemoveOutputFilter RemoveType TypesConfigトピック
参照
複数の拡張子のあるファイル
welcome.html.fr
がコンテントタイプは text/html
に、言語はフランス語にマップされる場合、welcome.fr.html
もまったく同じ情報にマップされます。
同じメタ情報にマップされる拡張子が複数あるときには、言語と
コンテントエンコーディングを除いて、
右側にあるものが使用されます。たとえば、.gif が MIME
タイプ image/gif にマップされ、.html
が MIME タイプ text/html
にマップされる場合は、ファイル welcome.gif.html は
MIME タイプ text/html に関連付けられます。welcome.html.en.de は
Content-Language: en, de と Content-Type:
text/html として送信されます。.imap が (mod_imap の) imap-file
にマップされていて、.html が MIME タイプ text/html
にマップされているときは、ファイル world.imap.html は
imap-file ハンドラと text/html MIME
タイプに関連付けられます。ファイルが処理されるときは imap-file
ハンドラが使用されますので、そのファイルは mod_imap
のイメージマップファイルとして扱われることになります。
コンテントエンコーディング
gzip の
ような圧縮のことを指しますが、pgp のような暗号化や、
バイナリファイルを ASCII (テキスト) 形式で送るために考案された
UUencoding のことを指すこともあります。
.doc 拡張子が Microsoft Word の
ファイルタイプと関連付けられていて、.zip 拡張子が
pkzip ファイルエンコーディングと関連付けられていると、ファイル
Resume.doc.zip は pkzip された Word ドキュメントである
ということがわかります。Content-Encoding ヘッダを
送ります。Content-encoding: pkzip
文字セットと言語
mod_negotiation 参照)
の最中に、複数の文字セット、言語、エンコーディング、MIME タイプからなる
代替物があるときにどのドキュメントをクライアントに送るのかを
決定するときに使われます。AddCharset,
AddEncoding, AddLanguage,
AddType の各ディレクティブで作成された
拡張子の関連付け (と MimeMagicFile でリストされている
拡張子) がこの選択に参加します。AddHandler,
AddInputFilter,
AddOutputFilter の
各ディレクティブでのみ関連付けられている拡張子は
MultiviewsMatch ディレクティブを
使うことでマッチの
処理に含めることも外すこともできます。Charset
Content-Language ヘッダで送ることもあります。
また、情報を正しく表示するために使用すべき文字セットを示すために
Conten-Type ヘッダに情報を追加することもあります。
Content-Language: en, fr
Content-Type: text/plain; charset=ISO-8859-1
charset が
使用すべき文字セットの名前です。AddCharset ディレクティブ
説明: ファイル名の拡張子を指定された文字セットにマップする 構文: AddCharset charset extension
[extension] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime AddCharset ディレクティブは、
与えられた拡張子を指定された charset にマップします。charset
は、拡張子 extension を含んでいるファイル名の MIME charset
パラメータです。新しいマッピングは既にある他のマッピングに追加され、同じ拡張子
extension のためのマッピングを上書きします。例
AddLanguage ja .ja
AddCharset EUC-JP .euc
AddCharset ISO-2022-JP .jis
AddCharset SHIFT_JIS .sjis
xxxx.ja.jis は charset が
ISO-2022-JP の日本語のドキュメントとして扱われます
(xxxx.jis.ja も同様)。AddCharset
ディレクティブは、ドキュメントが適切に解釈され表示されるように、
ドキュメントの charset の情報をクライアントに教えるために役に立ちます。
また、サーバがクライアントの charset
の優先度に基づいて複数のドキュメントの中からドキュメントを選ぶコンテントネゴシエーションのためにも役に立ちます。参照
AddEncoding ディレクティブ
説明: ファイル名の拡張子を指定されたエンコーディング
にマップする 構文: AddEncoding MIME-enc extension
[extension] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime AddEncoding ディレクティブは、
与えられた拡張子を指定されたエンコーディングにマップします。
MIME-enc は、拡張子 extension
を含んだドキュメントに使用する MIME エンコーディングです。
この新しいマッピングは既にある他のマッピングに追加され、
同じ拡張子 extension のためのマッピングを上書きします。例
AddEncoding x-gzip .gz
AddEncoding x-compress .Z.gz を含むファイル名が x-gzip
エンコーディングを使ってエンコードされていることと、拡張子 .Z
を含むファイル名が x-compress
でエンコードされていることを指定します。x-zip と x-compress
が返ってくることを期待しますが、標準規格ではそれぞれ
gzip と compress
と等価であることになっています。Apache
は、コンテントエンコーディングの比較をするときには、先頭にある
x- を無視します。Apache
がエンコーディング付きで応答を返すときは、クライアントが要求した形式
(すなわち、x-foo や foo)
を使用します。要するに、この二つのエンコーディングの場合は常に
x-gzip と x-compress
を使うべきである、ということです。deflate
のようなより新しいエンコーディングでは、x-
なしで指定してください。
AddHandler ディレクティブ
説明: ファイル名の拡張子を指定されたハンドラにマップする 構文: AddHandler handler-name extension
[extension] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime .cgi" で終わるファイルを CGI
スクリプトとして扱いたいときは、以下の設定をします。
AddHandler cgi-script .cgi
.cgi" のファイルは CGI プログラムとして扱われます。
参照
AddInputFilter ディレクティブ
説明: ファイルの拡張子をクライアントのリクエストを処理する
フィルタにマップする 構文: AddInputFilter filter[;filter...]
extension [extension] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime 互換性: 2.0.26 以降で使用可能 AddInputFilter はファイルの拡張子
extension をクライアントのリクエストや POST がサーバに来たときに
処理をするフィルタにマップします。
これは、SetInputFilter ディレクティブも
含め、他の場所で定義されているフィルタに加えられます。
このマッピングはすでにあるものより優先されてマージされ、
同じ extension に対する既存のマッピングを上書きします。参照
AddLanguage ディレクティブ
説明: ファイル名を指定された言語にマップ 構文: AddLanguage MIME-lang extension
[extension] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime AddLanguage ディレクティブは、与えられた拡張子を指定された
content language にマップします。MIME-lang は、拡張子
extension を含んでいるファイル名の MIME における言語です。
この新しいマッピングは既にあるマッピングに追加され、同じ拡張子
extension のためのマッピングを上書きします。例
AddEncoding x-compress .Z
AddLanguage en .en
AddLanguage fr .fr
xxxx.en.Z ドキュメントは compress
された英語のドキュメントとして扱われます (xxxx.Z.en
も同様)。content language はクライアントに通知されますが、
ブラウザがこの情報を使うことはおそらくありません。
AddLanguage
ディレクティブは、サーバがクライアントの言語の優先度に基づいて複数の
ドキュメントの中からドキュメントを選ぶコンテントネゴシエーションのためにより役に立ちます。
AddLanguage en .en
AddLanguage en-gb .en
AddLanguage en-us .en
.en のあるドキュメントは
en-us として扱われます。参照
AddOutputFilter ディレクティブ
説明: ファイル名の拡張子をサーバからの応答を処理するフィルタに
マップする 構文: AddOutputFilter filter[;filter...]
extension [extension] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime 互換性: 2.0.26 以降で使用可能 AddOutputFilter ディレクティブは
拡張子 extension をサーバの応答がクライアントに送られる
前に処理するフィルタを定義します。
これは SetOutputFilter
ディレクティブと AddOutputFilterByType ディレクティブ
を含め、他の場所で定義されているフィルタに加えられます。
この新しいマッピングは既にあるマッピングに追加され、同じ拡張子
extension のためのマッピングを上書きします。.shtml ファイルを SSI で処理し、
その出力を mod_deflate を使って圧縮します。
AddOutputFilter INCLUDES;DEFLATE shtml
参照
AddType ディレクティブ
説明: ファイル名の拡張子を指定されたコンテントタイプにマップ 構文: AddType MIME-type extension
[extension] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime AddType ディレクティブは、
与えられた拡張子を指定されたコンテントタイプにマップします。
MIME-type は拡張子 extension
を含んだドキュメントに使用する MIME タイプです。
この新しいマッピングは既にあるマッピングに追加され、同じ拡張子
extension のためのマッピングを上書きします。
このディレクティブは MIME タイプファイル (TypesConfig ディレクティブを参照)
に無いマッピングを追加するために使用することができます。例
AddType image/gif .gif
新しい MIME タイプは、
TypesConfig
ファイルを変更するのではなく、AddType
ディレクティブを使って追加することが推奨されています。
参照
DefaultLanguage ディレクティブ
説明: あるスコープのすべてのファイルを指定された言語に
設定する 構文: DefaultLanguage MIME-langコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime DefaultLanguage ディレクティブは、Apache
がディレクティブのスコープ (例えば、その時点の
<Directory>
の範囲) にある、明示的な言語拡張子
(AddLanguage で設定される
.fr や .de) のない全てのファイルを、指定された
MIME-lang 言語であるとみなすようにします。
これにより、すべてのファイル名を変えることなく、
ディレクトリがオランダ語のコンテントを含んでいる、
というようなことを指定することができます。
拡張子を使用して言語を指定する方法と違い、
DefaultLanguage
は一つの言語しか指定できないことに注意してください。DefaultLanguage
ディレクティブが有効でなく、ファイルに
AddLanguage
で設定された言語の拡張子がないときは、
ファイルには言語属性がないとみなされます。例
DefaultLanguage en
参照
ModMimeUsePathInfo ディレクティブ
説明: path_info コンポーネントをファイル名の一部として扱うように
mod_mime に通知する構文: ModMimeUsePathInfo On|Offデフォルト: ModMimeUsePathInfo Offコンテキスト: ディレクトリ ステータス: ベース モジュール: mod_mime 互換性: Apache 2.0.41 以降 ModMimeUsePathInfo ディレクティブは、
mod_mime の持つディレクティブを
リクエストに適用させるために、ファイル名と path_info URL
コンポーネントを結合させるために使用します。
デフォルトでは「 Off 」で、path_info
コンポーネントは無視されます。例
ModMimeUsePathInfo On
/bar が存在して (foo.shtml は存在しない)
ModMimeUsePathInfo が On であるとして、
/bar/foo.shtml に対するリクエストを発行した場合、
mod_mime は入ってきたリクエストを
/bar/foo.shtml として扱い、
AddOutputFileter INCLUDES .shtml のようなディレクティブは
INCLUDES フィルタをリクエストに付加させます。
ModMimeUsePathInfo が設定されなければ、
INCLUDES フィルタは付加されません。参照
MultiviewsMatch ディレクティブ
説明: MultiViews でのマッチングの検索に含ませる
ファイルのタイプを指定する 構文: MultiviewsMatch Any|NegotiatedOnly|Filters|Handlers
[Handlers|Filters]デフォルト: MultiviewsMatch NegotiatedOnlyコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime 互換性: 2.0.26 以降で使用可能 MultiviewsMatch を使用することで、
mod_negotiation の
Multiviews に 3 種類の異なる挙動をさせることができます。
Multiviews を使用すると、ファイル (例 index.html)
に対するリクエストに対して、ネゴシエーションする拡張子がベースに付いたもの
(index.html.en, index.html.fr や
index.html.gz)
をマッチさせることができます。NegotiatedOnly オプションでは、ベース名に続く拡張子全てが
コンテントネゴシエーションで mod_mime
が認識する拡張子 (例 文字セット、コンテントタイプ、言語やエンコーディング)
に関連付けられていなければなりません。これは副作用の最も少ない
最も的確な実装で、デフォルトになっています。MultiviewsMatch ディレクティブに Handlers,
Filters またはその両方のオプションをセットします。
もし他の条件が同じであれば、最も小さいファイルが送信されます。
例えば、500 文字の index.html.cgi と 1000 バイトの
index.html.pl であれば、.cgi
のファイルが優先されます。.asis ファイルを利用しているユーザは、
.asis ファイルが asis-handler に関連付けられているときには、
ハンドラオプションの使用を好むでしょう。mod_mime が認識しない拡張子であろうとも、
どんな拡張子でもマッチさせる Any が使用できます。
この挙動は Apache 1.3 のときと同じもので、予期しない動作、例えば .old や
.bak ファイルといったウェブマスタが送信を意図していない
ファイルを送信する、といった動作を行なう可能性があります。
MultiviewsMatch Handlers Filters
参照
RemoveCharset ディレクティブ
説明: ファイルの拡張子に関連付けられたすべての文字セット
を解除する 構文: RemoveCharset extension [extension]
...コンテキスト: バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime 互換性: 2.0.24 以降で使用可能 RemoveCharset ディレクティブ
は与えられた拡張子に関連付けられた文字セットを取り消します。
これにより、サブディレクトリにある .htaccess
ファイルが親ディレクトリやサーバの設定ファイル
から継承した関連付けを取り消すことができます。例えば:例
RemoveCharset .html .shtml
RemoveEncoding ディレクティブ
説明: ファイルの拡張子に関連付けられたすべてのコンテントエンコーディング
を解除する 構文: RemoveEncoding extension [extension]
...コンテキスト: バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime RemoveEncoding ディレクティブは、
与えられた拡張子に関連付けられたエンコーディングを取り消します。
これにより、サブディレクトリにある .htaccess
ファイルが親ディレクトリやサーバの設定ファイルから継承した関連付けを
取り消すことができます。/foo/.htaccess:
AddEncoding x-gzip .gz
AddType text/plain .asc
<Files *.gz.asc>
RemoveEncoding .gz
</Files>
foo.gz は gzip
でエンコードされていることを指定しますが、foo.gz.asc
はエンコードされていないプレーンテキストの
ファイルであるということを指定します。注意
RemoveEncoding は
AddEncoding
ディレクティブの後で処理されますので、
同じディレクトリの設定中に両方が現れると、
後者の効果が打ち消される可能性があります。RemoveHandler ディレクティブ
説明: ファイルの拡張子に関連付けられたすべてのハンドラを
解除する 構文: RemoveHandler extension [extension]
...コンテキスト: バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime RemoveHandler ディレクティブ
は与えられた拡張子に関連付けられたハンドラを取り消します。
これにより、サブディレクトリにある .htaccess
ファイルが親ディレクトリやサーバの設定ファイル
から継承した関連付けを取り消すことができます。たとえば:/foo/.htaccess:
AddHandler server-parsed .html
/foo/bar/.htaccess:
RemoveHandler .html
/foo/bar ディレクトリの .html
ファイルは SSI (mod_include モジュール参照) ではなく、
普通のファイルとして扱われるようにする効果があります。
RemoveInputFilter ディレクティブ
説明: ファイル拡張子に関連付けられた入力フィルタを解除する 構文: RemoveInputFilter extension [extension]
...コンテキスト: バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime 互換性: 2.0.26 以降で使用可能 RemoveInputFilter ディレクティブは
指定されたファイル拡張子に関連付けられた入力フィルタを解除します。
これを利用することで、親ディレクトリやサーバ設定ファイルから
継承した関連付けを サブディレクトリ内において
.htaccess ファイルで取り消すことができます。参照
RemoveLanguage ディレクティブ
説明: ファイル拡張子に関連付けられた言語を解除する 構文: RemoveLanguage extension [extension]
...コンテキスト: バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime 互換性: 2.0.24 以降で使用可能 RemoveLanguage ディレクティブは
指定されたファイル拡張子に関連付けられた言語を解除します。
これを利用することで、親ディレクトリやサーバ設定ファイルから
継承した関連付けを サブディレクトリ内において
.htaccess ファイルで取り消すことができます。RemoveOutputFilter ディレクティブ
説明: ファイル拡張子に関連付けられた出力フィルタを解除する 構文: RemoveOutputFilter extension [extension]
...コンテキスト: バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime 互換性: 2.0.26 以降でのみ使用可能 RemoveOutputFilter ディレクティブは
指定されたファイル拡張子に関連付けられた出力フィルタを解除します。
これを利用することで、親ディレクトリやサーバ設定ファイルから
継承した関連付けを サブディレクトリ内において
.htaccess ファイルで取り消すことができます。例
RemoveOutputFilter shtml
参照
RemoveType ディレクティブ
説明: ファイルの拡張子と関連付けられたコンテントタイプを
解除する 構文: RemoveType extension [extension]
...コンテキスト: バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: ベース モジュール: mod_mime RemoveType ディレクティブは与えられた拡張子の
MIME タイプの関連付けを取り消します。これにより、
サブディレクトリにある .htaccess
ファイルが親ディレクトリやサーバの設定ファイルから継承した
関連付けを取り消すことができます。たとえば:/foo/.htaccess:
RemoveType .cgi
/foo/ ディレクトリ以下の .cgi
ファイルの特別な扱いを取り消します。ファイルは DefaultType として扱われます。注意
RemoveType ディレクティブは
AddType
ディレクティブの後に処理されますので、
両方が同じディレクトリの設定中に現れた場合、
後者の効果が打ち消される可能性があります。TypesConfig ディレクティブ
説明: mime.types ファイルの位置構文: TypesConfig file-pathデフォルト: TypesConfig conf/mime.typesコンテキスト: サーバ設定ファイル ステータス: ベース モジュール: mod_mime TypesConfig ディレクティブは、MIME
タイプ設定ファイルの位置を設定します。filename は
ServerRoot からの相対パスです。
このファイルはファイルの拡張子からコンテントタイプへの
デフォルトのマッピングを設定します。
ほとんどの管理者は、よく使われるファイル名の拡張子を
IANA に登録されたコンテントタイプに関連付けている、
Apache の mime.types ファイルを使います。
現在の一覧は http://www.isi.edu/in-notes/iana/assignments/media-types/media-types
で管理されています。これは、主要なメディアタイプの定義を提供して、
必要ところを AddType で
上書きする、という方法で httpd.conf を簡略にします。
mime.types はサーバをアップグレードしたときに
置き換えられるかもしれないので、そのファイルを直接
編集しないでください。AddType
ディレクティブの引数と同じ形式の行で構成されます。
MIME-type [extension] ...
(1) IANA に既に登録されている、あるいは (2)
広く受け入れられていてプラットホーム間でファイル拡張子に衝突がない、
という場合でなければ、配布中の
mime.types
ファイルに新たなものを登録するように
Apache HTTP Server Project にリクエストしないでください。
category/x-subtype のリクエストは自動的に却下されますし、
言語や文字セットの名前空間で既に使用されていて、衝突の可能性のある
2 文字の拡張子も却下されます。
参照
mod/mod_negotiation.html 100644 0 0 37714 11074463036 13071 0 ustar 0 0
Apache Module mod_mime_magic
Description: Determines the MIME type of a file
by looking at a few bytes of its contents Status: Extension ModuleIdentifier: mime_magic_module SourceFile: mod_mime_magic.c Summary
file(1) command works: it looks at the first
few bytes of the file. It is intended as a "second line of defense"
for cases that mod_mime can't resolve.file(1) command for Unix, which uses "magic
numbers" and other hints from a file's contents to figure out
what the contents are. This module is active only if the magic
file is specified by the MimeMagicFile directive.
Format of the Magic File
#). The remaining lines are parsed for
the following columns:Column Description 1
byte number to begin checking from
">" indicates a dependency upon the previous
non-">" line2
bytesingle character shortmachine-order 16-bit integer longmachine-order 32-bit integer stringarbitrary-length string datelong integer date (seconds since Unix epoch/1970) beshortbig-endian 16-bit integer belongbig-endian 32-bit integer bedatebig-endian 32-bit integer date leshortlittle-endian 16-bit integer lelonglittle-endian 32-bit integer ledatelittle-endian 32-bit integer date 3
contents of data to match 4
MIME type if matched 5
MIME encoding if matched (optional) # Sun/NeXT audio data
0 string .snd
>12 belong 1 audio/basic
>12 belong 2 audio/basic
>12 belong 3 audio/basic
>12 belong 4 audio/basic
>12 belong 5 audio/basic
>12 belong 6 audio/basic
>12 belong 7 audio/basic
>12 belong 23 audio/x-adpcm
*.doc
files containing Microsoft Word or FrameMaker documents. (These are
incompatible file formats which use the same file suffix.)# Frame
0 string \<MakerFile application/x-frame
0 string \<MIFFile application/x-frame
0 string \<MakerDictionary application/x-frame
0 string \<MakerScreenFon application/x-frame
0 string \<MML application/x-frame
0 string \<Book application/x-frame
0 string \<Maker application/x-frame
# MS-Word
0 string \376\067\0\043 application/msword
0 string \320\317\021\340\241\261 application/msword
0 string \333\245-\0\0\0 application/msword
# gzip (GNU zip, not to be confused with
# [Info-ZIP/PKWARE] zip archiver)
0 string \037\213 application/octet-stream x-gzip
Performance Issues
file(1) code to make it fit in a busy web
server. It was designed for a server where there are thousands of users
who publish their own documents. This is probably very common
on intranets. Many times, it's helpful if the server can make
more intelligent decisions about a file's contents than the
file name allows ...even if just to reduce the "why doesn't my
page work" calls when users improperly name their own files.
You have to decide if the extra work suits your
environment.
Notes
mod_mime_magic
module and are included here for compliance with contributors'
copyright restrictions that require their acknowledgment.
Copyright (c) 1996-1997 Cisco Systems, Inc.
realloc().MimeMagicFile Directive
Description: Enable MIME-type determination based on file contents
using the specified magic file Syntax: MimeMagicFile file-pathContext: server config, virtual host Status: Extension Module: mod_mime_magic MimeMagicFile directive can be used to
enable this module, the default file is distributed at
conf/magic. Non-rooted paths are relative to the
ServerRoot. Virtual hosts will use
the same file as the main server unless a more specific setting is
used, in which case the more specific setting overrides the main
server's file.Example
MimeMagicFile conf/magic
mod/mod_nw_ssl.html 100644 0 0 14164 11074463036 12050 0 ustar 0 0
Apache モジュール mod_negotiation
This translation may be out of date. Check the
English version for recent changes.
説明: コンテントネゴシエーション
機能を提供する ステータス: Base モジュール識別子: negotiation_module ソースファイル: mod_negotiation.c 概要
type-map
ハンドラで扱われるファイル)。これは variants
を含んでいるファイルを明示的に指定します。MultiViews Option で有効になります)。
サーバが暗黙の内にファイル名のパターンマッチを行ない、
その結果から選択します。ディレクティブ
トピック
参照
タイプマップ
Content-Encoding:AddEncoding ディレクティブ
で定義されたエンコーディングだけを認識します。通常 compress
されたファイルのための x-compress と gzip
されたファイルのための x-gzip を含みます。
エンコーディングの比較をするときは、接頭辞 x-
は無視されます。Content-Language:en
は英語を表します。
複数の言語が格納される場合はコンマで区切られます。Content-Length:Content-Type:name=value
で、メディアタイプや他のパラメータとはセミコロンで分離されます。
共通のパラメータは以下のとおり:
leveltext/html では 2 がデフォルトで、その他の場合は
0 がデフォルトです。qsqs
はリソース毎に特有の値を取ります。
例
Content-Type: image/jpeg; qs=0.8
URI:Body:Example:
Body:----xyz----
<html>
<body>
<p>Content of the page.</p>
</body>
</html>
----xyz----
MultiViews
Multiviews Options ディレクティブにより有効になります。
サーバが /some/dir/foo
へのリクエストを受け取り、/some/dir/foo が存在
しない場合、サーバはディレクトリを読んで、
foo.* にあてはまる全てのファイルを探し、
事実上それらのファイルをマップするタイプマップを作ります。
そのとき、メディアタイプとコンテントエンコーディングは、
そのファイル名を直接指定したときと同じものが割り当てられます。
それからクライアントの要求に一番合うものを選び、
そのドキュメントを返します。MultiViewsMatch
ディレクティブで設定します。CacheNegotiatedDocs ディレクティブ
説明: コンテントネゴシエーションされたドキュメントをプロキシサーバが
キャッシュできるようにする 構文: CacheNegotiatedDocs On|Offデフォルト: CacheNegotiatedDocs Offコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: Base モジュール: mod_negotiation 互換性: バージョン 2.0で構文が変わりました CacheNegotiatedDocs は引数を取らず、
ディレクティブが存在することで on の動作をしていました。ForceLanguagePriority ディレクティブ
説明: 要求に合う単独のドキュメントが見つからなかったときに行なうことを指定
構文: ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback]デフォルト: ForceLanguagePriority Preferコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_negotiation 互換性: バージョン 2.0.30 以降で使用可能 ForceLanguagePriority ディレクティブは
要求に合うドキュメントを一つだけ返すことができないときに、
LanguagePriority
ディレクティブを使ってネゴシエーションの結果を返します。ForceLanguagePriority Prefer は、同等の選択肢が
いくつかあるときに、HTTP の 300 (MULTIPLE CHOICES) を返す代わりに、
LanguagePriority を使って一つだけドキュメントを返すように
します。以下のディレクティブが指定されていて、ユーザの Accept-Language
ヘッダでは en と de の品質が共に
.500 (同じくらい許容) であるときは、
最初にマッチする variant の en が送られます。
LanguagePriority en fr de
ForceLanguagePriority Prefer
ForceLanguagePriority Fallback では、HTTP 406
(NOT ACCEPTABLE) を送信する代わりに、
LanguagePriority
が正しい結果を送ります。
以下のディレクティブが指定されていて、ユーザの Accept-Language
が es 言語のみを許可していて、さらにそのような variant がないときには、
以下の LanguagePriority
のリストの最初の variant が送れれます。
LanguagePriority en fr de
ForceLanguagePriority Fallback
Prefer と Fallback の両方のオプションを
同時に指定することができます。
ですから、複数の variant があるときは
LanguagePriority の最初の
variant が送られ、クライアントの許容言語に合う vaiant がないときは
存在するドキュメントで最初のものが送られる、という様にすることができます。参照
LanguagePriority ディレクティブ
説明: クライアントが優先度を示さなかったときの言語の variant の優先度を
指定 構文: LanguagePriority MIME-lang [MIME-lang]
...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_negotiation LanguagePriority は、MultiViews
リクエストを扱うときに、クライアントが優先順位を提供していない場合の
言語の優先順位を設定します。MIME-lang
のリストが優先度の降順に並びます。Example:
LanguagePriority en fr de
foo.html がリクエストされ、foo.html.fr
と foo.html.de が両方存在し、
ブラウザが言語の優先順位を提供してない場合は
foo.html.fr が返されます。ForceLanguagePriority ディレクティブが
None 以外のときにのみ効果があることに注意してください。
一般的には、サーバ側ではなくクライアント側で好みの言語を決定します。参照
mod/mod_proxy.html 100644 0 0 165423 11074463036 11751 0 ustar 0 0
Apache Module mod_nw_ssl
Description: Enable SSL encryption for NetWare Status: Base ModuleIdentifier: nwssl_module SourceFile: mod_nw_ssl.c Compatibility: NetWare only Summary
Directives
NWSSLTrustedCerts Directive
Description: List of additional client certificates Syntax: NWSSLTrustedCerts filename [filename] ...Context: server config Status: Base Module: mod_nw_ssl .der file.NWSSLUpgradeable Directive
Description: Allows a connection to be upgraded to an SSL connection upon request Syntax: NWSSLUpgradeable [IP-address:]portnumberContext: server config Status: Base Module: mod_nw_ssl Listen
directive.SecureListen Directive
Description: Enables SSL encryption for the specified port Syntax: SecureListen [IP-address:]portnumber
Certificate-Name [MUTUAL]Context: server config Status: Base Module: mod_nw_ssl
mod/mod_proxy_connect.html 100644 0 0 6755 11074463036 13424 0 ustar 0 0
Apache Module mod_proxy
Description: HTTP/1.1 proxy/gateway server Status: Extension ModuleIdentifier: proxy_module SourceFile: mod_proxy.c Summary
Warning
ProxyRequests until you have secured your server. Open proxy servers are dangerous both to your
network and to the Internet at large.FTP, CONNECT (for SSL),
HTTP/0.9, HTTP/1.0, and HTTP/1.1.
The module can be configured to connect to other proxy modules for these
and other protocols.mod_proxy:
mod_proxy_http, mod_proxy_ftp
and mod_proxy_connect. Thus, if you want to use
one or more of the particular proxy functions, load
mod_proxy and the appropriate module(s)
into the server (either statically at compile-time or dynamically
via the LoadModule
directive).mod_cache and related
modules. The ability to contact remote servers using the SSL/TLS
protocol is provided by the SSLProxy* directives of
mod_ssl. These additional modules will need
to be loaded and configured to take advantage of these features.Directives
AllowCONNECT NoProxy <Proxy> ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyFtpDirCharset ProxyIOBufferSize <ProxyMatch> ProxyMaxForwards ProxyPass ProxyPassReverse ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyViaTopics
Forward and Reverse Proxies Basic Examples Controlling access to your proxy FTP Proxy Slow Startup Intranet Proxy Protocol AdjustmentsSee also
Forward and Reverse Proxies
mod_cache) to reduce network usage.ProxyRequests directive. Because
forward proxys allow clients to access arbitrary sites through
your server and to hide their true origin, it is essential that
you secure your server so that only
authorized clients can access the proxy before activating a
forward proxy.ProxyPass directive or the
[P] flag to the RewriteRule directive. It is
not necessary to turn ProxyRequests on in order to
configure a reverse proxy.
Basic Examples
mod_cache.Forward Proxy
ProxyRequests On
ProxyVia On
<Proxy *>
Order deny,allow
Deny from all
Allow from internal.example.com
</Proxy>
Reverse Proxy
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /foo http://foo.example.com/bar
ProxyPassReverse /foo http://foo.example.com/bar
Controlling access to your proxy
<Proxy> control block as in
the following example:
<Proxy *>
Order Deny,Allow
Deny from all
Allow from 192.168.0
</Proxy>
mod_access.ProxyRequests directive).
Otherwise, your server can be used by any client to access
arbitrary hosts while hiding his or her true identity. This is
dangerous both for your network and for the Internet at large.
When using a reverse proxy (using the ProxyPass directive with
ProxyRequests Off), access control is less
critical because clients can only contact the hosts that you
have specifically configured.
FTP Proxy
Why doesn't file type xxx
download via FTP?
application/octet-stream in your proxy's mime.types
configuration file. A useful line can beapplication/octet-stream bin dms lha lzh exe class tgz taz
How can I force an FTP ASCII download of
File xxx?
ASCII transfer method (while the default transfer is in
binary mode), you can override mod_proxy's
default by suffixing the request with ;type=a to force an
ASCII transfer. (FTP Directory listings are always executed in ASCII mode,
however.)How can I access FTP files outside
of my home directory?
/%2f to the path of your request, you can make
such a proxy change the FTP starting directory to / (instead
of the home directory). For example, to retrieve the file
/etc/motd, you would use the URL:
ftp://user@host/%2f/etc/motd
How can I hide the FTP cleartext password
in my browser's URL line?
user: anonymous
password: apache_proxy@
ftp://username@host/myfile
401 (Authorization
required) response, which causes the Browser to pop up the
username/password dialog. Upon entering the password, the connection
attempt is retried, and if successful, the requested resource is
presented. The advantage of this procedure is that your browser does not
display the password in cleartext (which it would if you had used
ftp://username:password@host/myfile
Note
Slow Startup
ProxyBlock directive, hostnames' IP addresses are looked up
and cached during startup for later match test. This may take a few
seconds (or more) depending on the speed with which the hostname lookups
occur.
Intranet Proxy
ProxyRemote directive
to forward the respective scheme to the firewall proxy).
However, when it has to
access resources within the intranet, it can bypass the firewall when
accessing hosts. The NoProxy
directive is useful for specifying which hosts belong to the intranet and
should be accessed directly.http://somehost.example.com/. Some commercial proxy servers
let them get away with this and simply serve the request, implying a
configured local domain. When the ProxyDomain directive is used and the server is configured for proxy service, Apache can return
a redirect response and send the client to the correct, fully qualified,
server address. This is the preferred method since the user's bookmark
files will then contain fully qualified hosts.
Protocol Adjustments
SetEnv directive.force-proxy-request-1.0 and
proxy-nokeepalive notes.
<Location /buggyappserver/>
ProxyPass http://buggyappserver:7001/foo/
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
</Location>
AllowCONNECT Directive
Description: Ports that are allowed to CONNECT through the
proxySyntax: AllowCONNECT port [port] ...Default: AllowCONNECT 443 563Context: server config, virtual host Status: Extension Module: mod_proxy AllowCONNECT directive specifies a list
of port numbers to which the proxy CONNECT method may
connect. Today's browsers use this method when a https
connection is requested and proxy tunneling over HTTP is in effect.443) and the
default snews port (563) are enabled. Use the
AllowCONNECT directive to override this default and
allow connections to the listed ports only.mod_proxy_connect present
in the server in order to get the support for the CONNECT at
all.NoProxy Directive
Description: Hosts, domains, or networks that will be connected to
directly Syntax: NoProxy host [host] ...Context: server config, virtual host Status: Extension Module: mod_proxy NoProxy directive specifies a
list of subnets, IP addresses, hosts and/or domains, separated by
spaces. A request to a host which matches one or more of these is
always served directly, without forwarding to the configured
ProxyRemote proxy server(s).Example
ProxyRemote * http://firewall.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21
NoProxy
directive are one of the following type list:
Examples
.com .apache.org.
Note
.MyDomain.com and
.mydomain.com. (note the trailing period) are considered
equal. Since a domain comparison does not involve a DNS lookup, it is much
more efficient than subnet comparison.
192.168 or 192.168.0.0255.255.0.0)192.168.112.0/21192.168.112.0/21 with a netmask of 21
valid bits (also used in the form 255.255.248.0)Example
192.168.123.7
Note
Examples
prep.ai.mit.edu
www.apache.org
Note
WWW.MyDomain.com
and www.mydomain.com. (note the trailing period) are
considered equal.See also
<Proxy> Directive
Description: Container for directives applied to proxied resources Syntax: <Proxy wildcard-url> ...</Proxy>Context: server config, virtual host Status: Extension Module: mod_proxy <Proxy>
sections apply only to matching proxied content. Shell-style wildcards are
allowed.yournetwork.example.com to access content via your proxy
server:
<Proxy *>
Order Deny,Allow
Deny from all
Allow from yournetwork.example.com
</Proxy>
foo
directory of example.com through the INCLUDES
filter when they are sent through the proxy server:
<Proxy http://example.com/foo/*>
SetOutputFilter INCLUDES
</Proxy>
ProxyBadHeader Directive
Description: Determines how to handle bad header lines in a
response Syntax: ProxyBadHeader IsError|Ignore|StartBodyDefault: ProxyBadHeader IsErrorContext: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0.44 and later ProxyBadHeader directive determines the
behaviour of mod_proxy if it receives syntactically invalid
header lines (i.e. containing no colon). The following arguments
are possible:
IsErrorIgnoreStartBodyProxyBlock Directive
Description: Words, hosts, or domains that are banned from being
proxied Syntax: ProxyBlock *|word|host|domain
[word|host|domain] ...Context: server config, virtual host Status: Extension Module: mod_proxy ProxyBlock directive specifies a list of
words, hosts and/or domains, separated by spaces. HTTP, HTTPS, and
FTP document requests to sites whose names contain matched words,
hosts or domains are blocked by the proxy server. The proxy
module will also attempt to determine IP addresses of list items which
may be hostnames during startup, and cache them for match test as
well. That may slow down the startup time of the server.Example
ProxyBlock joes-garage.com some-host.co.uk rocky.wotsamattau.edu
rocky.wotsamattau.edu would also be matched if referenced by
IP address.wotsamattau would also be sufficient to match
wotsamattau.edu.
ProxyBlock *
ProxyDomain Directive
Description: Default domain name for proxied requests Syntax: ProxyDomain DomainContext: server config, virtual host Status: Extension Module: mod_proxy ProxyDomain directive specifies
the default domain which the apache proxy server will belong to. If a
request to a host without a domain name is encountered, a redirection
response to the same host with the configured Domain appended
will be generated.Example
ProxyRemote * http://firewall.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21
ProxyDomain .mycompany.com
ProxyErrorOverride Directive
Description: Override error pages for proxied content Syntax: ProxyErrorOverride On|OffDefault: ProxyErrorOverride OffContext: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in version 2.0 and later ProxyFtpDirCharset Directive
Description: Define the character set for proxied FTP listings Syntax: ProxyFtpDirCharset character setDefault: ProxyFtpDirCharset ISO-8859-1Context: server config, virtual host, directory Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0.62 and later ProxyFtpDirCharset directive defines the
character set to be set for FTP directory listings in HTML generated by
mod_proxy_ftp.ProxyIOBufferSize Directive
Description: Determine size of internal data throughput buffer Syntax: ProxyIOBufferSize bytesDefault: ProxyIOBufferSize 8192Context: server config, virtual host Status: Extension Module: mod_proxy ProxyIOBufferSize directive adjusts the size
of the internal buffer, which is used as a scratchpad for the data between
input and output. The size must be less or equal 8192.<ProxyMatch> Directive
Description: Container for directives applied to regular-expression-matched
proxied resources Syntax: <ProxyMatch regex> ...</ProxyMatch>Context: server config, virtual host Status: Extension Module: mod_proxy <ProxyMatch> directive is
identical to the <Proxy> directive, except it matches URLs
using regular expressions.ProxyMaxForwards Directive
Description: Maximium number of proxies that a request can be forwarded
through Syntax: ProxyMaxForwards numberDefault: ProxyMaxForwards 10Context: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0 and later ProxyMaxForwards directive specifies the
maximum number of proxies through which a request may pass, if there's no
Max-Forwards header supplied with the request. This is
set to prevent infinite proxy loops, or a DoS attack.Example
ProxyMaxForwards 15
ProxyPass Directive
Description: Maps remote servers into the local server URL-space Syntax: ProxyPass [path] !|urlContext: server config, virtual host, directory Status: Extension Module: mod_proxy http://example.com/;
then
ProxyPass /mirror/foo/ http://backend.example.com/
http://example.com/mirror/foo/bar to be internally converted
into a proxy request to http://backend.example.com/bar.! directive is useful in situations where you don't want
to reverse-proxy a subdirectory, e.g.
ProxyPass /mirror/foo/i !
ProxyPass /mirror/foo http://backend.example.com
/mirror/foo to
backend.example.com except requests made to
/mirror/foo/i.Note
<Location> section, the first argument is omitted and the local
directory is obtained from the <Location>.The
ProxyRequests directive should
usually be set off when using
ProxyPass.RewriteRule directive with the
[P] flag.ProxyPassReverse Directive
Description: Adjusts the URL in HTTP response headers sent from a reverse
proxied server Syntax: ProxyPassReverse [path] urlContext: server config, virtual host, directory Status: Extension Module: mod_proxy Location,
Content-Location and URI headers on HTTP redirect
responses. This is essential when Apache is used as a reverse proxy to avoid
by-passing the reverse proxy because of HTTP redirects on the backend
servers which stay behind the reverse proxy.ProxyPass directive.http://example.com/; then
ProxyPass /mirror/foo/ http://backend.example.com/
ProxyPassReverse /mirror/foo/ http://backend.example.com/
http://example.com/mirror/foo/bar to be internally converted
into a proxy request to http://backend.example.com/bar
(the functionality ProxyPass provides here). It also takes care
of redirects the server backend.example.com sends: when
http://backend.example.com/bar is redirected by him to
http://backend.example.com/quux Apache adjusts this to
http://example.com/mirror/foo/quux before forwarding the HTTP
redirect response to the client. Note that the hostname used for
constructing the URL is chosen in respect to the setting of the UseCanonicalName directive.ProxyPassReverse directive can
also be used in conjunction with the proxy pass-through feature
(RewriteRule ... [P]) from mod_rewrite
because its doesn't depend on a corresponding ProxyPass directive.<Location> section, the first argument is omitted and the local
directory is obtained from the <Location>.ProxyPreserveHost Directive
Description: Use incoming Host HTTP request header for proxy
request Syntax: ProxyPreserveHost On|OffDefault: ProxyPreserveHost OffContext: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0.31 and later. Off. It is mostly
useful in special configurations like proxied mass name-based virtual
hosting, where the original Host header needs to be evaluated by the
backend server.ProxyReceiveBufferSize Directive
Description: Network buffer size for proxied HTTP and FTP
connections Syntax: ProxyReceiveBufferSize bytesDefault: ProxyReceiveBufferSize 0Context: server config, virtual host Status: Extension Module: mod_proxy ProxyReceiveBufferSize directive specifies an
explicit (TCP/IP) network buffer size for proxied HTTP and FTP connections,
for increased throughput. It has to be greater than 512 or set
to 0 to indicate that the system's default buffer size should
be used.Example
ProxyReceiveBufferSize 2048
ProxyRemote Directive
Description: Remote proxy used to handle certain requests Syntax: ProxyRemote match remote-serverContext: server config, virtual host Status: Extension Module: mod_proxy * to indicate
the server should be contacted for all requests. remote-server is
a partial URL for the remote server. Syntax:
remote-server =
scheme://hostname[:port]
http is supported by
this module.Example
ProxyRemote http://goodguys.com/ http://mirrorguys.com:8000
ProxyRemote * http://cleversite.com
ProxyRemote ftp http://ftpproxy.mydomain.com:8080
ProxyRemoteMatch Directive
Description: Remote proxy used to handle requests matched by regular
expressions Syntax: ProxyRemoteMatch regex remote-serverContext: server config, virtual host Status: Extension Module: mod_proxy ProxyRemoteMatch is identical to the
ProxyRemote directive, except the
first argument is a regular expression match against the requested URL.ProxyRequests Directive
Description: Enables forward (standard) proxy requests Syntax: ProxyRequests On|OffDefault: ProxyRequests OffContext: server config, virtual host Status: Extension Module: mod_proxy Off does not disable use of
the ProxyPass directive.)Off.mod_proxy_http or mod_proxy_ftp
(or both) present in the server.Warning
ProxyRequests until you have secured your server. Open proxy servers are dangerous
both to your network and to the Internet at large.ProxyTimeout Directive
Description: Network timeout for proxied requests Syntax: ProxyTimeout secondsDefault: ProxyTimeout 300Context: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0.31 and later ProxyVia Directive
Description: Information provided in the Via HTTP response
header for proxied requestsSyntax: ProxyVia On|Off|Full|BlockDefault: ProxyVia OffContext: server config, virtual host Status: Extension Module: mod_proxy Via: HTTP
header by the proxy. Its intended use is to control the flow of of
proxy requests along a chain of proxy servers. See RFC 2616 (HTTP/1.1), section
14.45 for an explanation of Via: header lines.
Off, which is the default, no special processing
is performed. If a request or reply contains a Via: header,
it is passed through unchanged.On, each request and reply will get a
Via: header line added for the current host.Full, each generated Via: header
line will additionally have the Apache server version shown as a
Via: comment field.Block, every proxy request will have all its
Via: header lines removed. No new Via: header will
be generated.
mod/mod_proxy_ftp.html 100644 0 0 6354 11074463036 12557 0 ustar 0 0
Apache Module mod_proxy_connect
Description: mod_proxy extension for
CONNECT request handlingStatus: Extension ModuleIdentifier: proxy_connect_module SourceFile: proxy_connect.c Summary
mod_proxy. It provides support for the CONNECT
HTTP method. This method is mainly used to tunnel SSL requests
through proxy servers.CONNECT
requests, mod_proxy and
mod_proxy_connect have to be present in the server.Warning
mod/mod_proxy_http.html 100644 0 0 7320 11074463036 12737 0 ustar 0 0
Apache Module mod_proxy_ftp
Description: FTP support module for
mod_proxyStatus: Extension ModuleIdentifier: proxy_ftp_module SourceFile: proxy_ftp.c Summary
mod_proxy. It provides support for the proxying
FTP sites.mod_proxy and mod_proxy_ftp
have to be present in the server.Warning
mod/mod_rewrite.html 100644 0 0 234567 11074463036 12257 0 ustar 0 0
Apache Module mod_proxy_http
Description: HTTP support module for
mod_proxyStatus: Extension ModuleIdentifier: proxy_http_module SourceFile: proxy_http.c Summary
mod_proxy. It provides the features used for
proxying HTTP requests. mod_proxy_http
supports HTTP/0.9, HTTP/1.0 and HTTP/1.1. It does not
provide any caching abilities. If you want to set up a caching
proxy, you might want to use the additional service of the
mod_cache module.mod_proxy and mod_proxy_http
have to be present in the server.Warning
mod/mod_setenvif.html 100644 0 0 33302 11074463036 12361 0 ustar 0 0
Apache Module mod_rewrite
Description: Provides a rule-based rewriting engine to rewrite requested
URLs on the fly Status: Extension ModuleIdentifier: rewrite_module SourceFile: mod_rewrite.c Compatibility: Available in Apache 1.3 and later Summary
httpd.conf) and per-directory context
(.htaccess) and can generate query-string
parts on result. The rewritten result can lead to internal
sub-processing, external request redirection or even to an
internal proxy throughput.Directives
RewriteBase RewriteCond RewriteEngine RewriteLock RewriteLog RewriteLogLevel RewriteMap RewriteOptions RewriteRuleTopics
API Phases
mod_rewrite uses two of
these hooks: the URL-to-filename translation hook
(used after the HTTP request has been read, but before any
authorization starts) and the Fixup hook (triggered
after the authorization phases, and after the per-directory
config files (.htaccess) have been read, but
before the content handler is activated).
Ruleset Processing
RewriteRule directives, with or without
RewriteConds), rule by rule.
When a particular rule is matched, mod_rewrite
also checks the corresponding conditions (RewriteCond
directives). For historical reasons the conditions are given
first, making the control flow a little bit long-winded. See
Figure 1 for more details.![[Needs graphics capability to display]](../images/mod_rewrite_fig1.gif)
Figure 1:The control flow of the rewrite engine through a
rewrite ruleset
mod_rewrite immediately stops processing that rule,
and goes on to the next rule. If the Pattern matches,
mod_rewrite checks for rule conditions.
If none are present, the URL will be replaced with a new string,
constructed from the Substitution string, and mod_rewrite goes on to the next rule.RewriteConds exist, an
inner loop is started, processing them in the order that they are
listed. Conditions are not matched against the current URL directly.
A TestString is constructed by expanding variables,
back-references, map lookups, etc., against which the
CondPattern is matched. If the pattern fails to match one
of the conditions, the complete set of rule and associated conditions
fails. If the pattern matches a given condition, then matching continues
to the next condition, until no more conditions are
available. If all conditions match, processing is continued
with the substitution of the Substitution string for the URL.
Regex Back-Reference Availability
$N and
%N (see below), for creating
the Substitution and TestString strings.
Figure 2 attempts to show how the back-references are
transferred through the process for later expansion.![[Needs graphics capability to display]](../images/mod_rewrite_fig2.gif)
Figure 2: The back-reference flow through a rule.
Quoting Special Characters
\$'; this keeps mod_rewrite from trying
to treat it as a backreference.
Environment Variables
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. 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/
Practical Solutions
RewriteBase Directive
Description: Sets the base URL for per-directory rewrites Syntax: RewriteBase URL-pathDefault: See usage for information.Context: directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite 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). In such a case, it will act locally,
stripping the local directory prefix before processing, and applying
rewrite rules only to the remainder. When processing is complete, the
prefix is automatically added back to the
path. The default setting is; RewriteBase physical-directory-pathRewriteBase directive to specify the
correct URL-prefix. If your webserver's URLs are not directly
related to physical file paths, you will need to use
RewriteBase in every .htaccess
file where you want to use RewriteRule directives.
#
# /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 were 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 gets correctly rewritten to
the physical file /abc/def/newstuff.html.For Apache Hackers
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
RewriteCond Directive
Description: Defines a condition under which rewriting will take place
Syntax: RewriteCond
TestString CondPatternContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite RewriteCond directive defines a
rule condition. One or more RewriteCond
can precede a RewriteRule
directive. The following rule is then only used if both
the current state of the URI matches its pattern, and if these conditions are met.
$N
(0 <= N <= 9), which provide access to the grouped
parts (in parentheses) of the pattern, from the
RewriteRule which is subject to the current
set of RewriteCond conditions..
%N
(1 <= N <= 9), which provide access to the grouped
parts (again, in parentheses) of the pattern, from the last matched
RewriteCond in the current set
of conditions.
${mapname:key|default}.
See the documentation for
RewriteMap for more details.
%{ NAME_OF_VARIABLE
}
where NAME_OF_VARIABLE can be a string taken
from the following list:
HTTP headers: connection & request:
HTTP_USER_AGENT
HTTP_REFERER
HTTP_COOKIE
HTTP_FORWARDED
HTTP_HOST
HTTP_PROXY_CONNECTION
HTTP_ACCEPT
REMOTE_ADDR
REMOTE_HOST
REMOTE_PORT
REMOTE_USER
REMOTE_IDENT
REQUEST_METHOD
SCRIPT_FILENAME
PATH_INFO
QUERY_STRING
AUTH_TYPE
server internals: system stuff: specials:
DOCUMENT_ROOT
SERVER_ADMIN
SERVER_NAME
SERVER_ADDR
SERVER_PORT
SERVER_PROTOCOL
SERVER_SOFTWARE
TIME_YEAR
TIME_MON
TIME_DAY
TIME_HOUR
TIME_MIN
TIME_SEC
TIME_WDAY
TIME
API_VERSION
THE_REQUEST
REQUEST_URI
REQUEST_FILENAME
IS_SUBREQ
HTTPS
struct tm fields of the Unix system.
Most are documented elsewhere in the Manual or in
the CGI specification. Those that are special to
mod_rewrite include those below.
IS_SUBREQAPI_VERSIONTHE_REQUESTGET
/index.html HTTP/1.1"). This does not
include any additional headers sent by the
browser.REQUEST_URIREQUEST_FILENAMEHTTPSmod_ssl is loaded).
filename field of the internal
request_rec structure of the Apache server.
The first name is the commonly known CGI variable name
while the second is the appropriate counterpart of
REQUEST_URI (which contains the value of the
uri field of request_rec).%{ENV:variable}, where variable can be
any environment variable, is also available.
This is looked-up via internal
Apache structures and (if not found there) via
getenv() from the Apache server process.%{SSL:variable}, where variable is the
name of an SSL environment
variable, can be used whether or not
mod_ssl is loaded, but will always expand to
the empty string if it is not. Example:
%{SSL:SSL_CIPHER_USEKEYSIZE} may expand to
128.%{HTTP:header}, where header can be
any HTTP MIME-header name, can always be used to obtain the
value of a header sent in the HTTP request.
Example: %{HTTP:Proxy-Connection} is
the value of the HTTP header
``Proxy-Connection:''.%{LA-U:variable} can be used for look-aheads which perform
an internal (URL-based) sub-request to determine the final
value of variable. This can be used to access
variable for rewriting which is not available at the current
stage, but will be set in a later phase.
REMOTE_USER variable from within the
per-server context (httpd.conf file) you must
use %{LA-U:REMOTE_USER} - this
variable is set by the authorization phases, which come
after the URL translation phase (during which mod_rewrite
operates)..htaccess file) via
the Fixup phase of the API and because the authorization
phases come before this phase, you just can use
%{REMOTE_USER} in that context.%{LA-F:variable} can be used to perform an internal
(filename-based) sub-request, to determine the final value
of variable. Most of the time, this is the same as
LA-U above.
!' character (exclamation mark) to specify a
non-matching pattern.
Treats the CondPattern as a plain string and
compares it lexicographically to TestString. True if
TestString lexicographically precedes
CondPattern.
Treats the CondPattern as a plain string and
compares it lexicographically to TestString. True if
TestString lexicographically follows
CondPattern.
Treats the CondPattern as a plain string and
compares it lexicographically to TestString. True if
TestString is lexicographically equal to
CondPattern (the two strings are exactly
equal, character for character). If CondPattern
is "" (two quotation marks) this
compares TestString to the empty string.
Treats the TestString as a pathname and tests
whether or not it exists, and is a directory.
Treats the TestString as a pathname and tests
whether or not it exists, and is a regular file.
Treats the TestString as a pathname and tests
whether or not it exists, and is a regular file with size greater
than zero.
Treats the TestString as a pathname and tests
whether or not it exists, and is a symbolic link.
Checks whether or not TestString is a valid file,
accessible via all the server's currently-configured
access controls for that path. This uses an internal
subrequest to do the check, so use it with care -
it can impact your server's performance!
Checks whether or not TestString is a valid URL,
accessible via all the server's currently-configured
access controls for that path. This uses an internal
subrequest to do the check, so use it with care -
it can impact your server's performance!Note
All of these tests can
also be prefixed by an exclamation mark ('!') to
negate their meaning.
[flags]
as the third argument to the RewriteCond
directive, where flags is a comma-separated list of any of the
following flags:
nocase|NC'
(no case)
This makes the test case-insensitive - differences
between 'A-Z' and 'a-z' are ignored, both in the
expanded TestString and the CondPattern.
This flag is effective only for comparisons between
TestString and CondPattern. It has no
effect on filesystem and subrequest checks.ornext|OR'
(or next condition)
Use this to combine rule conditions with a local OR
instead of the implicit AND. Typical example:
Without this flag you would have to write the condition/rule
pair three times.
RewriteCond %{REMOTE_HOST} ^host1.* [OR]
RewriteCond %{REMOTE_HOST} ^host2.* [OR]
RewriteCond %{REMOTE_HOST} ^host3.*
RewriteRule ...some special stuff for any of these hosts...
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]
RewriteEngine Directive
Description: Enables or disables runtime rewriting engine Syntax: RewriteEngine on|offDefault: RewriteEngine offContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite 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.RewriteRule directives!RewriteEngine on directive for each virtual host
in which you wish to use it.RewriteLock Directive
Description: Sets the name of the lock file used for RewriteMap
synchronizationSyntax: RewriteLock file-pathContext: server config Status: Extension Module: mod_rewrite 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 other types of rewriting
maps.RewriteLog Directive
Description: Sets the name of the file used for logging rewrite engine
processing Syntax: RewriteLog file-pathContext: server config, virtual host Status: Extension Module: mod_rewrite 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. To disable the logging of
rewriting actions it is not recommended to set
Filename to
/dev/null, because
although the rewriting engine does not then 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 how 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 Directive
Description: Sets the verbosity of the log file used by the rewrite
engine Syntax: RewriteLogLevel LevelDefault: RewriteLogLevel 0Context: server config, virtual host Status: Extension Module: mod_rewrite RewriteLogLevel directive sets 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. Using a high value for
Level will slow down your Apache server
dramatically! Use the rewriting logfile at a
Level greater than 2 only for debugging!
Example
RewriteLogLevel 3
RewriteMap Directive
Description: Defines a mapping function for key-lookup Syntax: RewriteMap MapName MapType:MapSource
Context: server config, virtual host Status: Extension Module: mod_rewrite Compatibility: The choice of different dbm types is available in
Apache 2.0.41 and later 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.${ MapName :
LookupKey }
${ MapName :
LookupKey | DefaultValue
}
RewriteMap as:
RewriteMap examplemap txt:/path/to/file/map.txt
RewriteRule as follows:
RewriteRule ^/ex/(.*) ${examplemap:$1}
MapType: txt, MapSource: Unix filesystem
path to valid regular file
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
MapType: rnd, MapSource: Unix filesystem
path to valid regular file
|'' characters which have the meaning of
``or''. In other words they indicate a set of
alternatives from which the actual returned value is
chosen randomly. For example, you might use the following map
file and directives to provide a random load balancing between
several back-end server, via a reverse-proxy. Images are sent
to one of the servers in the 'static' pool, while everything
else is sent to one of the 'dynamic' pool.Rewrite map file
##
## map.txt -- rewriting map
##
static www1|www2|www3|www4
dynamic www5|www6
Configuration directives
RewriteMap servers rnd:/path/to/file/map.txt
RewriteRule ^/(.*\.(png|gif|jpg)) http://${servers:static}/$1
[NC,P,L]
RewriteRule ^/(.*) http://${servers:dynamic}/$1 [P,L]
MapType:
dbm[=type], MapSource: Unix filesystem
path to valid regular file
#!/path/to/bin/perl
##
## txt2dbm -- convert txt map to dbm format
##
use NDBM_File;
use Fcntl;
($txtmap, $dbmmap) = @ARGV;
open(TXT, "<$txtmap") or die "Couldn't open $txtmap!\n";
tie (%DB, 'NDBM_File', $dbmmap,O_RDWR|O_TRUNC|O_CREAT, 0644)
or die "Couldn't create $dbmmap!\n";
while (<TXT>) {
next if (/^\s*#/ or /^\s*$/);
$DB{$1} = $2 if (/^\s*(\S+)\s+(\S+)/);
}
untie %DB;
close(TXT);
$ txt2dbm map.txt map.db
MapType: int, MapSource: Internal Apache
function
Converts the key to all upper case.
Converts the key to all lower case.
Translates special characters in the key to
hex-encodings.
Translates hex-encodings in the key back to
special characters.
MapType: prg, MapSource: Unix filesystem
path to valid regular file
#!/path/to/interpreter' as the first
line).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>) {
# ...put here any transformations or lookups...
print $_;
}
stdout. Avoid this, as it will cause a deadloop!
``$|=1'' is used above, to prevent this.RewriteLock directive can
be used to define a lockfile which mod_rewrite can use to synchronize
communication with the mapping program. By default no such
synchronization takes place.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. Note
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!
RewriteOptions Directive
Description: Sets some special options for the rewrite engine Syntax: RewriteOptions OptionsDefault: RewriteOptions MaxRedirects=10Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite Compatibility: MaxRedirects is available in Apache 2.0.45 and
laterRewriteOptions 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 are inherited.MaxRedirects=numberRewriteRules, mod_rewrite aborts
the request after reaching a maximum number of such redirects and
responds with an 500 Internal Server Error. If you really need
more internal redirects than 10 per request, you may increase
the default to the desired value.RewriteRule Directive
Description: Defines rules for the rewriting engine Syntax: RewriteRule
Pattern SubstitutionContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite Compatibility: The cookie-flag is available in Apache 2.0.40 and later. RewriteRule directive is the real
rewriting workhorse. The directive can occur more than once, with
each instance defining a single rewrite rule. The
order in which these rules are defined is important - this is the order
in which they will be applied at run-time.
Text:
. Any single character
[chars] Character class: Any character of the class ``chars''
[^chars] Character class: Not a character of the class ``chars''
text1|text2 Alternative: text1 or text2
Quantifiers:
? 0 or 1 occurrences of the preceding text
* 0 or N occurrences of the preceding text (N > 0)
+ 1 or N occurrences of the preceding text (N > 1)
Grouping:
(text) Grouping of text
(used either to set the borders of an alternative as above, or
to make backreferences, where the Nth group can
be referred to on the RHS of a RewriteRule as $N)
Anchors:
^ Start-of-line anchor
$ End-of-line anchor
Escaping:
\char escape the given char
(for instance, to specify the chars ".[]()" etc.)
Jeffrey E.F. Friedl
O'Reilly & Associates, Inc. 2002
ISBN 0-596-00289-0
!') is also available as a possible pattern
prefix. This enables you to negate a pattern; to say, for instance:
``if the current URL does NOT match this
pattern''. This can be used for exceptional cases, where
it is easier to match the negative pattern, or as a last
default rule.Note
When using the NOT character to negate a pattern, you cannot include
grouped wildcard parts in that pattern. This is because, when the
pattern does NOT match (ie, the negation matches), there are no
contents for the groups. Thus, if negated patterns are used, you
cannot use $N in the substitution string!
$N) to the RewriteRule
pattern%N) to the last matched
RewriteCond pattern%{VARNAME})${mapname:key|default})$N
(N=0..9), 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 above.L flag - see below.-' which means: NO
substitution! This is useful in providing
rewriting rules which only match
URLs but do not substitute anything for them. It is commonly used
in conjunction with the C (chain) flag, in order
to apply more than one pattern before substitution occurs.[flags]
as the third argument to the RewriteRule
directive. Flags is a comma-separated list of any of the
following flags:
chain|C'
(chained with next rule)
This flag chains the current rule with the next rule
(which itself can be chained with the following rule,
and so on). This has the following effect: if a rule
matches, then processing continues as usual -
the flag has no effect. If the rule does
not match, then all following chained
rules are skipped. For instance, it can be used to remove the
``.www'' part, inside a per-directory rule set,
when you let an external redirect happen (where the
``.www'' part should not occur!).cookie|CO=NAME:VAL:domain[:lifetime[:path]]'
(set cookie)
This sets a cookie in the client's browser. The cookie's name
is specified by NAME and the value is
VAL. The domain field is the domain of the
cookie, such as '.apache.org', the optional lifetime
is the lifetime of the cookie in minutes, and the optional
path is the path of the cookieenv|E=VAR:VAL'
(set environment variable)
This forces an environment variable named VAR to
be set to the value VAL, where VAL can
contain regexp backreferences ($N and
%N) which will be expanded. You can use this
flag more than once, to set more than one variable. The
variables can later be dereferenced in many situations, most commonly
from within XSSI (via <!--#echo
var="VAR"-->) or CGI ($ENV{'VAR'}).
You can also dereference the variable in a later RewriteCond pattern, using
%{ENV:VAR}. Use this to strip
information from URLs, while maintaining a record of that information.forbidden|F' (force URL
to be forbidden)
This forces the current URL to be forbidden - it immediately
sends back a HTTP response of 403 (FORBIDDEN).
Use this flag in conjunction with
appropriate RewriteConds to conditionally block some
URLs.gone|G' (force URL to be
gone)
This forces the current URL to be gone - it
immediately sends back a HTTP response of 410 (GONE). Use
this flag to mark pages which no longer exist as gone.last|L'
(last rule)
Stop the rewriting process here and don't apply any more
rewrite rules. This corresponds to the Perl
last command or the break command
in C. Use this flag to prevent the currently
rewritten URL from being rewritten further by following
rules. For example, use it to rewrite the root-path URL
('/') to a real one, e.g.,
'/e/www/'.next|N'
(next round)
Re-run the rewriting process (starting again with the
first rewriting rule). This time, the URL to match is no longer
the original URL, but rather the URL returned by the last rewriting rule.
This corresponds to the Perl next command or
the continue command in C. Use
this flag to restart the rewriting process -
to immediately go to the top of the loop.
Be careful not to create an infinite
loop!nocase|NC'
(no case)
This makes the Pattern case-insensitive,
ignoring difference between 'A-Z' and
'a-z' when Pattern is matched against the current
URL.noescape|NE'
(no URI escaping of
output)
This flag prevents mod_rewrite from applying the usual URI
escaping rules to the result of a rewrite. Ordinarily,
special characters (such as '%', '$', ';', and so on)
will be escaped into their hexcode equivalents ('%25',
'%24', and '%3B', respectively); this flag prevents this
from happening. This allows percent symbols to appear in
the output, as in
which would turn '
RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE]
/foo/zed' into a safe
request for '/bar?arg=P1=zed'.
nosubreq|NS' (
not for internal
sub-requests)
This flag forces the rewrite engine to skip a
rewrite rule if the current request is an internal
sub-request. For instance, sub-requests occur internally
in Apache when mod_include tries to find out
information about possible directory default files
(index.xxx). On sub-requests it is not
always useful, and can even cause errors, if
the complete set of rules are applied. Use this flag to
exclude some rules.
To decide whether or not to use this rule: if you
prefix URLs with CGI-scripts, to force them to be
processed by the CGI-script, it's likely that you
will run into problems (or significant overhead) on
sub-requests. In these cases, use this flag.
proxy|P' (force
proxy)
This flag forces the substitution part to be internally
sent as a proxy request and immediately (rewrite
processing stops here) put through the proxy module. You must make
sure that the substitution string is a valid URI
(typically starting with
http://hostname) which can be
handled by the Apache proxy module. If not, you will get an
error from the proxy module. Use this flag to achieve a
more powerful implementation of the ProxyPass directive,
to map remote content into the namespace of the local
server.
mod_proxy must be enabled in order
to use this flag.passthrough|PT'
(pass through to next
handler)
This flag forces the rewrite engine to set the
uri field of the internal
request_rec structure to the value of the
filename field. This flag is just a hack to
enable post-processing of the output of
RewriteRule directives, using
Alias, ScriptAlias,
Redirect, and other directives from
various URI-to-filename translators. For example, to rewrite
/abc to /def using
mod_rewrite, and then
/def to /ghi using
mod_alias:
If you omit the
RewriteRule ^/abc(.*) /def$1 [PT]
Alias /def /ghi
PT flag,
mod_rewrite will rewrite
uri=/abc/... to
filename=/def/... as a full API-compliant
URI-to-filename translator should do. Then
mod_alias will try to do a
URI-to-filename transition, which will fail.
mod_alias and
mod_rewrite.qsappend|QSA'
(query string
append)
This flag forces the rewrite engine to append a query
string part of the substitution string to the existing string,
instead of replacing it. Use this when you want to add more
data to the query string via a rewrite rule.redirect|R
[=code]' (force redirect)
Prefix Substitution with
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) will be returned. If you want to use other response
codes in the range 300-400, simply specify the appropriate number
or use one of the following symbolic names:
temp (default), permanent,
seeother. Use this for rules to
canonicalize the URL and return it to the client - to
translate ``/~'' into
``/u/'', or to always append a slash to
/u/user, etc.
Note: When you use this flag, make
sure that the substitution field is a valid URL! Otherwise,
you will be redirecting to an invalid location. Remember
that this flag on its own will only prepend
http://thishost[:thisport]/ to the URL, and rewriting
will continue. Usually, you will want to stop rewriting at this point,
and redirect immediately. To stop rewriting, you should add
the 'L' flag.
skip|S=num'
(skip next rule(s))
This flag forces the rewriting engine to skip the next
num rules in sequence, if the current rule
matches. Use this to make pseudo if-then-else constructs:
The last rule of the then-clause becomes
skip=N, where N is the number of rules in the
else-clause. (This is not the same as the
'chain|C' flag!)type|T=MIME-type'
(force MIME type)
Force the MIME-type of the target file to be
MIME-type. This can be used to
set up the content-type based on some conditions.
For example, the following snippet allows .php files to
be displayed by mod_php if they are called with
the .phps extension:
RewriteRule ^(.+\.php)s$ $1 [T=application/x-httpd-php-source]
Home directory expansion
mod_userdir.RewriteRule
directive.Note: Enabling rewrites in per-directory context
To enable the rewriting engine
for per-directory configuration files, you need to set
``RewriteEngine On'' in these files
and ``Options
FollowSymLinks'' must be 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.
Note: Pattern matching in per-directory context
Never forget that Pattern is
applied to a complete URL in per-server configuration
files. However, in per-directory configuration files, the
per-directory prefix (which always is the same for a specific
directory) is automatically removed for the pattern matching
and automatically added after the substitution has been
done. This feature is essential for many sorts of rewriting -
without this, you would always have to match the parent
directory which is not always possible.
http://'', then the directory
prefix will not be added, and an
external redirect or proxy throughput (if flag
P is used) is forced!Note: Substitution of Absolute URLs
http://thishost[:thisport],
mod_rewrite will automatically strip that
out. This auto-reduction on URLs with an implicit external redirect
is most useful in combination with
a mapping-function which generates the
hostname part.http://thishost because of this feature. To
achieve such a self-redirect, you have to use the
R-flag.Note: Query String
RewriteCond with the
%{QUERY_STRING} variable. You can, however, create
URLs in the substitution string, containing a query string
part. Simply use a question mark inside the substitution string, to
indicate that the following text should be re-injected into the
query string. When you want to erase an existing query string,
end the substitution string with just a question mark. To
combine a new query string with an old one, use the
[QSA] flag.httpd.conf)
for request ``GET
/somepath/pathinfo'':
Given Rule Resulting Substitution
---------------------------------------------- ----------------------------------
^/somepath(.*) otherpath$1 invalid, not supported
^/somepath(.*) otherpath$1 [R] invalid, not supported
^/somepath(.*) otherpath$1 [P] invalid, not supported
---------------------------------------------- ----------------------------------
^/somepath(.*) /otherpath$1 /otherpath/pathinfo
^/somepath(.*) /otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^/somepath(.*) /otherpath$1 [P] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^/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] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^/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
(/physical/path/to/somepath/.htacccess, with
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] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^localpath(.*) /otherpath$1 /otherpath/pathinfo
^localpath(.*) /otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^localpath(.*) /otherpath$1 [P] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^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] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^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
mod/mod_so.html 100644 0 0 23115 11074463036 11160 0 ustar 0 0
Apache モジュール mod_setenvif
説明: リクエストの特徴に基づいた環境変数の設定を可能にする ステータス: Base モジュール識別子: setenvif_module ソースファイル: mod_setenvif.c 概要
mod_setenvif
モジュールは、リクエストのある側面が指定された正規表現
に合うかどうかによって環境変数を設定する機能を提供します。
これらの環境変数を使用して、サーバの他の部分がどのような動作をするかを
決定することができます。netscape を設定します。
BrowserMatch ^Mozilla netscape
BrowserMatch MSIE !netscape
BrowserMatch ディレクティブ
説明: HTTP User-Agent に基づいて環境変数を設定する
構文: BrowserMatch regex [!]env-variable[=value]
[[!]env-variable[=value]] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_setenvif BrowserMatch は
SetEnvIf ディレクティブの
特例で、User-Agent HTTP リクエストヘッダに基づいて
環境変数を設定します。以下の 2 行の効果は同じになります:
BrowserMatchNoCase Robot is_a_robot
SetEnvIfNoCase User-Agent Robot is_a_robot
BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
BrowserMatch MSIE !javascript
BrowserMatchNoCase ディレクティブ
説明: HTTP User-Agent に基づいて大文字小文字を区別せずに
環境変数を設定する 構文: BrowserMatchNoCase regex [!]env-variable[=value]
[[!]env-variable[=value]] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_setenvif 互換性: Apache 1.2 以降
(Apache 1.2 ではこのディレクティブはもう用いられていない
mod_browser モジュールにありました) BrowserMatchNoCase ディレクティブは
意味的には BrowserMatch ディレクティブと
同じです。ただし、このディレクティブは大文字小文字を区別しない
マッチングを行ないます。例えば:
BrowserMatchNoCase mac platform=macintosh
BrowserMatchNoCase win platform=windows
BrowserMatch ディレクティブと
BrowserMatchNoCase ディレクティブは
SetEnvIf ディレクティブと
SetEnvIfNoCase ディレクティブの
特例です。以下の 2 行の効果は同じです:
BrowserMatchNoCase Robot is_a_robot
SetEnvIfNoCase User-Agent Robot is_a_robot
SetEnvIf ディレクティブ
説明: リクエストの属性に基づいて環境変数を設定する
構文: SetEnvIf attribute
regex [!]env-variable[=value]
[[!]env-variable[=value]] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_setenvif SetEnvIf
ディレクティブは、リクエストの属性に基づいて環境変数を定義します。
最初の引数で指定できる attribute は以下の三つのどれかです:
Host,
User-Agent, Referer,
Accept-Language です。リクエストヘッダの集合を現すために
正規表現を使うこともできます。
Remote_Host -
リクエストを行なっているクライアントのホスト名 (もしあれば)Remote_Addr -
リクエストを行なっているクライアントの IP アドレスServer_Addr -
リクエストを受け取ったサーバの IP アドレス
(2.0.43 以降のみ)Request_Method -
使用されているメソッド名 (GET, POST
など)Request_Protocol -
リクエストが行なわれたプロトコルの名前とバージョン
(例えば、"HTTP/0.9", "HTTP/1.1" など。)Request_URI -
URL のスキームとホストの後の部分SetEnvIf ディレクティブが以前のマッチの結果を
使うことができるようになります。この方法のテストでは前の部分にある
SetEnvIf[NoCase] の結果のみを使用可能です。「前」とは、
より広い範囲に対して定義されている (サーバ全体のように) か、現在のディレクティブの
範囲でより前の部分で定義されているか、ということです。
環境変数である可能性は、リクエストの特性に対するマッチが存在せず、
attribute に正規表現が使われなかったときにのみ考慮されます。
varname!varnamevarname=valuevalue の与えられた値に設定します。
2.0.51 以降では、regex 内に $1..$9
が存在すればそれを認識し、regex の対応する丸括弧で囲まれた部分で
置換します。例:
SetEnvIf Request_URI "\.gif$" object_is_image=gif
SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
:
SetEnvIf Referer www\.mydomain\.com intra_site_referral
:
SetEnvIf object_is_image xbm XBIT_PROCESSING=1
:
SetEnvIf ^TS* ^[a-z].* HAVE_TS
object_is_image を設定します。四つ目は
参照元のページがウェブサイト www.mydomain.com にあるときに
intra_site_referral を設定します。HAVE_TS を設定します。参照
SetEnvIfNoCase ディレクティブ
説明: リクエストの属性に基づいて大文字小文字を区別せずに環境変数を設定する 構文: SetEnvIfNoCase attribute regex
[!]env-variable[=value]
[[!]env-variable[=value]] ...コンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: FileInfo ステータス: Base モジュール: mod_setenvif 互換性: Apache 1.3 以降 SetEnvIfNoCase は意味的には
SetEnvIf ディレクティブと
同じです。違いは、正規表現のマッチングが大文字小文字を区別しないで
行なわれることです。例えば:
SetEnvIfNoCase Host Apache\.Org site=apache
Host: が
あり、その値が Apache.Org や apache.org、
その他の大文字小文字の組み合わせであったときに site
環境変数を "apache" に設定します。
mod/mod_speling.html 100644 0 0 13763 11074463036 12210 0 ustar 0 0
Apache モジュール mod_so
説明: 起動時や再起動時に実行コードとモジュールをサーバにロードする
ステータス: Extension モジュール識別子: so_module ソースファイル: mod_so.c 互換性: このモジュールは Window では (常に含まれている) Base
モジュールです 概要
.so という拡張子が付いています) からです。
Windows 上ではこのモジュールの拡張子は .so か .dll
です。警告
Windows 用のロード可能なモジュールを作成する
注
Configure
プログラムがありませんので、モジュールのソースファイルを
ApacheCore プロジェクトファイルに追加し、シンボルを
os\win32\modules.c ファイルに追加する必要があります。LoadModuleAP_MODULE_DECLARE_DATA (Apache
のヘッダファイルで定義されています) をモジュールのモジュールレコード
定義の部分に追加してください。たとえば、モジュールに
module foo_module;
module AP_MODULE_DECLARE_DATA foo_module;
.DEF
ファイルの方を良く知っているという場合は、
代わりにそれを使ってモジュールレコードを
エクスポートすることもできます。modules
ディレクトリにモジュールを置いて、
LoadModuleLoadFile ディレクティブ
説明: 指定されたオブジェクトファイルやライブラリをリンクする 構文: LoadFile filename [filename] ...コンテキスト: サーバ設定ファイル ステータス: Extension モジュール: mod_so LoadFile libexec/libxmlparse.soLoadModule ディレクティブ
説明: オブジェクトファイルやライブラリをリンクし、使用モジュールの
リストに追加する 構文: LoadModule module filenameコンテキスト: サーバ設定ファイル ステータス: Extension モジュール: mod_so module
型の外部変数の名前で、モジュールのドキュメントに
モジュール識別子として書かれているものです。例 :
LoadModule status_module modules/mod_status.so
mod/mod_ssl.html 100644 0 0 275456 11074463036 11401 0 ustar 0 0
Apache モジュール mod_speling
説明: ユーザが入力したであろう間違った URL を、
大文字小文字の区別を無視することと一つ以下の綴り間違いを許容することで
修正を試みる ステータス: Extension モジュール識別子: speling_module ソースファイル: mod_speling.c 概要
ディレクティブ
CheckSpelling ディレクティブ
説明: spelling モジュールを使用するようにする 構文: CheckSpelling on|offデフォルト: CheckSpelling Offコンテキスト: サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess 上書き: Options ステータス: Extension モジュール: mod_speling 互換性: CheckSpelling は Apache 1.1 では別配布のモジュールで、
大文字小文字の間違いのみの機能でした。Apache 1.3 で Apache の配布に
含まれるようになりました。Apache 1.3.2 より前では CheckSpelling
ディレクティブは「サーバ」と「バーチャルホスト」コンテキストでのみ
使用可能でした
http://my.host/~apahce/ のように)
を訂正することはできません。
訂正できるのはファイル名とディレクトリ名だけです。<Location /status>
はネゴシエーションの結果のファイル "/stats.html"
として間違って扱われるかもしれません。
mod/mod_status.html 100644 0 0 17007 11074463036 12065 0 ustar 0 0
Apache Module mod_ssl
Description: Strong cryptography using the Secure Sockets
Layer (SSL) and Transport Layer Security (TLS) protocols Status: Extension ModuleIdentifier: ssl_module SourceFile: mod_ssl.c Summary
Directives
SSLCACertificateFile SSLCACertificatePath SSLCARevocationFile SSLCARevocationPath SSLCertificateChainFile SSLCertificateFile SSLCertificateKeyFile SSLCipherSuite SSLEngine SSLMutex SSLOptions SSLPassPhraseDialog SSLProtocol SSLProxyCACertificateFile SSLProxyCACertificatePath SSLProxyCARevocationFile SSLProxyCARevocationPath SSLProxyCipherSuite SSLProxyEngine SSLProxyMachineCertificateFile SSLProxyMachineCertificatePath SSLProxyProtocol SSLProxyVerify SSLProxyVerifyDepth SSLRandomSeed SSLRequire SSLRequireSSL SSLSessionCache SSLSessionCacheTimeout SSLUserName SSLVerifyClient SSLVerifyDepthTopics
Environment Variables
Variable Name:
Value Type:
Description:
HTTPSflag HTTPS is being used. SSL_PROTOCOLstring The SSL protocol version (SSLv2, SSLv3, TLSv1) SSL_SESSION_IDstring The hex-encoded SSL session id SSL_CIPHERstring The cipher specification name SSL_CIPHER_EXPORTstring true if cipher is an export cipherSSL_CIPHER_USEKEYSIZEnumber Number of cipher bits (actually used) SSL_CIPHER_ALGKEYSIZEnumber Number of cipher bits (possible) SSL_VERSION_INTERFACEstring The mod_ssl program version SSL_VERSION_LIBRARYstring The OpenSSL program version SSL_CLIENT_M_VERSIONstring The version of the client certificate SSL_CLIENT_M_SERIALstring The serial of the client certificate SSL_CLIENT_S_DNstring Subject DN in client's certificate SSL_CLIENT_S_DN_x509string Component of client's Subject DN SSL_CLIENT_I_DNstring Issuer DN of client's certificate SSL_CLIENT_I_DN_x509string Component of client's Issuer DN SSL_CLIENT_V_STARTstring Validity of client's certificate (start time) SSL_CLIENT_V_ENDstring Validity of client's certificate (end time) SSL_CLIENT_A_SIGstring Algorithm used for the signature of client's certificate SSL_CLIENT_A_KEYstring Algorithm used for the public key of client's certificate SSL_CLIENT_CERTstring PEM-encoded client certificate SSL_CLIENT_CERT_CHAINnstring PEM-encoded certificates in client certificate chain SSL_CLIENT_VERIFYstring NONE, SUCCESS, GENEROUS or FAILED:reasonSSL_SERVER_M_VERSIONstring The version of the server certificate SSL_SERVER_M_SERIALstring The serial of the server certificate SSL_SERVER_S_DNstring Subject DN in server's certificate SSL_SERVER_S_DN_x509string Component of server's Subject DN SSL_SERVER_I_DNstring Issuer DN of server's certificate SSL_SERVER_I_DN_x509string Component of server's Issuer DN SSL_SERVER_V_STARTstring Validity of server's certificate (start time) SSL_SERVER_V_ENDstring Validity of server's certificate (end time) SSL_SERVER_A_SIGstring Algorithm used for the signature of server's certificate SSL_SERVER_A_KEYstring Algorithm used for the public key of server's certificate SSL_SERVER_CERTstring PEM-encoded server certificate C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email ]
Custom Log Formats
mod_ssl is built into Apache or at least
loaded (under DSO situation) additional functions exist for the Custom Log Format of
mod_log_config. First there is an
additional ``%{varname}x''
eXtension format function which can be used to expand any variables
provided by any module, especially those provided by mod_ssl which can
you find in the above table.%{name}c'' cryptography format function
provided. Information about this function is provided in the Compatibility chapter.
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
SSLCACertificateFile Directive
Description: File of concatenated PEM-encoded CA Certificates
for Client Auth Syntax: SSLCACertificateFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLCACertificatePath.Example
SSLCACertificateFile /usr/local/apache2/conf/ssl.crt/ca-bundle-client.crt
SSLCACertificatePath Directive
Description: Directory of PEM-encoded CA Certificates for
Client Auth Syntax: SSLCACertificatePath directory-pathContext: server config, virtual host Status: Extension Module: mod_ssl .N. And you should always make sure this directory
contains the appropriate symbolic links. Example
SSLCACertificatePath /usr/local/apache2/conf/ssl.crt/
SSLCARevocationFile Directive
Description: File of concatenated PEM-encoded CA CRLs for
Client Auth Syntax: SSLCARevocationFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLCARevocationPath.Example
SSLCARevocationFile /usr/local/apache2/conf/ssl.crl/ca-bundle-client.crl
SSLCARevocationPath Directive
Description: Directory of PEM-encoded CA CRLs for
Client Auth Syntax: SSLCARevocationPath directory-pathContext: server config, virtual host Status: Extension Module: mod_ssl .rN. And you should always make sure this directory
contains the appropriate symbolic links. Example
SSLCARevocationPath /usr/local/apache2/conf/ssl.crl/
SSLCertificateChainFile Directive
Description: File of PEM-encoded Server CA Certificates Syntax: SSLCertificateChainFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLCACertificatePath for explicitly
constructing the server certificate chain which is sent to the browser
in addition to the server certificate. It is especially useful to
avoid conflicts with CA certificates when using client
authentication. Because although placing a CA certificate of the
server certificate chain into SSLCACertificatePath has the same effect
for the certificate chain construction, it has the side-effect that
client certificates issued by this same CA certificate are also
accepted on client authentication. That's usually not one expect.Example
SSLCertificateChainFile /usr/local/apache2/conf/ssl.crt/ca.crt
SSLCertificateFile Directive
Description: Server PEM-encoded X.509 Certificate file Syntax: SSLCertificateFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl Example
SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt
SSLCertificateKeyFile Directive
Description: Server PEM-encoded Private Key file Syntax: SSLCertificateKeyFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLCertificateFile, use this additional directive to
point to the file with the stand-alone Private Key. When
SSLCertificateFile is used and the file
contains both the Certificate and the Private Key this directive need
not be used. But we strongly discourage this practice. Instead we
recommend you to separate the Certificate and the Private Key. If the
contained Private Key is encrypted, the Pass Phrase dialog is forced
at startup time. This directive can be used up to two times
(referencing different filenames) when both a RSA and a DSA based
private key is used in parallel.Example
SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key
SSLCipherSuite Directive
Description: Cipher Suite available for negotiation in SSL
handshake Syntax: SSLCipherSuite cipher-specDefault: SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXPContext: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl
RSA or Diffie-Hellman variants.
RSA, Diffie-Hellman, DSS or none.
DES, Triple-DES, RC4, RC2, IDEA or none.
MD5, SHA or SHA1.
Tag Description Key Exchange Algorithm: kRSARSA key exchange kDHrDiffie-Hellman key exchange with RSA key kDHdDiffie-Hellman key exchange with DSA key kEDHEphemeral (temp.key) Diffie-Hellman key exchange (no cert) Authentication Algorithm: aNULLNo authentication aRSARSA authentication aDSSDSS authentication aDHDiffie-Hellman authentication Cipher Encoding Algorithm: eNULLNo encoding DESDES encoding 3DESTriple-DES encoding RC4RC4 encoding RC2RC2 encoding IDEAIDEA encoding MAC Digest Algorithm: MD5MD5 hash function SHA1SHA1 hash function SHASHA hash function Aliases: SSLv2all SSL version 2.0 ciphers SSLv3all SSL version 3.0 ciphers TLSv1all TLS version 1.0 ciphers EXPall export ciphers EXPORT40all 40-bit export ciphers only EXPORT56all 56-bit export ciphers only LOWall low strength ciphers (no export, single DES) MEDIUMall ciphers with 128 bit encryption HIGHall ciphers using Triple-DES RSAall ciphers using RSA key exchange DHall ciphers using Diffie-Hellman key exchange EDHall ciphers using Ephemeral Diffie-Hellman key exchange ADHall ciphers using Anonymous Diffie-Hellman key exchange DSSall ciphers using DSS authentication NULLall ciphers using no encryption SSLv2, SSLv3, TLSv1, EXP, LOW, MEDIUM,
HIGH) for certain groups of ciphers. These tags can be joined
together with prefixes to form the cipher-spec. Available
prefixes are:
+: add ciphers to list and pull them to current location in list-: remove cipher from list (can be added later again)!: kill cipher from list completely (can not be added later again)openssl ciphers
-v'' command which provides a nice way to successively create the
correct cipher-spec string. The default cipher-spec string
is ``ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'' which
means the following: first, remove from consideration any ciphers that do not
authenticate, i.e. for SSL only the Anonymous Diffie-Hellman ciphers. Next,
use ciphers using RC4 and RSA. Next include the high, medium and then the low
security ciphers. Finally pull all SSLv2 and export ciphers to the
end of the list.
$ openssl ciphers -v 'ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'
NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1
NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
... ... ... ... ...
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
Example
SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW
Cipher-Tag Protocol Key Ex. Auth. Enc. MAC Type RSA Ciphers: DES-CBC3-SHASSLv3 RSA RSA 3DES(168) SHA1 DES-CBC3-MD5SSLv2 RSA RSA 3DES(168) MD5 IDEA-CBC-SHASSLv3 RSA RSA IDEA(128) SHA1 RC4-SHASSLv3 RSA RSA RC4(128) SHA1 RC4-MD5SSLv3 RSA RSA RC4(128) MD5 IDEA-CBC-MD5SSLv2 RSA RSA IDEA(128) MD5 RC2-CBC-MD5SSLv2 RSA RSA RC2(128) MD5 RC4-MD5SSLv2 RSA RSA RC4(128) MD5 DES-CBC-SHASSLv3 RSA RSA DES(56) SHA1 RC4-64-MD5SSLv2 RSA RSA RC4(64) MD5 DES-CBC-MD5SSLv2 RSA RSA DES(56) MD5 EXP-DES-CBC-SHASSLv3 RSA(512) RSA DES(40) SHA1 export EXP-RC2-CBC-MD5SSLv3 RSA(512) RSA RC2(40) MD5 export EXP-RC4-MD5SSLv3 RSA(512) RSA RC4(40) MD5 export EXP-RC2-CBC-MD5SSLv2 RSA(512) RSA RC2(40) MD5 export EXP-RC4-MD5SSLv2 RSA(512) RSA RC4(40) MD5 export NULL-SHASSLv3 RSA RSA None SHA1 NULL-MD5SSLv3 RSA RSA None MD5 Diffie-Hellman Ciphers: ADH-DES-CBC3-SHASSLv3 DH None 3DES(168) SHA1 ADH-DES-CBC-SHASSLv3 DH None DES(56) SHA1 ADH-RC4-MD5SSLv3 DH None RC4(128) MD5 EDH-RSA-DES-CBC3-SHASSLv3 DH RSA 3DES(168) SHA1 EDH-DSS-DES-CBC3-SHASSLv3 DH DSS 3DES(168) SHA1 EDH-RSA-DES-CBC-SHASSLv3 DH RSA DES(56) SHA1 EDH-DSS-DES-CBC-SHASSLv3 DH DSS DES(56) SHA1 EXP-EDH-RSA-DES-CBC-SHASSLv3 DH(512) RSA DES(40) SHA1 export EXP-EDH-DSS-DES-CBC-SHASSLv3 DH(512) DSS DES(40) SHA1 export EXP-ADH-DES-CBC-SHASSLv3 DH(512) None DES(40) SHA1 export EXP-ADH-RC4-MD5SSLv3 DH(512) None RC4(40) MD5 export SSLEngine Directive
Description: SSL Engine Operation Switch Syntax: SSLEngine on|offDefault: SSLEngine offContext: server config, virtual host Status: Extension Module: mod_ssl <VirtualHost> section to enable SSL/TLS for a
particular virtual host. By default the SSL/TLS Protocol Engine is
disabled for both the main server and all configured virtual hosts.Example
<VirtualHost _default_:443>
SSLEngine on
...
</VirtualHost>
SSLMutex Directive
Description: Semaphore for internal mutual exclusion of
operations Syntax: SSLMutex typeDefault: SSLMutex noneContext: server config Status: Extension Module: mod_ssl
none | no
posixsem
sysvsem
sem
pthread
fcntl:/path/to/mutex
fcntl()
fucntion are used as the Mutex.
Always use a local disk filesystem for /path/to/mutex and never a file
residing on a NFS- or AFS-filesystem. It is only available when the underlying platform
and APR supports it. Note: Internally, the Process ID (PID) of the
Apache parent process is automatically appended to
/path/to/mutex to make it unique, so you don't have to worry
about conflicts yourself. Notice that this type of mutex is not available
under the Win32 environment. There you have to use the semaphore
mutex.flock:/path/to/mutex
fcntl:/path/to/mutex method with the
exception that the flock() function is used to provide file
locking. It is only available when the underlying platform
and APR supports it.file:/path/to/mutex
fcntl and flock,
in that order. It is only available when the underlying platform and APR supports
at least one of the 2.default | yes
Example
SSLMutex file:/usr/local/apache/logs/ssl_mutex
SSLOptions Directive
Description: Configure various SSL engine run-time options Syntax: SSLOptions [+|-]option ...Context: server config, virtual host, directory, .htaccess Override: Options Status: Extension Module: mod_ssl SSLOptions
could apply to a directory, then the most specific one is taken
completely; the options are not merged. However if all the
options on the SSLOptions directive are preceded by a
plus (+) or minus (-) symbol, the options
are merged. Any options preceded by a + are added to the
options currently in force, and any options preceded by a
- are removed from the options currently in force.
StdEnvVars
CompatEnvVars
ExportCertData
SSL_SERVER_CERT, SSL_CLIENT_CERT and
SSL_CLIENT_CERT_CHAINn (with n = 0,1,2,..).
These contain the PEM-encoded X.509 Certificates of server and client for
the current HTTPS connection and can be used by CGI scripts for deeper
Certificate checking. Additionally all other certificates of the client
certificate chain are provided, too. This bloats up the environment a
little bit which is why you have to use this option to enable it on
demand.FakeBasicAuth
openssl x509 command: openssl x509 -noout -subject -in
certificate.crt). Note that no password is
obtained from the user. Every entry in the user file needs this password:
``xxj31ZMTZzkVA'', which is the DES-encrypted version of the
word `password''. Those who live under MD5-based encryption
(for instance under FreeBSD or BSD/OS, etc.) should use the following MD5
hash of the same word: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''.StrictRequire
SSLRequireSSL or
SSLRequire successfully decided that access should be
forbidden. Usually the default is that in the case where a ``Satisfy
any'' directive is used, and other access restrictions are passed,
denial of access due to SSLRequireSSL or
SSLRequire is overridden (because that's how the Apache
Satisfy mechanism should work.) But for strict access restriction
you can use SSLRequireSSL and/or SSLRequire in
combination with an ``SSLOptions +StrictRequire''. Then an
additional ``Satisfy Any'' has no chance once mod_ssl has
decided to deny access.OptRenegotiate
Example
SSLOptions +FakeBasicAuth -StrictRequire
<Files ~ "\.(cgi|shtml)$">
SSLOptions +StdEnvVars +CompatEnvVars -ExportCertData
<Files>
SSLPassPhraseDialog Directive
Description: Type of pass phrase dialog for encrypted private
keys Syntax: SSLPassPhraseDialog typeDefault: SSLPassPhraseDialog builtinContext: server config Status: Extension Module: mod_ssl SSLCertificateFile) and
Private Key (see SSLCertificateKeyFile) files of the
SSL-enabled virtual servers. Because for security reasons the Private
Key files are usually encrypted, mod_ssl needs to query the
administrator for a Pass Phrase in order to decrypt those files. This
query can be done in two ways which can be configured by
type:
builtin
exec:/path/to/program
servername:portnumber'', the second is either
``RSA'' or ``DSA''), which indicate for which
server and algorithm it has to print the corresponding Pass Phrase to
stdout. The intent is that this external program first runs
security checks to make sure that the system is not compromised by an
attacker, and only when these checks were passed successfully it provides
the Pass Phrase.stdout.
Nothing more or less! So, if you're really paranoid about security, here
is your interface. Anything else has to be left as an exercise to the
administrator, because local security requirements are so different.
SSLPassPhraseDialog exec:/usr/local/apache/sbin/pp-filter
SSLProtocol Directive
Description: Configure usable SSL protocol flavors Syntax: SSLProtocol [+|-]protocol ...Default: SSLProtocol allContext: server config, virtual host Override: Options Status: Extension Module: mod_ssl
SSLv2
SSLv3
TLSv1
All
+SSLv2 +SSLv3 +TLSv1'' and a
convinient way for enabling all protocols except one when used in
combination with the minus sign on a protocol as the example above
shows.Example
# enable SSLv3 and TLSv1, but not SSLv2
SSLProtocol all -SSLv2
SSLProxyCACertificateFile Directive
Description: File of concatenated PEM-encoded CA Certificates
for Remote Server Auth Syntax: SSLProxyCACertificateFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLProxyCACertificatePath.Example
SSLProxyCACertificateFile /usr/local/apache2/conf/ssl.crt/ca-bundle-remote-server.crt
SSLProxyCACertificatePath Directive
Description: Directory of PEM-encoded CA Certificates for
Remote Server Auth Syntax: SSLProxyCACertificatePath directory-pathContext: server config, virtual host Status: Extension Module: mod_ssl .N. And you should always make sure this directory
contains the appropriate symbolic links. Use the Makefile which
comes with mod_ssl to accomplish this task.Example
SSLProxyCACertificatePath /usr/local/apache2/conf/ssl.crt/
SSLProxyCARevocationFile Directive
Description: File of concatenated PEM-encoded CA CRLs for
Remote Server Auth Syntax: SSLProxyCARevocationFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLProxyCARevocationPath.Example
SSLProxyCARevocationFile /usr/local/apache2/conf/ssl.crl/ca-bundle-remote-server.crl
SSLProxyCARevocationPath Directive
Description: Directory of PEM-encoded CA CRLs for
Remote Server Auth Syntax: SSLProxyCARevocationPath directory-pathContext: server config, virtual host Status: Extension Module: mod_ssl .rN. And you should always make sure this directory
contains the appropriate symbolic links. Use the Makefile which
comes with mod_ssl to accomplish this task.Example
SSLProxyCARevocationPath /usr/local/apache2/conf/ssl.crl/
SSLProxyCipherSuite Directive
Description: Cipher Suite available for negotiation in SSL
proxy handshake Syntax: SSLProxyCipherSuite cipher-specDefault: SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXPContext: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl SSLCipherSuite, but for the proxy connection.
Please refer to SSLCipherSuite
for additional information.SSLProxyEngine Directive
Description: SSL Proxy Engine Operation Switch Syntax: SSLProxyEngine on|offDefault: SSLProxyEngine offContext: server config, virtual host Status: Extension Module: mod_ssl <VirtualHost> section to enable SSL/TLS for proxy
usage in a particular virtual host. By default the SSL/TLS Protocol Engine is
disabled for proxy image both for the main server and all configured virtual hosts.Example
<VirtualHost _default_:443>
SSLProxyEngine on
...
</VirtualHost>
SSLProxyMachineCertificateFile Directive
Description: File of concatenated PEM-encoded client certificates and keys to be used by the proxy Syntax: SSLProxyMachineCertificateFile filenameContext: server config Override: Not applicable Status: Extension Module: mod_ssl SSLProxyMachineCertificatePath.
SSLProxyMachineCertificateFile /usr/local/apache2/conf/ssl.crt/proxy.pem
SSLProxyMachineCertificatePath Directive
Description: Directory of PEM-encoded client certificates and keys to be used by the proxy Syntax: SSLProxyMachineCertificatePath directoryContext: server config Override: Not applicable Status: Extension Module: mod_ssl hash-value.N. And you should always make sure this
directory contains the appropriate symbolic links. Use the Makefile which
comes with mod_ssl to accomplish this task.
SSLProxyMachineCertificatePath /usr/local/apache2/conf/proxy.crt/
SSLProxyProtocol Directive
Description: Configure usable SSL protocol flavors for proxy usage Syntax: SSLProxyProtocol [+|-]protocol ...Default: SSLProxyProtocol allContext: server config, virtual host Override: Options Status: Extension Module: mod_ssl SSLProtocol
for additional information.
SSLProxyVerify Directive
Description: Type of remote server Certificate verification Syntax: SSLProxyVerify levelDefault: SSLProxyVerify noneContext: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl
but it need not to be (successfully) verifiable.Example
SSLProxyVerify require
SSLProxyVerifyDepth Directive
Description: Maximum depth of CA Certificates in Remote Server
Certificate verification Syntax: SSLProxyVerifyDepth numberDefault: SSLProxyVerifyDepth 1Context: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl SSLProxyCACertificatePath), etc.Example
SSLProxyVerifyDepth 10
SSLRandomSeed Directive
Description: Pseudo Random Number Generator (PRNG) seeding
source Syntax: SSLRandomSeed context source
[bytes]Context: server config Status: Extension Module: mod_ssl startup) and/or just before a new SSL connection is established
(context is connect). This directive can only be used
in the global server context because the PRNG is a global facility.
builtin
file:/path/to/source
/path/to/source as the
source for seeding the PRNG. When bytes is specified, only the
first bytes number of bytes of the file form the entropy (and
bytes is given to /path/to/source as the first
argument). When bytes is not specified the whole file forms the
entropy (and 0 is given to /path/to/source as
the first argument). Use this especially at startup time, for instance
with an available /dev/random and/or
/dev/urandom devices (which usually exist on modern Unix
derivates like FreeBSD and Linux)./dev/random provides only as
much entropy data as it actually has, i.e. when you request 512 bytes of
entropy, but the device currently has only 100 bytes available two things
can happen: On some platforms you receive only the 100 bytes while on
other platforms the read blocks until enough bytes are available (which
can take a long time). Here using an existing /dev/urandom is
better, because it never blocks and actually gives the amount of requested
data. The drawback is just that the quality of the received data may not
be the best.exec:/path/to/program/ variant (see below) or use
egd:/path/to/egd-socket (see below).exec:/path/to/program
/path/to/program as the source for seeding the
PRNG. When bytes is specified, only the first
bytes number of bytes of its stdout contents
form the entropy. When bytes is not specified, the
entirety of the data produced on stdout form the
entropy. Use this only at startup time when you need a very strong
seeding with the help of an external program (for instance as in
the example above with the truerand utility you can
find in the mod_ssl distribution which is based on the AT&T
truerand library). Using this in the connection context
slows down the server too dramatically, of course. So usually you
should avoid using external programs in that context.egd:/path/to/egd-socket (Unix only)
Example
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/random
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed startup exec:/usr/local/bin/truerand 16
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/random
SSLRandomSeed connect file:/dev/urandom 1024
SSLRequire Directive
Description: Allow access only when an arbitrarily complex
boolean expression is true Syntax: SSLRequire expressionContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl
expr ::= "true" | "false"
| "!" expr
| expr "&&" expr
| expr "||" expr
| "(" expr ")"
| comp
comp ::= word "==" word | word "eq" word
| word "!=" word | word "ne" word
| word "<" word | word "lt" word
| word "<=" word | word "le" word
| word ">" word | word "gt" word
| word ">=" word | word "ge" word
| word "in" "{" wordlist "}"
| word "=~" regex
| word "!~" regex
wordlist ::= word
| wordlist "," word
word ::= digit
| cstring
| variable
| function
digit ::= [0-9]+
cstring ::= "..."
variable ::= "%{" varname "}"
function ::= funcname "(" funcargs ")"
varname any variable from Table 3 can be used. Finally for
funcname the following functions are available:
file(filename)
Example
SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
HTTP_USER_AGENT PATH_INFO AUTH_TYPE
HTTP_REFERER QUERY_STRING SERVER_SOFTWARE
HTTP_COOKIE REMOTE_HOST API_VERSION
HTTP_FORWARDED REMOTE_IDENT TIME_YEAR
HTTP_HOST IS_SUBREQ TIME_MON
HTTP_PROXY_CONNECTION DOCUMENT_ROOT TIME_DAY
HTTP_ACCEPT SERVER_ADMIN TIME_HOUR
HTTP:headername SERVER_NAME TIME_MIN
THE_REQUEST SERVER_PORT TIME_SEC
REQUEST_METHOD SERVER_PROTOCOL TIME_WDAY
REQUEST_SCHEME REMOTE_ADDR TIME
REQUEST_URI REMOTE_USER ENV:variablename
REQUEST_FILENAME
HTTPS SSL_CLIENT_M_VERSION SSL_SERVER_M_VERSION
SSL_CLIENT_M_SERIAL SSL_SERVER_M_SERIAL
SSL_PROTOCOL SSL_CLIENT_V_START SSL_SERVER_V_START
SSL_SESSION_ID SSL_CLIENT_V_END SSL_SERVER_V_END
SSL_CIPHER SSL_CLIENT_S_DN SSL_SERVER_S_DN
SSL_CIPHER_EXPORT SSL_CLIENT_S_DN_C SSL_SERVER_S_DN_C
SSL_CIPHER_ALGKEYSIZE SSL_CLIENT_S_DN_ST SSL_SERVER_S_DN_ST
SSL_CIPHER_USEKEYSIZE SSL_CLIENT_S_DN_L SSL_SERVER_S_DN_L
SSL_VERSION_LIBRARY SSL_CLIENT_S_DN_O SSL_SERVER_S_DN_O
SSL_VERSION_INTERFACE SSL_CLIENT_S_DN_OU SSL_SERVER_S_DN_OU
SSL_CLIENT_S_DN_CN SSL_SERVER_S_DN_CN
SSL_CLIENT_S_DN_T SSL_SERVER_S_DN_T
SSL_CLIENT_S_DN_I SSL_SERVER_S_DN_I
SSL_CLIENT_S_DN_G SSL_SERVER_S_DN_G
SSL_CLIENT_S_DN_S SSL_SERVER_S_DN_S
SSL_CLIENT_S_DN_D SSL_SERVER_S_DN_D
SSL_CLIENT_S_DN_UID SSL_SERVER_S_DN_UID
SSL_CLIENT_S_DN_Email SSL_SERVER_S_DN_Email
SSL_CLIENT_I_DN SSL_SERVER_I_DN
SSL_CLIENT_I_DN_C SSL_SERVER_I_DN_C
SSL_CLIENT_I_DN_ST SSL_SERVER_I_DN_ST
SSL_CLIENT_I_DN_L SSL_SERVER_I_DN_L
SSL_CLIENT_I_DN_O SSL_SERVER_I_DN_O
SSL_CLIENT_I_DN_OU SSL_SERVER_I_DN_OU
SSL_CLIENT_I_DN_CN SSL_SERVER_I_DN_CN
SSL_CLIENT_I_DN_T SSL_SERVER_I_DN_T
SSL_CLIENT_I_DN_I SSL_SERVER_I_DN_I
SSL_CLIENT_I_DN_G SSL_SERVER_I_DN_G
SSL_CLIENT_I_DN_S SSL_SERVER_I_DN_S
SSL_CLIENT_I_DN_D SSL_SERVER_I_DN_D
SSL_CLIENT_I_DN_UID SSL_SERVER_I_DN_UID
SSL_CLIENT_I_DN_Email SSL_SERVER_I_DN_Email
SSL_CLIENT_A_SIG SSL_SERVER_A_SIG
SSL_CLIENT_A_KEY SSL_SERVER_A_KEY
SSL_CLIENT_CERT SSL_SERVER_CERT
SSL_CLIENT_CERT_CHAINn
SSL_CLIENT_VERIFY
SSLRequireSSL Directive
Description: Deny access when SSL is not used for the
HTTP request Syntax: SSLRequireSSLContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl Example
SSLRequireSSL
SSLSessionCache Directive
Description: Type of the global/inter-process SSL Session
Cache Syntax: SSLSessionCache typeDefault: SSLSessionCache noneContext: server config Status: Extension Module: mod_ssl
none
dbm:/path/to/datafile
shm:/path/to/datafile[(size)]
/path/to/datafile) to synchronize the local OpenSSL memory
caches of the server processes. This storage type is not available on all
platforms.Examples
SSLSessionCache dbm:/usr/local/apache/logs/ssl_gcache_data
SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000)
SSLSessionCacheTimeout Directive
Description: Number of seconds before an SSL session expires
in the Session Cache Syntax: SSLSessionCacheTimeout secondsDefault: SSLSessionCacheTimeout 300Context: server config, virtual host Status: Extension Module: mod_ssl Example
SSLSessionCacheTimeout 600
SSLUserName Directive
Description: Variable name to determine user name Syntax: SSLUserName varnameContext: server config, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl Compatibility: Available in Apache 2.0.51 and later REMOTE_USER to be set. The varname can be
any of the SSL environment variables.Example
SSLUserName SSL_CLIENT_S_DN_CN
SSLVerifyClient Directive
Description: Type of Client Certificate verification Syntax: SSLVerifyClient levelDefault: SSLVerifyClient noneContext: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl
but it need not to be (successfully) verifiable.Example
SSLVerifyClient require
SSLVerifyDepth Directive
Description: Maximum depth of CA Certificates in Client
Certificate verification Syntax: SSLVerifyDepth numberDefault: SSLVerifyDepth 1Context: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl SSLCACertificatePath), etc.Example
SSLVerifyDepth 10
mod/mod_suexec.html 100644 0 0 10607 11074463036 12035 0 ustar 0 0
Apache モジュール mod_status
This translation may be out of date. Check the
English version for recent changes.
説明: サーバの活動状況と性能に関する情報を提供する ステータス: Base モジュール識別子: status_module ソースファイル: mod_status.c 概要
Status を使用可能にする
httpd.conf 設定ファイルに追加します
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>
http://your.server.name/server-status をアクセスすることにより
知ることができるようになります。
自動更新
http://your.server.name/server-status?refresh=N
というページをアクセスしてください。
機械読み取り可能なステータスファイル
http://your.server.name/server-status?auto を
アクセスすることにより、ステータスファイルの機械読み取り可能なバージョンを
得ることができます。これは自動的に実行されるときに便利です。
Apache の /support ディレクトリにある
Perl プログラム log_server_status を見てください。
mod_status がサーバに組み込まれている
場合、ハンドラの機能はディレクトリ毎のファイル
(すなわち、.htaccess) も含むすべての
設定ファイルで使用可能になることには注意をしておく必要があります。
これは、サイトによってはセキュリティに関する望ましくない結果を
もたらすことがあるかもしれません。
mod/mod_unique_id.html 100644 0 0 25773 11074463036 12535 0 ustar 0 0
Apache モジュール mod_suexec
This translation may be out of date. Check the
English version for recent changes.
説明: 指定されたユーザとグループで CGI スクリプトを実行する ステータス: 拡張 モジュール識別子: suexec_module ソースファイル: mod_suexec.c 互換性: Apache 2.0 以降で使用可能 概要
SuexecUserGroup ディレクティブ
説明: CGI プログラムのユーザパーミッション、グループパーミッション 構文: SuexecUserGroup User Groupコンテキスト: サーバ設定ファイル, バーチャルホスト ステータス: 拡張 モジュール: mod_suexec 互換性: SuexecUserGroup は 2.0 以降でのみ使用可能。 SuexecUserGroup ディレクティブは CGI プログラム
が実行されるユーザとグループを指定できるようにします。CGI 以外の
リクエストは User ディレクティブで指定されたユーザのままで処理されます。
このディレクティブは Apache 1.3 における VirtualHosts の中で
User ディレクティブと Group ディレクティブを使う用法の代わりになります。例
SuexecUserGroup nobody nogroup
Apache モジュール mod_unique_id
This translation may be out of date. Check the
English version for recent changes.
説明: それぞれのリクエストに対する一意な識別子の入った環境変数を
提供する ステータス: Extension モジュール識別子: unique_id_module ソースファイル: mod_unique_id.c 概要
UNIQUE_ID に識別子が設定されます。
一意な識別子が便利な理由はいろいろありますが、
このドキュメントの目的からは外れるため、ここでは説明しません。
理論
UNIQUE_ID 環境変数は 112 ビット (32 ビット IP
アドレス、32 ビット pid, 32 ビットタイムスタンプ、16
ビットカウンタの四つの組) をアルファベット [A-Za-z0-9@-]
を用いて MIME の base64 符号化と同様の方法により符号化し、19
の文字を生成することにより作成されます。MIME の base64
のアルファベットは実際は [A-Za-z0-9+/] ですが、
+ と / とは URL
では特別な符号化が必要なので、あまり望ましくありません。
全ての値はネットワークバイトオーダで符号化されますので、
符号は違ったバイトオーダのアーキテクチャ間で比較可能です。
実際の符号化の順番は: タイムスタンプ、IP アドレス、pid,
カウンタです。この順には目的がありますが、
アプリケーションは符号を解析するべきではないことを強調しておきます。
アプリケーションは符号化された UNIQUE_ID
全体を透過的なトークンとして扱うべきです。
UNIQUE_ID は他の UNIQUE_ID
との等価性を調べるためだけにのみ使用できます。UNIQUE_ID
のデータベースとの衝突を心配することなく符号を変更することが
可能になるように選択しています。
新しい符号はタイムスタンプを最初の要素として残すのが望ましく、
それ以外は同じアルファベットとビット長を使うことができます。
タイムスタンプは本質的に増加系列ですので、
クラスタの全てのマシンがリクエストとサーバ機能を停止して