Apache HTTP サーバ バージョン 2.2

Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.2 > モジュール

# Apache コア機能

Available Languages: de | en | ja

説明: | 常に使用可能な Apache HTTP サーバのコア機能
ステータス: | Core

### ディレクティブ

## AcceptFilter ディレクティブ

説明: | プロトコルを Listen しているソケットの最適化を設定する
構文: | `AcceptFilter protocol accept_filter`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core
互換性: | 2.1.5 以降

Listen しているソケットに対して、OS が固有に持っているプロトコルについての最適化を 有効にするディレクティブです。大前提となる条件は、データが受信されるか HTTP リクエスト全体がバッファされるかするまで、カーネルがサーバプロセスに ソケットを送らないようになっている、ということです。現在サポートされているのは、 FreeBSD の Accept Filter と Linux のプリミティブな `TCP_DEFER_ACCEPT` のみです。

FreeBSD のデフォルト値は :

`AcceptFilter http httpready
AcceptFilter https dataready`

`httpready` Accept Filter は HTTP リクエスト全体を、 カーネルレベルでバッファリングします。リクエスト全体を受信し終わると、 その後サーバプロセスにそれを送ります。詳細については accf_http(9) を参照してください。HTTPS のリクエストは暗号化されているので accf_data(9) フィルタのみが使用されます。

Linux でのデフォルト値は :

`AcceptFilter http data
AcceptFilter https data`

Linux の `TCP_DEFER_ACCEPT` は HTTP リクエストのバッファリングを サポートしていません。`none` 以外の値で `TCP_DEFER_ACCEPT` が有効になります。詳細については Linux man ページ tcp(7) を参照してください。

引数に `none` を指定すると、プロトコルに対する全ての Accept Filter が無効になります。`nntp` といった、先にサーバにデータを 送る必要のあるプロトコルに有効です :

`AcceptFilter nttp none`

## 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` が有効なファイルにマップすれば 受け付けられます。
`Default`
  続きのパス名情報の扱いはリクエストの ハンドラで決まります。 普通のファイルのためのコアハンドラのデフォルトは `PATH_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>`

### 参照

- `AllowOverride`
- 設定ファイル
- .htaccess ファイル

## AddDefaultCharset ディレクティブ

説明: | レスポンスのコンテントタイプが `text/plain` あるいは `text/html` の場合に追加するデフォルトの charset パラメータ
構文: | `AddDefaultCharset On|Off|charset`
デフォルト: | `AddDefaultCharset Off`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core

レスポンスのコンテントタイプが `text/plain` あるいは `text/html` の場合に限りますが、レスポンスに追加するメディアタイプの文字セットパラメータ (文字エンコーディングの名前) のデフォルト値を、このディレクティブで指定します。 これはレスポンス (訳注: レスポンスの HTML) 内で `META` 要素で指定された、どのような文字セットも無効にしますが、 最終的な挙動はユーザのクライアント側の設定で決まります。 この機能は `AddDefaultCharset Off` という設定で無効になります。 `AddDefaultCharset On` にすれば、 Apache 内部のデフォルト文字セット `iso-8859-1` に設定されます。 その他 charset に指定できる値であれば、どんな値でも使えます。 指定する値は、MIME メディアタイプとして使われる IANA に登録されている文字セット名のうちの一つにすべきです。 例えば:

`AddDefaultCharset utf-8`

`AddDefaultCharset` を使うときは、全てのテキストリソースが 指定する文字エンコードになっていると分かっていて、かつ、 リソースの個々に文字セットを指定するのが大変な場合のみです。 例を挙げると、レガシーな CGI スクリプトなどの、動的に生成される コンテンツを含むリソースに文字セットパラメータを追加する場合で、 ユーザの入力データが出力に入り、クロスサイトスクリプティングが 引き起こされうる場合です。デフォルト文字セットをセットしたとしても、 ブラウザの "文字エンコードの自動選択" 機能が有効になっているユーザを 守ることにはならないので、もちろんより良い解決策は単にスクリプトを修正 (あるいは削除) することです。

### 参照

- `AddCharset`

## AddOutputFilterByType ディレクティブ

説明: | MIME-type に出力フィルタを割り当てる
構文: | `AddOutputFilterByType filter[;filter...] MIME-type [MIME-type] ...`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core
互換性: | Apache 2.0.33 以降で使用可能。ただし 2.1 以降で非推奨。

このディレクティブは応答の MIME タイプ に応じて出力フィルタを使用するようにします。 ただし下で説明される理由により、本ディレクティブは非推奨です。 同等の機能は `mod_filter` で利用できます。

次の例は `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 スクリプトでコンテントタイプを設定するというものでも 大丈夫です。

タイプ毎の出力フィルタはプロキシリクエストには決して適用されません。

### 参照

- `AddOutputFilter`
- `SetOutputFilter`
- フィルタ

## 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` と合わせて 使うときに一番役に立ちます。

### 注

符号化されたスラッシュを許可することは、復号をすることを 意味しません。`%2F` や (関係するシステムでの) `%5C` は、他の部分が復号された URL の中でもそのままの形式で 残されます。

### 参照

- `AcceptPathInfo`

## AllowOverride ディレクティブ

説明: | `.htaccess` で許可されるディレクティブの種類
構文: | `AllowOverride All|None|directive-type [directive-type] ...`
デフォルト: | `AllowOverride All`
コンテキスト: | ディレクトリ
ステータス: | Core
モジュール: | core

サーバが (`AccessFileName` によって指定された) `.htaccess` ファイルを見つけた時、そのファイルの中で 宣言されたどのディレクティブがより前に定義された設定ディレクティブを 上書きできるかを知る必要があります。

### <Directory> セクションでのみ使用可能

`AllowOverride` は正規表現無しの`<Directory>` セクションでのみ有効で、`<Location>` や `<DirectoryMatch>` や `<Files>` セクションでは無効です。

このディレクティブを `None` に設定すると、.htaccess ファイルは完全に 無視されます。 この場合、サーバはファイルシステムの `.htaccess` ファイルを読むことを 試みさえしません。

このディレクティブが `All` に設定されている時には、 `.htaccess` という コンテキスト を持つ 全てのディレクティブが利用できます。

directive-type には、以下のディレクティブ群の キーワードのどれかを指定します。

AuthConfig
  認証に関するディレクティブの使用を許可する (`AuthDBMGroupFile`, `AuthDBMUserFile`, `AuthGroupFile`, `AuthName`, `AuthType`, `AuthUserFile`, `Require` など)。
FileInfo
  ドキュメントタイプを制御するディレクティブ (`DefaultType`, `ErrorDocument`, `ForceType`, `LanguagePriority`, `SetHandler`, `SetInputFilter`, `SetOutputFilter`, `mod_mime` の Add* と Remove* ディレクティブなど)、 ドキュメントのメタデータを制御するディレクティブ (`Header`, `RequestHeader`, `SetEnvIf`, `SetEnvIfNoCase`, `BrowserMatch`, `CookieExpires`, `CookieDomain`, `CookieStyle`, `CookieTracking`, `CookieName`), `mod_rewrite` のディレクティブ `RewriteEngine`, `RewriteOptions`, `RewriteBase`, `RewriteCond`, `RewriteRule`) と `mod_actions` の `Action` ディレクティブの使用を許可する。
Indexes
  ディレクトリインデックスを制御するためのディレクティブの使用を許可する (`AddDescription`, `AddIcon`, `AddIconByEncoding`, `AddIconByType`, `DefaultIcon`, `DirectoryIndex`, `FancyIndexing`, `HeaderName`, `IndexIgnore`, `IndexOptions`, `ReadmeName` など)。
