[APACHE DOCUMENTATION]

Apache HTTP Server Version 1.3

Apache コア機能

以下のディレクティブは Apache のコア機能をコントロールするもので、常に利用可能です。

ディレクティブ


AcceptFilter ディレクティブ

構文: AcceptFilter on|off
デフォルト: AcceptFilter on
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: AcceptFilter は Apache 1.3.22 以降で利用可能です。

AcceptFilter は、BSD に特有のフィルタの最適化をコントロールします。 この機能はデフォルトで組み込まれます。 そして、システムがこの機能をサポート (setsocketopt() で SO_ACCEPTFILTER オプションが利用できる) していれば、デフォルトで有効となります。 現在のところ、FreeBSD においてのみサポートされています。

詳しい情報を得るには、性能のヒントのフィルタセクションを 見てください。

なお、コンパイル時に AP_ACCEPTFILTER_OFF フラグを利用すればデフォルトを無効にすることが可能です。 httpd -Vhttpd -L を利用することによって、コンパイル時のデフォルトと SO_ACCEPTFILTER が有効になっているかどうかを参照することができます。


AcceptMutex ディレクティブ

構文: AcceptMutex uslock|pthread|sysvsem|fcntl|flock|os2sem|tpfcore|none|default
デフォルト: AcceptMutex default
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: AcceptMutex は Apache 1.3.21 以降で利用可能です。

AcceptMutex は、accept() においてどの方法の mutex を利用するのかを指定します。なお、利用できる mutex はコンパイル時に決定され、 プラットフォームによってはすべての方法は利用できないことがあります。 利用できる mutex は、コマンドラインオプションで httpd -V を指定すると一覧が表示されます。

コンパイル時のフラグとして -D HAVE_METHOD_SERIALIZED_ACCEPT を指定することによって、異なる方法を追加することもでき、 特定のプラットフォーム向けに include/ap_config.h を編集することも可能です。

このディレクティブは Microsoft Windows に対して指定しても効果はありません

詳しい情報についてはパフォーマンスチューンニングを 参照してください。


AccessConfig ディレクティブ

構文: AccessConfig file-path|directory-path|wildcard-path
デフォルト: AccessConfig conf/access.conf
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性:Apache 1.3.13 以降でのみ、ファイル名の代わりにディレクトリパスを指定できます。 このディレクティブはバージョン 2.0 以降には存在しません。

ResourceConfig ファイルを読み込んだ後、 それに加えて多くのディレクティブをここで記したファイルから読み込みます。 File-path は、ServerRoot で記したパスからの、相対パスです。
なお、この機能を無効にするには次のように指定します。

AccessConfig /dev/null
Win32 の場合
AccessConfig nul
以前は、このファイルには <Directory> セクションのみが書かれていました。 現在ではサーバ設定ファイルに記述できることすべてが記述可能になっています。 ただ、Apache のバージョン 1.3.4 以降では、 Apache と共に配布されているデフォルトの access.conf ファイルにはコメントしか書かれておらず、 すべてのディレクティブが主となるサーバ設定ファイルの httpd.conf に記述されています。

もし、この AccessConfig ディレクティブに、ファイルではなくディレクトリが指定されれば、 Apache はそのディレクトリ内のすべてのファイルを読み込み、 それらを設定ファイルとして処理します。

代わりに、ワイルドカードを使って範囲を絞ることもできます。 すなわち、*.conf ファイルのみ、といったように。

デフォルトでは指定されたディレクトリの「どのような」 ファイルでも設定ファイルとして読み込まれます。

ですから誤って (例えばエディタでテンポラリファイルを作成する等) ファイルを置かないように注意してください。

参照: Include,ResourceConfig.


AccessFileName ディレクティブ

構文: AccessFileName filename [filename] ...
デフォルト: AccessFileName .htaccess
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性: AccessFileName は Apache 1.3 以降においてのみ複数のファイル名を指定できます。

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

AccessFileName .acl
のように指定されていると、 /usr/local/web/index.html を返す場合、以下のようにして無効にされていない限り、 ドキュメントを返す前に /.acl, /usr/.acl, /usr/local/.acl, /usr/local/web/.acl からディレクティブを読み込みます。
<Directory />
AllowOverride None
</Directory>

参照: AllowOverride 及び 設定ファイル


AddDefaultCharset ディレクティブ

構文: AddDefaultCharset On|Off|charset
コンテキスト: すべて
ステータス: core
デフォルト: AddDefaultCharset Off
互換性: AddDefaultCharset は Apache 1.3.12 以降で利用可能です。

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

例:

AddDefaultCharset utf-8

注意: これはデフォルトで Apache が生成するステータスページ ('404 Not Found' や '301 Moved Permanently' など) には影響しません。 それらは、(ページの内容がハードコードされて書かれている) 実際の 文字セットがあるため、デフォルトが適用される必要はないからです。


AddModule ディレクティブ

構文: AddModule module [module] ...
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: AddModule は Apache 1.2 以降で利用可能です。

Apache では、使用しないコンパイル済みのモジュールを持つことができます。 このディレクティブは、それらのモジュールを使用するようにできます。 起動後、あらかじめ使用モジュールのリストを作成していますが、 ClearModuleList ディレクティブによりそのリストの中身を消すことができます。

例:

AddModule mod_include.c

AddModule の順番は重要です。モジュールは優先度の 逆順に書きます―後に書かれているものは前の方に書かれているものの 振る舞いを上書きすることができます。これは、目に見える影響があります。 例えば、UserDir が Alias の後にあれば、ユーザのホームディレクトリの エイリアスを作ることはできません。より詳しい情報と、推奨されている 順番については Apache ソース配布中の src/Configuration.tmpl を参照してください。

参照: ClearModuleListLoadModule


AllowOverride ディレクティブ

構文: AllowOverride All|None|directive-type [directive-type] ...
デフォルト: AllowOverride All
コンテキスト: ディレクトリ
ステータス: core

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

Note: AllowOverride is only valid in <Directory> sections, not in <Location> or <Files> sections, as implied by the Context section above.

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

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

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

AuthConfig
認証に関するディレクティブの使用を許可する (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthDigestRealmSeed, AuthType, AuthUserFile, Require など)。
FileInfo
ドキュメントタイプを制御するためのディレクティブの使用を許可する (AddEncoding, AddLanguage, AddType, DefaultType, ErrorDocument, LanguagePriority など)。
Indexes
ディレクトリインデックスを制御するためのディレクティブの使用を許可する (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName など)。
Limit
ホストへのアクセス制御を行うためのディレクティブの使用を許可する (Allow, Deny and Order).
Options
特定のディレクトリにおける機能を指定するためのディレクティブの使用を許可する (OptionsXBitHack).

例:

AllowOverride AuthConfig Indexes

参照: AccessFileName 及び 設定ファイルの記述


AuthName ディレクティブ

構文: AuthName auth-domain
コンテキスト: ディレクトリ、 .htaccess
上書き: AuthConfig
ステータス: core

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

例:

AuthName "秘密のパスワード"

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

訳注: 引数に与える文字列は英数字やハイフンなどの記号のみを利用するべきですが、2 バイト文字を指定した場合でも、 Apache は通常の文字列同様にクライアントへ送出します。 (ただサポートが表明されているわけではありません)

参照: 認証、承認、アクセス制御


AuthDigestRealmSeed directive

構文: AuthDigestRealmSeed secret-real-string
コンテキスト: ディレクトリ、 .htaccess
上書き: AuthConfig
ステータス: コア

このディレクティブは認可領域ごとの秘密の一度きりの接頭辞を 設定します。これは Digest 交換の間に取得したユーザ名、パスワード、認可領域名文字列を、 他の場所で再利用できない様にします。

これは mod_digest.html にしか適用されません。 実験的な mod_auth_digest.html は専用の再利用対策 (より進んだ、時間も考慮したもの) を実装しています。

動作するためには AuthType に Digest のタイプ、 Require ディレクティブと AuthUserFileAuthGroupFile ディレクティブが設定されていることが必要です。

参照: 認証、承認、アクセス制御


AuthType ディレクティブ

構文: AuthType Basic|Digest
コンテキスト: ディレクトリ、 .htaccess
上書き: AuthConfig
ステータス: core

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

AuthDigest が使われると AuthDigestRealmSeed もセットされます。

参照: 認証、承認、アクセス制御


BindAddress ディレクティブ

