core
常に使用可能な Apache HTTP サーバのコア機能
Core
AcceptPathInfo
後に続くパス名情報を受け付けるリソースの指定
AcceptPathInfo On|Off|Default
AcceptPathInfo Default
server config
virtual host
directory
.htaccess
FileInfo
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-isa のようにスクリプトを扱うハンドラは 一般的にデフォルトで `PATH_INFO` を受け付けます。

`AcceptPathInfo` の主な目的はハンドラの `PATH_INFO` を 受け付けるか拒否するかの選択を上書きできるようにすることです。 例えば、これは例えば INCLUDES のような フィルタを使って `PATH_INFO` に 基づいてコンテンツを生成しているときに必要になります。

<Files "mypaths.shtml">
Options +Includes
SetOutputFilter INCLUDES
AcceptPathInfo On
</Files>
AccessFileName
分散設定ファイルの名前
AccessFileName filename [filename] ...
AccessFileName .htaccess
server config
virtual host

リクエストを処理するとき、サーバはディレクトリに 対して分散設定ファイルが有効になっていれば、 そのドキュメントへの パス上にある全てのディレクトリから、ここで指定された名前の一覧の中で 最初に見つかったファイルをそれぞれ設定ファイルとして読み込みます。例えば:

AccessFileName .acl

という設定があると、以下のようにして無効にされていない限り、 ドキュメント `/usr/local/web/index.html` を返す前に、サーバは `/.acl`, `/usr/.acl`, `/usr/local/.acl`, `/usr/local/web/.acl` から ディレクティブを読み込みます。

<Directory />
AllowOverride None
</Directory>
AllowOverride
設定ファイル
.htaccess ファイル
AddDefaultCharset
明示的に文字セットを指定していない応答に追加される デフォルトの文字セット
AddDefaultCharset On|Off|charset
AddDefaultCharset Off
server config
virtual host
directory
.htaccess
FileInfo

このディレクティブは、HTTP ヘッダにコンテントタイプパラメータを 持たない応答に追加される文字セットの名前を指定します。 これは、ドキュメント内の META タグで指定されたどのような文字セット も無効にします。 `AddDefaultCharset Off` という設定により、この機能は無効になります。 `AddDefaultCharset On` にすれば、ディレクティブの要求通り Apache 内部のデフォルト文字セット `iso-8859-1` に設定します。 また、他の charset も指定できます。例えば:

AddDefaultCharset utf-8
AddOutputFilterByType
MIME-type に出力フィルタを割り当てる
AddOutputFilterByType filter[;filter...] MIME-type [MIME-type] ...
server config
virtual host
directory
.htaccess
FileInfo
Apache 2.0.33 以降で使用可能

このディレクティブは応答の MIME-type に応じて出力フィルタを使用するようにします。

次の例は 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
server config
virtual host
Apache 2.0.46 以降で使用可能