Limit
  ホストへのアクセス制御を行うためのディレクティブの使用を許可する (`Allow`, `Deny`, `Order`).
Options[=Option,...]
  特定のディレクトリにおける機能を指定するためのディレクティブの使用を許可する (`Options` と `XBitHack`)。 `Options` で設定するオプション を、(空白を含めない) コンマ区切りのリストにして等号の後に続けることで 設定できます。

例:

`AllowOverride AuthConfig Indexes`

上の例では `AuthConfig` と `Indexes` のどちらにも 属さないディレクティブはすべて内部サーバエラーを引き起こします。

### 参照

- `AccessFileName`
- 設定ファイル
- .htaccess ファイル

## AuthName ディレクティブ

説明: | HTTP 認証の認可領域 (訳注: realm)
構文: | `AuthName auth-domain`
コンテキスト: | ディレクトリ, .htaccess
上書き: | AuthConfig
ステータス: | Core
モジュール: | core

このディレクティブはディレクトリに対する認可領域 (訳注: realm) の名前を指定します。 認可領域は、利用者がどのユーザ名とパスワードを送信すればよいのかを クライアントに教えるために利用します。 `AuthName` は一つの引数をとり、 スペースが含まれる場合には、 引用符で括らなければなりません。 このディレクティブは `AuthType` ディレクティブや `Require` ディレクティブと、 `AuthUserFile` や `AuthGroupFile` などのディレクティブと 一緒に利用する必要があります。

例えば:

`AuthName "Top Secret"`

ここで `AuthName` に指定した文字列が、 大部分のブラウザのパスワードダイアログに表示されます。

### 参照

- 認証、承認、アクセス制御

## AuthType ディレクティブ

説明: | ユーザ認証の種類
構文: | `AuthType Basic|Digest`
コンテキスト: | ディレクトリ, .htaccess
上書き: | AuthConfig
ステータス: | Core
モジュール: | core

このディレクティブは対象ディレクトリで利用するユーザー認証の種類を選びます。 使用できる認証方式は `Basic` (`mod_auth_basic` で実装) と `Digest` (`mod_auth_digest` で実装) です。

認証を有効にするには、`AuthName` と `Require` ディレクティブも 使う必要があります。それに加えて認証プロバイダモジュールの `mod_authn_file` 等と、承認モジュール `mod_authz_user` 等もサーバに組み込む必要があります。

### 参照

- 認証、承認、アクセス制御

## CGIMapExtension ディレクティブ

説明: | CGI スクリプトのインタープリタの位置を調べるための手法
構文: | `CGIMapExtension cgi-path .extension`
コンテキスト: | ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core
互換性: | NetWare のみ

このディレクティブは Apache が CGI スクリプトを実行するための インタープリタを探す方法を制御します。 例えば、`CGIMapExtension sys:\foo.nlm .foo` と設定すると `.foo` という拡張子のすべての CGI スクリプトは FOO インタープリタに 渡されます。

## ContentDigest ディレクティブ

説明: | `Content-MD5` HTTP 応答ヘッダの生成を有効にする
構文: | `ContentDigest On|Off`
デフォルト: | `ContentDigest Off`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | Options
ステータス: | Core
モジュール: | core

このディレクティブは、RFC1864 及び RFC2068 において定義されている `Content-MD5` ヘッダーの生成を有効にします。

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

サーバは、MIME タイプ のマッピングでは決定できない ドキュメントの送信を要求されることがあります。

サーバは、ドキュメントのコンテントタイプをクライアントに通知する必要が ありますので、このようにタイプが未知の場合は `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-path 引数には注意してください: その引数は Apache がファイルをアクセスするために使うファイルシステムのパスに そのままマッチする必要があります。ある `<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/dir/.htaccess` の順にそれらのファイル中の FileInfo ディレクティブが適用される。

正規表現は、通常のセクションがすべて適用されるまで 考慮されません。 その後、全ての正規表現が設定ファイルに現れた順で試されます。 例えば、以下のような場合に

`<Directory ~ abc$>
# ... directives here ...
</Directory>`

正規表現のセクションはすべての通常の `<Directory>` と `.htaccess` の適用が終わるまで考慮されません。 その後で、正規表現は `/home/abc/public_html/abc` にマッチし、 対応する `<Directory>` が適用されます。

Apache のデフォルトでは `<Directory />` へのアクセスは `Allow from All` になっていることに注意してください。 これは、URL からマップされたどのファイルでも Apache は送るということです。 これは以下のようにして変更することが推奨されています。

`<Directory />
Order Deny,Allow
Deny from All
</Directory>`

そしてアクセスを可能にしたいディレクトリに対して 個別に設定すればよいでしょう。 このあたりについては、セキュリティに関するコツを 参照してください。

ディレクトリセクションは `httpd.conf` ファイル書きます。 `<Directory>` ディレクティブは入れ子にすることができず、 `<Limit>` や `<LimitExcept>` セクションの中にも 記述できません。

### 参照

- リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法

## <DirectoryMatch> ディレクティブ

説明: | 正規表現にマッチするファイルシステムのディレクトリと サブディレクトリとのみに適用されるディレクティブを囲む
構文: | `<DirectoryMatch regex> ... </DirectoryMatch>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core

`<Directory>` ディレクティブと同様に、`<DirectoryMatch>` と `</DirectoryMatch>` は指定されたディレクトリと そのサブディレクトリにのみ適用されるディレクティブ群を囲います。 しかし、このディレクティブは引数として正規表現をとります。例えば:

`<DirectoryMatch "^/www/(.+/)?[0-9]{3}">`

は `/www/` 以下にある数字 3 文字のディレクトリにマッチします。

### 参照

- 通常の `<Directory>` と正規表現の指定が 適用される順番については `<Directory>`
- リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法

## 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` が返されます。 directory-path が絶対パスでない場合は、 `ServerRoot` からの相対パスとみなされます。

`DocumentRoot` は最後のスラッシュ無しで 指定する必要があります。

### 参照

- URL をファイルシステムの位置に マップする

## EnableMMAP ディレクティブ

説明: | 配送中にファイルを読み込むためにメモリマッピングを 使うかどうか
構文: | `EnableMMAP On|Off`
デフォルト: | `EnableMMAP On`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core

このディレクティブは配送中にファイルの内容を読み込む必要があるときに `httpd` がメモリマッピングを使うかどうかを制御します。 デフォルトでは、 例えば、`mod_include` を使って SSI ファイルを配送 するときのように、ファイルの途中のデータをアクセスする必要があるときには Apache は OS がサポートしていればファイルをメモリにマップします。

このメモリマップは性能の向上を持たらすことがあります。 しかし、環境によっては運用上の問題を防ぐためにメモリマッピングを 使用しないようにした方が良い場合もあります:

- マルチプロセッサシステムの中にはメモリマッピングをすると `httpd` の性能が落ちるものがあります。
- NFS マウントされた `DocumentRoot` では、`httpd` がメモリマップしている間にファイルが削除されたり 短くなったりしたときに起こるセグメンテーションフォールトのために `httpd` がクラッシュする可能性があります。

これらの問題に当てはまるサーバの設定の場合は、以下のようにして ファイルの配送時のメモリマッピングを使用不可にしてください:

`EnableMMAP Off`

NFS マウントされたファイルには、問題のあるファイルにのみ明示的に この機能を使用不可にします:

`<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 を使って ファイルの内容を送ります。

sendfile は read と send を別々に行なうことと、バッファの割り当てを 回避します。しかし、プラットフォームやファイルシステムの中には 運用上の問題を避けるためにこの機能を使用不可にした方が良い場合があります:

- プラットフォームの中にはビルドシステムが検知できなかった、壊れた sendfile のサポートが存在するものがあります。これは特に バイナリが別のマシンでビルドされ、壊れた sendfile のあるマシンに 移動したときに起こります。
- Linux では、sendfile を用いると、 IPv6 使用時に存在する特定ネットワークカードの TCP-checksum オフロードのバグを踏んでしまいます。
- Itanium で動いている Linux で、sendfile は 2GB 以上の ファイルを扱うことができないでしょう。
- ネットワークマウントされた `DocumentRoot` (例えば NFS や SMB) では、カーネルは自身のキャッシュを使ってネットワークからのファイルを 送ることができないことがあります。

これらの問題に当てはまるサーバの設定の場合は、以下のようにして この機能を使用不可にしてください:

`EnableSendfile Off`

NFS や SMB マウントされたファイルには、問題のあるファイルにのみ明示的に この機能を使用不可にします:

`<Directory "/path-to-nfs-files"> EnableSendfile Off </Directory>`

## ErrorDocument ディレクティブ

説明: | エラーが発生したときにサーバがクライアントに送るもの
構文: | `ErrorDocument error-code document`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core
互換性: | Apache 2.0 ではテキストをクウォートする構文が以前のバージョンから 変わっています。

問題やエラーが発生したときの動作として、 Apache には以下の四つのうち一つの動作を設定することができます。

1. Apache 標準の簡単なエラーメッセージを表示
2. 自分で指定したメッセージを表示
3. 問題やエラーの処理をする為に、自サーバ内の URL-path へリダイレクト
4. 問題やエラーの処理をする為に、外部の URL へリダイレクト

最初のものがデフォルトの動作で、2 番目から 4 番目は、 `ErrorDocument`ディレクティブにより、 HTTP のレスポンスコードと、メッセージか URL を指定することで設定します。 Apache が問題もしくはエラーに関する追加情報を提供することがあります。

URL の場合は、スラッシュで始まる (/) ローカルの web-path ( `DocumentRoot` からの相対パス ) か、クライアントが解決できる完全な URL を指定します。 もしくは、ブラウザに表示されるメッセージを指定できます。 例:

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

リモート URL (例えば、頭に `http` と付与した方法) を `ErrorDocument` に指定するとき、 たとえ文書が同じサーバにあろうとも、ドキュメントがどこにあるかを通知するために、 Apache はリダイレクトをクライアントに送出するということに、注意してください。 これにはいろいろと関連して起こる問題があります。 中でも最も重要なのは、クライアントは元々のエラーステータスコードを受け取らず、 代わりにリダイレクトのステータスコードを受け取るということです。 これにより、ステータスコードを使って URL が有効であるかどうかを決定しようとする ウェブロボットやその他クライアントを、混乱させるかもしれません。 さらに、`ErrorDocument 401` にリモートの URL を指定すると、 クライアントは 401 というステータスコードを受け取らないため、 パスワードをユーザーに入力要求しなければならないことがわかりません。 従って、`ErrorDocument 401` というディレクティブを使う場合は、 必ずローカルな文書を参照しなければなりません。

Microsoft Internet Explorer (MSIE) はデフォルトではサーバが生成したエラーメッセージが 「小さすぎる」ときには無視をして自分自身の「やさしい」エラーメッセージで 置換します。サイズのしきい値はエラーの種類によって異なりますが、 一般的にはエラーの文書を 512 バイトよりも大きくすると、MSIE は サーバが生成したエラーを隠さずに表示します。詳しい情報は Microsoft Knowledge Base の記事 Q294807 にあります。

ほとんどのエラーメッセージを上書きすることができますが、特定の状況下では `ErrorDocument` の設定にかかわらず 内蔵のメッセージが使われます。 特に、不正な形式のリクエストが検出された場合、通常のリクエスト処理は 即座に中止され、内蔵のエラーメッセージが返されます。 この処置は不正なリクエストによって引き起こされる、セキュリティ問題から 守るために必要な措置です。

2.0 より前のバージョンでは、対になっていない二重引用符を 先頭に付けることによりメッセージであることを指定していました。

### 参照

- カスタマイズ可能な エラー応答のドキュメンテーション

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

file-path がパイプ (|) から始まる場合は、 エラーログを処理するために実行されるコマンドが 指定されていると解釈されます。

### 例

`ErrorLog "|/usr/local/bin/httpd_errors"`

ファイル名の変わりに `syslog` と指定することによって、 システムがサポートしていれば syslogd(8) を利用したロギングが有効になります。 デフォルトでは、`local7` ファシリティとなりますが、 `syslog:facility` といった形で記述することにより、 通常 syslog(1) のドキュメントで説明されているファシリティの一つを使うように することができます。

### 例

`ErrorLog syslog:user`

セキュリティ: ログファイルを格納するディレクトリが、サーバを起動したユーザ以外の ユーザによって書き込める場合にセキュリティが破られる可能性があることに 関する詳細は セキュリティに関するコツ を 参照してください。

### 注

Unix 以外のプラットフォームでファイルのパスを入力するときは、 プラットフォームがバックスラッシュの使用を許していたとしても、 確実にスラッシュのみが使用されるように注意してください。一般的には、 設定ファイル全般でスラッシュのみを使う方が良いでしょう。

### 参照

- `LogLevel`
- Apache ログファイル

## FileETag ディレクティブ

説明: | ETag HTTP 応答ヘッダを作成するために使用される ファイルの属性
構文: | `FileETag component ...`
デフォルト: | `FileETag INode MTime Size`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core

`FileETag` ディレクティブは ドキュメントがファイルに基づいたものであるときに、 `ETag` (エンティティタグ) 応答ヘッダフィールドを作成するときに使用する ファイルの属性を設定します。 (`ETag` の値はネットワークの帯域を節約するための キャッシュの管理で使われます。) Apache 1.3.22 以前では、`ETag` の値は 常にファイルの inode, サイズ、最終修正時刻 (mtime) から作成 されていました。`FileETag` ディレクティブにより、これらのどれを使うかを 選ぶことができます。認識されるキーワードは:

INode
  ファイルの inode 番号を計算に使います
MTime
  ファイルの最終修正時刻を使います
Size
  ファイルの中身のバイト数を使います
All
  使用可能なすべてのフィールドを使います。 これは

  `FileETag INode MTime Size`

  と等価です。
None
  ドキュメントがファイルに基づいたものでも、`ETag` フィールドを 応答に付加しません

`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>` セクション内に ネストさせることができ、 ファイルシステムの一部にのみ限定して適用させることができます。

filename 引数は、ファイル名かワイルドカード文字列 で、ワイルドカードでは `?` は一つの文字、`*` は任意の文字列にマッチします。 `~` という文字を付加することで正規表現を使うこともできます。 例えば、

`<Files ~ "\.(gif|jpe?g|png)$">`

とすることにより、一般的なインターネットの画像フォーマットにマッチします。 ただし、 `<FilesMatch>` を使う方が 推奨されています。

ちなみに、`<Directory>` と `<Location>` セクションとは異なり、 `<Files>` は `.htaccess` ファイル内で利用することができます。 これにより、ユーザがファイル毎にアクセスの制御を行なうことができるように なっています。

### 参照

- リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法

## <FilesMatch> ディレクティブ

説明: | 正規表現にマッチするファイル名に適用される ディレクティブを囲む
構文: | `<FilesMatch regex> ... </FilesMatch>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core

