Apache コア機能

Available Languages: de | en | ja

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

ディレクティブ

AcceptPathInfo
AccessFileName
AddDefaultCharset
AddOutputFilterByType
AllowEncodedSlashes
AllowOverride
AuthName
AuthType
CGIMapExtension
ContentDigest
DefaultType
<Directory>
<DirectoryMatch>
DocumentRoot
EnableMMAP
EnableSendfile
ErrorDocument
ErrorLog
FileETag
<Files>
<FilesMatch>
ForceType
HostnameLookups
IdentityCheck
<IfDefine>
<IfModule>
Include
KeepAlive
KeepAliveTimeout
<Limit>
<LimitExcept>
LimitInternalRecursion
LimitRequestBody
LimitRequestFields
LimitRequestFieldSize
LimitRequestLine
LimitXMLRequestBody
<Location>
<LocationMatch>
LogLevel
MaxKeepAliveRequests
NameVirtualHost
Options
Require
RLimitCPU
RLimitMEM
RLimitNPROC
Satisfy
ScriptInterpreterSource
ServerAdmin
ServerAlias
ServerName
ServerPath
ServerRoot
ServerSignature
ServerTokens
SetHandler
SetInputFilter
SetOutputFilter
TimeOut
UseCanonicalName
<VirtualHost>

AcceptPathInfo ディレクティブ

説明:	後に続くパス名情報を受け付けるリソースの指定
構文:	`AcceptPathInfo On\|Off\|Default`
デフォルト:	`AcceptPathInfo Default`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き:	FileInfo
ステータス:	Core
モジュール:	core
互換性:	Apache 2.0.30 以降で使用可能

このディレクティブは実際のファイル名 (もしくは存在するディレクトリの存在しないファイル) の後に続くパス名情報があるリクエストを受け付けるか拒否するかを制御します。続きのパス名情報はスクリプトには PATH_INFO 環境変数として利用可能になります。

例えば、/test/ が、here.html というファイル一つのみがあるディレクトリを指しているとします。そうすると、 /test/here.html/more と /test/nothere.html/more へのリクエストは両方とも /more を PATH_INFO とします。

AcceptPathInfo ディレクティブに指定可能な三つの引数は:

Off: リクエストは存在するパスにそのままマップされる場合にのみ受け付けられます。ですから、上の例の /test/here.html/more のように、本当のファイル名の後にパス名情報が続くリクエストには 404 NOT FOUND エラーが返ります。
On: 前の方のパスが存在するファイルにマップする場合はリクエストが受け付けられます。上の例の /test/here.html/more は /test/here.html が有効なファイルにマップすれば受け付けられます。
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`
コンテキスト:	サーバ設定ファイル, バーチャルホスト
ステータス:	Core
モジュール:	core

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

AccessFileName .acl

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

<Directory /> AllowOverride None </Directory>

参照

AddDefaultCharset ディレクティブ

説明:	明示的に文字セットを指定していない応答に追加されるデフォルトの文字セット
構文:	`AddDefaultCharset On\|Off\|charset`
デフォルト:	`AddDefaultCharset Off`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き:	FileInfo
ステータス:	Core
モジュール:	core

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

AddDefaultCharset utf-8

AddOutputFilterByType ディレクティブ

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

このディレクティブは応答の 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 スクリプトでコンテントタイプを設定するというものでも大丈夫です。

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

参照

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

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

例:

AllowOverride AuthConfig Indexes

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

参照

AuthName ディレクティブ

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

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

例えば:

AuthName "Top Secret"

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

参照

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

AuthType ディレクティブ

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

このディレクティブは対象ディレクトリで利用するユーザー認証の種類を選びます。ただ、現在のところは Basic と Digest しか実装されていません。このディレクティブは AuthNameディレクティブや Require ディレクティブと、 AuthUserFile や AuthGroupFile などのディレクティブと一緒に利用する必要があります。

参照

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

CGIMapExtension ディレクティブ

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

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

ContentDigest ディレクティブ

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

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

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

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

Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==

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

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

DefaultType ディレクティブ

説明:	サーバがコンテントタイプを決定できないときに送られる MIME コンテントタイプ
構文:	`DefaultType MIME-type`
デフォルト:	`DefaultType text/plain`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き:	FileInfo
ステータス:	Core
モジュール:	core

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

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

DefaultType image/gif

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

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

<Directory> ディレクティブ

説明:	指定のファイルシステムのディレクトリとサブディレクトリとのみに適用されるディレクティブを囲む
構文:	`<Directory directory-path> ... </Directory>`
コンテキスト:	サーバ設定ファイル, バーチャルホスト
ステータス:	Core
モジュール:	core

指定されたディレクトリとそのサブディレクトリにのみディレクティブを適用させるためには、 <Directory> と </Directory> を対として、ディレクティブ群を囲います。その中には、ディレクトリコンテキストで許可された全てのディレクティブを利用できます。 directive-path は、フルパスもしくは Unix のシェル形式のワイルドカードを指定します。 ? は任意の 1 文字、* は任意の文字列にマッチします。シェルにおける指定同様、文字の範囲を [] で指定できます。ワイルドカードは `/' 文字にはマッチしませんので、 /home/user/public_html には <Directory /*/public_html> はマッチしませんが、 <Directory /home/*/public_html> はマッチします。例:

<Directory /usr/local/httpd/htdocs> Options Indexes FollowSymLinks </Directory>

directory-path 引数には注意してください: その引数は Apache がファイルをアクセスするために使うファイルシステムのパスにそのままマッチする必要があります。ある <Directory> に適用されるディレクティブは、別のシンボリックリンクをたどったりして同じディレクトリを違うパスでアクセスした場合には適用されません。

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

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

といった指定の場合、/www/ 以下にある数字 3 文字のディレクトリにマッチします。

もし複数の (正規表現以外の) <Directory>セクションがドキュメントを含むディレクトリ (やその上位ディレクトリのどれか) とマッチしたならば、 .htaccess ファイルのディレクティブも読み込みつつ、短いパスから順に適用されます。例えば、

<Directory /> AllowOverride None </Directory> <Directory /home/> AllowOverride FileInfo </Directory>

と設定し、ドキュメント /home/web/dir/doc.html へのアクセスがあった場合には以下のように動作します:

AllowOverride None が適用される。 (.htaccess ファイルは無効になる)
AllowOverride FileInfo が適用される (/home ディレクトリに対して)。
/home/.htaccess, /home/web/.htaccess, /home/web/.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 が返されます。

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

参照

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

EnableMMAP ディレクティブ

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

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

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

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

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

EnableMMAP Off

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

<Directory "/path-to-nfs-files"> EnableMMAP Off </Directory>

EnableSendfile ディレクティブ

説明:	ファイルのクライアントへの配送時にカーネルの sendfile サポートを使うかどうか
構文:	`EnableSendfile On\|Off`
デフォルト:	`EnableSendfile On`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き:	FileInfo
ステータス:	Core
モジュール:	core
互換性:	バージョン 2.0.44 以降で使用可能

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

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

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

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

EnableSendfile Off

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

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

ErrorDocument ディレクティブ

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

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

Apache 標準の簡単なエラーメッセージを表示
自分で指定したメッセージを表示
問題やエラーの処理をする為に、自サーバ内の URL-path へリダイレクト
問題やエラーの処理をする為に、外部の 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"

加えて、特別な値 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 にあります。

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

参照

FileETag ディレクティブ

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

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

INode: ファイルの inode 番号を計算に使います
MTime: ファイルの最終修正時刻を使います
Size: ファイルの中身のバイト数を使います
All: 使用可能なすべてのフィールドを使います。これは
FileETag INode MTime Size
と等価です。
None: ドキュメントがファイルに基づいたものでも、ETag フィールドを応答に付加しません

INode, MTime, Size キーワードには + や - を前に付けて指定することもできます。この場合は、より広い範囲から継承されたデフォルトの設定に変更を加えるようになります。そのような接頭辞の無いキーワードを指定すると、即座に継承した設定を無効にします。

あるディレクトリの設定に FileETag INode MTime Size があり、サブディレクトリの設定に FileETag -INode があるときは、そのサブディレクトリの設定は (設定が上書きされなければサブディレクトリのサブディレクトリにも継承されます) FileETag MTime Size と同じになります。

<Files> ディレクティブ

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

<Files> ディレクティブは、その中にあるディレクティブの適用範囲をファイル名で制限します。 <Directory> ディレクティブや <Location> ディレクティブと同じような機能を持ちます。これは、</Files> ディレクティブと対になっていなければなりません。このセクション中のディレクティブは、ベース名 (ファイル名の最後の部分) が指定されたファイル名にマッチするすべてのオブジェクトに適用されます。 <Files> セクションは <Directory> セクションと .htaccess が読み込まれた後、 <Location> セクションよりは先に設定ファイルに現れた順に適用されます。 <Files> は、 <Directory> セクション内にネストさせることができ、ファイルシステムの一部にのみ限定して適用させることができます。

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

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

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

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

参照

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

