Apache HTTP サーバ バージョン 2.4

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

# Apache コア機能

翻訳済み言語: de | en | es | fr | ja | tr

この日本語訳はすでに古くなっている 可能性があります。 最近更新された内容を見るには英語版をご覧下さい。

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

### ディレクティブ

### Bugfix checklist

- httpd changelog
- Known issues
- Report a bug

### 参照

- コメント

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

## 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 ファイル

## AllowOverrideList ディレクティブ

説明: | Individual directives that are allowed in `.htaccess` files
構文: | `AllowOverrideList None|directive [directive-type] ...`
デフォルト: | `AllowOverrideList None`
コンテキスト: | ディレクトリ
ステータス: | Core
モジュール: | core

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `AccessFileName`
- `AllowOverride`
- Configuration Files
- .htaccess Files

## CGIMapExtension ディレクティブ

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

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

## CGIPassAuth ディレクティブ

説明: | Enables passing HTTP authorization headers to scripts as CGI variables
構文: | `CGIPassAuth On|Off`
デフォルト: | `CGIPassAuth Off`
コンテキスト: | ディレクトリ, .htaccess
上書き: | AuthConfig
ステータス: | Core
モジュール: | core
互換性: | Available in Apache HTTP Server 2.4.13 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## CGIVar ディレクティブ

説明: | Controls how some CGI variables are set
構文: | `CGIVar variable rule`
コンテキスト: | ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core
互換性: | Available in Apache HTTP Server 2.4.21 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## ContentDigest ディレクティブ

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

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

MD5 は、任意長のデータの「メッセージダイジェスト」(「指紋」 と表現されることもある) を計算するアルゴリズムで、 データの変更があった場合には非常に高い信頼度でメッセージダイジェストに変更が 反映されます。

`Content-MD5` ヘッダは、エンドツーエンドで エンティティボディーに含まれるメッセージの完全性チェック (Message Integrity Check - MIC)を提供します。 このヘッダを調べることで、プロキシやクライアントは、 途中経路におけるエンティティボディの予期せぬ変更などを 検出することができます。ヘッダの例:

`Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==`

リクエスト毎にメッセージダイジェストを計算する (値はキャッシュされません) ことから、 サーバパフォーマンスが低下することについて注意してください。

`Content-MD5`は、`core` 機能により処理された ドキュメントを送るときのみ有効であり、 SSI ドキュメントや CGI スクリプトの出力、バイトレンジを指定した 応答の場合にはこのヘッダは付与されません。

## DefaultRuntimeDir ディレクティブ

説明: | Base directory for the server run-time files
構文: | `DefaultRuntimeDir directory-path`
デフォルト: | `DefaultRuntimeDir DEFAULT_REL_RUNTIMEDIR (logs/)`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core
互換性: | Available in Apache 2.4.2 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- the security tips for information on how to properly set permissions on the `ServerRoot`

## DefaultType ディレクティブ

説明: | サーバがコンテントタイプを決定できないときに 送られる MIME コンテントタイプ
構文: | `DefaultType MIME-type|none`
デフォルト: | `DefaultType text/plain`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core
互換性: | 引数 `none` は Apache 2.2.7 以降で利用可能

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

サーバは、ドキュメントのコンテントタイプをクライアントに通知するべきです。 サーバで通常の方法ではこれが判定できない場合は、 `DefaultType` で指定されたタイプを利用します。 例:

`DefaultType image/gif`

これは `.gif` という拡張子がファイル名に含まれていない 多くの GIF 画像が含まれているディレクトリに適しているでしょう。

サーバでも管理者でも判定することができない (例えばプロクシの) 場合、 誤った情報を与えるよりは MIME タイプの指定がない状態が望ましいことも あります。この場合は次のようにします :

`DefaultType None`

`DefaultType None` は httpd-2.2.7 以降でのみ利用できます。

`ForceType` ディレクティブと 違って、このディレクティブはデフォルトの MIME タイプを提供するだけで あることに注意してください。ファイル名の拡張子を含め、 メディアタイプを決定できる他の MIME タイプの定義があれば このデフォルトは上書きされます。

## Define ディレクティブ

説明: | 変数の存在を宣言する
構文: | `Define parameter-name`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core

`httpd` の `-D` 引数と同じものです。

このディレクティブを使うと、スタートアップスクリプトに 記載されている `-D` 引数を書き換える必要なく、 `<IfDefine>` セクションを切り替えることができます。

## <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 をファイルシステムの位置に マップする

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

