Apache HTTP Server Version 1.3

Apache コア機能

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

ディレクティブ

• AcceptFilter
• AcceptMutex
• AccessConfig
• AccessFileName
• AddDefaultCharset
• AddModule
• AllowOverride
• AuthName
• AuthType
• AuthDigestRealmSeed
• BindAddress
• BS2000Account
• CGICommandArgs
• ClearModuleList
• ContentDigest
• CoreDumpDirectory
• DefaultType
• <Directory>
• <DirectoryMatch>
• DocumentRoot
• EBCDICConvert
• EBCDICConvertByType
• EBCDICKludge
• EnableExceptionHook
• ErrorDocument
• ErrorLog
• FileETag
• <Files>
• <FilesMatch>
• Group
• HostnameLookups
• IdentityCheck
• <IfDefine>
• <IfModule>
• Include
• KeepAlive
• KeepAliveTimeout
• <Limit>
• <LimitExcept>
• LimitInternalRecursion
• LimitRequestBody
• LimitRequestFields
• LimitRequestFieldsize
• LimitRequestLine
• Listen
• ListenBacklog
• <Location>
• <LocationMatch>
• LockFile
• LogLevel
• MaxClients
• MaxKeepAliveRequests
• MaxRequestsPerChild
• MaxSpareServers
• MinSpareServers
• NameVirtualHost
• Options
• PidFile
• Port
• ProtocolReqCheck
• Require
• ResourceConfig
• RLimitCPU
• RLimitMEM
• RLimitNPROC
• Satisfy
• ScoreBoardFile
• ScriptInterpreterSource
• SendBufferSize
• ServerAdmin
• ServerAlias
• ServerName
• ServerPath
• ServerRoot
• ServerSignature
• ServerTokens
• ServerType
• ShmemUIDisUser
• StartServers
• ThreadsPerChild
• ThreadStackSize
• TimeOut
• UseCanonicalName
• User
• <VirtualHost>

AcceptFilter ディレクティブ

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

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

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

AcceptMutex ディレクティブ

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

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

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

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

AccessConfig ディレクティブ

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

AccessConfig /dev/null

AccessConfig nul

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

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

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

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

参照: Include,ResourceConfig.

AccessFileName ディレクティブ

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

AccessFileName .acl

<Directory />
AllowOverride None
</Directory>

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

AddDefaultCharset ディレクティブ

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

例:

AddDefaultCharset utf-8

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

AddModule ディレクティブ

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

例:

AddModule mod_include.c

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

参照: ClearModuleList と LoadModule

AllowOverride ディレクティブ