`<FilesMatch>` ディレクティブは、 `<Files>` ディレクティブ同様にその中にあるディレクティブの適用範囲をファイル名で制限します。ただし、 このディレクティブには正規表現を指定します。 例えば:

`<FilesMatch "\.(gif|jpe?g|png)$">`

は一般的なインターネットの画像形式にマッチします。

### 参照

- リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法

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

このディレクティブは、ホスト名をログ収集できるように DNS ルックアップを有効にします (さらに、CGI/SSI に `REMOTE_HOST` 変数として渡します)。 `Double`を指定した場合、2 重の逆引きを行ないます。 つまり、逆引きの後に、その結果に対して正引きを行ないます。正引きの 結果の IP アドレスの中にオリジナルのアドレスと一致するものがなければ なりません。("tcpwrappers" の用語では `PARANOID` と呼ばれています。)

`mod_authz_host` でホスト名によるアクセス 制御を行なう場合には、 設定の如何によらず 2 重の逆引きが実行されます。 これは、セキュリティを保つために必要です。 `HostnameLookups Double` を設定しない限り、 他の部分はこの 2 重逆引きの結果を使うことはできません。 例えば、`HostnameLookups On` と設定してある状態で、 ホスト名によるアクセス制限を行なったオブジェクトへの リクエストを受けたとすると、2 重の逆引きが成功するか否かによらず、 `REMOTE_HOST` には通常の逆引き結果が渡されます。

ディレクティブのデフォルトは 本当に逆引きを必要としているわけではないサイトの ネットワークトラフィックを低減させるために、`Off` になっています。 ルックアップによる余計な遅延がなくなるため、 エンドユーザにとっても良いでしょう。 DNS のルックアップには、かなりの時間が必要となる場合が多く、 負荷の高いサイトではこのディレクティブは `Off` にすべきです。 なお、/support ディレクトリに含まれ、デフォルトでは インストールディレクトリの `bin` サブディレクトリに インストールされる `logresolve` ユーティリティにより、 Apache の動作とは別に、ログに残されている IP アドレスからホスト名を ルックアップすることが可能です。

## <IfDefine> ディレクティブ

説明: | 起動時にテストが真であるときのみに処理されるディレクティブを 囲む
構文: | `<IfDefine [!]parameter-name> ... </IfDefine>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core

`<IfDefine test>...</IfDefine>` セクションは、 ディレクティブを条件付きで指定するために利用します。 `<IfDefine>` セクションに 含まれるディレクティブは、testが 定義されているときのみ処理されます。 もし test が定義されていなければ、 開始と終了の指定の間のディレクティブは無視されます。

`<IfDefine>` セクションディレクティブに 指定する test は、 次の二つの形式のうちの一つをとります:

- parameter-name
- `!`parameter-name

前者の場合には、parameter-name と名付けられたパラメータが 定義されていれば開始と終了の間のディレクティブが処理されます。 後者の場合は逆で、parameter-name が指定されていない 場合に処理されます。

parameter-name 引数は、サーバを起動する際に `httpd` のコマンドラインに `-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-file|module-identifier> ... </IfModule>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core
互換性: | モジュール識別子はバージョン 2.1 以降で使用可能。

`<IfModule test>...</IfModule>` セクションは、モジュールが存在するときに処理されるディレクティブを 指定するために利用します。 `<IfModule>` セクションに 含まれるディレクティブは、test で指定するモジュールが組み込まれているときのみ処理されます。 もし test が組み込まれていなければ、開始と終了の間のディレクティブ は無視されます。

`<IfModule>` セクションディレクティブに 指定する test は、 次の二つの形式のうちの一つをとります。

- module
- !module

前者の場合は、module と名付けられたモジュールが Apache に組み込まれていれば (コンパイル済みのものと、`LoadModule` を利用して 動的に読み込んだものの両方)、 開始と終了の間のディレクティブが処理されます。 後者の場合は逆で、module が組み込まれていない 場合に処理されます。

module 引数は、モジュール識別子か コンパイルをした時のモジュールのファイル名です。 例えば、`rewrite_module` は識別子で `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`

### 参照

- `apachectl`

## KeepAlive ディレクティブ

説明: | HTTP の持続的な接続を有効にする
構文: | `KeepAlive On|Off`
デフォルト: | `KeepAlive On`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core

HTTP/1.0 の Keep-Alive 拡張と HTTP/1.1 の持続的接続の機能は、 複数のリクエストが同じ TCP の接続で送られる、長時間持続する HTTP セッションを提供します。たくさんの画像が 含まれる HTML ドキュメントでは場合によっては遅延時間が 50% 短縮される結果も でています。Keep-Alive 接続を有効にするには `KeepAlive On` と設定します。

HTTP/1.0 に対応したクライアントの際には、 クライアントより特に要求があった場合のみ Keep-Alive 接続となります。 さらに、HTTP/1.0 クライアントでは、コンテンツの容量が先に (訳注: 要求に対して応答を返す前に) わかる場合のみ Keep-Alive 接続を利用できます。 これは、CGI の出力や SSI のページ、 サーバが生成したディレクトリのリストのような動的コンテンツを HTTP/1.0 クライアントに送る場合には Keep-Alive 接続を使えないことを意味します。 HTTP/1.1 に対応したクライアントの際には、 特に指定されない限りはデフォルトとして持続的な接続が行なわれます。 クライアントが要求すれば、コンテンツの容量を判別できないものを 持続的な接続を通して送るために、チャンクエンコーディングが用いられます。

### 参照

- `MaxKeepAliveRequests`

## KeepAliveTimeout ディレクティブ

説明: | 持続的な接続で次のリクエストが来るまでサーバが待つ時間
構文: | `KeepAliveTimeout seconds`
デフォルト: | `KeepAliveTimeout 5`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core

接続を閉じる前に、Apache が次のリクエストを何秒待つかを指定します。 リクエストを受け付けた後は、`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` は内部リダイレクトや サブリクエストが無限ループに陥ったときのサーバクラッシュを防ぎます。 普通、そのようなループは設定に失敗したときに発生します。

このディレクティブは、リクエスト毎に評価される、二つの違う限界値を 設定します。最初の number は、起こり得る 内部リクエストの最大値を設定します。二つめの number は サブリクエストが入れ子にできる深さを設定します。number を 一つだけ指定したときは、両方の限界値にその値が設定されます。

### 例

`LimitInternalRecursion 5`

## LimitRequestBody ディレクティブ

説明: | クライアントから送られる HTTP リクエストのボディの 総量を制限する
構文: | `LimitRequestBody bytes`
デフォルト: | `LimitRequestBody 0`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core

このディレクティブは、リクエストボディに許されるバイト数、bytes を 0 (無制限を意味します) から 2147483647 (2GB) までの数値で指定します。

`LimitRequestBody` ディレクティブは、 ディレクティブが書かれたコンテキスト (サーバ全体、ディレクトリ、ファイル、ロケーション) 内で 許容する HTTP リクエストメッセージボディのサイズに制限をかけることができます。 クライアントのリクエストがその制限値を越えていれば、 サーバはリクエストを処理せずにエラーを返します。 普通のリクエストメッセージボディのサイズは、リソースの種類や 許可されているメソッドによって大きく変わります。 CGI スクリプトは、よく情報を受信するために メッセージボディを使います。 `PUT` メソッドの実装は、このディレクティブの値として 少なくともあるリソースに対してサーバが受け付けようとする 表現の大きさほどの値を必要とします。

このディレクティブは、 管理者にクライアントからの異常なリクエストを制御できるようにし、 何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。