説明: | Contains directives that apply only if the condition of a previous `<If>` or `<ElseIf>` section is not satisfied by a request at runtime
構文: | `<Else> ... </Else>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core
互換性: | Nested conditions are evaluated in 2.4.26 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `<If>`
- `<ElseIf>`
- How <Directory>, <Location>, <Files> sections work for an explanation of how these different sections are combined when a request is received. `<If>`, `<ElseIf>`, and `<Else>` are applied last.

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

説明: | Contains directives that apply only if a condition is satisfied by a request at runtime while the condition of a previous `<If>` or `<ElseIf>` section is not satisfied
構文: | `<ElseIf expression> ... </ElseIf>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core
互換性: | Nested conditions are evaluated in 2.4.26 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- Expressions in Apache HTTP Server, for a complete reference and more examples.
- `<If>`
- `<Else>`
- How <Directory>, <Location>, <Files> sections work for an explanation of how these different sections are combined when a request is received. `<If>`, `<ElseIf>`, and `<Else>` are applied last.

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

## Error ディレクティブ

説明: | Abort configuration parsing with a custom error message
構文: | `Error message`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
ステータス: | Core
モジュール: | core
互換性: | 2.3.9 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## ErrorDocument ディレクティブ

説明: | エラーが発生したときにサーバがクライアントに送るもの
構文: | `ErrorDocument error-code document`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | FileInfo
ステータス: | Core
モジュール: | core

問題やエラーが発生したときの動作として、 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 ログファイル

## ErrorLogFormat ディレクティブ

説明: | Format specification for error log entries
構文: | `ErrorLogFormat [connection|request] format`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `ErrorLog`
- `LogLevel`
- Apache HTTP Server Log Files

## ExtendedStatus ディレクティブ

説明: | Keep track of extended status information for each request
構文: | `ExtendedStatus On|Off`
デフォルト: | `ExtendedStatus Off[*]`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## 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` と同じになります。

### 警告

WebDAV を使っていて、`mod_dav_fs` をストレージプロバイダとして 使っているような Directory や Location では、デフォルト値を変更しないでください。 `mod_dav_fs` では、条件付リクエストでの比較演算に `INode MTime Size` の固定フォーマットを使っています。 `FileETag` で `ETag` フォーマットを 変更してしまうと、条件付リクエストでうまく動作しなくなります。

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

## GprofDir ディレクティブ

説明: | Directory to write gmon.out profiling data to.
構文: | `GprofDir /tmp/gprof/|/tmp/gprof/%`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## 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 アドレスからホスト名を ルックアップすることが可能です。

## HttpProtocolOptions ディレクティブ

説明: | Modify restrictions on HTTP Request Messages
構文: | `HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods] [Allow0.9|Require1.0]`
デフォルト: | `HttpProtocolOptions Strict LenientMethods Allow0.9`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core
互換性: | 2.2.32 or 2.4.24 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

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

説明: | 実行時、リクエストが条件を満たした場合にのみ適用される ディレクティブを包含する
構文: | `<If expression> ... </If>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core

`<If>` ディレクティブは 実行時に式を評価し、条件式が真になるときにのみ 内包するディレクティブを適用します。 例えば

`<If "$req{Host} = ''">`

上記例は Host: ヘッダの存在しない HTTP/1.0 のリクエストに マッチします。

### 参照

- どのように <Directory>, <Location>, <Files> セクションが動作するか では、リクエストを受けたときに、 これらの異なるセクションがどのように組み合わさるかについて記載されています。 `<If>` は `<Files>` と同じ処理順と用法になっています。

## <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` という形で指定するか あるいは `Define` ディレクティブで指定されると定義されます。

`<IfDefine>` セクションは 入れ子にすることができ、複数のパラメータによるテストをするために使用できます。 例:

`httpd -DReverseProxy -DUseCache -DMemCache ...
# httpd.conf
<IfDefine ReverseProxy>
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<IfDefine UseCache>
LoadModule cache_module modules/mod_cache.so
<IfDefine MemCache>
LoadModule mem_cache_module modules/mod_mem_cache.so
</IfDefine>
<IfDefine !MemCache>
LoadModule cache_disk_module modules/mod_cache_disk.so
</IfDefine> </IfDefine> </IfDefine>`

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

説明: | Encloses directives that are processed conditional on the presence or absence of a specific directive
構文: | `<IfDirective [!]directive-name> ... </IfDirective>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core
互換性: | Available in 2.4.34 and later.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `<IfSection>`

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

説明: | Encloses directives that will be processed only if file exists at startup
構文: | `<IfFile [!]filename> ... </IfFile>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core
互換性: | Available in 2.4.34 and later.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## <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>` セクションの中に 入れる必要はありません。

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

説明: | Encloses directives that are processed conditional on the presence or absence of a specific section directive
構文: | `<IfSection [!]section-name> ... </IfSection>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き: | All
ステータス: | Core
モジュール: | core
互換性: | Available in 2.4.34 and later.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `<IfDirective>`

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

## IncludeOptional ディレクティブ

説明: | Includes other configuration files from within the server configuration files
構文: | `IncludeOptional file-path|directory-path|wildcard`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス: | Core
モジュール: | core
互換性: | Available in 2.3.6 and later. Not existent file paths without wildcards do not cause SyntaxError after 2.4.30

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `Include`
- `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 に対応したクライアントの際には、 特に指定されない限りはデフォルトとして持続的な接続が行なわれます。 クライアントが要求すれば、コンテンツの容量を判別できないものを 持続的な接続を通して送るために、チャンクエンコーディングが用いられます。