サーバが (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

特定のディレクトリにおける機能を指定するためのディレクティブの使用を許可する (Options と XBitHack).

例:

AllowOverride AuthConfig Indexes

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

AuthName ディレクティブ

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

例:

AuthName "秘密のパスワード"

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

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

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

AuthDigestRealmSeed directive

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

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

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

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

AuthType ディレクティブ

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

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

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

BindAddress ディレクティブ

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

例:

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

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

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

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

BS2000Account ディレクティブ

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

参照: Apache の EBCDIC への移植版

CGICommandArgs directive

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

ClearModuleList ディレクティブ

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

参照: AddModule と LoadModule

ContentDigest ディレクティブ

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

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

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

   Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==

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

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

CoreDumpDirectory ディレクティブ

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

設定例:

CoreDumpDirectory /tmp

DefaultType ディレクティブ

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

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

DefaultType image/gif

参照: AddType 及び TypesConfig

<Directory> ディレクティブ

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

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

<Directory />
AllowOverride None
</Directory>

<Directory /home/*>
AllowOverride FileInfo
</Directory>

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

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

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

<Directory ~ abc$>
... directives here ...
</Directory>


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

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

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

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

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

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

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

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

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

参照: DirectoryMatch

<DirectoryMatch>

指定されたディレクトリ配下にのみディレクティブを適用させるために、 <Directory> と同様に <DirectoryMatch> 及び </DirectoryMatch> を対として、ディレクティブ群を囲うことができます。 ただし、引数は正規表現となります。例えば、

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

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

参照: 通常の <Directory> セクションと一緒に正規表現を利用するための解説としては <Directory>
参照: リクエストを受けた際に、 異なる複数のセクションがどのようにして組み合わされるのかについては Directory, Location 及び Files セクションがどのように動作するのか

DocumentRoot ディレクティブ

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

DocumentRoot /usr/web

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

EBCDICConvert

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

オプションの形式 On=direction (や Off=direction) が指定されると (direction は In, 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

参照: EBCDICConvertByType と EBCDICConvertByType 変換関数の概要

EBCDICConvertByType

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

オプションの形式 On=direction (や Off=direction) が指定されると (direction は In, 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 */*

    # すべてのドキュメントは既に ASCII
    EBCDICConvertByType Off */*

参照: EBCDICConvert と EBCDIC 変換関数の概要

EBCDICKludge

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, EBCDICConvertByType と EBCDIC 変換関数の概要

EnableExceptionHook directive

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

ErrorDocument ディレクティブ

問題やエラーが発生したときの動作として、 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 ディレクティブ

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

例

ErrorLog logs/vhost1.error

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

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

例:

ErrorLog syslog

ErrorLog syslog:user

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

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

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

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

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

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

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

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

<FilesMatch>

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

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

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

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

Group ディレクティブ

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

グループ名

名前でグループを指定します。

# を先頭にグループ ID

数字でグループを指定します。

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

例:

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

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

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

HostnameLookups ディレクティブ

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

このディレクティブは、クライアントマシン上で 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> セクションは入れ子にすることができ、 複数のパラメータによるテストをするために使用できます。 例:

  $ httpd -DReverseProxy ...

  # httpd.conf
  <IfDefine ReverseProxy>
  LoadModule rewrite_module libexec/mod_rewrite.so
  LoadModule proxy_module   libexec/libproxy.so
  </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 といった形になります。

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

Include ディレクティブ

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

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

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

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

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

<Limit> ディレクティブ

アクセス制御は、通常すべてのアクセスメソッドに対して 影響し、普通はこれが望ましい挙動です。 そうしたことから、大部分の場合にはアクセス制御に関わるディレクティブを <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> と </LimitExcept> は、引数に含まれていない HTTP のアクセスメソッドに適用するためのアクセス制御 ディレクティブを囲むために利用します。つまり、<Limit> セクションの反対の動作をし、 標準のメソッドと標準外や未認識のメソッドの場合の両方を設定できます。 <Limit> のドキュメントも併せて参照してください。

例:

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

LimitInternalRecursion directive

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

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

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

例

    LimitInternalRecursion 5
    

LimitRequestBody ディレクティブ

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

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

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

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

LimitRequestBody 102400

LimitRequestFields ディレクティブ

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

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

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

例:

LimitRequestFields 50

LimitRequestFieldsize ディレクティブ

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

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

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

例:

LimitRequestFieldSize 16380

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

LimitRequestLine ディレクティブ

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

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

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

例:

LimitRequestLine 16380

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

Listen ディレクティブ

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

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

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

<Location> ディレクティブ

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

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

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

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

LockFile ディレクティブ

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

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

LogLevel ディレクティブ

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

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

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

例:

LogLevel notice

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

MaxClients ディレクティブ

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

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

MaxKeepAliveRequests ディレクティブ

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

例

MaxKeepAliveRequests 500

MaxRequestsPerChild ディレクティブ

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

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

• (予期せぬ) メモリリークによってプロセスが消費する メモリの総量を制限することができます。
• プロセスの実行時間制限が設けられることにより、 サーバの負荷低減時にプロセスの数を減少させることを助けます。

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

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

MaxSpareServers ディレクティブ

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

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

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

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

MinSpareServers、StartServers、MaxClients も参照してください。

MinSpareServers ディレクティブ

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

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

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

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

MinSpareServers、StartServers、MaxClients も参照してください。

NameVirtualHost ディレクティブ

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

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

NameVirtualHost 111.22.33.44

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

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

NameVirtualHost 111.22.33.44:8080

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

Options ディレクティブ

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

option を None に指定すると、特別な機能はすべて無効になります。また、以下の示す 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> 内にこのオプションを指定しても無視されます。

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

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

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

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

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

PidFile ディレクティブ

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

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

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

Port ディレクティブ

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

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

• ポート番号を指定している Listen や BindAddress がなければ、主サーバ内 (<VirtualHost> セクション外) に記述することによって、サーバが listen するポートの番号を指定できます。Listen 若しくは BindAddress において :number といった指定がされていれば、Port はサーバが listen するポートには影響しません。
• Port ディレクティブの値は、SERVER_PORT 環境変数 (CGI や SSI において設定される) を設定し、サーバが自分自身を参照する URL を生成する (例えば、自分自身へ外部リダイレクトを作成する場合など) 場合に利用されます。この動作は UseCanonicalName により変更できます。

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

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

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

ProtocolReqCheck ディレクティブ

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

Require ディレクティブ

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

• Require user userid [userid] ...

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

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

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

• Require valid-user

  すべての認証されたユーザに、リソースへのアクセスを許可します。

• file-owner

  名前がファイルの所有者のシステムでの名前に合うユーザだけが リソースをアクセスできます。
  [Apache 1.3.20 以降で使用可能]

• file-group

  ファイルの所有者のグループのシステムでの名前に合うグループのメンバだけが リソースにアクセスできます。
  [Apache 1.3.20 以降で使用可能]

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

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


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

ResourceConfig ディレクティブ

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

ResourceConfig /dev/null

ResourceConfig nul

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

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

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

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

参照: AccessConfig

RLimitCPU ディレクティブ

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

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

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

RLimitMEM や RLimitNPROC も参照してください。

RLimitMEM ディレクティブ

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

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

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

RLimitCPU や RLimitNPROC も参照してください。

RLimitNPROC ディレクティブ

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

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

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

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

RLimitCPU や RLimitCPU も参照してください。

Satisfy ディレクティブ

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

Require と Allow も参照してください。

ScoreBoardFile ディレクティブ

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

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

Apache 1.2 以降:

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

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

参照: Apache の停止と再起動

ScriptInterpreterSource ディレクティブ

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

SendBufferSize ディレクティブ

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

ServerAdmin ディレクティブ

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

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

ServerAdmin www-admin@foo.bar.com

ServerAlias ディレクティブ

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

例:

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

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

ServerName ディレクティブ

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

ServerName www.example.com

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

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

ServerPath ディレクティブ

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

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

ServerRoot ディレクティブ

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

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

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

ServerSignature ディレクティブ

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

ServerTokens ディレクティブ

このディレクティブは、クライアントに送り返す 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 には、次のどちらかを指定します。

inetd

サーバは、inetd プロセスから実行され、 /etc/inetd.conf に起動するコマンドを記述します。

standalone

サーバは、デーモンプロセスとして実行し、 システムのスタートアップスクリプト (/etc/rc.local か /etc/rc3.d/...) に起動するコマンドを記述します。

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

ShmemUIDisUser ディレクティブ

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

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

StartServers ディレクティブ

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

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

MinSpareServers や MaxSpareServers も参照してください。

ThreadsPerChild

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

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

ThreadStackSize

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

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

TimeOut ディレクティブ

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

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

UseCanonicalName ディレクティブ

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

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

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

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

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

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

参照: ServerName, Port

User ディレクティブ

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

ユーザ名

名前でユーザを指定。

# の後にユーザ番号。

番号でユーザを指定。

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

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

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

<VirtualHost> ディレクティブ

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

• バーチャルホストの IP アドレス
• バーチャルホストの IP に対応する完全なドメイン名

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

<VirtualHost 192.168.1.2 204.255.176.199>
DocumentRoot /www/docs/host.foo.com
ServerName host.foo.com
ServerAlias host
</VirtualHost>

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

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

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

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

Apache HTTP Server Version 1.3