ある場所へのファイルアップロードを許可する場合に、 アップロードできるファイルのサイズを 100K に制限したければ、 以下のように指定します:

`LimitRequestBody 102400`

## LimitRequestFields ディレクティブ

説明: | クライアントからの HTTP リクエストのヘッダフィールドの数を 制限する
構文: | `LimitRequestFields number`
デフォルト: | `LimitRequestFields 100`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core

number には、0 (無制限を意味します) から 32767 までの整数を指定します。 デフォルト値は、定数 `DEFAULT_LIMIT_REQUEST_FIELDS` によりコンパイル時に定義されます (配布時には 100 と指定されています)。

`LimitRequestBody` ディレクティブは、 サーバ管理者が HTTP リクエスト中において許可するリクエストヘッダフィールド数を 指定します。 サーバはこの値には通常のクライアントからのリクエストに含まれるであろう フィールドの数より大きな値が必要とします。 クライアントにより使われた要求ヘッダーフィールドの数が 20 を超えることはほとんどありませんが、 これは種々のクライアントの実装によって変わり、 詳細なコンテントネゴシエーションをするためのブラウザの設定までにも 影響されることがあります。 オプションの HTTP 拡張はリクエストヘッダフィールドを使って表される場合が 多くあります。

このディレクティブは、 管理者にクライアントからの異常なリクエストを制御できるようにし、 何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。 リクエストのフィールドが多過ぎることを意味するエラー応答が 普通のクライアントに返されるような時はこの値を増やしてください。

例:

`LimitRequestFields 50`

## LimitRequestFieldSize ディレクティブ

説明: | クライアントからの HTTP リクエストのヘッダの サイズを制限する
構文: | `LimitRequestFieldsize bytes`
デフォルト: | `LimitRequestFieldsize 8190`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core

このディレクティブは、HTTP リクエストヘッダ一つで受付ける バイト数 bytes を指定します。

`LimitRequestFieldSize` ディレクティブは、 HTTP リクエストヘッダで許容されるサイズを増減させることができます。 サーバは、このディレクティブの値として、 一般的なクライアントからリクエストが送られた際に、そのリクエストに 付属しているどのヘッダフィールドについても、 十分足りる大きさになっていなければなりません。 一般的なリクエストヘッダのサイズといっても、その大きさは個々の クライアントの実装によって大きく異なり、 詳細なコンテントネゴシエーションをサポートするかどうかの、 ブラウザの設定にも影響されたりします。 SPNEGO 認証ヘッダでは 12392 バイトにまで及ぶことすらあります。

このディレクティブは、 管理者にクライアントからの異常なリクエストを制御できるようにし、 何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。

例:

`LimitRequestFieldSize 4094`

通常はデフォルトから変更する必要はありません。

## LimitRequestLine ディレクティブ

説明: | クライアントからの HTTP リクエスト行のサイズを制限する
構文: | `LimitRequestLine bytes`
デフォルト: | `LimitRequestLine 8190`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core

このディレクティブは、HTTP リクエスト行内で許容されるバイト数 bytes を指定します。

`LimitRequestLine` ディレクティブにより、 クライアントからの HTTP リクエスト行の許容サイズを増減できます。 リクエスト行は、HTTPメソッド、URI、プロトコルバージョンから成っており、 `LimitRequestLine` はサーバへのリクエストに対して 許容するリクエスト URI の長さを制限することになります。 サーバは、`GET` リクエストのクエリ部分も含めて、リソースの名前が入るに足る 大きさを必要とします。

このディレクティブは、 管理者にクライアントからの異常なリクエストを制御できるようにし、 何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。

例:

`LimitRequestLine 4094`

通常はデフォルトから変更する必要はありません。

## LimitXMLRequestBody ディレクティブ

説明: | XML 形式のリクエストのボディのサイズを制限する
構文: | `LimitXMLRequestBody bytes`
デフォルト: | `LimitXMLRequestBody 1000000`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core

XML 形式のリクエストのボディの最大値を (バイト単位で) 制限します。 値に `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 />` で、これはサーバ全体に対して 設定を適用する簡単な方法です。

全ての (プロキシ以外の) リクエストに対し、 URL は `/path/` という、 接頭辞 `http://servername` を含まない形でマッチします。 プロキシリクエストの場合には、`scheme://servername/path` という接頭辞を含む形でマッチし、接頭辞を含めて指定する必要があります。

URL にはワイルドカードを利用することができます。 `?` は任意の一文字、`*` は任意の文字列にマッチします。

`~` という文字を追加することで、正規表現を 利用することもできます。 例えば:

`<Location ~ "/(extra|special)/data">`

は URL に `/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>`

### / (スラッシュ) に関する注

スラッシュ文字は、URL 内に現れる場所に応じて変化する 特別な意味を持っています。 ファイルシステムにおいて利用する場合には複数のスラッシュでも一つの スラッシュとして扱われることが多いですが、 (すなわち、`/home///foo` は `/home/foo` と同じいったように) URL においては必ずしもそうなるわけではありません。 `<LocationMatch>` ディレクティブや正規表現を利用した `<Location>` ディレクティブで、 複数のスラッシュにマッチさせたいときには、、明示的に記述する 必要があります。

例えば、`<LocationMatch ^/abc>` は、 `/abc` というリクエスト URL にマッチしますが、 `//abc` というリクエスト URL にはマッチしません。 (正規表現でない) `<Location>` ディレクティブは、 proxy リクエストに対して利用する際には同様の振る舞いをしますが、 (正規表現でない) `<Location>` を proxy でないリクエストに対して利用する際には、 一つのスラッシュで複数のスラッシュにマッチします。 例えば、`<Location /abc/def>` と指定し、 `/abc//def` というリクエストがあれば、 マッチすることになります。

### 参照

- リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法

## <LocationMatch> ディレクティブ

説明: | 囲んだディレクティブを正規表現にマッチする URL のみに 適用
構文: | `<LocationMatch regex> ... </LocationMatch>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core

`<LocationMatch>` ディレクティブは、 `<Location>` と同じ様に URL により中に書かれたディレクティブの適用範囲を制限します。 但し、引数は普通の文字列ではなく、正規表現となります。 例えば、

`<LocationMatch "/(extra|special)/data">`

は URL に `/extra/data` か `/special/data` という文字列が含まれている場合にマッチします。

### 参照

- リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法

## 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` ディレクティブは、 名前ベースのバーチャルホストの設定を行ないたい場合に 必要となるものです。

addr にはホスト名を指定できますが、 常に IP アドレスを指定するのが推奨されます。 例えば、

`NameVirtualHost 111.22.33.44`

`NameVirtualHost` ディレクティブは、 名前ベースのバーチャルホストを 利用してリクエストを受け付ける IP アドレスを指定します。 これは、普通は名前ベースのバーチャルホストアドレスです。 ただし、ファイアーウォールや他のプロキシがリクエストを受け付け、 違う IP アドレスのサーバにフォワードするという場合は、 リクエストを提供したいマシン上の物理インターフェースの IP アドレスを指定する必要があります。 複数のアドレスで複数の名前ベースのバーチャルホストを指定する場合は 各アドレスに対してディレクティブを書いてください。

### 中

「主サーバ」や、どの `_default_` サーバも、 `NameVirtualHost` で指定した IP アドレスへのリクエスト を処理することはありません (なぜか `NameVirtualHost` を 指定したけどそのアドレスに `VirtualHost` を定義しなかった場合を除く)。

名前ベースのバーチャルホストにポート番号を指定することも可能です。 例えば

`NameVirtualHost 111.22.33.44:8080`