クライアントが Keep-Alive コネクションを使用している場合、 そのコネクションを通してどれだけたくさんのリクエストが処理されても、 それは「リクエスト」1 つとして、MaxRequestsPerChild ディレクティブでは 数えられます。

### 参照

- `MaxKeepAliveRequests`

## KeepAliveTimeout ディレクティブ

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

接続を閉じる前に、Apache が次のリクエストを何秒待つかを指定します。 リクエストを受け付けた後は、`Timeout` ディレクティブによって 指定されたタイムアウト値が使われます。

`KeepAliveTimeout` を大きな値に設定すると、 負荷の高いサーバにおいてはパフォーマンスの問題を引き起こす場合があります。 タイムアウトが長ければ長いほど、より多くのサーバプロセスが 活性でないクライアントからの接続の終了を待ち続けることになります。

名前ベースのバーチャルホストコンテキストでは、 `NameVirtualHost` のセットの中で最初に定義されたバーチャルホストの値 (デフォルトホスト) が使われます。 その他の値は無視されます。

## <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` メソッドに制限をかけることはできません (`<TraceEnable>` 参照)。

アクセス制御が目的の場合は `<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 にはワイルドカードを利用することができます。 `?` は任意の一文字、`*` は任意の文字列にマッチします。 どちらのワイルドカードも URL パス中の / にはマッチしません。

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

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

は URL に `/extra/data` か `/special/data` という文字列が 含まれている場合にマッチします。 `<LocationMatch>` ディレクティブは `<Location>` の正規表現 版とまったく同じ動作をします。

`<Location>` 機能は、`SetHandler` ディレクティブと 組合わせて利用すると特に便利です。 例えば、`example.com` のブラウザからのみステータスの参照を有効にしたければ、 次のようにすれば良いでしょう。

`<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .example.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`

## MaxRangeOverlaps ディレクティブ

説明: | Number of overlapping ranges (eg: `100-200,150-300`) allowed before returning the complete resource
構文: | `MaxRangeOverlaps default | unlimited | none | number-of-ranges`
デフォルト: | `MaxRangeOverlaps 20`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス: | Core
モジュール: | core
互換性: | Available in Apache HTTP Server 2.3.15 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## MaxRangeReversals ディレクティブ

説明: | Number of range reversals (eg: `100-200,50-70`) allowed before returning the complete resource
構文: | `MaxRangeReversals default | unlimited | none | number-of-ranges`
デフォルト: | `MaxRangeReversals 20`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス: | Core
モジュール: | core
互換性: | Available in Apache HTTP Server 2.3.15 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## MaxRanges ディレクティブ

説明: | Number of ranges allowed before returning the complete resource
構文: | `MaxRanges default | unlimited | none | number-of-ranges`
デフォルト: | `MaxRanges 200`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス: | Core
モジュール: | core
互換性: | Available in Apache HTTP Server 2.3.15 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## MergeTrailers ディレクティブ

説明: | Determines whether trailers are merged into headers
構文: | `MergeTrailers [on|off]`
デフォルト: | `MergeTrailers off`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core
互換性: | 2.4.11 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## Mutex ディレクティブ

説明: | Configures mutex mechanism and lock file directory for all or specified mutexes
構文: | `Mutex mechanism [default|mutex-name] ... [OmitPID]`
デフォルト: | `Mutex default`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core
互換性: | Available in Apache HTTP Server 2.3.4 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## 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>` 内に このオプションを指定しても無視されることに 注意してください。

  このオプションを省略したからといってセキュリティの強化にはなりません。 なぜなら symlink の検査はレースコンディションを引き起こす可能性があり、 そのため回避可能になるからです。

`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>` 内にこのオプションを 指定しても無視されます。

  このオプションはセキュリティの強化にはなりません。 なぜなら symlink の検査はレースコンディションを引き起こす可能性があり、 そのため回避可能になるからです。

通常、ディレクトリに対して複数の `Options` が 適用可能な場合、 最も近いもの一つのみが適用され、他のものは無視されます。 複数の指定がマージされるわけではありません。(セクションのマージ方法を参照してください。) しかし、すべての `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` に なります。

## Protocol ディレクティブ

説明: | Protocol for a listening socket
構文: | `Protocol protocol`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core
互換性: | Available in Apache 2.1.5 and later. On Windows, from Apache 2.3.3 and later.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `AcceptFilter`
- `Listen`

