Apache コア機能

AcceptPathInfo ディレクティブ

このディレクティブは実際のファイル名 (もしくは存在するディレクトリの 存在しないファイル) の後に続くパス名情報があるリクエストを受け付けるか 拒否するかを制御します。続きのパス名情報はスクリプトには 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 に 基づいてコンテンツを生成しているときに必要になります。

AccessFileName ディレクティブ

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

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

参照

• AllowOverride
• 設定ファイル
• .htaccess ファイル

AddDefaultCharset ディレクティブ

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

AddOutputFilterByType ディレクティブ

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

次の例は mod_deflate の DEFLATE フィルタを 使っています。text/html と text/plain の すべての出力 (静的なものも動的なものも) をクライアントに送られる前に 圧縮します。

複数のフィルタでコンテンツを処理させたいときは、それぞれの名前をセミコロンで 分ける必要があります。各フィルタに対して AddOutputFilterByType を一つずつ書くこともできます。

次の例は text/html のスクリプトのすべての出力を まず INCLUDES フィルタで処理し、さらに DEFLATE フィルタにかけます。

参照

• AddOutputFilter
• SetOutputFilter
• フィルタ

AllowEncodedSlashes ディレクティブ

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.

参照

• AcceptPathInfo

AllowOverride ディレクティブ

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

このディレクティブを 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)。

例:

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

参照

• AccessFileName
• 設定ファイル
• .htaccess ファイル

AuthName ディレクティブ

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

例えば:

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

参照

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

AuthType ディレクティブ

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

参照

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

CGIMapExtension ディレクティブ

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

ContentDigest ディレクティブ

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

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

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

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

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

DefaultType ディレクティブ

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

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

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

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

<Directory> ディレクティブ

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

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

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

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

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

• AllowOverride None が適用される。 (.htaccess ファイルは無効になる)
• AllowOverride FileInfo が適用される (/home ディレクトリに対して)。
• /home/.htaccess, /home/web/.htaccess, /home/web/.htaccess の順にそれらのファイル中の FileInfo ディレクティブが適用される。

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

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

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

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

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

参照

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

<DirectoryMatch> ディレクティブ

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

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

参照

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

DocumentRoot ディレクティブ

このディレクティブは、httpd がファイルを提供するディレクトリを設定します。 Alias のようなディレクティブにマッチしない場合には、 ドキュメントの (訳注:ファイルシステム上の) パスを生成するために、 リクエストされた URL のパス部分をドキュメントルートに付与します。 例:

この場合、 http://www.my.host.com/index.html へのアクセスがあれば /usr/web/index.html が返されます。

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

参照

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

EnableMMAP ディレクティブ

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

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

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

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

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

EnableSendfile ディレクティブ

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

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

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

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

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

ErrorDocument ディレクティブ

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

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

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

URL の場合は、ローカルの URL の指定としてスラッシュで始まる (/) パスか、 クライアントが解釈できるフル URL を指定します。
もしくは、ブラウザに表示されるメッセージを指定できます。 例:

加えて、特別な値 default を使って Apache に ハードコードされている簡単なメッセージを指定することができます。 通常は必要ではありませんが、default を使うと 既存の ErrorDocument ディレクティブの設定を 継承するところで、Apache のハードコードされた簡単なメッセージに 戻すことができます。

リモート 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 が絶対パスでないときは、ServerRoot からの相対パスとみなされます。

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

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

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

参照

• LogLevel
• Apache ログファイル

FileETag ディレクティブ

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

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

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

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

参照

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

<FilesMatch> ディレクティブ

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

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

参照

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

ForceType ディレクティブ

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

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

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

HostnameLookups ディレクティブ

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

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

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

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

<IfDefine> ディレクティブ

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

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

• parameter-name
• !parameter-name

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

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

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

<IfModule> ディレクティブ

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

Include ディレクティブ

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

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

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

例:

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

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

参照

• apachectl

KeepAlive ディレクティブ

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 ディレクティブ

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

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

<Limit> ディレクティブ

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

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

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

<LimitExcept> ディレクティブ

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

例:

LimitInternalRecursion ディレクティブ

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

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

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

LimitRequestBody ディレクティブ

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

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

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

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

LimitRequestFields ディレクティブ

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

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

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

例:

LimitRequestFieldSize ディレクティブ

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

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

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

例:

LimitRequestLine ディレクティブ

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

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

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

例:

LimitXMLRequestBody ディレクティブ

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

例:

<Location> ディレクティブ

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

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

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

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

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

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

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

参照

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

<LocationMatch> ディレクティブ

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

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

参照

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

LogLevel ディレクティブ

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

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

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

例:

MaxKeepAliveRequests ディレクティブ

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

例:

NameVirtualHost ディレクティブ

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

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

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

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

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

すべてのインタフェースへのリクエストを受け取るようにするためには、 引数として * を使います。

参照

• バーチャルホスト説明書

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 ディレクティブが + や - 付きで 指定された場合はオプションの値はマージされます。 + を頭につければ現在の設定に加えられ、 - を付ければ現在の設定から削除されます。

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

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

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

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

Require ディレクティブ

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

Require user userid [userid] ...

指定されたユーザのみ、ディレクトリへのアクセスを許可します。

Require group group-name [group-name] ...

指定されたグループに属するユーザのみ、ディレクトリへのアクセスを許可します。

Require valid-user

全ての認証されたユーザに、ディレクトリへのアクセスを許可します。

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

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

参照

• Satisfy
• mod_access

RLimitCPU ディレクティブ

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

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