IPV6 のアドレスは次の例のように角括弧で囲む必要があります:

`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` ディレクティブは、特定のディレクトリに対して どの機能が使用可能かを制御します。

option を `None`に指定すると、 特別な機能は全て無効になります。 また、以下の示す 1 個以上のものを指定できます。

`All`
  `MultiViews` を除いた全ての機能が有効となります。 これがデフォルトです。
`ExecCGI`
  `mod_cgi` による CGI スクリプトの実行を許可します。
`FollowSymLinks`
  サーバが、このディレクトリ内でシンボリックリンクをたどれるようにします。

  サーバがシンボリックリンクをたどる場合でも、 `<Directory>` セクションに マッチさせるための パス名は変更されません。

  `<Location>` 内に このオプションを指定しても無視されることに 注意してください。

`Includes`
  `mod_include` が提供する SSI を有効にします。
`IncludesNOEXEC`
  SSI は有効になりますが、`#exec` コマンド と `#exec CGI` は無効になります。 ただし、`#include virtual` により、`ScriptAlias` されたディレクトリで CGI を実行することは可能です。
`Indexes`
  もし、URL がディレクトリにマップするリクエストであって、 且つ `DirectoryIndex` で指定したファイル (例えば、`index.html`) が ディレクトリ内に無ければ、`mod_autoindex` が ディレクトリ内の一覧を整形して返します。
`MultiViews`
  `mod_negotiation` による コンテントネゴシエーション された "MultiViews" を許可します。
`SymLinksIfOwnerMatch`
  シンボリック先のファイルまたはディレクトリが、 シンボリックリンクの所有ユーザ ID と同じ場合にのみシンボリックリンクを たどれるようにします。

  ### 注

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

このディレクティブは、認証されたユーザがリソースに対して アクセスできるかを制御します。 制限条件は承認モジュールで処理されます。 `mod_authz_user` と `mod_authz_groupfile` で提供されている構文には、次のようなものもあります:

`Require user userid [userid] ...`
  指定されたユーザのみ、ディレクトリへのアクセスを許可します。
`Require group group-name [group-name] ...`
  指定されたグループに属するユーザのみ、ディレクトリへのアクセスを許可します。
`Require valid-user`
  全ての認証されたユーザに、ディレクトリへのアクセスを許可します。

require オプションを実装している他の承認モジュールには、 `mod_authnz_ldap`, `mod_authz_dbm`, `mod_authz_owner` といったものがあります。

`Require` は、正しく動作するためには `AuthName` 及び `AuthType` ディレクティブや、 (ユーザとグループを指定するために) `AuthUserFile` 及び `AuthGroupFile` といったディレクティブと共に 指定する必要があります。 例えば:

`AuthType Basic
AuthName "Restricted Resource"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin`

このようにして適用されたアクセス制御は、全てのメソッドに 対して行なわれます。 通常は、これが望ましい動作です。 もし、特定のメソッドに対してのみアクセスの制御を適用し、 他のメソッドは制限しない場合には、`<Limit>` セクション内に `Require` を 指定してください。

`Require` を `Allow` ディレクティブや `Deny` ディレクティブと 組み合わせて使った場合、これらの制約の相互作用は `Satisfy` ディレクティブで制御されます。

### サブディレクトリで制御を解除する方法

`Satisfy` ディレクティブ で、保護されたディレクトリのサブディレクトリ内でアクセス制御を 無効にする例は、下のようになります。 `mod_authz_host` によるアクセス制御も無効化されるので、 このテクニックは注意してご活用ください。

`<Directory /path/to/protected/>
Require user david
</Directory>
<Directory /path/to/protected/unprotected>
# All access controls and authentication are disabled
# in this directory
Satisfy Any
Allow from all
</Directory>
`

### 参照

- 認証・承認・アクセス制御
- `Satisfy`
- `mod_authz_host`

## RLimitCPU ディレクティブ

説明: | Apache の子プロセスから起動されたプロセスの CPU 消費量を 制限する
構文: | `RLimitCPU seconds|max [seconds|max]`
デフォルト: | `未設定。オペレーティングシステムのデフォルトを使用`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core

一つか二つのパラメータをとります。 最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、 2 番目のパラメータは最大のリソースリミットを設定します。 パラメータには数字か、オペレーティングシステムの最大となる `max` のどちらかを指定することができます。 最大のリソースリミットを上げるためには、サーバを `root` で実行するか起動されなければいけません。

ちなみに、この設定は Apache の子プロセス自体ではなく、 リクエストを受け付けた Apache の子プロセスから fork されたプロセスに 適用されます。 これには CGI や SSI から実行されたコマンドが含まれますが、Apache の 親プロセスから fork されたログのパイププロセスなどには適用されません。

CPU リソースのリミットはプロセスあたりの秒数で表わされます。

### 参照

- `RLimitMEM`
- `RLimitNPROC`

## RLimitMEM ディレクティブ

説明: | Apache の子プロセスから起動されたプロセスのメモリ消費量を 制限する
構文: | `RLimitMEM bytes|max [bytes|max]`
デフォルト: | `未設定。オペレーティングシステムのデフォルトを使用`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core

一つか二つのパラメータをとります。 最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、 2 番目のパラメータは最大のリソースリミットを設定します。 パラメータには数字か、オペレーティングシステムの最大となる `max` のどちらかを指定することができます。 最大のリソースリミットを上げるためには、サーバを `root` で実行するか起動されなければいけません。

この設定は Apache の子プロセス自体ではなく、 リクエストを受け付けた Apache の子プロセスから fork されたプロセスに 適用されます。 これには CGI や SSI から実行されたコマンドが含まれますが、Apache の 親プロセスから fork されたログのパイププロセスなどには適用されません。

メモリリソースのリミットはプロセスあたりのバイト数で表わされます。

### 参照

- `RLimitCPU`
- `RLimitNPROC`

## RLimitNPROC ディレクティブ

説明: | Apache の子プロセスから起動されたプロセスが起動するプロセスの 数を制限する
構文: | `RLimitNPROC number|max [number|max]`
デフォルト: | `未設定。オペレーティングシステムのデフォルトを使用`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core

一つか二つのパラメータをとります。 最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、 2 番目のパラメータは最大のリソースリミットを設定します。 パラメータには数字か、オペレーティングシステムの最大となる `max` のどちらかを指定することができます。 最大のリソースリミットを上げるためには、サーバを `root` で実行するか起動されなければいけません。

この設定は Apache の子プロセス自体ではなく、 リクエストを受け付けた Apache の子プロセスから fork されたプロセスに 適用されます。 これには CGI や SSI から実行されたコマンドが含まれますが、Apache の 親プロセスから fork されたログのパイププロセスなどには適用されません。

プロセスの制限は、ユーザあたりのプロセス数で制御されます。

### 注

CGI プロセスがウェブサーバのユーザ ID 以外で実行されるので 無ければ、 このディレクティブは、サーバ自身が生成できるプロセスの数を制限することになります。 そのような状況になっているかどうかは、`error_log` 中の `cannot fork` というメッセージにより 確認することができます。

### 参照

- `RLimitMEM`
- `RLimitCPU`

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

バージョン 2.0.51 からは `<Limit>` セクションと `<LimitExcept>` セクションを使用することで `Satisfy` ディレクティブが 適用されるメソッドを制限することが できるようになりました。

### 参照

- `Allow`
- `Require`

## ScriptInterpreterSource ディレクティブ