<FilesMatch> ディレクティブ

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

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

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

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

参照

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

ForceType ディレクティブ

説明:	すべてのマッチするファイルが指定の MIME コンテントタイプで送られるようにする
構文:	`ForceType MIME-type\|None`
コンテキスト:	ディレクトリ, .htaccess
上書き:	FileInfo
ステータス:	Core
モジュール:	core
互換性:	Apache 2.0 で core に移動

.htaccess や <Directory> セクション、 <Location> セクション、 <Files> セクションに書かれた場合、このディレクティブはそこにあるすべてのファイルが MIME-type で指定されたコンテントタイプとして扱われるようにします。たとえば、 GIF ファイルばかりのディレクトリがあって、すべてのファイルを .gif で終わらせたくはないときに、以下のものを使用します:

ForceType image/gif

DefaultType と違ってこのディレクティブはメディアタイプを決めることができるかもしれないファイルの拡張子も含め、すべての MIME タイプの関連付けを上書きすることに注意してください。

None という値を使うことで ForceType の設定を無効にできます:

# force all files to be image/gif: <Location /images> ForceType image/gif </Location> # but normal mime-type associations here: <Location /images/mixed> ForceType None </Location>

HostnameLookups ディレクティブ

説明:	クライアントの IP アドレスの DNS ルックアップを有効にする
構文:	`HostnameLookups On\|Off\|Double`
デフォルト:	`HostnameLookups Off`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:	Core
モジュール:	core

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

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

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

IdentityCheck ディレクティブ

説明:	リモートユーザの RFC1413 によるアイデンティティのロギングを有効にする
構文:	`IdentityCheck On\|Off`
デフォルト:	`IdentityCheck Off`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:	Core
モジュール:	core

このディレクティブは、クライアントマシン上で identd やそれに類似したデーモンが動作しているときに、それぞれの接続に対して RFC 1413 に準処したリモートユーザの名前のロギングを行なうようにします。この情報は、アクセスログに収集されます。

ここで得られた情報は簡単なユーザ追跡に使う以外は、まったく信頼するべきではありません。

すべてのリクエストに対してルックアップが行なわれますので、深刻な遅延の問題を起こすかもしれないことに注意してください。 (訳注: 例えばクライアント側に) ファイアウォールがあると、ルックアップが失敗し、各リクエストに 30 秒の遅延が加わることになる可能性があります。従って、一般的にはインターネットからアクセス可能なパブリックなサーバで有益なものではありません。

<IfDefine> ディレクティブ

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

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

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

parameter-name
!parameter-name

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

parameter-name 引数は、サーバを起動する際に httpd のコマンドラインに -Dparameter- という形で指定すると定義されます。

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

httpd -DReverseProxy ... # httpd.conf <IfDefine ReverseProxy> LoadModule rewrite_module modules/mod_rewrite.so LoadModule proxy_module modules/libproxy.so </IfDefine>

<IfModule> ディレクティブ

説明:	モジュールの存在するかしないかに応じて処理されるディレクティブを囲む
構文:	`<IfModule [!]module-name> ... </IfModule>`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き:	All
ステータス:	Core
モジュール:	core