## Protocols ディレクティブ

説明: | Protocols available for a server/virtual host
構文: | `Protocols protocol ...`
デフォルト: | `Protocols http/1.1`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core
互換性: | Only available from Apache 2.4.17 and later.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `ProtocolsHonorOrder`

## ProtocolsHonorOrder ディレクティブ

説明: | Determines if order of Protocols determines precedence during negotiation
構文: | `ProtocolsHonorOrder On|Off`
デフォルト: | `ProtocolsHonorOrder On`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core
互換性: | Only available from Apache 2.4.17 and later.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `Protocols`

## QualifyRedirectURL ディレクティブ

説明: | Controls whether the REDIRECT_URL environment variable is fully qualified
構文: | `QualifyRedirectURL ON|OFF`
デフォルト: | `QualifyRedirectURL OFF`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ
上書き: | FileInfo
ステータス: | Core
モジュール: | core
互換性: | Directive supported in 2.4.18 and later. 2.4.17 acted as if 'QualifyRedirectURL ON' was configured.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## RegexDefaultOptions ディレクティブ

説明: | Allow to configure global/default options for regexes
構文: | `RegexDefaultOptions [none] [+|-]option [[+|-]option] ...`
デフォルト: | `RegexDefaultOptions DOLLAR_ENDONLY`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core
互換性: | Only available from Apache 2.4.30 and later.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## RegisterHttpMethod ディレクティブ

説明: | Register non-standard HTTP methods
構文: | `RegisterHttpMethod method [method [...]]`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core
互換性: | Available in Apache HTTP Server 2.4.24 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `HTTPProtocolOptions`
- `AllowMethods`

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

## 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 レジストリに手動で設定する必要がありますので、システムでの偶発的なプログラムの 実行を防ぐことができます。

## SeeRequestTail ディレクティブ

説明: | Determine if mod_status displays the first 63 characters of a request or the last 63, assuming the request itself is greater than 63 chars.
構文: | `SeeRequestTail On|Off`
デフォルト: | `SeeRequestTail Off`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core
互換性: | Available in Apache httpd 2.2.7 and later.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

## 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` ディレクティブは、ネームベースのバーチャルホストにおいて 使用するホストの別名を指定します。 適切であれば、`ServerAlias` ディレクティブでは ワイルドカードを使うこともできます。

`<VirtualHost *>
ServerName server.domain.com
ServerAlias server server2.domain.com server2
# ...
</VirtualHost>`

### 参照

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

## ServerName ディレクティブ

説明: | サーバが自分自身を示すときに使うホスト名とポート
構文: | `ServerName [scheme://]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: ヘッダに現れる必要があるのかを指定します。

SSL を処理するデバイス、例えばリバースプロクシやロードバランサや SSL 処理軽減アプライアンスの裏側でサーバが稼動する場合もあるでしょう。 そういった場合では、クライアントが接続するときに使う `https://` スキームとポート番号を `ServerName` ディレクティブで指定して、自己参照 URL が正しく生成できるようにします。

自己参照 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 以降では、表示されるサーバーのバージョン番号の詳細は`ServerTokens` ディレクティブにより制御されます。

### 参照

- `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 60`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Core
モジュール: | core

`TimeOut` ディレクティブは、 様々な条件下での I/O 待ち時間を定義します:

1. クライアントからのデータを読み込む時。 受信バッファが空になっていて、TCP パケットが届くまで 待つ時間の長さ
2. クライアントに対してデータを送り出す時。 送信バッファがいっぱいで、パケットの受信完了 (訳注: ACK) が届くまで待つ時間の長さ
3. `mod_cgi` 内で、CGI スクリプトが出力を 返すまでの待ち時間の長さ
4. `mod_ext_filter` 内で、フィルタ処理で出力を 待つ時間の長さ
5. `mod_proxy` 内で、 `ProxyTimeout` が設定されていない場合のデフォルトの待ち時間

## TraceEnable ディレクティブ

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

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

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

## UnDefine ディレクティブ

説明: | Undefine the existence of a variable
構文: | `UnDefine parameter-name`
コンテキスト: | サーバ設定ファイル
ステータス: | Core
モジュール: | core

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

### 参照

- `Define`
- `IfDefine`

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

さまざまな局面で 自己参照 URL -- それ自体のサーバを参照する URL を作ることになります。`UseCanonicalPhysicalPort On` と設定すると、 `UseCanonicalName` に従って別名を 生成する場合に、実際の物理ポート番号を使って構成するようになります。 `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.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>`

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_` のときは これを使うことが推奨されています。)

`<VirtualHost>` ブロックごとに `ServerName` を指定すべきです。 もしなければ、メインサーバ設定の `ServerName` が継承されます

### セキュリティ

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

### 参照

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

翻訳済み言語: de | en | es | fr | ja | tr

## コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.