構文: BindAddress *|IP-address|domain-name
デフォルト: BindAddress *
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: BindAddress は 非推奨で Apache 2.0 では削除されます。

Unix® において HTTP サーバは、サーバのすべての IP アドレスを listen することができ、一つの IP アドレスだけを listen することもできます。このディレクティブに * を指定すると、サーバはすべての IP アドレス上で listen を行います。それ以外の場合は、特定の IP-addressdomain-name のみで listen します。

例:

BindAddress 192.168.15.48

なお、BindAddress ディレクティブは一つしか利用できません。

このディレクティブは Apache 2.0 においては非推奨で、取り除かれています。 代わりに、同等の機能を持ちかつ複数のアドレスやポートにおいて listen できるようになった Listen ディレクティブを利用できます。

BindAddress は、<VirtualHost> セクションを使う代わりに、複数のサーバを起動してバーチャルホストをサポートする ために利用することができます。

参照: DNS に関する問題
参照: Apache が利用するアドレスとポートの設定


BS2000Account ディレクティブ

構文: BS2000Account account
デフォルト: none
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: BS2000Account は BS2000 マシンでかつ Apache 1.3.22 以降でのみ利用可能です。

BS2000Account ディレクティブは、BS2000 ホストでのみ有効であり、(User ディレクティブを利用して) Apache を実行する権限を管理者以外のアカウント番号に指定する必要があります。 これは、CGI スクリプトが、通常 SYSROOT である、サーバを起動した管理者権限を持つアカウントの リソースにアクセスできないようにするために、 (サブログインによって、BS2000 のタスク環境下に置かれる) BS2000 の POSIX サブシステムにおいて必要です。BS2000Account ディレクティブは 1 回だけ利用できます。

参照: Apache の EBCDIC への移植版


CGICommandArgs directive

構文: CGICommandArgs On|Off
デフォルト: CGICommandArgs On
コンテキスト: ディレクトリ、.htaccess
上書き: Options
ステータス: core
互換性: Apache 1.3.24 以降で使用可能。

昔々、インターネットがより安全で純粋だったときには、 サーバが '=' 文字を含まないクエリー文字列を受け取って解析し、 CGI プログラムへコマンドラインの引数として渡すと便利なことがありました。 例えば、<IsIndex> により生成された検索はよく そのように動作していました。このような動作は今日では一般に 安全でないと見なされていますが、Apache のデフォルトの動作は 後方互換性のためにこの振る舞いを維持しています。たいていの CGI プログラムはコマンドラインの引数を受け付けませんが、引数を 受け付けるものの中では、ほとんどがこの引数の渡し方に気付いておらず、 悪意のあるクライアントがこの方法を使って安全でないものを渡す ことに対する脆弱性があります。そのようなスクリプトを Apache の機能をほぼ損なうことなく保護するために、 CGICommandArgs Off と設定することが推奨されています。


ClearModuleList ディレクティブ

構文: ClearModuleList
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: ClearModuleList は Apache 1.2 以降で利用可能です。

サーバはあらかじめ有効なモジュールの一覧を持っています。 このディレクティブはその一覧をクリアします。後で AddModule ディレクティブを使って モジュールを一覧に再び加えることが期待されています。

参照: AddModuleLoadModule


ContentDigest ディレクティブ

構文: ContentDigest on|off
デフォルト: ContentDigest off
コンテキスト: サーバ設定ファイル、 バーチャルホスト、ディレクトリ、.htaccess
上書き: Options
ステータス: experimental
互換性: ContentDigest は Apache 1.1 以降で利用可能です。

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

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

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

   Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==

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

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


CoreDumpDirectory ディレクティブ

構文: CoreDumpDirectory ディレクトリパス
デフォルト: ServerRoot と同じ場所
コンテキスト: サーバ設定ファイル
ステータス: core

これにより、Apache がコアダンプをする前に移動するためのディレクトリを指定できます。 デフォルトの場合は、ServerRoot において指定したディレクトリとなるものの、 通常の場合はサーバを実行しているユーザによって書き込み権限が無く、 コアダンプが残されることはありません。 もし、デバッグのためにコアダンプが必要なのであれば、 このディレクティブにより違う場所に設定をすることができます。

設定例:

CoreDumpDirectory /tmp

DefaultType ディレクティブ

構文: DefaultType MIME-type
デフォルト: DefaultType text/html
コンテキスト: サーバ設定ファイル、 バーチャルホスト、ディレクトリ、.htaccess
上書き: FileInfo
ステータス: core

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

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

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

参照: AddType 及び TypesConfig


<Directory> ディレクティブ

構文: <Directory directory-path|proxy:url-path> ... </Directory>
コンテキスト: サーバ設定ファイル、 バーチャルホスト
ステータス: Core