<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`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:	Core
モジュール:	core
互換性:	ワイルドカードによるマッチは 2.0.41 以降で使用可能

このディレクティブにより、サーバの設定ファイルから他の設定ファイルをインクルードすることができます。

複数のファイルをアルファベット順に一度に読み込むために、シェル形式 (fnmatch) のワイルドカード文字を使うことができます。さらに、Include にディレクトリを指定した場合は、ディレクトリとそのサブディレクトリ内の全てのファイルをアルファベット順に読み込んで、設定ファイルとして処理します。しかし、ディレクトリ全体を読み込むのはお勧めできません。ふとしたことから httpd が読み込みに失敗するような一時ファイルをディレクトリに残してしまうようなことがよくあるからです。

指定するファイルパスは絶対パスか、 ServerRoot ディレクトリからの相対パスか、のどちらかです。

例:

Include /usr/local/apache2/conf/ssl.conf Include /usr/local/apache2/conf/vhosts/*.conf

ServerRoot からの相対パスの場合は:

Include conf/ssl.conf Include conf/vhosts/*.conf

apachectl configtest を実行すると、設定をチェックしている時に読み込まれたファイルのリストが表示されます:

root@host# apachectl configtest Processing config file: /usr/local/apache2/conf/ssl.conf Processing config file: /usr/local/apache2/conf/vhosts/vhost1.conf Processing config file: /usr/local/apache2/conf/vhosts/vhost2.conf Syntax OK

参照

apachectl

KeepAlive ディレクティブ

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

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

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

参照

MaxKeepAliveRequests

KeepAliveTimeout ディレクティブ

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

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

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

<Limit> ディレクティブ

説明:	囲いの中にあるアクセス制御の適用を特定の HTTP メソッドのみに制限する
構文:	`<Limit method [method] ... > ... </Limit>`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き:	All
ステータス:	Core
モジュール:	core

アクセス制御は、通常全てのアクセスメソッドに対して影響し、普通はこれが望ましい挙動です。 そうしたことから、大部分の場合にはアクセス制御に関わるディレクティブを <Limit> セクション内に書くべきではありません。

<Limit> ディレクティブの目的は、アクセス制御の範囲を指定された HTTP メソッドに限定するためです。それ以外のメソッドは、<Limit> で囲われたアクセス制御の 影響を受けません。以下の例は、POST, PUT, DELETE のメソッドに対してのみアクセスの制御を行ない、それ以外のメソッドについては制限しません:

<Limit POST PUT DELETE> Require valid-user </Limit>

メソッド名には以下の中から一つ以上を列挙することができます: GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK. メソッド名は大文字小文字を区別します。 GET を指定した場合には HEAD リクエストにも制限がかかります。TRACE メソッドに制限をかけることはできません。

アクセス制御が目的の場合は <Limit> セクションの代わりに <LimitExcept> セクションを使用した方が良いでしょう。 <LimitExcept> セクションでは不特定のメソッドに対しても防御できるからです。

<LimitExcept> ディレクティブ

説明:	指定されたもの以外の HTTP メソッドにアクセス制御を制限する
構文:	`<LimitExcept method [method] ... > ... </LimitExcept>`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き:	All
ステータス:	Core
モジュール:	core

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

例:

<LimitExcept POST GET> Require valid-user </LimitExcept>

LimitInternalRecursion ディレクティブ

説明:	内部リダイレクトと入れ子になったサブリクエストの最大数を決定する
構文:	`LimitInternalRecursion number [number]`
デフォルト:	`LimitInternalRecursion 10`
コンテキスト:	サーバ設定ファイル, バーチャルホスト
ステータス:	Core
モジュール:	core
互換性:	Apache 2.0.47 以降で使用可能

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

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

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

例

LimitInternalRecursion 5

LimitRequestBody ディレクティブ

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

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

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

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

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

LimitRequestBody 102400

LimitRequestFields ディレクティブ

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

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

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

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

例:

LimitRequestFields 50

LimitRequestFieldSize ディレクティブ

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

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

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

例:

LimitRequestFieldSize 4094

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

LimitRequestLine ディレクティブ

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

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

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

例:

LimitRequestLine 4094

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

LimitXMLRequestBody ディレクティブ

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

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

例:

LimitXMLRequestBody 0

<Location> ディレクティブ

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

<Location> ディレクティブは、 URL により中に書かれたディレクティブの適用範囲を制限します。 <Directory> ディレクティブと似ていて、 </Location> ディレクティブで終了するサブセクションを開始します。 <Location> セクションは、 <Directory> セクションと .htaccess の読み込みの後、 <Files> セクションを適用した後に、設定ファイルに現れた順に処理されます。

<Location> セクションは完全にファイルシステムと関連せずに動作します。このことから導かれる結果にはいつくか注意する点があります。最も重要なものは、ファイルシステムの位置へのアクセス制御に <Location> ディレクティブを使うべきではないということです。複数の URL がファイルシステムの同じ位置にマップされる可能がありますので、そのようなアクセス制御は回避されてしまう可能性があります。

いつ `<Location>` を使うか

<Location> ディレクティブはファイルシステム外のコンテンツにディレクティブを適用するときに使用してください。ファイルシステムに存在するコンテンツに対しては、 <Directory> と <Files> を使ってください。例外は、<Location /> で、これはサーバ全体に対して設定を適用する簡単な方法です。

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

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

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

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

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

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

<Location /status> SetHandler server-status Order Deny,Allow Deny from all Allow from .foo.com </Location>

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

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

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

参照

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

<LocationMatch> ディレクティブ

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

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

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

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

参照

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

LogLevel ディレクティブ

説明:	ErrorLog の冗長性を制御する
構文:	`LogLevel level`
デフォルト:	`LogLevel warn`
コンテキスト:	サーバ設定ファイル, バーチャルホスト
ステータス:	Core
モジュール:	core

LogLevel は、エラーログ (ErrorLog ディレクティブを見てください) へ記録するメッセージの冗長性を調整します。以下の level を指定でき、順に重要度が下がっていきます。

レベル	説明	例
`emerg`	緊急 - システムが利用できない	Child cannot open lock file. Exiting (子プロセスがロックファイルを開けないため終了した)
`alert`	直ちに対処が必要	getpwuid: couldn't determine user name from uid (getpwuid: UID からユーザ名を特定できなかった)
`crit`	致命的な状態	socket: Failed to get a socket, exiting child (socket: ソケットが得られないため、子プロセスを終了させた)
`error`	エラー	Premature end of script headers (スクリプトのヘッダが足りないままで終わった)
`warn`	警告	child process 1234 did not exit, sending another SIGHUP (子プロセス 1234 が終了しなかった。もう一度 SIGHUP を送る)
`notice`	普通だが、重要な情報	httpd: caught SIGBUS, attempting to dump core in ... (httpd: SIGBUS シグナルを受け、... へコアダンプをした)
`info`	追加情報	"Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..." (「サーバは負荷が高い、 (StartServers や Min/MaxSpareServers の値を増やす必要があるかも)」)
`debug`	デバッグメッセージ	"Opening config file ..." (設定ファイルを開いている...)

特定のレベルが指定された場合、それより高いレベルの全てのメッセージが報告されます。 例えば、LogLevel info に指定すると、 notice と warn も報告されます。

なお crit 以上のレベルを指定することが推奨されます。

例:

LogLevel notice

注

ファイルにログを出力する場合、notice レベルのメッセージは抑制されず、すべてログに出力されます。しかし syslog を使用している場合は、これは当てはまりません。

MaxKeepAliveRequests ディレクティブ

説明:	持続的な接続上で許可されるリクエストの数
構文:	`MaxKeepAliveRequests number`
デフォルト:	`MaxKeepAliveRequests 100`
コンテキスト:	サーバ設定ファイル, バーチャルホスト
ステータス:	Core
モジュール:	core

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

例:

MaxKeepAliveRequests 500

NameVirtualHost ディレクティブ

説明:	名前ベースのバーチャルホストのための IP アドレスを指定
構文:	`NameVirtualHost addr[:port]`
コンテキスト:	サーバ設定ファイル
ステータス:	Core
モジュール:	core

NameVirtualHost ディレクティブは、名前ベースのバーチャルホストの設定を行ないたい場合に必要となるものです。

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

NameVirtualHost 111.22.33.44

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

中

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

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

NameVirtualHost 111.22.33.44:8080

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

NameVirtualHost [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`
コンテキスト:	サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
上書き:	Options
ステータス:	Core
モジュール:	core