AllowEncodedSlashes ディレクティブは符号化された パス分離文字 (`/` は `%2F`、さらにシステムによっては `\` に対応する `%5C`) が存在する URL の使用を 許可するかどうかを決定します。通常はそのような URL は 404 (Not found) エラー で拒否されます。

AllowEncodedSlashes `On` による パス分離文字の使用は、`PATH_INFO` と合わせて 使うときに一番役に立ちます。

Turning AllowEncodedSlashes `On` is mostly useful when used in conjunction with `PATH_INFO`.

# 注

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

AcceptPathInfo
AllowOverride
.htaccess
で許可されるディレクティブの種類
AllowOverride All|None|directive-type [directive-type] ...
AllowOverride All
directory

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

# Only available in <Directory> sections

AllowOverride is valid only in Directory sections, not in Location or Files sections.

このディレクティブを 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* ディレクティブなど。)。
Indexes
  ディレクトリインデックスを制御するためのディレクティブの使用を許可する (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName など。)。
Limit
  ホストへのアクセス制御を行うためのディレクティブの使用を許可する (Allow, Deny, Order).
Options
  特定のディレクトリにおける機能を指定するためのディレクティブの使用を許可する (Options と XBitHack).

例:

AllowOverride AuthConfig Indexes
AccessFileName
設定ファイル
.htaccess ファイル
AuthName
HTTP 認証の認可領域 (訳注: realm)
AuthName auth-domain
directory
.htaccess
AuthConfig

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

例えば:

AuthName "Top Secret"

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

認証、承認、アクセス制御
AuthType
ユーザ認証の種類
AuthType Basic|Digest
directory
.htaccess
AuthConfig

このディレクティブは対象ディレクトリで利用するユーザー認証の種類を選びます。 ただ、現在のところは `Basic` と `Digest` しか 実装されていません。

このディレクティブは AuthNameディレクティブや Require ディレクティブと、 AuthUserFile や AuthGroupFile などのディレクティブと 一緒に利用する必要があります。

認証、承認、アクセス制御
CGIMapExtension
CGI スクリプトのインタープリタの位置を調べるための手法
CGIMapExtension cgi-path .extension
None
directory
.htaccess
FileInfo
NetWare のみ

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

ContentDigest
Content-MD5
HTTP 応答ヘッダの生成を有効にする
ContentDigest On|Off
ContentDigest Off
server config
virtual host
directory
.htaccess
Options
Experimental

このディレクティブは、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
server config
virtual host
directory
.htaccess
FileInfo

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

サーバは、ドキュメントのコンテントタイプをクライアントに通知する必要が ありますので、このようにタイプが未知の場合は `DefaultType` で指定されたタイプを利用します。 例:

DefaultType image/gif

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

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

Directory
指定のファイルシステムのディレクトリとサブディレクトリとのみに 適用されるディレクティブを囲む
<Directory directory-path> ... </Directory>
server config
virtual host

指定されたディレクトリとそのサブディレクトリにのみ ディレクティブを適用させるためには、 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/.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>
server config
virtual host

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

<DirectoryMatch "^/www/.*/[0-9]{3}">

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

通常の Directory と正規表現の指定が 適用される順番については Directory
リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法
DocumentRoot
ウェブから見えるメインのドキュメントツリーになる ディレクトリ
DocumentRoot directory-path
DocumentRoot /usr/local/apache/htdocs
server config
virtual host

このディレクティブは、`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
server config
virtual host
directory
.htaccess
FileInfo

このディレクティブは配送中にファイルの内容を読み込む必要があるときに `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
server config
virtual host
directory
.htaccess
FileInfo
バージョン 2.0.44 以降で使用可能

このディレクティブはクライアンにファイルの内容を送るときに `httpd` がカーネルの sendfile サポートを使うかどうかを制御します。デフォルトでは、 例えば静的なファイルの配送のように、リクエストの処理にファイルの 途中のデータのアクセスを必要としないときには、Apache は OS が サポートしていればファイルを読み込むことなく sendfile を使って ファイルの内容を送ります。

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

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

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

EnableSendfile Off

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

<Directory "/path-to-nfs-files"> EnableSendfile Off </Directory>
ErrorDocument
エラーが発生したときにサーバがクライアントに送るもの
ErrorDocument error-code document
server config
virtual host
directory
.htaccess
FileInfo
Apache 2.0 ではテキストをクウォートする構文が以前のバージョンから 変わっています。

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

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

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

URL の場合は、ローカルの URL の指定としてスラッシュで始まる (/) パスか、 クライアントが解釈できるフル 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"

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

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

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

カスタマイズ可能な エラー応答のドキュメンテーション
ErrorLog
サーバがエラーをログ収集する場所
ErrorLog file-path|syslog[:facility]
ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)
server config
virtual host

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
server config
virtual host
directory
.htaccess
FileInfo

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>
server config
virtual host
directory
.htaccess
All

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>
server config
virtual host
directory
.htaccess
All

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

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

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

リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法
ForceType
すべてのマッチするファイルが指定の MIME コンテントタイプで 送られるようにする
ForceType MIME-type|None
directory
.htaccess
FileInfo
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
server config
virtual host
directory

このディレクティブは、ホスト名をログ収集できるように 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>
server config
virtual host
directory
.htaccess
All

`<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-name> ... </IfModule>
server config
virtual host
directory
.htaccess
All

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

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

- module name
- !module name

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

module name 引数は、 コンパイルをした時のモジュールのファイル名で、 例えば `mod_rewrite.c` といった形になります。 モジュールが複数のソースファイルから構成されている場合は、文字列 `STANDARD20_MODULE_STUFF` があるファイルの名前を 使ってください。

IfModule セクションは 入れ子にすることが可能であり、 複数のモジュールのテストを行なうために使用できます。

特定のモジュールの存在に関わらず動作する 設定ファイルの原本が必要なときにのみこのセクションを使用してください。 通常の動作では、ディレクティブを IfModule セクションの中に 入れる必要はありません。

Include
サーバ設定ファイル中から他の設定ファイルを取り込む
Include file-path|directory-path
server config
virtual host
directory
ワイルドカードによるマッチは 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
server config
virtual host

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 15
server config
virtual host

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

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

Limit
囲いの中にあるアクセス制御の適用を特定の HTTP メソッドのみに 制限する
<Limit method [method] ... > ... </Limit>
server config
virtual host
directory
.htaccess
All

アクセス制御は、通常全てのアクセスメソッドに対して 影響し、普通はこれが望ましい挙動です。 そうしたことから、大部分の場合にはアクセス制御に関わるディレクティブを 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>
server config
virtual host
directory
.htaccess
All

LimitExcept と `</LimitExcept>` は、引数に 含まれていない HTTP のアクセスメソッドに適用するためのアクセス制御 ディレクティブを括るために利用します。 つまり、Limit セクションの反対の動作をし、 標準のメソッドと標準外や未認識のメソッドの場合の両方を設定できます。 Limit のドキュメントも 併せて参照してください。

例:

<LimitExcept POST GET>
Require valid-user
</LimitExcept>
LimitInternalRecursion
内部リダイレクトと入れ子になったサブリクエストの最大数を決定する
LimitInternalRecursion number [number]
LimitInternalRecursion 10
server config
virtual host
Apache 2.0.47 以降で使用可能

内部リダイレクトは例えば Action ディレクティブを 使っているときに起こります。Action ディレクティブは 元々のリクエストを CGI スクリプトに内部リダイレクトを行ないます。 サブリクエストはいくつかの URI に対して、リクエストされたときに 何が起こるかを調べるための Apache の機構です。例えば、mod_dir は DirectoryIndex ディレクティブ がリストするファイルを調べるためにサブリクエストを使います。

LimitInternalRecursion は内部リダイレクトや サブリクエストが無限ループに陥ったときのサーバクラッシュを防ぎます。 普通、そのようなループは設定に失敗したときに発生します。

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

# 例

LimitInternalRecursion 5
LimitRequestBody
クライアントから送られる HTTP リクエストのボディの 総量を制限する
LimitRequestBody bytes
LimitRequestBody 0
server config
virtual host
directory
.htaccess
All

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

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

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

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

LimitRequestBody 102400
LimitRequestFields
クライアントからの HTTP リクエストのヘッダフィールドの数を 制限する
LimitRequestFields number
LimitRequestFields 100
server config

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

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

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

例:

LimitRequestFields 50
LimitRequestFieldSize
クライアントからの HTTP リクエストのヘッダの サイズを制限する
LimitRequestFieldsize bytes
LimitRequestFieldsize 8190
server config

このディレクティブは、HTTP リクエストヘッダ内に含めることのできる バイト数、bytes を 0 からコンパイル時に定義される定数 `DEFAULT_LIMIT_REQUEST_FIELDSIZE` (配布時には 8192 と指定) で指定された値までの数字で指定します。

LimitRequestFieldSize ディレクティブは、 サーバのコンパイル時に指定したインプットバッファ容量以下に HTTP リクエストヘッダの許容されるサイズを制限することができます。 サーバは、このディレクティブの値として、 通常のクライアントリクエストから送られた個々のヘッダフィールドに 十分足る大きさを必要とします。 普通のリクエストヘッダのサイズは、個々のクライアントにより大きく変わり、 詳細なコンテントネゴシエーションをするためのブラウザの設定までにも 影響されることがあります。

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

例:

LimitRequestFieldSize 4094

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

LimitRequestLine
クライアントからの HTTP リクエスト行のサイズを制限する
LimitRequestLine bytes
LimitRequestLine 8190
server config

このディレクティブは、HTTP リクエスト行内で許容されるバイト数 bytes を 0 からコンパイル時の定数 `DEFAULT_LIMIT_REQUEST_LINE` (配布時には 8190 と指定) で指定された値までの数字で指定します。

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

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

例:

LimitRequestLine 4094

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

LimitXMLRequestBody
XML 形式のリクエストのボディのサイズを制限する
LimitXMLRequestBody bytes
LimitXMLRequestBody 1000000
server config
virtual host
directory
.htaccess
All

XML 形式のリクエストのボディの最大値を (バイト単位で) 制限します。 値に `0` を指定するとチェックを無効にします。

例:

LimitXMLRequestBody 0
Location
囲んだディレクティブをマッチする URL のみに適用
<Location URL-path|URL> ... </Location>
server config
virtual host

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>
server config
virtual host

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

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

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

リクエストを受けた際にこれらの異なるセクションが 組み合わされる方法については <Directory>, <Location>, <Files> セクションの動作法
LogLevel
ErrorLog の冗長性を制御する
LogLevel level
LogLevel warn
server config
virtual host

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
server config
virtual host

MaxKeepAliveRequests ディレクティブは、 KeepAlive が有効な場合に、 一回の接続で受け付け可能なリクエストの数を制限します。 `0` に設定していれば、受け付けるリクエストは無制限になります。 この設定は、サーバ性能を向上させるために、大きな数値を指定すること勧めます。

例:

MaxKeepAliveRequests 500
NameVirtualHost
名前ベースのバーチャルホストのための IP アドレスを指定
NameVirtualHost addr[:port]
server config

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 [fe80::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
server config
virtual host
directory
.htaccess
Options

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] ...
directory
.htaccess
AuthConfig

このディレクティブは、どの認証済みのユーザがディレクトリに アクセスすることができるかを指定します。 以下のような構文になります。

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

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

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

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

Satisfy
mod_authz_host
RLimitCPU
Apache の子プロセスから起動されたプロセスの CPU 消費量を 制限する
RLimitCPU seconds|max [seconds|max]
未設定。オペレーティングシステムのデフォルトを使用
server config
virtual host
directory
.htaccess
All

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

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

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

RLimitMEM
RLimitNPROC
RLimitMEM
Apache の子プロセスから起動されたプロセスのメモリ消費量を 制限する
RLimitMEM bytes|max [bytes|max]
未設定。オペレーティングシステムのデフォルトを使用
server config
virtual host
directory
.htaccess
All

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

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

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

RLimitCPU
RLimitNPROC
RLimitNPROC
Apache の子プロセスから起動されたプロセスが起動するプロセスの 数を制限する
RLimitNPROC number|max [number|max]
未設定。オペレーティングシステムのデフォルトを使用
server config
virtual host
directory
.htaccess
All

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

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

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

# 注

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

RLimitMEM
RLimitCPU
Satisfy
ホストレベルのアクセス制御とユーザ認証との相互作用を指定
Satisfy Any|All
Satisfy All
directory
.htaccess
AuthConfig

Allow と Require の両方が使われているときの アクセスポリシーを設定します。パラメータは `All` か `Any` です。このディレクティブはある場所へのアクセスがユーザ名/パスワード とクライアントのホストのアドレスで制限されているときにのみ 役立ちます。デフォルトの動作 (`All`) はクライアントがアドレスによる アクセス制限を満たし、かつ正しいユーザ名とパスワードを入力することを 要求します。`Any` では、クライアントはホストの制限を満たすか、 正しいユーザ名とパスワードの入力をするかをすればアクセスを許可されます。 これは、ある場所をパスワードで保護するけれど、特定のアドレスからの クライアントにはパスワードの入力を要求せずにアクセスを許可する、 というようなときに使用できます。

例えば、同じネットワーク上にいる人にはウェブサイトのある部分について 無制限のアクセスを許したいけれど、外のネットワークの人には パスワードを提供させるようにするためには、次のような設定をすることが できます:

Require valid-user
Allow from 192.168.1
Satisfy Any
Allow
Require
ScriptInterpreterSource
CGI スクリプトのインタープリタの位置を調べるための手法
ScriptInterpreterSource Registry|Registry-Strict|Script
ScriptInterpreterSource Script
server config
virtual host
directory
.htaccess
FileInfo
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
server config
virtual host

ServerAdmin は、クライアントに返すさまざまな エラーメッセージ中に記述する、 電子メールのアドレスを設定します。

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

ServerAdmin www-admin@foo.example.com

といったようにします。ユーザはいつもサーバに関する話であるということを 明記してくるわけではありませんので。

ServerAlias
リクエストを名前ベースのバーチャルホストにマッチさせているときに 使用されるホストの別名
ServerAlias hostname [hostname] ...
virtual host

ServerAlias ディレクティブは、ネームベースのバーチャルホストにおいて 使用するホストの別名を指定します。

<VirtualHost *>
ServerName server.domain.com
ServerAlias server server2.domain.com server2
# ...
</VirtualHost>
Apache バーチャルホスト説明書
ServerName
サーバが自分自身を示すときに使うホスト名とポート
ServerName fully-qualified-domain-name[:port]
server config
virtual host
このディレクティブはバージョン 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 ディレクティブを参照してください。

DNS と Apache に関する話
Apache バーチャルホスト説明書
UseCanonicalName
NameVirtualHost
ServerAlias
ServerPath
非互換のブラウザが名前ベースのバーチャルホストにアクセスしたときの ための互換用 URL パス名
ServerPath URL-path
virtual host

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

Apache バーチャルホスト説明書
ServerRoot
インストールされたサーバのベースディレクトリ
ServerRoot directory-path
ServerRoot /usr/local/apache
server config

ServerRoot ディレクティブは、 サーバが存在するディレクトリを設定します。 通常、`conf/` や `logs/` といったサブディレクトリが 存在します。 また、他の設定ファイルにおける相対パスは、このディレクトリからとなります。

# 例

ServerRoot /home/httpd
`httpd` の `-d` オプション
ServerRoot
の権限を適切に設定する方法はセキュリティのこつ
ServerSignature
サーバが生成するドキュメントのフッタを設定
ServerSignature On|Off|EMail
ServerSignature Off
server config
virtual host
directory
.htaccess
All

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
server config

このディレクティブは、クライアントに送り返す `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
server config
virtual host
directory
.htaccess
FileInfo
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 で定義された設定を無効にすることが できます。

AddHandler
SetInputFilter
クライアントのリクエストや POST の入力を処理するフィルタを設定する
SetInputFilter filter[;filter...]
server config
virtual host
directory
.htaccess
FileInfo

SetInputFilter ディレクティブはクライアントの リクエストや POST の入力をサーバが受け取ったときに処理するフィルタを 設定します。これは AddInputFilter ディレクティブを含め、他の場所で定義されているフィルタの設定に 追加されます。

複数のフィルタを指定するときは、データを処理する順番に セミコロンで区切る必要があります。

フィルタ説明書
SetOutputFilter
サーバの応答を処理するフィルタを設定する
SetOutputFilter filter[;filter...]
server config
virtual host
directory
.htaccess
FileInfo

SetOutputFilter ディレクティブは サーバの応答をクライアントに送り返される前に処理するフィルタを設定します。 これは AddOutputFilter ディレクティブを含め、他の場所で定義されているフィルタの設定に 追加されます。

例えば、以下の設定は `/www/data/` ディレクトリのすべての ファイルを SSI で処理します。

<Directory /www/data/>
SetOutputFilter INCLUDES
</Directory>

複数のフィルタを指定するときは、データを処理する順番に セミコロンで区切る必要があります。

フィルタ説明書
TimeOut
各イベントについて、リクエストを失敗させるまでにサーバが 待つ時間を設定
TimeOut seconds
TimeOut 300
server config

TimeOut ディレクティブは、現在のところ 以下の三つの待ち時間についての定義を行います:

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

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

UseCanonicalName
サーバが自分自身の名前とポートを決定する方法を設定する
UseCanonicalName On|Off|Dns
UseCanonicalName On
server config
virtual host
directory

多くの状況で Apache は自己参照 URL、すなわち 同じサーバを指す URL、を作成する必要があります。 `UseCanonicalName On` を使うと (1.3 より前の すべてのバージョンでも) Apache は ServerName ディレクティブと Port ディレクティブを使ってサーバの正式な名前を作成します。 この名前がすべての自己参照 URL で使われ、CGI の `SERVER_NAME` と `SERVER_PORT` にも使われます。

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

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

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

# 警告

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

ServerName
Listen
VirtualHost
特定のホスト名や IP アドレスのみに適用されるディレクティブを 囲む
<VirtualHost addr[:port] [addr[:port]] ...> ... </VirtualHost>
server config

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 [fe80::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` コマンドにより 達成できます)。

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

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

# 注意点

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

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

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

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

# セキュリティ

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

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