説明: | CGI スクリプトのインタープリタの位置を調べるための手法
構文: | `ScriptInterpreterSource Registry|Registry-Strict|Script`
デフォルト: | `ScriptInterpreterSource Script`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core
互換性: | Win32 のみ。 オプション `Registry-Strict` は Apache 2.0 以降で使用可能

このディレクティブは、Apache で CGI スクリプトを 実行する場合に利用するインタープリタを、 どのように探し出すかについて制御するために使用します。 デフォルトの設定は `Script` です。これはスクリプトの shebang 行 (最初の行で `#!` から始まるもの) に指されているインタープリタを使用します。Win32 ではその行は 以下の様になります。

`#!C:/Perl/bin/perl.exe`

もしくは、`perl` が `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` ファイルへのリクエストはサーバの バックグラウンドでブラウザを実行することになります。これは、一分内くらいで システムをクラッシュさるための良い方法です。

Apache 2.0 から導入されたオプション `Registry-Strict` は `Registry` と同じことを行ないますが、サブキー `Shell\ExecCGI\Command` のみを使います。 `ExecCGI` キーは普通に使われるキーではありません。Windows レジストリに手動で設定する必要がありますので、システムでの偶発的なプログラムの 実行を防ぐことができます。

## ServerAdmin ディレクティブ

説明: | サーバがクライアントに送るエラーメッセージに含める電子メールの アドレス
構文: | `ServerAdmin email-address|URL`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core

`ServerAdmin` は、クライアントに返すさまざまな エラーメッセージ中に記述する、 問合せアドレスを設定します。与えられた引数を `httpd` が URL と認識しない場合は、email-address だと解釈して、 ハイパーリンクのターゲットに `mailto:` を付けます。 実際には、ここには電子メールアドレスを使うことが推奨されています。 多くの CGI スクリプトはそうなっていることを仮定しています。 URL を使う場合は、あなたの管理下にある別サーバを指すようにしてください。 そうでないと、エラーが起こったときに連絡をすることができなくなって しまいます。

その際、これのために専用のアドレスを設定するのが良いでしょう。 例えば、

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

### 参照

- Apache バーチャルホスト説明書

## 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: ヘッダに現れる必要があるのかを指定します。

自己参照 URL (例えば `mod_dir` モジュールによるものなど) が指定されたポートを使うか、クライアントのリクエストのポート番号を使うかを 決定する設定は `UseCanonicalName` ディレクティブと `UseCanonicalPhysicalPort` ディレクティブを参照してください。

### 参照

- DNS と Apache に関する話
- Apache バーチャルホスト説明書
- `UseCanonicalName`
- `UseCanonicalPhysicalPort`
- `NameVirtualHost`
- `ServerAlias`

## ServerPath ディレクティブ

説明: | 非互換のブラウザが名前ベースのバーチャルホストにアクセスしたときの ための互換用 URL パス名
構文: | `ServerPath URL-path`
コンテキスト: | バーチャルホスト
ステータス: | Core
モジュール: | core

`ServerPath` ディレクティブは、ネームベースのバーチャルホストにおいて利用する 互換用 URL パス名を設定します。

### 参照

- Apache バーチャルホスト説明書

## ServerRoot ディレクティブ

説明: | インストールされたサーバのベースディレクトリ
構文: | `ServerRoot directory-path`
デフォルト: | `ServerRoot /usr/local/apache`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core

`ServerRoot` ディレクティブは、 サーバが存在するディレクトリを設定します。 通常、`conf/` や `logs/` といったサブディレクトリが 存在します。 また、他の設定ディレクティブ (例えば `Include` や `LoadModule` など) における相対パスは、 このディレクトリからの相対位置となります。

### 例

`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:" が追加されます。

バージョン 2.0.44 以降ではこのディレクティブは `ServerSignature` ディレクティブにより表示される情報も制御します。

### 参照

- `ServerTokens`

## ServerTokens ディレクティブ

説明: | `Server` HTTP 応答ヘッダを設定する
構文: | `ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full`
デフォルト: | `ServerTokens Full`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core

このディレクティブは、クライアントに送り返す `Server` 応答ヘッダ内に、サーバの一般的な OS 種別や、 コンパイルされて組み込まれているモジュールの情報を 含めるかどうかを指定します。

`ServerTokens Prod[uctOnly]`
  サーバは (例えば): `Server: Apache` といったように送ります。
`ServerTokens Major`
  Server sends (e.g.): `Server: Apache/2`
`ServerTokens Minor`
  Server sends (e.g.): `Server: Apache/2.0`
`ServerTokens Min[imal]`
  サーバは (例えば): `Server: Apache/2.0.41` といったように送ります。
`ServerTokens OS`
  サーバは (例えば): `Server: Apache/2.0.41 (Unix)` といったように送ります。
`ServerTokens Full` (もしくは未指定)
  サーバは (例えば): `Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2` といったように送ります。

この設定はサーバ全体に適用され、バーチャルホスト上で有効にしたり 無効にしたりはできません。

バージョン 2.0.44 以降ではこのディレクティブは `ServerSignature` ディレクティブにより表示される情報も制御します。

### 参照

- `ServerSignature`

## SetHandler ディレクティブ

説明: | マッチするファイルがハンドラで処理されるようにする
構文: | `SetHandler handler-name|None`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core
互換性: | Apache 2.0 で core に移動

`.htaccess` や `<Directory>` セクション、`<Location>` セクションに書かれた場合、 このディレクティブはそこにあるすべてのファイルが handler-name で指定されたハンドラで扱われることを強制します。例えば、拡張子に関わらず、 ディレクトリ全体がイメージマップファイルとして解析して欲しい場合には、 以下をそのディレクトリの `.htaccess` ファイルに記述します:

`SetHandler imap-file`

別の例: URL `http://servername/status` が指定されたときにサーバが状態報告をするようにしたいときは、以下を `httpd.conf` に記述します:

`<Location /status>
SetHandler server-status
</Location>`

`None` という値を設定することで、 前の方の `SetHandler` で定義された設定を無効にすることが できます。

注意:SetHandler はデフォルトのハンドラをオーバーライド しますので、通常の挙動、たとえば、スラッシュ (/) で終わる URL が リクエストされたときにディレクトリやインデックスファイルを返すよう取り扱う挙動は、 行われなくなります。

### 参照

- `AddHandler`

## 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` ディレクティブは、現在のところ 以下の三つの待ち時間についての定義を行います:

1. GET リクエストを受け取るのにかかる総時間
2. POST や PUTリクエストにおいて、次の TCP パケットが届くまでの待ち時間
3. レスポンスを返す際、TCP の ACK が帰ってくるまでの時間

将来には別々の設定をすることが可能にできるよう考慮中です。 Apache 1.2 以前はタイマーは 1200 がデフォルトでしたが、 300 に下げられました。300 でもほとんどの場合は十分すぎる値です。 コード中の変な場所にまだパケットを送る際にタイマをリセットしない 場所があるかもしれないので、デフォルトをより小さい値にはしていません。

## TraceEnable ディレクティブ

説明: | `TRACE` メソッドのリクエストに対する応答方法を決める
構文: | `TraceEnable [on|off|extended]`
デフォルト: | `TraceEnable on`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core
互換性: | Apache 1.3.34, 2.0.55 以降

コアサーバと `mod_proxy` 両方の `TRACE` の挙動をオーバーライドします。デフォルトの `TraceEnable on` は、リクエストボディを受け入れないような、RFC2616 に準拠した `TRACE` リクエストを受け付けます。 `TraceEnale off` と設定すると、コアサーバと `mod_proxy` は `405` (メソッド不許可) エラーをクライアントに返します。