Options ディレクティブは、特定のディレクトリに対してどの機能が使用可能かを制御します。

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

All: MultiViews を除いた全ての機能が有効となります。これがデフォルトです。
ExecCGI: mod_cgi による CGI スクリプトの実行を許可します。
FollowSymLinks: サーバが、このディレクトリ内でシンボリックリンクをたどれるようにします。
サーバがシンボリックリンクをたどる場合でも、 <Directory> セクションにマッチさせるためのパス名は変更されません。

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

通常、ディレクトリに対して複数の Options が適用可能な場合、最も近いもの一つのみが適用され、他のものは無視されます。複数の指定がマージされるわけではありません。(セクションのマージ方法を参照してください。) しかし、すべての Options ディレクティブが + や - 付きで指定された場合はオプションの値はマージされます。 + を頭につければ現在の設定に加えられ、 - を付ければ現在の設定から削除されます。

例えば、+ や - を利用しない場合は:

<Directory /web/docs> Options Indexes FollowSymLinks </Directory> <Directory /web/docs/spec> Options Includes </Directory>

/web/docs/spec というディレクトリには、 Includes だけが適用されます。しかし、2 番目の Options で + や - を利用してみると:

<Directory /web/docs> Options Indexes FollowSymLinks </Directory> <Directory /web/docs/spec> Options +Includes -Indexes </Directory>

/web/docs/spec というディレクトリには、 FollowSymLinks と Includes が適用されます。

注

-IncludesNOEXEC もしくは -Includes を指定すると、前の設定がどのようになっていようとも SSI は無効となります。

どのような設定もされていなければ、デフォルトでは All になります。

Require ディレクティブ

説明:	どの認証済みユーザがリソースをアクセスできるかを選択する
構文:	`Require entity-name [entity-name] ...`
コンテキスト:	ディレクトリ, .htaccess
上書き:	AuthConfig
ステータス:	Core
モジュール:	core

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

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_access

RLimitCPU ディレクティブ

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

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

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

CPU リソースのリミットはプロセスあた