指定されたディレクトリ配下にのみディレクティブを適用させるために、 <Directory> 及び </Directory> を対として、ディレクティブ群を囲うことができます。 囲いの中では、ディレクトリコンテキストで許可されたすべての ディレクティブが利用できます。directive-path は、フルパス若しくはワイルドカードにて指定します。 `?' は任意の 1 文字、`*' は任意の文字列にマッチします。Apache 1.3 の場合、シェルにおける指定同様、文字の範囲指定を `[ ]' で可能です。 また、Apache 1.3では、UNIX のシェルの挙動に似せるために、 ワイルドカードは `/' 文字にはマッチしません。 例:

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

Apache 1.2 以降の場合: ~ という文字を付加することで拡張正規表現を利用することもできます。
例えば、

   <Directory ~ "^/www/.*/[0-9]{3}">
といった指定の場合、/www/ 以下にある数字 3 文字のディレクトリにマッチします。

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

<Directory />
AllowOverride None
</Directory>

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

ディレクトリセクションにおける正規表現については、Apache 1.2 と 1.3 で若干扱いが違います。

Apache 1.2 の場合、通常のディレクトリセクションが同じく、 設定ファイル内に現れる順に評価されます。正規表現のディレクトリセクションは、 一番短くマッチした場合に一度だけ適用されます。 Apache 1.3 では、 正規表現は、通常のセクションがすべて適用されるまで考慮されません。 その後、すべての正規表現が設定ファイルに現れた順で試されます。 例えば、以下のような場合に

<Directory ~ abc$>
... directives here ...
</Directory>
アクセスされているファイル名が /home/abc/public_html/abc/index.html であるとしましょう。サーバは /, /home, /home/abc, /home/abc/public_html 及び /home/abc/public_html/abc の順に考慮します。 Apache 1.2 であれば、/home/abc の評価をする際に、正規表現がマッチし適用されます。 Apache 1.3 の場合は正規表現はツリー上のその時点では全く考慮されません。 すべての通常の <Directory> と .htaccess ファイルが評価されるまで、考慮されません。その後、正規表現は /home/abc/public_html/abc にマッチし、適用されます。

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

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

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

<Directory> ディレクティブは入れ子にすることができず、 <Limit><LimitExcept> セクションの中にも記述できません。

mod_proxy が有効になっている場合、 proxy: 構文を使って、プロキシされているコンテンツに 対して適用させることができます。この構文は設定を適用したい プロキシされている URL を指定するか、プロキシされているコンテンツすべてに 適用させるために * を指定する、というようになっています:

すべてのプロキシされているコンテンツに適用させるには:

   <Directory proxy:*>
     ... directives here ...
   </Directory>
   

プロキシされているコンテンツの一部分にのみ適用させるには:

   <Directory proxy:http://www.example.com/>
     ... directives here ...
   </Directory>
   

参照: リクエストを受けた際に、 異なる複数のセクションがどのようにして組み合わされるのかについては Directory, Location 及び Files セクションがどのように動作するのか

参照: DirectoryMatch


<DirectoryMatch>

構文: <DirectoryMatch regex> ... </DirectoryMatch>
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: Core
互換性: Apache 1.3 以降で使用可能

指定されたディレクトリ配下にのみディレクティブを適用させるために、 <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

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

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

ところで、DocumentRoot の引数のパスの最後の文字にスラッシュが指定されていると (例えば、"DocumentRoot /usr/web/" のように) 問題が起こるという mod_dir のバグがあるようです。 そのため、このような指定はしないようにしてください。


EBCDICConvert

構文: EBCDICConvert On|Off[=direction] extension [extension] ...
コンテキスト: サーバ設定ファイル、 バーチャルホスト、ディレクトリ、.htaccess
ステータス: core
上書き: FileInfo
互換性: EBCDICConvert は Apache 1.3.19 以降でかつ EBCDIC ベースのプラットフォームにおいてのみ利用可能です。

EBCDICConvert ディレクティブは与えられたファイルの拡張子を指定の変換設定 (OnOff) にマップします。 拡張子の最初のドットはあってもなくても構いません。

オプションの形式 On=direction (や Off=direction) が指定されると (directionIn, Out, InOut のどれか)、 ディレクティブは指定された向きにだけ適用されます (In: PUT や POST リクエストでコンテンツをアップロード、Out: GET や POST リクエストで返されるコンテンツ、InOut: 両方の向きで変換)。
それ以外の形式では、InOut (両方の向きで変換) であるとみなされます。

一般的な MIME に基づいたルールを、 より細かいファイルの拡張子に基づいたルールが上書きできるように、 拡張子に基づいた設定は MIME タイプに基づいた設定より前に試されます。

:
以下の設定では、普通の *.html ファイルは EBCDIC エンコーディングの HTML で、*.ahtml ファイルは ASCII エンコーディングの HTML です:

    # *.html と *.ahtml は HTML:
    AddType  text/html  .html .ahtml

    # *.ahtml は変換されない (既に ASCII になっている):
    EBCDICConvert       Off .ahtml

    # 他のすべての text/html ファイルは EBCDIC のはず:
    EBCDICConvertByType On  text/html


参照: EBCDICConvertByTypeEBCDICConvertByType 変換関数の概要


EBCDICConvertByType

構文: EBCDICConvertByType On|Off[=direction] mimetype [mimetype] ...
コンテキスト: サーバ設定ファイル、 バーチャルホスト、ディレクトリ、.htaccess
ステータス: core
上書き: FileInfo
互換性: EBCDICConvertByType は Apache 1.3.19 以降でかつ EBCDIC ベースのプラットフォームにおいてのみ 利用可能です。

EBCDICConvertByType ディレクティブは与えられた MIME タイプ (ワイルドカードも可) を指定された変換設定 (OnOff) にマップします。

オプションの形式 On=direction (や Off=direction) が指定されると (directionIn, Out, InOut のどれか)、 ディレクティブは指定された向きにだけ適用されます (In: PUT や POST リクエストでコンテンツをアップロード、Out: GET や POST リクエストで返されるコンテンツ、InOut: 両方の向きで変換)。
それ以外の形式では、InOut (両方の向きで変換) であるとみなされます。

:
有用な標準設定には以下のデフォルトがあるべきです:

    # すべてのテキストドキュメントは EBCDIF のファイル:
    EBCDICConvertByType On  text/* message/* multipart/*
    EBCDICConvertByType On  application/x-www-form-urlencoded \
                model/vrml application/postscript
    # すべての他のファイルはバイナリとみなす
    EBCDICConvertByType Off */*
例えば NFS でマウントされた unix サーバからドキュメントを送る、というように ASCII のドキュメントのみを扱う場合は、以下のようにしてください:
    # すべてのドキュメントは既に ASCII
    EBCDICConvertByType Off */*

参照: EBCDICConvertEBCDIC 変換関数の概要


EBCDICKludge

構文: EBCDICKludge On|Off
デフォルト: EBCDICKludge Off
コンテキスト: サーバ設定ファイル、 バーチャルホスト、ディレクトリ、.htaccess
ステータス: core
上書き: FileInfo
互換性: EBCDICKludge は Apache 1.3.19 以降で EBCDIC ベースのプラットフォームでのみ使用可能です。 非推奨で、将来のバージョンでは削除される予定です。

EBCDICKludge は apache のバージョン 1.3.0 から 1.3.18 との互換性を保つために提供されています。それらのバージョンでは、 "text/", "message/", "multipart" で始まる MIME タイプと、 "application/x-www-form-urlencoded" のすべてのファイルはデフォルトで変換され、 他のすべてのドキュメントは無変換で送られていました。 "text/x-ascii-subtype" がドキュメントに対して設定されている場合にのみ、ドキュメントは ASCII フォーマットであるとみなされ、再変換されませんでした。 変換する代わりに、"x-ascii-" がタイプから取り除かれ、"text/subtype" がドキュメントの MIME タイプになっていました。

EBCDICKludge ディレクトリが On に設定されていて、 EBCDICConvert ディレクティブがそこの コンテキストにマッチすれば、サーバは type/x-ascii-subtype という形式の MIME タイプを調べます。ドキュメントにそのようなタイプがあれば、 "x-ascii-" が取り除かれて、変換は Off に設定されます。例えば NFS でマウントされたディレクトリの ASCII のドキュメントを送っているような場合に、これにより すべてのテキストファイルは EBCDIC であるという前提を変更することができます。
EBCDICKludge では、他の MIME タイプ (例えば model/vrml) を EBCDIC のテキストファイルとして扱うことはできません。 そのような変換には上記の EBCDICConvertByType ディレクティブの使用がより良い方法です。(Apache バージョン 1.3.19 より前では、バイナリドキュメントを EBCDIC テキストファイルとして扱う方法は全くありませんでした)。

参照: EBCDICConvert, EBCDICConvertByTypeEBCDIC 変換関数の概要


EnableExceptionHook directive

構文: EnableExceptionHook on|off
デフォルト: EnableExceptionHook off
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: EnableExceptionHook は Apache 1.3.30 以降で使用可能

EnableExceptionHook はモジュールに実装された 例外フックを子プロセスがクラッシュした後に呼ぶかどうかを制御します。 例外フックはモジュールがクラッシュの原因を決定するための診断情報を ログ収集するできるようにします。


ErrorDocument ディレクティブ

構文: ErrorDocument error-code document
コンテキスト: サーバ設定ファイル、 バーチャルホスト、ディレクトリ、.htaccess
ステータス: core
上書き: FileInfo
互換性: ディレクトリ若しくは .htaccess コンテキストにおいての指定は Apache 1.1 以降でのみ利用可能です。

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

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

最初のものがデフォルトの動作で、2 番目から 4 番目は、 ErrorDocument ディレクティブにより、HTTP のレスポンスコードと、メッセージか URL を指定することで設定します。

メッセージを記述する場合には、二重引用符 1 文字 (") を最初に付与します。 二重引用符はメッセージには含まれません。 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 (MSIC) はデフォルトでそれを無視し、 「親切な」エラーメッセージで置き換えます。しきい値はエラーの 種類によって異りますが、通常、エラードキュメントを 512 バイトより 大きくすると、MSIE はサーバが生成したエラーを隠さずに表示します。 より詳しい情報は Microsoft Knowledgebase の記事 Q294807 にあります。

参照: レスポンスをカスタマイズする方法についての解説。 ステータスコードとその意味の完全なリストは HTTP 仕様書を参照してください。


ErrorLog ディレクティブ

構文: ErrorLog file-pathh|syslog[:facility]
デフォルト: ErrorLog logs/error_log (Unix)
デフォルト: ErrorLog logs/error.log (Windows and OS/2)
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core

エラーログディレクティブは、サーバに生じたさまざまなエラーを 記録するためのファイルの名前を設定します。 file-path がスラッシュ (/) から始まらない場合は、ServerRoot からの相対パスとみなされます。 file-path がパイプ (|) から始まる場合は、 エラーログを処理するために実行されるコマンドが 指定されていると解釈されます。

ErrorLog logs/vhost1.error

or

ErrorLog |/usr/local/bin/errorlog.pl

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

例:

ErrorLog syslog

or

ErrorLog syslog:user

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

参照: LogLevel 及び Apache のログファイル


FileETag ディレクティブ

構文: FileETag component ...
コンテキスト: サーバ設定ファイル、 バーチャルホスト、ディレクトリ、.htaccess
上書き: FileInfo
ステータス: core
互換性: Apache 1.3.23 以降で利用可能です。

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
ステータス: core
互換性: Apache 1.2 以降で利用可能です。

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

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

   <Files ~ "\.(gif|jpe?g|png)$">
とすることにより、一般的なインターネットの画像フォーマットにマッチします。 ただし、Apache 1.3 以降の場合には、 <FilesMatch> を使う方が推奨されています。

ちなみに、<Directory> 及び <Location> セクションとは異なり、 <Files> は .htaccess ファイル内で利用することができます。 これにより、ユーザがファイル毎にアクセスの制御を行なうことができるように なっています。 例えば、ディレクトリ内にある一つのファイルに対してパスワードによる保護を行なうには、 .htaccess に以下のような設定を追加すれば良いでしょう。

    <Files admin.cgi>
    Require group admin
    </Files>

なお、このディレクティブはサブディレクトリにも適用され、 上の例の場合には、特に設定が上書きされない限り、 サブディレクトリ中の admin.cgi というファイルにも保護がかかるということを忘れないでください。

(Require ディレクティブの使い方については、Requireを参照してください。)

参照: リクエストを受けた際に、異なる複数のセクションがどのようにして 組み合わされるのかについては Directory, Location, Files セクションの動作方法


<FilesMatch>

構文: <FilesMatch regex> ... </FilesMatch>
コンテキスト: サーバ設定ファイル、バーチャルホスト、.htaccess
ステータス: core
互換性: Apache 1.3 以降で利用可能です。

<FilesMatch> ディレクティブは、<Files> ディレクティブ同様にファイル名によるアクセス制御の機能を提供します。ただし、 このディレクティブには正規表現を指定します。 例えば:

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

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

参照: リクエストを受けた際に、異なる複数のセクションがどのようにして 組み合わされるのかについては Directory, Location, Files セクションの動作方法


Group ディレクティブ

構文: Group unix-group
デフォルト: Group #-1
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core

Group ディレクティブは、サーバがリクエストに応答する際のグループを設定します。 このディレクティブを使うためには、スタンドアローンサーバを root で起動しなければなりません。 Unix-group は、以下のどちらかをとります。

グループ名
名前でグループを指定します。
# を先頭にグループ ID
数字でグループを指定します。

サーバを実行するために新しいグループを作成することが推奨されています。 nobody と指定する管理者もいますが、そのユーザは利用可能でない 場合もありますし、望ましくもありません。

例:

Group www-group

注意点: root ユーザ以外でサーバを起動された場合、 指定したグループへ移ることができず、そのままのユーザで実行されます。

特に注意すべき点: <VirtualHost> 内でこのディレクティブを使用するためには、suEXEC ラッパーが設定されていなければなりません。 この場合、CGI を実行するときにのみ、指定したグループが利用されます。 CGI 以外の場合には、メイン設定における Group ディレクティブで指定されたグループで処理されます。

セキュリティ: セキュリティに関する解説は User を参照してください。


HostnameLookups ディレクティブ

構文: HostnameLookups on|off|double
デフォルト: HostnameLookups off
コンテキスト: サーバ設定ファイル、バーチャルホスト、ディレクトリ
ステータス: core
互換性: double は Apache 1.3 以降で利用可能です。
互換性: Apache 1.3 より前はデフォルトが on になっています。

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

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

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


IdentityCheck ディレクティブ

構文: IdentityCheck on|off
デフォルト: IdentityCheck off
コンテキスト: サーバ設定ファイル、 バーチャルホスト、ディレクトリ
ステータス: core

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

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

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


<IfDefine> ディレクティブ

構文: <IfDefine [!]parameter-name> ... </IfDefine>
デフォルト: None
コンテキスト: すべて
ステータス: Core
互換性: <IfDefine> は Apache 1.3.1 以降で利用可能です。

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

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

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

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

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

  $ httpd -DReverseProxy ...

  # httpd.conf
  <IfDefine ReverseProxy>
  LoadModule rewrite_module libexec/mod_rewrite.so
  LoadModule proxy_module   libexec/libproxy.so
  </IfDefine>

<IfModule> ディレクティブ

構文: <IfModule [!]module-name> ... </IfModule>
デフォルト: None
コンテキスト: すべて
ステータス: Core
互換性: IfModule は Apache 1.2 以降で利用可能です。

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

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

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

module name 引数は、コンパイルをした時のモジュールのファイル名で、例えば mod_rewrite.c といった形になります。

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


Include ディレクティブ

構文: Include file-path|directory-path|wildcard-path
コンテキスト: サーバ設定ファイル
ステータス: Core
互換性: Include は Apache 1.3 以降で利用可能です。ワイルドカードはバージョン 1.3.27 で導入されました。

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

file-path は、(スラッシュから始まる) フルパスか、 ServerRoot からの相対パスで指定します。

Apache 1.3.13 から、Include にファイルの代わりに ディレクトリを指定することによって、 ディレクトリとそのサブディレクトリ内のすべてのファイルを 読み込んで処理できるようになりました。

ワイルドカードを使うことで、これを例えば '*.conf' ファイルのみに制限することができます。

例:

Include /usr/local/apache/conf/ssl.conf
Include /usr/local/apache/conf/vhosts/

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

Include conf/ssl.conf
Include conf/vhosts/

なお、ディレクトリを指定する際は、エディタのテンポラリファイルなど、 目的外のファイルを置かないようにしなければなりません。 そのようなファイルがあると、Apache はそれらからディレクティブを 読み込もうとして、起動に失敗するかもしれません。 apachectl configtest を実行すると、設定をチェックしている時に 読み込まれたファイルのリストが表示されます:

root@host# apachectl configtest
 Processing config directory: /usr/local/apache/conf/vhosts
 Processing config file: /usr/local/apache/conf/vhosts/vhost1
 Processing config file: /usr/local/apache/conf/vhosts/vhost2
Syntax OK

これにより、設定の一部として意図したファイルだけが 使われているかどうかを確認できます。

参照: apachectl


KeepAlive ディレクティブ

構文: (Apache 1.1) KeepAlive max-requests
デフォルト: (Apache 1.1) KeepAlive 5
構文: (Apache 1.2) KeepAlive on|off
デフォルト: (Apache 1.2) KeepAlive On
コンテキスト: サーバ設定ファイル
ステータス: Core
互換性: KeepAlive は Apache 1.1 以降で利用可能です。

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

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

Apache 1.1 のみ: Apache が接続ごとに受付できる要求の最大数を max-requests にて指定できます。 制限は、サーバのリソースを多大に利用するようなクライアントを防ぐために 行ないます。 0 に設定すると制限値はなくなります。 Apache 1.2 及び 1.3 の場合には、MaxKeepAliveRequests ディレクティブにより制御します。

参照 MaxKeepAliveRequests


KeepAliveTimeout ディレクティブ

構文: KeepAliveTimeout seconds
デフォルト: KeepAliveTimeout 15
コンテキスト: サーバ設定ファイル
ステータス: Core
互換性: KeepAliveTimeout は Apache 1.1 以降で利用可能です。

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

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


<Limit> ディレクティブ

構文: <Limit method [method] ... > ... </Limit>
コンテキスト: any
ステータス: 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> ディレクティブ

構文: <LimitExcept method [method] ... > ... </LimitExcept>
コンテキスト: any
ステータス: core
互換性: Apache 1.3.5 以降で利用可能です。

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

例:

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

LimitInternalRecursion directive

構文: LimitInternalRecursion number [number]
デフォルト: LimitInternalRecursion 20
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性: LimitInternalRecursion is は Apache 1.3.28 以降でのみ使用可能です。

内部リダイレクトは、例えば、オリジナルのリクエストを CGI スクリプトに内部リダイレクトする Action ディレクティブを使った場合に発生します。 サブリクエストはある URI がリクエストされた場合に何が起きるのかを突き止めるための Apache の方法です。例えば、mod_dirDirectoryIndex に挙げられているファイルを探すためにサブリクエストを使います。

LimitInternalRecursion は内部リダイレクトや サブリクエストが無限ループに陥った場合に サーバがクラッシュするのを防ぎます。 このようなループは通常、設定ミスが原因で起こります。

このディレクティブは二つの異なる制限値を保存します。それぞれの値は、 リクエスト単位で評価されます。最初の number は後に続くことのできる 内部リダイレクトの上限を設定します。二つめの number は サブリクエストの入れ子構造の深さを設定します。Number を 一つだけ指定した場合は、その値が両方の制限値に使用されます。 値 0 は「無制限」を意味します。

    LimitInternalRecursion 5
    

LimitRequestBody ディレクティブ

構文: LimitRequestBody bytes
デフォルト: LimitRequestBody 0
コンテキスト: サーバ設定ファイル、バーチャルホスト、ディレクトリ、.htaccess
ステータス: core
互換性: LimitRequestBody は Apache 1.3.2 以降で利用可能です。

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

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

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

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

LimitRequestBody 102400

LimitRequestFields ディレクティブ

構文: LimitRequestFields number
デフォルト: LimitRequestFields 100
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: LimitRequestFields はApache 1.3.2 以降で利用可能です。

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

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

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

例:

LimitRequestFields 50

LimitRequestFieldsize ディレクティブ

構文: LimitRequestFieldsize bytes
デフォルト: LimitRequestFieldsize 8190
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: LimitRequestFieldsize は Apache 1.3.2 以降で利用可能です。

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

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

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

例:

LimitRequestFieldSize 16380

通常はデフォルトから変更する必要はないでしょう。


LimitRequestLine ディレクティブ

構文: LimitRequestLine bytes
デフォルト: LimitRequestLine 8190
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: LimitRequestLine は Apache 1.3.2 以降で利用可能です。

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

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

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

例:

LimitRequestLine 16380

通常の場合には、デフォルトから変更する必要ないでしょう。


Listen ディレクティブ

構文: Listen [IP-address:]port
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: Listen は Apache 1.1 以降で利用可能です。

Listen ディレクティブは、Apache が複数の IP アドレスやポートを listen するように指示します。デフォルトでは、すべての IP インターフェースへのリクエストに応答し、Port ディレクティブが指定したポートのみを listen することになります。

BindAddressPort の代わりに Listen を使用することができます。 Listen は特定のポート若しくはアドレスとポートの組合わせにより リクエストの受け付けを指定することが可能です。 最初のポート番号のみの指定方法を利用した場合には、 サーバは Port ディレクティブで与えられたポートに代わり、 すべてのインターフェース上で指定されたポートを listen します。もし、ポートと一緒に IP アドレスが指定されていれば、 指定されたインターフェースのポートを listen します。

なお、Apache が自分のサーバを指す URL を正しく生成できるように Port ディレクティブも使う必要があるかもしれないことに 注意してください。

Listen する複数のアドレスとポートを指定するために、 複数の Listen ディレクティブを使用することができます。 その場合、サーバは指定されたすべてのアドレスとポートで、 リクエストに対する応答を行ないます。

サーバが 80 番ポートと 8000 番ポートの両方で接続を受け付ける設定の例:

   Listen 80
   Listen 8000
二つのインターフェースとポート番号において接続を受け付ける設定の例:
   Listen 192.170.2.1:80
   Listen 192.170.2.5:8000

参照: DNS に関する問題
参照: Apache が利用するアドレスとポートの設定
参照: 既知のバグ


ListenBacklog ディレクティブ

構文: ListenBacklog backlog
デフォルト: ListenBacklog 511
コンテキスト: サーバ設定ファイル
ステータス: Core
互換性: ListenBacklog は Apache 1.2.0 以降で利用可能です。

受け付けできていない接続を待機させる際の最大数を指定します。 通常は変更の必要はありませんし、変更することは望ましくありません。 しかし、システムによっては TCP SYN フラッド攻撃を受けているときに この数値を増やした方が良い場合があります。listen(2) システムコールの backlog パラメータを参照してください。

この数値は、OS によって小さな値に制限されていることがよくあり、 OS によってさまざまです。さらに、多くの OS は backlog で指定された値そのものを使うのではなく、それに基づく値 (通常はより大きな値) を使うということにも注意してください。


<Location> ディレクティブ

構文: <Location URL-path|URL> ... </Location>
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性: Location は Apache 1.1 以降で利用可能です。

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

URL はファイルシステムに対応する必要はなく、<Location> は完全にファイルシステムに関係せず動作することを強調しておきます。

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

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

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

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

は URL に "/extra/data" か "/special/data" という文字列が含まれている場合にマッチします。そして、 Apache 1.3 以降の場合には、<Location> の正規表現版と全く同じ動作をする <LocationMatch> という新しいディレクティブがあります。

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

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

Apache 1.3 以降における / (スラッシュ) の取り扱いについての注意: スラッシュ文字は、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>

構文: <LocationMatch regex> ... </LocationMatch>
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性: LocationMatch は Apache 1.3 以降で利用可能です。

<LocationMatch> ディレクティブは、<Location> と同じ様に URL によるアクセス制御を提供します。 ただし、引数は普通の文字列ではなく、正規表現となります。例えば、

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

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

参照: リクエストを受けた際に、 異なる複数のセクションがどのようにして 組み合わされるのかについては Directory, Location, Files セクションの動作法


LockFile ディレクティブ

構文: LockFile ファイルパス
デフォルト: LockFile logs/accept.lock
コンテキスト: サーバ設定ファイル
ステータス: core

LockFile ディレクティブは Apache が USE_FCNTL_SERIALIZED_ACCEPT か USE_FLOCK_SERIALIZED_ACCEPT でコンパイルされたときに使うロックファイルへのパスを指定します。 このディレクティブは通常はデフォルト値のままにしておくべきです。 これを変える主な理由は、logs ディレクトリが NFS マウントされている、というものです。これは、ロックファイルは ローカルディスク上に作られなければならないからです。 主サーバプロセスの PID がファイル名の後に追加されます。

セキュリティ /var/tmp のような皆が書き込めるディレクトリは避けるのが賢明です。 これは、サーバが作成しようとするロックファイルと同じ名前のファイルを 作成することで、サーバの起動を阻止する、というサービス拒否攻撃を 行うことが可能になるからです。


LogLevel ディレクティブ

構文: LogLevel level
デフォルト: LogLevel warn
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性: LogLevel は Apache 1.3 以降で利用可能です。

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 に指定すると、 noticewarn も報告されます。

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

例:

LogLevel notice

注: 通常のファイルに記録する場合レベル notice のメッセージは抑制することができず、 常に記録されます。しかし、これは syslog を使ってログ収集を行なう場合にはあてはまりません。


MaxClients ディレクティブ

構文: MaxClients 数値
デフォルト: MaxClients 256
コンテキスト: サーバ設定ファイル
ステータス: core

MaxClients ディレクティブは、同時にサポートできる最大リクエスト数を設定します。 子サーバプロセスは、これより多くは作成されません。 なお、256 クライアントより大きな数値を指定するためには、httpd.h の HARD_SERVER_LIMIT を編集して再コンパイルしなければなりません。

MaxClients の制限を超えた接続は、通常は ListenBacklog ディレクティブで指定した数までキューに入れられます。 そして、別のリクエストを終了し子プロセスが解放された時点で、 接続が受け付けられます。


MaxKeepAliveRequests ディレクティブ

構文: MaxKeepAliveRequests 数値
デフォルト: MaxKeepAliveRequests 100
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: Apache 1.2 以降で利用可能です。

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

MaxKeepAliveRequests 500

MaxRequestsPerChild ディレクティブ

構文: MaxRequestsPerChild 数値
デフォルト: MaxRequestsPerChild 0
コンテキスト: サーバ設定ファイル
ステータス: core

MaxRequestsPerChild ディレクティブは、 個々の子サーバープロセスが処理できるリクエストの最大数を設定します。 MaxRequestsPerChild で指定された数のリクエストを処理すると、子プロセスは終了します。 なお、0 を指定すると、プロセスは限りなく動きつづけます。

MaxRequestsPerChild により、最大数を 0 以外の値に設定することは、二つの有益な効果があります:

ただし、Win32 においてはこれを 0 に設定した方が良いでしょう。 0 以外を指定すると、リクエストの制限に到達したときに子プロセスが終了し、 子プロセスがもう一度作られ、その際に設定ファイルを読み直します。 これにより、設定ファイルを修正後に、 まだ修正内容が適用されるのを期待していないときに 予期せぬ振る舞いをすることがあります。 ThreadsPerChild も参照してください。

注意: KeepAlive リクエストの場合、 最初のリクエストのみカウントされます。 実質的には子プロセスあたりの接続数を指定するものといえます。


MaxSpareServers ディレクティブ

構文: MaxSpareServers 数値
デフォルト: MaxSpareServers 10
コンテキスト: サーバ設定ファイル
ステータス: core

MaxSpareServers ディレクティブは、アイドル状態である 子サーバプロセスの望ましい最大数を指定します。 アイドル状態のプロセスとは、リクエストを処理していないプロセスのことです。 MaxSpareServers で指定した数以上がアイドル状態であれば、 親プロセスは増えすぎたプロセスを kill します。

この数値の変更は、とてもアクセスの多いサイトにおいてのみ必要となるでしょう。 大きな数値を指定することは、ほとんどの場合には良くない設定です。

なお、これは予備サーバの最大数であり、 クライアントからのリクエストを一度にどれだけ処理できるのかの最大数を 指定するものではありません。 もし、そういった最大数を指定したいのであれば、MaxClients ディレクティブを参照してください。

このディレクティブは、Microsoft Windows プラットフォームにおける Apache サーバでは意味を持ちません。

MinSpareServersStartServersMaxClients も参照してください。


MinSpareServers ディレクティブ

構文: MinSpareServers 数値
デフォルト: MinSpareServers 5
コンテキスト: サーバ設定ファイル
ステータス: core

MinSpareServers ディレクティブは、アイドル状態である 子サーバプロセスの望ましい最小数を指定します。 アイドル状態のプロセスとは、リクエストを処理していないプロセスのことです。 もし MinSpareServers で指定した数よりアイドル状態のサーバが少なければ、 親プロセスは 1 秒間に 1 個を限度として新しい子プロセスを生成します。

この数値の変更は、とてもアクセスの多いサイトにおいてのみ必要となるでしょう。 大きな数値を指定することは、ほとんどの場合には良くない設定です。

なお、このディレクティブにおいてある数値 m を指定したとすると、 n という数の稼動中のクライアントリクエストがある時に、 n + m 以上の httpd プロセスが確実に保持されるようにします。

このディレクティブは、Microsoft Windows プラットフォームでは意味を持ちません。

MinSpareServersStartServersMaxClients も参照してください。


NameVirtualHost ディレクティブ

構文: NameVirtualHost addr[:port]
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: NameVirtualHost は Apache 1.3 以降で利用可能です。

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

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

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

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

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

NameVirtualHost 111.22.33.44:8080
Apache 1.3.13 以上の場合には、addr* を指定することができます。 これにより、NameVirtualHostディレクティブや <VirtualHost> セクションで指定されなかった、 より細かく設定されているアドレス以外のすべてのアドレスへの接続にマッチします。 名前ベースのバーチャルホストだけを利用したい場合や、 設定ファイル中にサーバの IP アドレスを記述することを望まない場合に有用でしょう。

参照: Apache バーチャルホスト解説書


Options ディレクティブ

構文: Options [+|-]option [[+|-]option] ...
コンテキスト: サーバ設定ファイル、バーチャルホスト、ディレクトリ、.htaccess
上書き: Options
ステータス: core

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

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

All
MultiViews を除いたすべての機能が有効となります。 これがデフォルトです。
ExecCGI
CGI スクリプトの実行を許可します。
FollowSymLinks
サーバが、このディレクトリ内でシンボリックリンクをたどれるようにします。
注意点: サーバがシンボリックリンクをたどる場合でも、 <Directory> セクションにマッチさせるためのパス名は変更されません
注意点: <Location> 内にこのオプションを指定しても無視されます。
Includes
SSI を有効にします。
IncludesNOEXEC
SSI は有効になりますが、#exec コマンド と #exec CGI は無効になります。ただし、#include virtual により、ScriptAlias されたディレクトリで CGI を実行することは可能です。
Indexes
もし、URL がディレクトリにマップするリクエストであって、かつ DirectoryIndex で指定したファイル (例えば、index.html) が ディレクトリ内に無ければ、 ディレクトリ内の一覧を整形して返せるようにします。
MultiViews
コンテントネゴシエーション された 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 というディレクトリには、 FollowSymLinksIncludes が適用されます。

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

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


PidFile ディレクティブ

構文: PidFile ファイルパス
デフォルト: PidFile logs/httpd.pid
コンテキスト: サーバ設定ファイル
ステータス: core

PidFile ディレクティブはサーバがデーモンのプロセス ID を記録するファイルを設定します。ファイル名がスラッシュ (/) から始められていなければ、ServerRoot からの相対パスとなります。 PidFile は standalone モードでのみ使用できます。

ErrorLog と TransferLog を閉じて開き直して、 設定ファイルを再読み込みさせることができるようにサーバに シグナルを送ることができれば便利なことがあります。 これは、SIGHUP (kill -1) シグナルを PidFile に記載されているプロセス ID に送ることによって可能です。

PidFile はログファイルの場所と 安全性と同じような 注意が必要です。


Port ディレクティブ

構文: Port number
デフォルト: Port 80
コンテキスト: サーバ設定ファイル
ステータス: core

numberには、0 から 65535 までの番号を指定します。いくつかのポート番号 (特に1024番以前) は、特定のプロトコルのために予約されています。 /etc/services を見ると、定義されているポートの一覧があります。通常、HTTP プロトコルの標準のポートは 80 です。

Port ディレクティブは、二つの意味を持っており、一つは NCSA の上位互換としての必要性です (Apache の設定では混同しやすい点です)

Port ディレクティブの主な動作は、ServerName ディレクティブと同様のものとみなすことができます。 ServerName と Port は、サーバの正式なアドレスが、何であるかを指定します。

80 番ポートは、UNIX の特別なポートの一つです。1024 番未満のすべてのポートはシステムが使用するために予約されています。 すなわち、一般ユーザ (root 以外) は使用することができません。 一般ユーザはそれ以上のポートしか使用できません。そのため、 80 番ポートを使用するには、root アカウントでサーバを起動しなければなりません。 起動後に、ポートをバインドした後、リクエストを受け付ける前に Apache は User ディレクティブで指定された、より特権の低いユーザに移行します。

もし、80 番ポートを使用できない場合には、 使用していない他の任意のポートを選んでください。root 以外のユーザなら、 8000 などのように 1023 より上のポートを選んで下さい。

セキュリティ: もし、root によってサーバを起動したなら、 User を root 以外に設定してください。接続を root で扱うと、サイトは重大なセキュリティ攻撃にさらされる 可能性があります。


ProtocolReqCheck ディレクティブ

構文: ProtocolReqCheck on|off
デフォルト: ProtocolReqCheck on
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: ProtocolReqCheck は Apache 1.3.27 以降でのみ使用可能です。

このディレクティブは Request 行の Protocol フィールドの厳密なチェックを行うようにします。Apache の 1.3.26 以前のバージョンは (HTTP-1.1 のような) 間違った Protocol を黙って受け付けて、HTTP/1.0 とみなしていました。このバージョンではそうではなく、Protocol フィールドは正しいものでなければならなくなりました。 1.3.26 以前の動作が望ましかったり、必要だったりする場合は ProtocolReqCheck off と設定することにより厳密なチェックをしないようにできます。


Require ディレクティブ

構文: Require entity-name [entity-name] ...
コンテキスト: ディレクトリ、.htaccess
上書き: AuthConfig
ステータス: core

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

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

AuthType Basic
AuthName "Restricted Directory"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin
アクセス制御は、すべてのメソッドに対して行われます。 通常は、これが望ましい動作です。 もし、特定のメソッドに対してのみアクセスの制御を適用し、 他のメソッドは制限しない場合には、<Limit> セクション内に Require を指定してください。

Satisfy 及び mod_access も参照してください。


ResourceConfig ディレクティブ

構文: ResourceConfig file-path|directory-path|wildcard-path
デフォルト: ResourceConfig conf/srm.conf
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性: ファイル名ではなく、 ディレクトリを指定する機能は Apache 1.3.13 以降でのみ使用可能です。

サーバは httpd.conf ファイルを読み込んだ後、 追加のディレクティブをここで記したファイルから読み込みます。 File-pathは、ServerRoot からの相対パスです。
この機能を無効にするには次のように指定します。

ResourceConfig /dev/null
Win32 の場合
ResourceConfig nul
以前は、サーバ設定に関するディレクティブと <ディレクトリ> セクション以外のほとんどのディレクティブが書かれていました。 実際、現在では「サーバ設定ファイル」コンテキストに記述できることすべてが 記述可能になっています。 ただ、Apache のバージョン 1.3.4 以降で配布されているデフォルトの srm.conf ではこのファイル内にはコメントしか書かれておらず、 すべてのディレクティブがサーバ設定ファイルの httpd.conf に記述されています。

ResourceConfig がファイルではなくディレクトリを指定していれば、Apache はそのディレクトリ内とすべてのサブディレクトリ内のすべてのファイルを 読み込み、それらを設定ファイルとして処理します。

代わりに、ワイルドカードを使って範囲を絞ることもできます。 すなわち、*.conf ファイルのみ、といったように。

デフォルトでは指定されたディレクトリの「どのような」 ファイルでも設定ファイルとして読み込まれます。

ですから誤って (例えばエディタでテンポラリファイルを作成する等) ファイルを置かないように注意してください。

参照: AccessConfig


RLimitCPU ディレクティブ

構文: RLimitCPU number|max [number|max]
デフォルト: Unset; uses operating system defaults
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性: RLimitCPU は Apache 1.2 以降で利用可能です。

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

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

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

RLimitMEMRLimitNPROC も参照してください。


RLimitMEM ディレクティブ

構文: RLimitMEM number|max [number|max]
デフォルト: Unset; uses operating system defaults
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性: RLimitMEM は Apache 1.2 以降で利用可能です。

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

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

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

RLimitCPURLimitNPROC も参照してください。


RLimitNPROC ディレクティブ

構文: RLimitNPROC number|max [number|max]
デフォルト: Unset; uses operating system defaults
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core
互換性: RLimitNPROC は Apache 1.2 以降で利用可能です。

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

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

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

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

RLimitCPURLimitCPU も参照してください。


Satisfy ディレクティブ

構文: Satisfy any|all
デフォルト: Satisfy all
コンテキスト: ディレクトリ、.htaccess
ステータス: core
互換性: Satisfy は Apache 1.2 以降で利用可能です。

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

RequireAllow も参照してください。


ScoreBoardFile ディレクティブ

構文: ScoreBoardFile ファイルパス
デフォルト: ScoreBoardFile logs/apache_status
コンテキスト: サーバ設定ファイル
ステータス: core

アーキテクチャによっては、サーバの親プロセスと子プロセスが 通信するためのファイルを置く場所を指定するために ScoreBoardFile ディレクティブを使う必要があることがあります。 使用しているアーキテクチャが scoreboard ファイルを必要としているかどうかを調べる一番簡単な方法は Apache を実行してこのディレクティブで指定されている ファイルを作成するかどうかを見ることです。 使用しているアーキテクチャでこれが必要な場合は、このファイルを使う Apache は一つだけであることを確実にする必要があります。

ScoreBoardFile を使う必要がある場合は、それを RAM ディスク上に置くことで速度が向上するでしょう。 ただし、ログファイルの位置と セキュリティに関する 警告を十分注意する必要があります。

Apache 1.2 以降:

Linux 1.x ユーザは ConfigurationEXTRA_CFLAGS-DHAVE_SHMGET を 設定することができるかもしれません。これは、1.x のいくつかでは動作しますが、 すべてで動作するというわけではありません。(1.3b4 より前では HAVE_SHMGET で十分でした。)

SVR4 ユーザは ConfigurationEXTRA_CFLAGS-DUSE_SHMGET_SCOREBOARD を追加することを考慮した方が良いでしょう。 これは動作すると考えられていますが、1.2 のリリースまでにテストをすることはできませんでした。(1.3b4 より前では HAVE_SHMGET で十分でした。)

参照: Apache の停止と再起動


ScriptInterpreterSource ディレクティブ

構文: ScriptInterpreterSource registry|script
デフォルト: ScriptInterpreterSource script
コンテキスト: ディレクトリ、.htaccess
ステータス: core (Windows のみ)

このディレクティブは、Apache 1.3.5 以降で CGI スクリプトを実行する場合に利用するインタープリタを、 どのように探し出すかについて制御するために使用します。 デフォルトの場合はスクリプトの #! 行に指されているインタープリタを使用しますが ScriptInterpreterSource registry を指定すると、スクリプトファイルの拡張子 (例えば、 .pl) をキーとして、Windows のレジストリを検索するようになります。


SendBufferSize ディレクティブ

構文: SendBufferSize bytes
コンテキスト: サーバ設定ファイル
ステータス: core

サーバは、TCP バッファのサイズを指定されたバイト数に設定します。高速で大きな遅延 (例えば、100ms 程度あるような高速な大陸横断回線など) のある場合に、サイズを標準の OS のデフォルト以上に大きくするために非常に有用です。


ServerAdmin ディレクティブ

構文: ServerAdmin email-address
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core

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

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

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

ServerAlias ディレクティブ

構文: ServerAlias hostname [hostname] ...
コンテキスト: バーチャルホスト
ステータス: core
互換性: ServerAlias は Apache 1.1 以降で利用可能です。

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

例:

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

参照: Apache バーチャルホスト説明書


ServerName ディレクティブ

構文: ServerName fully-qualified-domain-name
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core

ServerName ディレクティブは、サーバのホスト名を設定します。 これは、リダイレクトする URL を生成する際に利用されます。 特に指定がなされていなかった場合には、自サーバに付与されている IP アドレスから推測しますが、これは確実な方法ではなく、 正しいホスト名を返すとも限りません。
例えば:

ServerName www.example.com
を、マシンに対する正しい (メインの) 名前が、 simple.example.com であるときに使うことができます。

名前ベースのバーチャルホスト を利用している場合、<VirtualHost> セクション内の ServerName はこのバーチャルホストにマッチするために何がリクエストの Host: ヘッダに現れる必要があるのかを指定します。

参照:
DNS に関する問題
Apacheバーチャルホスト説明書
UseCanonicalName
NameVirtualHost
ServerAlias


ServerPath ディレクティブ

構文: ServerPath ディレクトリパス
コンテキスト: バーチャルホスト
ステータス: core
互換性: ServerPath は Apache 1.1 以降で利用可能です。

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

参照: Apache バーチャルホスト説明書


ServerRoot ディレクティブ

構文: ServerRoot ディレクトリパス
デフォルト: ServerRoot /usr/local/apache
コンテキスト: サーバ設定ファイル
ステータス: core

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

httpd の -d について を参照してください。

ServerRoot の権限をどのように設定するかについては セキュリティに関する覚書 に情報があります。


ServerSignature ディレクティブ

構文: ServerSignature On|Off|EMail
デフォルト: ServerSignature Off
コンテキスト: サーバ設定ファイル、バーチャルホスト、ディレクトリ、.htaccess
ステータス: core
互換性: ServerSignature は Apache 1.3 以降で利用可能です。

ServerSignature ディレクティブは、サーバが生成するドキュメント (エラーメッセージ、mod_proxy における FTP のディレクトリリスト、 mod_info の出力、等々) の最下行に付与するフッタの設定を行ないます。 そのような、フッタ行を有効にしたい理由としては、 プロキシが複数連なっている場合に、ユーザはどのサーバが返した エラーメッセージかを知る手段がほとんど無いからです。
デフォルトである Off に設定をすると、エラーの際の行が抑制されます。 (そして、Apache-1.2 以前と互換の動作をします) On に設定した場合は、単にドキュメントの中に、 サーバのバージョン、稼動中のバーチャルホストの ServerName の書かれた行を追加し、 EMail にした場合はさらに参照されたドキュメントに対する ServerAdmin を指す "mailto:" が追加されます。


ServerTokens ディレクティブ

構文: ServerTokens Minimal|ProductOnly|OS|Full
デフォルト: ServerTokens Full
コンテキスト: サーバ設定ファイル
ステータス: core
互換性: ServerTokens は Apache 1.3 以降で利用可能です。 また、ProductOnly キーワードは Apache 1.3.12 以降で利用可能です。

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

ServerTokens Prod[uctOnly]
サーバは (例えば): Server: Apache といったように送ります。
ServerTokens Min[imal]
サーバは (例えば): Server: Apache/1.3.0 といったように送ります。
ServerTokens OS
サーバは (例えば): Server: Apache/1.3.0 (Unix) といったように送ります。
ServerTokens Full (もしくは未指定)
サーバは (例えば): Server: Apache/1.3.0 (Unix) PHP/3.0 MyMod/1.2 といったように送ります。

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


ServerType ディレクティブ

構文: ServerType type
デフォルト: ServerType standalone
コンテキスト: サーバ設定ファイル
ステータス: core

ServerType ディレクティブは、サーバがシステムにどのように 実行されるかを指定します。 Type には、次のどちらかを指定します。

inetd
サーバは、inetd プロセスから実行され、 /etc/inetd.conf に起動するコマンドを記述します。
standalone
サーバは、デーモンプロセスとして実行し、 システムのスタートアップスクリプト (/etc/rc.local/etc/rc3.d/...) に起動するコマンドを記述します。
Inetd は、あまり利用されません。 その設定では、HTTP 接続を受ける度に、サーバが 1 から立ち上げられ、接続が終了した後にプログラムも終了します。 これは、接続の度にとても負荷がかかりますが、 セキュリティを理由にこのオプションを好む管理者もいます。 ただ、Inetd モードは推奨されておらず、 今後もずっと利用可能というわけではありません。 可能な限り使わないでください。

Standalone は、ずっと効率的であるため、ServerType の標準的な設定となっています。 サーバは一度起動されると、すべての接続を処理します。 もし、負荷の高いサイトで Apache を利用するつもりであれば、 standalone は唯一のオプションといえるでしょう。


ShmemUIDisUser ディレクティブ

構文: ShmemUIDisUser on|off
デフォルト: ShmemUIDisUser off
コンテキスト: サーバ設定ファイル
ステータス: core 互換性:

ShmemUIDisUser ディレクティブは System V 共有メモリに基づいたスコアボードの、所有者の uidgid をサーバの設定の UserGroup に変更するかどうかを制御します。 Apache 1.3.26 までのリリースはデフォルトでこれを行っていました。 子プロセスは既に共有メモリセグメントにアタッチされていますので、 その動作は Apache の通常の動作には必要ではなく、攻撃を防ぐためにも、 Apache はそのような動作をしなくなりました。しかし、特別な場合には 以前の動作が必要になることもあり、それはこのディレクティブを on にすることで実現できます。

このディレクティブはSystem V に基づいたスコアボードではない、 mmap のようなシステムでは効力はありません。


StartServers ディレクティブ

構文: StartServers 数値
デフォルト: StartServers 5
コンテキスト: サーバ設定ファイル
ステータス: core

StartServers ディレクティブは、起動時にどれだけのサーバ子プロセスを 実行するのかを指定します。 プロセスの数は、負荷によって動的に制御されるため、 普通はこのパラメータを変更する理由はほとんどありません。

Microsoft Windows で実行する場合には、このディレクティブは意味を持ちません。 Windows では常に一つの子プロセスがすべてのリクエストを扱います。 子プロセスの内部では、リクエストはスレッドで処理されます。 ThreadsPerChild ディレクティブは リクエストを扱う最大の子スレッドの数を制御しますので、UNIX で StartServers を指定したのと同じような効果になります。

MinSpareServersMaxSpareServers も参照してください。


ThreadsPerChild

構文: ThreadsPerChild 数値
デフォルト: ThreadsPerChild 50
コンテキスト: サーバ設定ファイル
ステータス: core (Windows, NetWare)
互換性: Windows 上で動作する Apache 1.3 以降においてのみ有効

このディレクティブは、サーバがどれだけのスレッドを使用するのかを 指示します。 これが、サーバが処理できる最大接続数になります。 たくさんのヒットがあるサイトの場合には数値を増やす必要があります。

なお、このディレクティブは UNIX システム上では意味を持ちません。 UNIX の場合には、 StartServersMaxRequestsPerChild を参照してください。


ThreadStackSize

構文: ThreadStackSize 数値
デフォルト: ThreadStackSize 65536
コンテキスト: サーバ設定ファイル
ステータス: core (NetWare)
互換性: NetWare 上で動作する Apache 1.3 以降においてのみ有効

このディレクティブは、各スレッドのスタックのサイズをサーバに指示します。 スタックがオーバフローするようであれば、より大きな数値に設定する 必要があります。

このディレクティブは、他のシステムの場合には意味を持ちません。


TimeOut ディレクティブ

構文: TimeOut 数値
デフォルト: TimeOut 300
コンテキスト: サーバ設定ファイル
ステータス: core

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

  1. GET リクエストを受け取るのにかかる総時間
  2. POST や PUTリクエストにおいて、次の TCP パケットが届くまでの待ち時間
  3. レスポンスを返す際、TCP の ACK が帰ってくるまでの時間
将来には別々の設定をすることが可能にできるよう考案中です。 Apache 1.2 以前においてはタイマーは 1200 がデフォルトでしたが、 300 に下げられました。300 でもほとんどの場合は十分すぎる値です。 コード中の変な場所にまだパケットを送る際にタイマをリセットしない 場所があるかもしれないので、デフォルトをより小さい値にはしていません。

UseCanonicalName ディレクティブ

構文: UseCanonicalName on|off|dns
デフォルト: UseCanonicalName on
コンテキスト: サーバ設定ファイル、バーチャルホスト、ディレクトリ
上書き: Options
互換性: UseCanonicalName は Apache 1.3 以降で利用可能です。

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

例えば、ServerNamewww.example.com に設定されていて、Port9090 に設定されている場合は、サーバの正式な名前www.example.com:9090 になります。Port の値がデフォルトの 80 であるときは、 :80正式な名前からは省かれます。

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


User ディレクティブ

構文: User unix-userid
デフォルト: User #-1
コンテキスト: サーバ設定ファイル、バーチャルホスト
ステータス: core

User ディレクティブはサーバがリクエストに応答するときのユーザ ID を設定します。このディレクティブを使うためには、standalone サーバが root として起動されていなければなりません。 Unix-userid は以下のどれかです:

ユーザ名
名前でユーザを指定。
# の後にユーザ番号。
番号でユーザを指定。
ユーザは外の世界から見られることを意図していないファイルをアクセス できてしまうような権限が無いものにすべきで、同様に httpd のリクエスト に対して意図されていないコードを実行できないようなものにすべきです。 サーバを実行するためだけに新しい専用のユーザとグループを設定することを お勧めします。管理者の中には nobody を使う人もいますが、 このユーザは常に使用可能というわけではなく、望ましいわけでもありません。 例えば、mod_proxy のキャッシュを使用しているときは、 それをこのユーザがアクセスできる必要があります (CacheRoot ディレクティブ を参照)。

注意: root でないユーザでサーバを実行した場合は、より少ない権限の ユーザへの変更に失敗し、元々のユーザとして実行し続けます。 root でサーバを実行したときは、親プロセスが root のまま実行し続けるのは正常な動作です。

特別な注意: このディレクティブを <VirtualHost> 内で使うには適切に設定された suEXEC ラッパーが必要です。このように <VirtualHost> の中で使われたときは CGI を実行するユーザだけが影響を受けます。 CGI 以外のリクエストは依然として主 User ディレクティブで指定されたユーザで処理されます。

セキュリティ: 自分が何をやっているかを完全に理解していて どのような危険性があるかを理解していない場合は、 User (もしくは Group) を root にしないでください。


<VirtualHost> ディレクティブ

構文: <VirtualHost addr[:port] [addr[:port]] ...> ... </VirtualHost>
コンテキスト: サーバ設定ファイル
ステータス: Core.
互換性: IP アドレスベースでないバーチャルホストは、 Apache 1.1 以降で利用可能です。
互換性: 複数のアドレスの指定は Apache 1.2 以降でのみ可能です。

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

例:
<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>
各々のバーチャルホストにはそれぞれ違う IP アドレス、ポート番号若しくはホスト名に対応する必要があり、 1 番目の場合には複数のアドレスで IP パケットを受信できるようにサーバマシンを設定しなければなりません。 (もし、マシンが複数のネットワークインターフェースを持たない場合は、 (OSがサポートしていれば) ifconfig alias コマンドや VIF のようなカーネルパッチ (SunOS(TM) 4.1.x 用) により達成できます)。

複数の IP アドレスを定義することもできます。 二つのインタフェースに対して同じ名前で応答しているときに有用でしょう。 例えば、内部向け (イントラネット) と 外部向け (インターネット) にバーチャルホストをしている場合です。
設定例:

<VirtualHost 192.168.1.2 204.255.176.199>
DocumentRoot /www/docs/host.foo.com
ServerName host.foo.com
ServerAlias host
</VirtualHost>
_default_ という特別な名前を指定することにより、 他のバーチャルホストで指定されていない IP アドレスすべてに対してマッチさせることが可能です。_default_ バーチャルホストが無いときは、もしどこにもマッチしないと VirtualHost セクションの外の定義からなる「主」サーバ設定が使用されます。

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

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

注意点: <VirtualHost> は Apache が Listen する IP アドレスには影響を与えませんBindAddressListen を使って Apache が正しいアドレスを listen するように設定する必要があるかもしれません。

参照: Apache バーチャルホスト説明書
参照: DNS に関する問題
参照: Apache が利用するアドレスとポートを設定する
参照: リクエストを受けた際に、異なる複数のセクションがどのようにして組み合わされるのかについては Directory, Location, Files セクションの動作法



Apache HTTP Server Version 1.3

Index Home