最後に、テストや調査目的などの限定用途として、使用に準拠しない `TraceEnable extended` を使って、リクエストボディを 受け付けるように挙動を変更できます。(オリジンサーバとしての) コアサーバでは、リクエストボディのサイズは 64k ( `Transfer-Encoding: chunked` が使われている場合は chunk ヘッダ用に +8k) に制限されます。 コアサーバは、フルヘッダと全ての chunk ヘッダをレスポンスの ボディとして返却します。 proxy サーバとしては、リクエストボディのサイズは 64k に制限されません。

## UseCanonicalName ディレクティブ

説明: | サーバが自分自身の名前とポートを決定する方法を設定する
構文: | `UseCanonicalName On|Off|Dns`
デフォルト: | `UseCanonicalName Off`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス: | Core
モジュール: | core

多くの状況で Apache は自己参照 URL、すなわち 同じサーバを指す URL、を作成する必要があります。 `UseCanonicalName On` の場合は、`ServerName` ディレクティブで指定されている ホスト名とポート番号を使って、その正規名 (自己参照の名前) を生成します。 この名前は、すべての自己参照 URL で使われますし、CGI の `SERVER_NAME` と `SERVER_PORT` でも使われます。

`UseCanonicalName Off` の場合、 クライアントがホスト名とポートを指定したときには、 それらを元に自己参照 URL を作成します (指定がなかったときは 上の定義と同様にして正規名を解決します)。 これらの値は名前ベースの バーチャルホストを実装で使われているのと同じ値で、 同じクライアントで取得できる値になっています。 CGI 変数 `SERVER_NAME` と `SERVER_PORT` もクライアントから与えられた値から作成されます。

このような挙動が便利な例は、イントラネットのサーバで `www` のような短い名前でユーザがマシンに接続するときです。 ユーザの入力で短いホスト名が使われていて、URL が最後のスラッシュ無しの ディレクトリになっている `http://www/splat` のようなとき、 Apache はリクエストを `http://www.domain.com/splat/` へリダイレクトします。 認証をするように設定していると、この場合 ユーザは 2 回認証をしなければならなくなります (`www` に 対して 1 回、`www.domain.com` に対してもう 1 回 -- 詳細は この話題の FAQ を参照してください)。 しかし `UseCanonicalName` が `Off` になっていると、 Apache は `http://www/splat/` にリダイレクトします。

三つ目のオプション `UseCanonicalName DNS` は、 大規模な IP ベースのバーチャルホスティングで、 `Host:` ヘッダを提供しない古いクライアントを サポートする場合を想定しています。 このオプションでは Apache は、クライアントが接続した IP アドレスに対して DNS の逆引きを行なって、自己参照 URL を作成します。

### 警告

CGI が `SERVER_NAME` に関して何らかの前提条件を 仮定しているときには、このオプションの設定によっては動作しなく なるかもしれません。クライアントは実質的にはホスト名として 何でも望みの値を指定することができます。CGI が `SERVER_NAME` を使って自己参照 URL を作成することしかしない 場合は、どの設定を行なっても大丈夫なはずです。

### 参照

- `UseCanonicalPhysicalPort`
- `ServerName`
- `Listen`

## UseCanonicalPhysicalPort ディレクティブ

説明: | サーバの名前とポートの解決方法を設定する
構文: | `UseCanonicalPhysicalPort On|Off`
デフォルト: | `UseCanonicalPhysicalPort Off`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス: | Core
モジュール: | core

Apache は様々な状況で 自己参照 URL つまりサーバが自分自身を指し示す URL を生成する必要があります。 `UseCanonicalName` ディレクティブの 設定によってサーバの別名を構成するようになりますが、 その際の別名に使うポートは `UseCanonicalPhysicalPort On` という設定があれば、 実際のポート番号をポート番号として使う候補に入れてリクエストを 処理するようになります。`UseCanonicalPhysicalPort Off` という設定であれば、実際のポート番号は使用せず、設定されている情報を 全て信じてポート番号を構成するようになります。

### 注

実際のポート番号が使われる順序は次のようになっています :
`UseCanonicalName On`

- `ServerName` で指定されているポート番号
- 実際のポート番号
- デフォルトのポート番号

`UseCanonicalName Off | DNS`

- `Host:` ヘッダから抽出されたポート番号
- 実際のポート番号
- `ServerName` で指定されているポート番号
- デフォルトのポート番号

`UseCanonicalPhysicalPort Off` で、 実際のポート番号が上の順序から取り除かれます。

### 参照

- `UseCanonicalName`
- `ServerName`
- `Listen`

## <VirtualHost> ディレクティブ

説明: | 特定のホスト名や IP アドレスのみに適用されるディレクティブを 囲む
構文: | `<VirtualHost addr[:port] [addr[:port]] ...> ... </VirtualHost>`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core

`<VirtualHost>` 及び `</VirtualHost>` は、 特定のバーチャルホストに対してのみ適用されるディレクティブ群を括る ために使われます。 バーチャルホストコンテキストで許可される全てのディレクティブを指定可能です。 サーバが、指定されたバーチャルホストにあるドキュメントへの リクエストを受け付けた場合、 `<VirtualHost>` セクションの中にある ディレクティブが適用されます。 Addrは、次のものが利用できます:

- バーチャルホストの IP アドレス
- バーチャルホストの IP に対応する完全なドメイン名
- `NameVirtualHost *` と共に使われる、 すべての IP アドレスにマッチする文字 `*`
- IP ベースのバーチャルホストで他のものにマッチしない 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>`

IPv6 アドレスはオプションのポート番号の指定と区別するために、 角括弧で括って指定する必要があります。次は IPv6 の例です:

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

各々のバーチャルホストにはそれぞれ違う IP アドレス、ポート番号 もしくはホスト名に対応する必要があり、 1 番目の場合には複数のアドレスで IP パケットを受信できるように サーバマシンを設定しなければなりません。 (もし、マシンが複数のネットワークインターフェースと持たない場合は、 (OSがサポートしていれば) `ifconfig alias` コマンドにより 達成できます)。

### 注意点

`<VirtualHost>` は Apache が Listen する IP アドレスには影響を与えません。 `Listen` を 使って Apache が正しいアドレスを listen するように設定する必要があります。

IP ベースのバーチャルホストを使っている場合は、特別な名前 `_default_` を指定することができます。その場合は そのバーチャルホストは他のバーチャルホストで明示的に挙げられていない すべての IP アドレスにマッチします。`_default_` バーチャルホストが無い 場合に IP がバーチャルホストで指定されたものにマッチしないときは、 VirtualHost セクションの外のすべての定義からなる「主」サーバ設定が 使われます。(ただし、`NameVirtualHost` ディレクティブにマッチする すべての IP アドレスは「主」サーバ設定も `_default_` バーチャルホストも 使わないことに注意してください。詳しくは ネームベースのバーチャルホスト を 参照してください。)

`:port` といった形式で記述することにより、 マッチさせるポートを変更可能です。 この指定をしない場合には、主サーバ設定における 一番最後に `Port` で指定されたポートが デフォルトとなります。 `:*` を指定することにより、 アドレス上の全てのポートにマッチします。(`_default_` のときは これを使うことが推奨されています。)

### セキュリティ

サーバーを起動した以外のユーザがログファイルが保管されるディレクトリに 書き込み可能なときになぜセキュリティが破られる可能性があるかの詳細は セキュリティに関するコツ を 参照してください。

### 参照

- Apache バーチャルホスト説明書
- DNS と Apache に関する話
- Apache が使用するアドレスとポートの設定
- リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法

Available Languages: de | en | ja