しかし後述する問題のため、このディレクティブは非推奨です。
同等の機能は <
module>mod_filter</
module> で実現可能です。</
p>
<
p>次の例は <
module>mod_deflate</
module> の <
code>DEFLATE</
code> フィルタを
すべての出力 (静的なものも動的なものも) をクライアントに送られる前に
<
p>複数のフィルタでコンテンツを処理させたいときは、それぞれの名前をセミコロンで
<
directive>AddOutputFilterByType</
directive> を一つずつ書くこともできます。</
p>
<
p>次の例は <
code>
text/
html</
code> のスクリプトのすべての出力を
まず <
code>INCLUDES</
code> フィルタで処理し、さらに <
code>DEFLATE</
code> フィルタにかけます。</
p>
<Location /cgi-bin/><
br />
AddOutputFilterByType INCLUDES;DEFLATE
text/
html<
br />
<
note type="warning"><
title>注:</
title>
<
p><
directive>AddOutputFilterByType</
directive> ディレクティブにより
有効にしたフィルタは場合によっては、部分的もしくは完全に適用されないことが
あります。例えば、<
glossary ref="mime-type">MIME タイプ</
glossary> が決定できないときには
<
directive module="core">DefaultType</
directive> の設定が同じだったとしても、
<
directive module="core">DefaultType</
directive> 設定を使うようになります。</
p>
<
p>しかし、確実にフィルタが適用されるようにしたいときは、リソースに
明示的にコンテントタイプを割り当てることができます。これには例えば
<
directive module="mod_mime">AddType</
directive> ディレクティブや
<
directive module="core">ForceType</
directive> ディレクティブを使います。
(nphでない) CGI スクリプトでコンテントタイプを設定するというものでも
<
seealso><
directive module="mod_mime">AddOutputFilter</
directive></
seealso>
<
seealso><
directive module="core">SetOutputFilter</
directive></
seealso>
<
name>AllowEncodedSlashes</
name>
<
description>URL 中の符号化されたパス分離文字が先に伝えられるのを許可するかどうかを
<
syntax>AllowEncodedSlashes On|Off</
syntax>
<
default>AllowEncodedSlashes Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
compatibility>Apache 2.0.46 以降で使用可能</
compatibility>
<
p><
directive>AllowEncodedSlashes</
directive> ディレクティブは符号化された
パス分離文字 (<
code>/</
code> は <
code>%2F</
code>、さらにシステムによっては
<
code>\</
code> に対応する <
code>%5C</
code>) が存在する URL の使用を
許可するかどうかを決定します。通常はそのような URL は 404 (Not found) エラー
<
p><
directive>AllowEncodedSlashes</
directive> <
code>On</
code> による
パス分離文字の使用は、<
code>PATH_INFO</
code> と合わせて
<
p>符号化されたスラッシュを許可することは、<
em>復号</
em>をすることを
意味<
em>しません</
em>。<
code>%2F</
code> や (関係するシステムでの)
<
code>%5C</
code> は、他の部分が復号された URL の中でもそのままの形式で
<
seealso><
directive module="core">AcceptPathInfo</
directive></
seealso>
<
name>AllowOverride</
name>
<
description><
code>.htaccess</
code> で許可されるディレクティブの種類</
description>
<
syntax>AllowOverride All|None|<
var>directive-type</
var>
[<
var>directive-type</
var>] ...</
syntax>
<
default>AllowOverride All</
default>
<
contextlist><
context>directory</
context></
contextlist>
module="core">AccessFileName</
directive> によって指定された)
<
code>.htaccess</
code> ファイルを見つけた時、そのファイルの中で
宣言されたどのディレクティブがより前に定義された設定ディレクティブを
<
note><
title><Directory> セクションでのみ使用可能</
title>
<
directive>AllowOverride</
directive> は正規表現無しの<
directive type="section" module="core">Directory</
directive>
セクションでのみ有効で、<
directive type="section" module="core">Location</
directive> や <
directive module="core" type="section">DirectoryMatch</
directive>
や <
directive type="section" module="core">Files</
directive> セクションでは無効です。
<
p>このディレクティブを <
code>None</
code> に設定すると、<
a href="#accessfilename">.htaccess</
a> ファイルは完全に
この場合、サーバはファイルシステムの <
code>.htaccess</
code> ファイルを読むことを
<
p>このディレクティブが <
code>All</
code> に設定されている時には、
<
code>.htaccess</
code> という <
a <
p><
var>directive-type</
var> には、以下のディレクティブ群の
認証に関するディレクティブの使用を許可する (<
directive module="mod_authn_dbm">AuthDBMGroupFile</
directive>,
<
directive module="mod_authn_dbm">AuthDBMUserFile</
directive>,
<
directive module="mod_authz_groupfile">AuthGroupFile</
directive>,
<
directive module="mod_authn_core">AuthName</
directive>,
<
directive module="mod_authn_core">AuthType</
directive>, <
directive module="mod_authn_file">AuthUserFile</
directive>, <
directive module="mod_authz_core">Require</
directive> <
em>など</
em>)。</
dd>
ドキュメントタイプを制御するためのディレクティブの使用を許可する (<
directive module="core">DefaultType</
directive>, <
directive module="core">ErrorDocument</
directive>, <
directive module="core">ForceType</
directive>, <
directive module="mod_negotiation">LanguagePriority</
directive>,
<
directive module="core">SetHandler</
directive>, <
directive module="core">SetInputFilter</
directive>, <
directive module="core">SetOutputFilter</
directive>,
<
module>mod_mime</
module> の Add* と Remove*
module="mod_headers">Header</
directive>, <
directive module="mod_headers">RequestHeader</
directive>, <
directive module="mod_setenvif">SetEnvIf</
directive>, <
directive module="mod_setenvif">SetEnvIfNoCase</
directive>, <
directive module="mod_setenvif">BrowserMatch</
directive>, <
directive module="mod_usertrack">CookieExpires</
directive>, <
directive module="mod_usertrack">CookieDomain</
directive>, <
directive module="mod_usertrack">CookieStyle</
directive>, <
directive module="mod_usertrack">CookieTracking</
directive>, <
directive module="mod_usertrack">CookieName</
directive>),
<
module>mod_rewrite</
module> のディレクティブ <
directive module="mod_rewrite">RewriteEngine</
directive>, <
directive module="mod_rewrite">RewriteOptions</
directive>, <
directive module="mod_rewrite">RewriteBase</
directive>, <
directive module="mod_rewrite">RewriteCond</
directive>, <
directive module="mod_rewrite">RewriteRule</
directive>) と
<
module>mod_actions</
module> の
<
directive module="mod_actions">Action</
directive>
ディレクトリインデックスを制御するためのディレクティブの使用を許可する
module="mod_autoindex">AddDescription</
directive>,
<
directive module="mod_autoindex">AddIcon</
directive>, <
directive module="mod_autoindex">AddIconByEncoding</
directive>,
<
directive module="mod_autoindex">AddIconByType</
directive>,
<
directive module="mod_autoindex">DefaultIcon</
directive>, <
directive module="mod_dir">DirectoryIndex</
directive>, <
directive module="mod_autoindex">FancyIndexing</
directive>, <
directive module="mod_autoindex">HeaderName</
directive>, <
directive module="mod_autoindex">IndexIgnore</
directive>, <
directive module="mod_autoindex">IndexOptions</
directive>, <
directive module="mod_autoindex">ReadmeName</
directive>
ホストへのアクセス制御を行うためのディレクティブの使用を許可する (<
directive module="mod_authz_host">Allow</
directive>, <
directive module="mod_authz_host">Deny</
directive>, <
directive module="mod_authz_host">Order</
directive>).</
dd>
<
dt>Options[=<
var>Option</
var>,...]</
dt>
特定のディレクトリにおける機能を指定するためのディレクティブの使用を許可する
(<
directive module="core">Options</
directive> と
<
directive module="mod_include">XBitHack</
directive>)。
<
directive module="core">Options</
directive> で設定するオプション
を、(空白を含めない) コンマ区切りのリストにして等号の後に続けることで
AllowOverride AuthConfig Indexes
<
p>上の例では <
code>AuthConfig</
code> と <
code>Indexes</
code> のどちらにも
属さないディレクティブはすべて内部サーバエラーを引き起こします。</
p>
<
seealso><
directive module="core">AccessFileName</
directive></
seealso>
<
name>CGIMapExtension</
name>
<
description>CGI スクリプトのインタープリタの位置を調べるための手法</
description>
<
syntax>CGIMapExtension <
var>cgi-path</
var> <
var>.extension</
var></
syntax>
<
contextlist><
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
<
compatibility>NetWare のみ</
compatibility>
<
p>このディレクティブは Apache が CGI スクリプトを実行するための
例えば、<
code>CGIMapExtension sys:\
foo.nlm .foo</
code> と設定すると
<
code>.foo</
code> という拡張子のすべての CGI スクリプトは FOO インタープリタに
<
name>ContentDigest</
name>
<
description><
code>Content-MD5</
code> HTTP 応答ヘッダの生成を有効にする</
description>
<
syntax>ContentDigest On|Off</
syntax>
<
default>ContentDigest Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>Options</
override>
<
status>Experimental</
status>
<
p>このディレクティブは、RFC1864 及び RFC2616 において定義されている
<
code>Content-MD5</
code> ヘッダーの生成を有効にします。</
p>
<
p>MD5 は、任意長のデータの「メッセージダイジェスト」(「指紋」
と表現されることもある) を計算するアルゴリズムで、
データの変更があった場合には非常に高い信頼度でメッセージダイジェストに変更が
<
p><
code>Content-MD5</
code> ヘッダは、エンドツーエンドで
エンティティボディーに含まれるメッセージの完全性チェック
(Message Integrity Check - MIC)を提供します。
このヘッダを調べることで、プロキシやクライアントは、
途中経路におけるエンティティボディの予期せぬ変更などを
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
<
p>リクエスト毎にメッセージダイジェストを計算する (値はキャッシュされません)
サーバパフォーマンスが低下することについて注意してください。</
p>
<
p><
code>Content-MD5</
code >は、<
module>core</
module> 機能により処理された
SSI ドキュメントや CGI スクリプトの出力、バイトレンジを指定した
<
description>サーバがコンテントタイプを決定できないときに
送られる MIME コンテントタイプ</
description>
<
syntax>DefaultType <
var>MIME-type|none</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
<
compatibility>引数 <
code>none</
code> は Apache 2.2.7 以降で利用可能</
compatibility>
<
p>サーバは、<
glossary ref="mime-type">MIME タイプ</
glossary>
のマップからは決定できないドキュメントの送信を要求されることがあります。</
p>
<
p>サーバは、ドキュメントのコンテントタイプをクライアントに通知するべきです。
<
code>DefaultType</
code> で指定されたタイプを利用します。
<
p>これは <
code>.gif</
code> という拡張子がファイル名に含まれていない
多くの GIF 画像が含まれているディレクトリに適しているでしょう。</
p>
<
p>サーバでも管理者でも判定することができない (例えばプロクシの) 場合、
誤った情報を与えるよりは MIME タイプの指定がない状態が望ましいことも
<
p><
code>DefaultType None</
code> は httpd-2.2.7
<
p><
directive module="core">ForceType</
directive> ディレクティブと
違って、このディレクティブはデフォルトの MIME タイプを提供するだけで
あることに注意してください。ファイル名の拡張子を含め、
メディアタイプを決定できる他の MIME タイプの定義があれば
<
description>変数の存在を宣言する</
description>
<
syntax>Define <
var>parameter-name</
var></
syntax>
<
contextlist><
context>server config</
context></
contextlist>
<
p><
program>httpd</
program> の <
code>-D</
code>
<
p>このディレクティブを使うと、スタートアップスクリプトに
記載されている <
code>-D</
code> 引数を書き換える必要なく、
<
directive module="core" type="section">IfDefine</
directive>
<
directivesynopsis type="section">
<
description>指定のファイルシステムのディレクトリとサブディレクトリとのみに
適用されるディレクティブを囲む</
description>
<
syntax><Directory <
var>directory-path</
var>>
... </Directory></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p>指定されたディレクトリとそのサブディレクトリにのみ
<
directive type="section">Directory</
directive> と
<
code></Directory></
code> を対として、ディレクティブ群を囲います。
その中には、ディレクトリコンテキストで許可された全てのディレクティブを
<
var>directive-path</
var> は、フルパスもしくは Unix のシェル形式の
<
code>?</
code> は任意の 1 文字、<
code>*</
code> は任意の文字列にマッチします。
シェルにおける指定同様、文字の範囲を <
code>[]</
code> で指定できます。
ワイルドカードは `/' 文字にはマッチしませんので、
<
code><Directory /*/public_html></
code> はマッチしませんが、
<
code><Directory /home/*/public_html></
code> はマッチします。
Options Indexes FollowSymLinks<
br />
<
p><
var>directory-path</
var> 引数には注意してください: その引数は
Apache がファイルをアクセスするために使うファイルシステムのパスに
そのままマッチする必要があります。ある <
code><Directory></
code> に
適用されるディレクティブは、別のシンボリックリンクをたどったりして
同じディレクトリを違うパスでアクセスした場合には適用されません。</
p>
付加することで<
glossary ref="regex">正規表現</
glossary>を利用することもできます。
<Directory ~ "^/www/.*/[0-9]{3}">
<
p>といった指定の場合、<
code>/www/</
code> 以下にある数字
<
p>もし複数の (正規表現以外の) <
directive type="section" >Directory</
directive>セクションが
ドキュメントを含むディレクトリ (やその上位ディレクトリのどれか) とマッチしたならば、
href="#accessfilename">.htaccess</
a> ファイルのディレクティブも読み込みつつ、
<Directory /><
br />
<Directory /home/><
br />
AllowOverride FileInfo<
br />
アクセスがあった場合には以下のように動作します:</
p>
<
li><
code>AllowOverride None</
code> が適用される。
(<
code>.htaccess</
code> ファイルは無効になる)</
li>
<
li><
code>AllowOverride FileInfo</
code> が適用される
(<
code>/home</
code> ディレクトリに対して)。</
li>
FileInfo ディレクティブが適用される。</
li>
<
p>正規表現は、通常のセクションがすべて適用されるまで
その後、全ての正規表現が設定ファイルに現れた順で試されます。
<Directory ~ abc$><
br />
# ... directives here ...<
br />
<
p>正規表現のセクションはすべての通常の <
directive type="section">Directory</
directive> と
<
code>.htaccess</
code> の適用が終わるまで考慮されません。
対応する <
directive type="section">Directory</
directive> が適用されます。</
p>
<
p><
strong>Apache のデフォルトでは <
code><Directory /></
code> へのアクセスは
<
code>Allow from All</
code> になっていることに注意してください。
これは、URL からマップされたどのファイルでも Apache は送るということです。
これは以下のようにして変更することが推奨されています。</
strong></
p>
<Directory /><
br />
<
p><
strong>そしてアクセスを<
em>可能にしたい</
em>ディレクトリに対して
<
p>ディレクトリセクションは <
code>
httpd.conf</
code> ファイルに書きます。
<
directive type="section">Directory</
directive>
<
directive module="core" type="section">Limit</
directive> や <
directive module="core" type="section">LimitExcept</
directive> セクションの中にも
<
seealso>リクエストを受けた際にこれらの異なるセクションが
<Directory>, <Location>, <Files> セクションの動作法</
a></
seealso>
<
directivesynopsis type="section">
<
name>DirectoryMatch</
name>
<
description>正規表現にマッチするファイルシステムのディレクトリと
サブディレクトリとのみに適用されるディレクティブを囲む</
description>
<
syntax><DirectoryMatch <
var>regex</
var>>
... </DirectoryMatch></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive module="core" type="section">Directory</
directive>
ディレクティブと同様に、<
directive type="section">DirectoryMatch</
directive>
と <
code></DirectoryMatch></
code> は指定されたディレクトリと
そのサブディレクトリにのみ適用されるディレクティブ群を囲います。
しかし、このディレクティブは引数として<
glossary ref="regex">正規表現</
glossary>をとります。例えば:</
p>
<DirectoryMatch "^/www/(.+/)?[0-9]{3}">
<
p>は <
code>/www/</
code> 以下にある数字 3 文字のディレクトリにマッチします。</
p>
<
seealso>通常の <
directive type="section">Directory</
directive> と正規表現の指定が
適用される順番については <
directive type="section"module="core">Directory</
directive></
seealso>
<
seealso>リクエストを受けた際にこれらの異なるセクションが
<Directory>, <Location>, <Files> セクションの動作法</
a></
seealso>
<
name>DocumentRoot</
name>
<
description>ウェブから見えるメインのドキュメントツリーになる
<
syntax>DocumentRoot <
var>directory-path</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p>このディレクティブは、<
program>httpd</
program>
<
directive module="mod_alias">Alias</
directive> のようなディレクティブにマッチしない場合には、
ドキュメントの (訳注:ファイルシステム上の) パスを生成するために、
リクエストされた URL のパス部分をドキュメントルートに付与します。
<
var>directory-path</
var> が絶対パスでない場合は、
<
directive module="core">ServerRoot</
directive>
<
p><
directive>DocumentRoot</
directive> は最後のスラッシュ無しで
<
description>配送中にファイルを読み込むためにメモリマッピングを
<
syntax>EnableMMAP On|Off</
syntax>
<
default>EnableMMAP On</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
<
p>このディレクティブは配送中にファイルの内容を読み込む必要があるときに
<
program>httpd</
program> がメモリマッピングを使うかどうかを制御します。
例えば、<
module>mod_include</
module> を使って SSI ファイルを配送
するときのように、ファイルの途中のデータをアクセスする必要があるときには
Apache は OS がサポートしていればファイルをメモリにマップします。</
p>
このメモリマップは性能の向上をもたらすことがあります。
しかし、環境によっては運用上の問題を防ぐためにメモリマッピングを
使用しないようにした方が良い場合もあります:</
p>
<
li>マルチプロセッサシステムの中にはメモリマッピングをすると
<
program>httpd</
program> の性能が落ちるものがあります。</
li>
<
li>NFS マウントされた <
directive module="core">DocumentRoot</
directive>
では、<
program>httpd</
program> がメモリマップしている間にファイルが削除されたり
短くなったりしたときに起こるセグメンテーションフォールトのために
<
program>httpd</
program> がクラッシュする可能性があります。</
li>
<
p>これらの問題に当てはまるサーバの設定の場合は、以下のようにして
ファイルの配送時のメモリマッピングを使用不可にしてください:</
p>
<
p>NFS マウントされたファイルには、問題のあるファイルにのみ明示的に
<Directory "/path-to-nfs-files">
<
name>EnableSendfile</
name>
<
description>ファイルのクライアントへの配送時にカーネルの sendfile サポートを
<
syntax>EnableSendfile On|Off</
syntax>
<
default>EnableSendfile On</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
<
compatibility>バージョン 2.0.44 以降で使用可能</
compatibility>
<
p>このディレクティブはクライアントにファイルの内容を送るときに
<
program>httpd</
program> がカーネルの
sendfile サポートを使うかどうかを制御します。デフォルトでは、
例えば静的なファイルの配送のように、リクエストの処理にファイルの
途中のデータのアクセスを必要としないときには、Apache は OS が
サポートしていればファイルを読み込むことなく sendfile を使って
<
p>sendfile は read と send を別々に行なうことと、バッファの割り当てを
回避します。しかし、プラットフォームやファイルシステムの中には
運用上の問題を避けるためにこの機能を使用不可にした方が良い場合があります:</
p>
<
li>プラットフォームの中にはビルドシステムが検知できなかった、壊れた
sendfile のサポートが存在するものがあります。これは特に
バイナリが別のマシンでビルドされ、壊れた sendfile のあるマシンに
<
li>Linux では、sendfile を用いると、
IPv6 使用時に存在する特定ネットワークカードの TCP-checksum
<
li>Itanium 上の Linux では、sendfile では 2GB 以上の
<
li>ネットワークマウントされた <
directive module="core">DocumentRoot</
directive>
では、カーネルは自身のキャッシュを使ってネットワークからのファイルを
<
p>これらの問題に当てはまるサーバの設定の場合は、以下のようにして
<
p>NFS や SMB マウントされたファイルには、問題のあるファイルにのみ明示的に
<Directory "/path-to-nfs-files">
<
name>ErrorDocument</
name>
<
description>エラーが発生したときにサーバがクライアントに送るもの</
description>
<
syntax>ErrorDocument <
var>error-code document</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
Apache には以下の四つのうち一つの動作を設定することができます。</
p>
<
li>Apache 標準の簡単なエラーメッセージを表示</
li>
<
li>問題やエラーの処理をする為に、自サーバ内の
<
var>URL-path</
var> へリダイレクト</
li>
<
li>問題やエラーの処理をする為に、外部の <
var>URL</
var> へリダイレクト</
li>
<
p>最初のものがデフォルトの動作で、2 番目から 4 番目は、
<
directive>ErrorDocument</
directive>ディレクティブにより、
HTTP のレスポンスコードと、メッセージか URL を指定することで設定します。
Apache が問題もしくはエラーに関する追加情報を提供することがあります。</
p>
<
p>URL の場合は、スラッシュで始まる (/) ローカルの web-path (
<
directive module="core">DocumentRoot</
directive> からの相対パス
) か、クライアントが解決できる完全な URL を指定します。
もしくは、ブラウザに表示されるメッセージを指定できます。
ErrorDocument 403 "Sorry can't allow you access today"
<
p>加えて、特別な値 <
code>default</
code> を使って Apache に
ハードコードされている簡単なメッセージを指定することができます。
通常は必要ではありませんが、<
code>default</
code> を使うと
既存の <
directive>ErrorDocument</
directive> ディレクティブの設定を
継承するところで、Apache のハードコードされた簡単なメッセージに
ErrorDocument 404 default<
br />
<
p>リモート URL (例えば、頭に <
code>http</
code> と付与した方法) を
<
directive>ErrorDocument</
directive> に指定するとき、
たとえ文書が同じサーバにあろうとも、ドキュメントがどこにあるかを通知するために、
Apache はリダイレクトをクライアントに送出するということに、注意してください。
中でも最も重要なのは、クライアントは元々のエラーステータスコードを受け取らず、
代わりにリダイレクトのステータスコードを受け取るということです。
これにより、ステータスコードを使って URL が有効であるかどうかを決定しようとする
ウェブロボットやその他クライアントを、混乱させるかもしれません。
さらに、<
code>ErrorDocument 401</
code> にリモートの URL を指定すると、
クライアントは 401 というステータスコードを受け取らないため、
パスワードをユーザーに入力要求しなければならないことがわかりません。
従って、<
strong><
code>ErrorDocument 401</
code> というディレクティブを使う場合は、
必ずローカルな文書を参照しなければなりません。</
strong></
p>
<
p>Microsoft Internet Explorer (MSIE) はデフォルトではサーバが生成したエラーメッセージが
「小さすぎる」ときには無視をして自分自身の「やさしい」エラーメッセージで
置換します。サイズのしきい値はエラーの種類によって異なりますが、
一般的にはエラーの文書を 512 バイトよりも大きくすると、MSIE は
サーバが生成したエラーを隠さずに表示します。詳しい情報は Microsoft
<
p>ほとんどのエラーメッセージを上書きすることができますが、特定の状況下では
<
directive module="core">ErrorDocument</
directive> の設定にかかわらず
特に、不正な形式のリクエストが検出された場合、通常のリクエスト処理は
即座に中止され、内蔵のエラーメッセージが返されます。
この処置は不正なリクエストによって引き起こされる、セキュリティ問題から
<
p>2.0 より前のバージョンでは、対になっていない二重引用符を
先頭に付けることによりメッセージであることを指定していました。</
p>
エラー応答のドキュメンテーション</
a></
seealso>
<
description>サーバがエラーをログ収集する場所</
description>
<
syntax> ErrorLog <
var>file-path</
var>|syslog[:<
var>facility</
var>]</
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive>ErrorLog</
directive> ディレクティブは、
<
var>file-path</
var> が絶対パスでないときは、<
directive module="core">ServerRoot</
directive> からの相対パスとみなされます。</
p>
<
example><
title>例</
title>
<
p><
var>file-path</
var> がパイプ (|) から始まる場合は、
<
example><
title>例</
title>
<
p>ファイル名の変わりに <
code>syslog</
code> と指定することによって、
システムがサポートしていれば syslogd(8) を利用したロギングが有効になります。
デフォルトでは、<
code>local7</
code> ファシリティとなりますが、
<
code>syslog:<
var>facility</
var></
code> といった形で記述することにより、
通常 syslog(1) のドキュメントで説明されているファシリティの一つを使うように
<
example><
title>例</
title>
ログファイルを格納するディレクトリが、サーバを起動したユーザ以外の
ユーザによって書き込める場合にセキュリティが破られる可能性があることに
<
note type="warning"><
title>注</
title>
<
p>Unix 以外のプラットフォームでファイルのパスを入力するときは、
プラットフォームがバックスラッシュの使用を許していたとしても、
確実にスラッシュのみが使用されるように注意してください。一般的には、
設定ファイル全般でスラッシュのみを使う方が良いでしょう。</
p>
<
seealso><
directive module="core">LogLevel</
directive></
seealso>
<
seealso><
a href="/logs.html">Apache ログファイル</
a></
seealso>
<
description>ETag HTTP 応答ヘッダを作成するために使用される
<
syntax>FileETag <
var>component</
var> ...</
syntax>
<
default>FileETag INode MTime Size</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
<
directive>FileETag</
directive> ディレクティブは
ドキュメントがファイルに基づいたものであるときに、
<
code>ETag</
code> (エンティティタグ) 応答ヘッダフィールドを作成するときに使用する
ファイルの属性を設定します。 (<
code>ETag</
code> の値はネットワークの帯域を節約するための
キャッシュの管理で使われます。) Apache 1.3.22 以前では、<
code>ETag</
code> の値は
<
em>常に</
em>ファイルの inode, サイズ、最終修正時刻 (mtime) から作成
されていました。<
directive>FileETag</
directive> ディレクティブにより、これらのどれを使うかを
<
dt><
strong>INode</
strong></
dt>
<
dd>ファイルの inode 番号を計算に使います</
dd>
<
dt><
strong>MTime</
strong></
dt>
<
dd>ファイルの最終修正時刻を使います</
dd>
<
dt><
strong>Size</
strong></
dt>
<
dd>ファイルの中身のバイト数を使います</
dd>
<
dt><
strong>All</
strong></
dt>
これは <
example>FileETag INode MTime Size</
example> と等価です。</
dd>
<
dt><
strong>None</
strong></
dt>
<
dd>ドキュメントがファイルに基づいたものでも、<
code>ETag</
code> フィールドを
<
p><
code>INode</
code>, <
code>MTime</
code>, <
code>Size</
code> キーワードには
<
code>+</
code> や <
code>-</
code> を前に付けて
指定することもできます。この場合は、より広い範囲から継承された
デフォルトの設定に変更を加えるようになります。そのような接頭辞の
無いキーワードを指定すると、即座に継承した設定を無効にします。</
p>
<
code>FileETag INode MTime Size</
code> があり、
サブディレクトリの設定に <
code>FileETag -INode</
code> があるときは、
そのサブディレクトリの設定は (設定が上書きされなければサブディレクトリの
サブディレクトリにも継承されます) <
code>FileETag MTime Size</
code>
<
note type="warning"><
title>警告</
title>
WebDAV を使っていて、<
module>mod_dav_fs</
module> をストレージプロバイダとして
使っているような Directory や Location では、デフォルト値を変更しないでください。
<
module>mod_dav_fs</
module> では、条件付リクエストでの比較演算に
<
code>INode MTime Size</
code>
<
directive>FileETag</
directive> で <
code>ETag</
code> フォーマットを
変更してしまうと、条件付リクエストでうまく動作しなくなります。
<
directivesynopsis type="section">
<
description>マッチするファイル名に適用されるディレクティブを囲む</
description>
<
syntax><Files <
var>filename</
var>> ... </Files></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
p><
directive type="section">Files</
directive> ディレクティブは、
その中にあるディレクティブの適用範囲をファイル名で制限します。
type="section">Directory</
directive> ディレクティブや <
directive module="core" type="section">Location</
directive> ディレクティブと
これは、<
code></Files></
code> ディレクティブと対に
このセクション中のディレクティブは、ベース名 (ファイル名の最後の部分)
が指定されたファイル名にマッチするすべてのオブジェクトに適用されます。
<
directive type="section">Files</
directive> セクションは
<
directive type="section">Directory</
directive> セクションと
<
code>.htaccess</
code> が読み込まれた後、
<
directive type="section">Location</
directive> セクションよりは先に
<
directive type="section">Files</
directive> は、
<
directive type="section">Directory</
directive> セクション内に
ファイルシステムの一部にのみ限定して適用させることができます。</
p>
<
p><
var>filename</
var> 引数は、ファイル名かワイルドカード文字列
で、ワイルドカードでは <
code>?</
code> は一つの文字、<
code>*</
code> は任意の文字列にマッチします。
<
code>~</
code> という文字を付加することで<
glossary ref="regex">正規表現</
glossary>を使うこともできます。
<Files ~ "\.(gif|jpe?g|png)$">
<
p>とすることにより、一般的なインターネットの画像フォーマットにマッチします。
<
directive module="core" type="section">FilesMatch</
directive> を使う方が
<
p>ちなみに、<
directive module="core" type="section" >Directory</
directive> と <
directive module="core" type="section" >Location</
directive> セクションとは異なり、
<
directive type="section">Files</
directive>
は <
code>.htaccess</
code> ファイル内で利用することができます。
これにより、ユーザがファイル毎にアクセスの制御を行なうことができるように
<
seealso>リクエストを受けた際にこれらの異なるセクションが
<Directory>, <Location>, <Files> セクションの動作法</
a></
seealso>
<
directivesynopsis type="section">
<
description>正規表現にマッチするファイル名に適用される
<
syntax><FilesMatch <
var>regex</
var>> ... </FilesMatch></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
p><
directive type="section">FilesMatch</
directive> ディレクティブは、
<
directive module="core" type="section">Files</
directive>
ディレクティブ同様にその中にあるディレクティブの適用範囲をファイル名で制限します。ただし、
このディレクティブには<
glossary ref="regex">正規表現</
glossary>を指定します。
<FilesMatch "\.(gif|jpe?g|png)$">
<
p>は一般的なインターネットの画像形式にマッチします。</
p>
<
seealso>リクエストを受けた際にこれらの異なるセクションが
<Directory>, <Location>, <Files> セクションの動作法</
a></
seealso>
<
description>すべてのマッチするファイルが指定の MIME コンテントタイプで
<
syntax>ForceType <
var>MIME-type</
var>|None</
syntax>
<
contextlist><
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
<
compatibility>Apache 2.0 で core に移動</
compatibility>
<
p><
code>.htaccess</
code> や <
directive type="section" module="core" >Directory</
directive> セクション、
<
directive type="section" module="core">Location</
directive> セクション、
<
directive type="section" module="core">Files</
directive> セクションに
書かれた場合、このディレクティブはそこにあるすべてのファイルが
で指定されたコンテントタイプとして扱われるようにします。たとえば、
GIF ファイルばかりのディレクトリがあって、すべてのファイルを <
code>.gif</
code>
で終わらせたくはないときに、以下のものを使用します:</
p>
<
p><
directive module="core">DefaultType</
directive> と違って
このディレクティブはメディアタイプを決めることができるかもしれない
ファイルの拡張子も含め、すべての MIME タイプの関連付けを
<
p><
code>None</
code> という値を使うことで <
directive>ForceType</
directive> の
# force all files to be
image/
gif:<
br />
<Location /images><
br />
# but normal mime-type associations here:<
br />
<
name>HostnameLookups</
name>
<
description>クライアントの IP アドレスの DNS ルックアップを
<
syntax>HostnameLookups On|Off|Double</
syntax>
<
default>HostnameLookups Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context></
contextlist>
<
p>このディレクティブは、ホスト名をログ収集できるように
(さらに、
CGI/
SSI に <
code>REMOTE_HOST</
code> 変数として渡します)。
<
code>Double</
code>を指定した場合、2 重の逆引きを行ないます。
つまり、逆引きの後に、その結果に対して正引きを行ないます。正引きの
結果の IP アドレスの中にオリジナルのアドレスと一致するものがなければ
なりません。("tcpwrappers" の用語では <
code>PARANOID</
code> と呼ばれています。)</
p>
<
p><
module>mod_authz_host</
module> でホスト名によるアクセス
設定の如何によらず 2 重の逆引きが実行されます。
<
code>HostnameLookups Double</
code> を設定しない限り、
他の部分はこの 2 重逆引きの結果を使うことはできません。
例えば、<
code>HostnameLookups On</
code> と設定してある状態で、
ホスト名によるアクセス制限を行なったオブジェクトへの
リクエストを受けたとすると、2 重の逆引きが成功するか否かによらず、
<
code>REMOTE_HOST</
code> には通常の逆引き結果が渡されます。</
p>
ネットワークトラフィックを低減させるために、<
code>Off</
code> になっています。
DNS のルックアップには、かなりの時間が必要となる場合が多く、
負荷の高いサイトではこのディレクティブは <
code>Off</
code> にすべきです。
なお、<
var>/support</
var> ディレクトリに含まれ、デフォルトでは
インストールディレクトリの <
code>bin</
code> サブディレクトリに
インストールされる <
program>logresolve</
program> ユーティリティにより、
Apache の動作とは別に、ログに残されている IP アドレスからホスト名を
<
directivesynopsis type="section">
<
description>実行時、リクエストが条件を満たした場合にのみ適用される
ディレクティブを包含する</
description>
<
syntax><If <
var>expression</
var>> ... </If></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
p><
directive type="section">If</
directive> ディレクティブは
<If "$req{Host} = ''">
<
p>上記例は <
var>Host:</
var> ヘッダの存在しない
HTTP/
1.0 のリクエストに
<
seealso><
a href="/sections.html">どのように <Directory>, <Location>,
<Files> セクションが動作するか</
a> では、リクエストを受けたときに、
これらの異なるセクションがどのように組み合わさるかについて記載されています。
<
directive type="section">If</
directive> は
<
directive type="section">Files</
directive>
と同じ処理順と用法になっています。</
seealso>
<
directivesynopsis type="section">
<
description>起動時にテストが真であるときのみに処理されるディレクティブを
<
syntax><IfDefine [!]<
var>parameter-name</
var>> ...
</IfDefine></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
p><
code><IfDefine <
var>test</
var>>...</IfDefine></
code>
ディレクティブを条件付きで指定するために利用します。
<
directive type="section">IfDefine</
directive> セクションに
含まれるディレクティブは、<
var>test</
var>が
もし <
var>test</
var> が定義されていなければ、
開始と終了の指定の間のディレクティブは無視されます。</
p>
<
p><
directive type="section">IfDefine</
directive> セクションディレクティブに
<
li><
var>parameter-name</
var></
li>
<
li><
code>!</
code><
var>parameter-name</
var></
li>
<
p>前者の場合には、<
var>parameter-name</
var> と名付けられたパラメータが
定義されていれば開始と終了の間のディレクティブが処理されます。
後者の場合は逆で、<
em>parameter-name</
em> が指定されて<
strong>いない</
strong>
<
p><
var>parameter-name</
var> 引数は、サーバを起動する際に
<
program>httpd</
program> のコマンドラインに
<
code>-D<
var>parameter</
var></
code> という形で指定するか
あるいは <
directive module="core">Define</
directive>
ディレクティブで指定されると定義されます。 </
p>
<
p><
directive type="section">IfDefine</
directive> セクションは
入れ子にすることができ、複数のパラメータによるテストをするために使用できます。
httpd -DReverseProxy -DUseCache -DMemCache ...<
br />
<IfDefine ReverseProxy><
br />
<IfDefine UseCache><
br />
<IfDefine MemCache><
br />
<IfDefine !MemCache><
br />
<
directivesynopsis type="section">
<
description>モジュールの存在するかしないかに応じて処理される
<
syntax><IfModule [!]<
var>module-file</
var>|<
var>module-identifier</
var>> ...
</IfModule></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
compatibility>モジュール識別子はバージョン 2.1 以降で使用可能。</
compatibility>
<
p><
code><IfModule <
var>test</
var>>...</IfModule></
code>
セクションは、モジュールが存在するときに処理されるディレクティブを
<
directive type="section">IfModule</
directive> セクションに
含まれるディレクティブは、<
var>test</
var>
で指定するモジュールが組み込まれているときのみ処理されます。
もし <
var>test</
var> が組み込まれていなければ、開始と終了の間のディレクティブ
<
p><
directive type="section">IfModule</
directive> セクションディレクティブに
<
li><
var>module</
var></
li>
<
li>!<
var>module</
var></
li>
<
p>前者の場合は、<
var>module</
var> と名付けられたモジュールが
module="mod_so">LoadModule</
directive> を利用して
後者の場合は逆で、<
var>module</
var> が組み込まれて<
strong>いない</
strong>
<
p><
var>module</
var> 引数は、モジュール識別子か
例えば、<
code>rewrite_module</
code> は識別子で
モジュールが複数のソースファイルから構成されている場合は、文字列
<
code>STANDARD20_MODULE_STUFF</
code> があるファイルの名前を
<
p><
directive type="section">IfModule</
directive> セクションは
複数のモジュールのテストを行なうために使用できます。</
p>
<
note>特定のモジュールの存在に関わらず動作する
設定ファイルの原本が必要なときにのみこのセクションを使用してください。
<
directive type="section">IfModule</
directive> セクションの中に
<
description>サーバ設定ファイル中から他の設定ファイルを取り込む</
description>
<
syntax>Include <
var>file-path</
var>|<
var>directory-path</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context>
<
compatibility>ワイルドカードによるマッチは 2.0.41 以降で使用可能</
compatibility>
<
p>このディレクティブにより、サーバの設定ファイルから
他の設定ファイルをインクルードすることができます。</
p>
<
p>複数のファイルをアルファベット順に一度に読み込むために、
シェル形式 (<
code>fnmatch</
code>) のワイルドカード文字を使うことができます。
さらに、<
directive>Include</
directive> にディレクトリを指定した場合は、
ディレクトリとそのサブディレクトリ内の全てのファイルを
アルファベット順に読み込んで、設定ファイルとして処理します。
しかし、ディレクトリ全体を読み込むのはお勧めできません。
ふとしたことから <
code>httpd</
code> が読み込みに失敗するような
一時ファイルをディレクトリに残してしまうようなことがよくあるからです。</
p>
<
directive module="core">ServerRoot</
directive> ディレクトリからの
<
p><
directive module="core">ServerRoot</
directive> からの相対パスの場合は:</
p>
<
seealso><
program>apachectl</
program></
seealso>
<
description>HTTP の持続的な接続を有効にする</
description>
<
syntax>KeepAlive On|Off</
syntax>
<
default>KeepAlive On</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
複数のリクエストが同じ TCP の接続で送られる、長時間持続する
HTTP セッションを提供します。たくさんの画像が
含まれる HTML ドキュメントでは場合によっては遅延時間が 50% 短縮される結果も
でています。Keep-Alive 接続を有効にするには
<
code>KeepAlive On</
code> と設定します。</
p>
クライアントより特に要求があった場合のみ Keep-Alive 接続となります。
(訳注: 要求に対して応答を返す前に) わかる場合のみ Keep-Alive
サーバが生成したディレクトリのリストのような動的コンテンツを
HTTP/
1.0 クライアントに送る場合には Keep-Alive 接続を使えないことを意味します。
特に指定されない限りはデフォルトとして持続的な接続が行なわれます。
クライアントが要求すれば、コンテンツの容量を判別できないものを
持続的な接続を通して送るために、チャンクエンコーディングが用いられます。</
p>
<
p>クライアントが Keep-Alive コネクションを使用している場合、
そのコネクションを通してどれだけたくさんのリクエストが処理されても、
それは「リクエスト」1 つとして、MaxRequestsPerChild ディレクティブでは
<
seealso><
directive module="core">MaxKeepAliveRequests</
directive></
seealso>
<
name>KeepAliveTimeout</
name>
<
description>持続的な接続で次のリクエストが来るまでサーバが待つ時間</
description>
<
syntax>KeepAliveTimeout <
var>seconds</
var></
syntax>
<
default>KeepAliveTimeout 5</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p>接続を閉じる前に、Apache が次のリクエストを何秒待つかを指定します。
module="core">Timeout</
directive> ディレクティブによって
<
p><
directive>KeepAliveTimeout</
directive> を大きな値に設定すると、
負荷の高いサーバにおいてはパフォーマンスの問題を引き起こす場合があります。
タイムアウトが長ければ長いほど、より多くのサーバプロセスが
活性でないクライアントからの接続の終了を待ち続けることになります。</
p>
<
p>名前ベースのバーチャルホストコンテキストでは、
<
directive module="core">NameVirtualHost</
directive>
のセットの中で最初に定義されたバーチャルホストの値
<
directivesynopsis type="section">
<
description>囲いの中にあるアクセス制御の適用を特定の HTTP メソッドのみに
<
syntax><Limit <
var>method</
var> [<
var>method</
var>] ... > ...
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
p>アクセス制御は、通常<
strong>全ての</
strong>アクセスメソッドに対して
<
strong>そうしたことから、大部分の場合にはアクセス制御に関わるディレクティブを
<
directive type="section">Limit</
directive> セクション内に
書くべきではありません。 </
strong></
p>
<
p><
directive type="section">Limit</
directive> ディレクティブの
指定された HTTP メソッドに限定するためです。
それ以外のメソッドは、<
directive type="section">Limit</
directive> で囲われたアクセス制御の
<
strong>影響を受けません</
strong>。
以下の例は、<
code>POST</
code>, <
code>PUT</
code>, <
code>DELETE</
code> のメソッドに対してのみアクセスの制御を行ない、
それ以外のメソッドについては制限しません:</
p>
<Limit POST PUT DELETE><
br />
<
p>メソッド名には以下の中から一つ以上を列挙することができます:
<
code>POST</
code>, <
code>PUT</
code>, <
code>DELETE</
code>,
<
code>CONNECT</
code>, <
code>OPTIONS</
code>,
<
code>PATCH</
code>, <
code>PROPFIND</
code>, <
code>PROPPATCH</
code>,
<
code>MKCOL</
code>, <
code>COPY</
code>, <
code>MOVE</
code>,
<
code>LOCK</
code>, <
code>UNLOCK</
code>. <
strong>メソッド名は
大文字小文字を区別します。</
strong> <
code>GET</
code> を指定した場合には
<
code>HEAD</
code> リクエストにも制限がかかります。<
code>TRACE</
code>
(<
directive type="section" module="core">TraceEnable</
directive> 参照)。</
p>
<
note type="warning">アクセス制御が目的の場合は
<
directive type="section" module="core">Limit</
directive>
セクションの代わりに <
directive type="section" module="core">LimitExcept</
directive> セクションを使用した方が良いでしょう。
<
directive type="section" module="core">LimitExcept</
directive>
セクションでは不特定のメソッドに対しても防御できるからです。</
note>
<
directivesynopsis type="section">
<
description>指定されたもの以外の HTTP メソッドにアクセス制御を
<
syntax><LimitExcept <
var>method</
var> [<
var>method</
var>] ... > ...
</LimitExcept></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
p><
directive type="section">LimitExcept</
directive> と
<
code></LimitExcept></
code> は、引数に
HTTP のアクセスメソッドに適用するためのアクセス制御
つまり、<
directive type="section" module="core" >Limit</
directive> セクションの反対の動作をし、
標準のメソッドと標準外や未認識のメソッドの場合の両方を設定できます。
<
directive type="section" module="core">Limit</
directive> のドキュメントも
<LimitExcept POST GET><
br />
<
name>LimitInternalRecursion</
name>
<
description>内部リダイレクトと入れ子になったサブリクエストの最大数を決定する</
description>
<
syntax>LimitInternalRecursion <
var>number</
var> [<
var>number</
var>]</
syntax>
<
default>LimitInternalRecursion 10</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
compatibility>Apache 2.0.47 以降で使用可能</
compatibility>
<
p>内部リダイレクトは例えば <
directive>Action</
directive> ディレクティブを
使っているときに起こります。<
directive>Action</
directive> ディレクティブは
元々のリクエストを CGI スクリプトに内部リダイレクトを行ないます。
サブリクエストはいくつかの URI に対して、リクエストされたときに
何が起こるかを調べるための Apache の機構です。例えば、<
module>mod_dir</
module>
は <
directive module="mod_dir">DirectoryIndex</
directive> ディレクティブ
がリストするファイルを調べるためにサブリクエストを使います。</
p>
<
p><
directive>LimitInternalRecursion</
directive> は内部リダイレクトや
サブリクエストが無限ループに陥ったときのサーバクラッシュを防ぎます。
普通、そのようなループは設定に失敗したときに発生します。</
p>
<
p>このディレクティブは、リクエスト毎に評価される、二つの違う限界値を
設定します。最初の <
var>number</
var> は、起こり得る
内部リクエストの最大値を設定します。二つめの <
var>number</
var> は
サブリクエストが入れ子にできる深さを設定します。<
var>number</
var> を
一つだけ指定したときは、両方の限界値にその値が設定されます。</
p>
<
example><
title>例</
title>
<
name>LimitRequestBody</
name>
<
description>クライアントから送られる HTTP リクエストのボディの
<
syntax>LimitRequestBody <
var>bytes</
var></
syntax>
<
default>LimitRequestBody 0</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
p>このディレクティブは、リクエストボディに許されるバイト数、<
var>bytes</
var>
を 0 (無制限を意味します) から 2147483647 (2GB) までの数値で指定します。</
p>
<
p><
directive>LimitRequestBody</
directive> ディレクティブは、
(サーバ全体、ディレクトリ、ファイル、ロケーション) 内で
許容する HTTP リクエストメッセージボディのサイズに制限をかけることができます。
クライアントのリクエストがその制限値を越えていれば、
普通のリクエストメッセージボディのサイズは、リソースの種類や
<
code>PUT</
code> メソッドの実装は、このディレクティブの値として
少なくともあるリソースに対してサーバが受け付けようとする
管理者にクライアントからの異常なリクエストを制御できるようにし、
何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。</
p>
<
p>ある場所へのファイルアップロードを許可する場合に、
アップロードできるファイルのサイズを 100K に制限したければ、
<
name>LimitRequestFields</
name>
<
description>クライアントからの HTTP リクエストのヘッダフィールドの数を
<
syntax>LimitRequestFields <
var>number</
var></
syntax>
<
default>LimitRequestFields 100</
default>
<
contextlist><
context>server config</
context></
contextlist>
<
p><
var>number</
var> には、0 (無制限を意味します) から 32767
デフォルト値は、定数 <
code>DEFAULT_LIMIT_REQUEST_FIELDS</
code>
によりコンパイル時に定義されます (配布時には 100 と指定されています)。</
p>
<
p><
directive>LimitRequestBody</
directive> ディレクティブは、
サーバ管理者が HTTP リクエスト中において許可するリクエストヘッダフィールド数を
サーバはこの値には通常のクライアントからのリクエストに含まれるであろう
クライアントにより使われた要求ヘッダーフィールドの数が
詳細なコンテントネゴシエーションをするためのブラウザの設定までにも
オプションの HTTP 拡張はリクエストヘッダフィールドを使って表される場合が
管理者にクライアントからの異常なリクエストを制御できるようにし、
何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。
リクエストのフィールドが多過ぎることを意味するエラー応答が
普通のクライアントに返されるような時はこの値を増やしてください。</
p>
<
name>LimitRequestFieldSize</
name>
<
description>クライアントからの HTTP リクエストのヘッダの
<
syntax>LimitRequestFieldSize <
var>bytes</
var></
syntax>
<
default>LimitRequestFieldSize 8190</
default>
<
contextlist><
context>server config</
context></
contextlist>
<
p>このディレクティブは、HTTP リクエストヘッダ一つで受付ける
バイト数 <
var>bytes</
var> を指定します。</
p>
<
p><
directive>LimitRequestFieldSize</
directive> ディレクティブは、
HTTP リクエストヘッダで許容されるサイズを増減させることができます。
一般的なクライアントからリクエストが送られた際に、そのリクエストに
一般的なリクエストヘッダのサイズといっても、その大きさは個々の
詳細なコンテントネゴシエーションをサポートするかどうかの、
SPNEGO 認証ヘッダでは 12392 バイトにまで及ぶことすらあります。</
p>
管理者にクライアントからの異常なリクエストを制御できるようにし、
何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。</
p>
LimitRequestFieldSize 4094
<
note>通常はデフォルトから変更する必要はありません。</
note>
<
name>LimitRequestLine</
name>
<
description>クライアントからの HTTP リクエスト行のサイズを制限する</
description>
<
syntax>LimitRequestLine <
var>bytes</
var></
syntax>
<
default>LimitRequestLine 8190</
default>
<
contextlist><
context>server config</
context></
contextlist>
<
p>このディレクティブは、HTTP リクエスト行内で許容されるバイト数
<
var>bytes</
var> を指定します。</
p>
<
p><
directive>LimitRequestLine</
directive> ディレクティブにより、
クライアントからの HTTP リクエスト行の許容サイズを増減できます。
リクエスト行は、HTTPメソッド、URI、プロトコルバージョンから成っており、
<
directive>LimitRequestLine</
directive> はサーバへのリクエストに対して
許容するリクエスト URI の長さを制限することになります。
サーバは、<
code>GET</
code> リクエストのクエリ部分も含めて、リソースの名前が入るに足る
管理者にクライアントからの異常なリクエストを制御できるようにし、
何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。</
p>
<
note>通常はデフォルトから変更する必要はありません。</
note>
<
name>LimitXMLRequestBody</
name>
<
description>XML 形式のリクエストのボディのサイズを制限する</
description>
<
syntax>LimitXMLRequestBody <
var>bytes</
var></
syntax>
<
default>LimitXMLRequestBody 1000000</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context></
contextlist>
<
p>XML 形式のリクエストのボディの最大値を (バイト単位で) 制限します。
値に <
code>0</
code> を指定するとチェックを無効にします。</
p>
<
directivesynopsis type="section">
<
description>囲んだディレクティブをマッチする URL のみに適用</
description>
<
var>URL-path</
var>|<
var>URL</
var>> ... </Location></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive type="section">Location</
directive> ディレクティブは、
URL により中に書かれたディレクティブの適用範囲を制限します。
<
directive type="section" module="core">Directory</
directive>
<
code></Location></
code> ディレクティブで終了する
<
directive type="section">Location</
directive> セクションは、
<
directive type="section" module="core">Directory</
directive> セクションと
<
code>.htaccess</
code> の読み込みの後、
<
directive type="section" module="core">Files</
directive> セクションを
適用した後に、設定ファイルに現れた順に処理されます。</
p>
<
p><
directive type="section">Location</
directive> セクションは
完全にファイルシステムと関連せずに動作します。このことから導かれる
結果にはいくつか注意する点があります。最も重要なものは、
ファイルシステムの位置へのアクセス制御に <
directive type="section">Location</
directive> ディレクティブを使うべきではない
ということです。複数の URL がファイルシステムの同じ位置にマップされる
可能がありますので、そのようなアクセス制御は回避されてしまう可能性が
<
note><
title>いつ <
directive type="section">Location</
directive> を使うか</
title>
<
p><
directive type="section">Location</
directive> ディレクティブは
ファイルシステム外のコンテンツにディレクティブを適用するときに
使用してください。ファイルシステムに存在するコンテンツに対しては、
type="section" module="core">Directory</
directive> と <
directive type="section" module="core">Files</
directive> を使ってください。
例外は、<
code><Location /></
code> で、これはサーバ全体に対して
<
p>全ての (プロキシ以外の) リクエストに対し、
URL は <
code>/path/</
code> という、
という接頭辞を含む形でマッチし、接頭辞を含めて指定する必要があります。</
p>
<
p>URL にはワイルドカードを利用することができます。
<
code>?</
code> は任意の一文字、<
code>*</
code> は任意の文字列にマッチします。
どちらのワイルドカードも URL パス中の / にはマッチしません。</
p>
<
p><
code>~</
code> という文字を追加することで、<
glossary ref="regex">正規表現</
glossary>を
<Location ~ "/(extra|special)/data">
<
directive type="section" module="core" >LocationMatch</
directive> ディレクティブは
<
directive type="section">Location</
directive> の正規表現
<
p><
directive type="section">Location</
directive> 機能は、<
directive module="core">SetHandler</
directive> ディレクティブと
例えば、<
code>
example.com</
code> のブラウザからのみステータスの参照を有効にしたければ、
<Location /status><
br />
SetHandler server-status<
br />
<
note><
title>/ (スラッシュ) に関する注</
title>
<
p>スラッシュ文字は、URL 内に現れる場所に応じて変化する
ファイルシステムにおいて利用する場合には複数のスラッシュでも一つの
(<
em>すなわち</
em>、<
code>/home///foo</
code> は
URL においては必ずしもそうなるわけではありません。
<
directive type="section" module="core">LocationMatch</
directive>
<
directive type="section">Location</
directive> ディレクティブで、
複数のスラッシュにマッチさせたいときには、明示的に記述する
<
p>例えば、<
code><LocationMatch ^/abc></
code> は、
<
code>/abc</
code> というリクエスト URL にマッチしますが、
<
code>//abc</
code> というリクエスト URL にはマッチしません。
(正規表現でない) <
directive type="section">Location</
directive>
proxy リクエストに対して利用する際には同様の振る舞いをしますが、
(正規表現でない) <
directive type="section">Location</
directive> を proxy
一つのスラッシュで複数のスラッシュにマッチします。
例えば、<
code><Location /
abc/
def></
code> と指定し、
<
code>/abc//def</
code> というリクエストがあれば、
<
seealso>リクエストを受けた際にこれらの異なるセクションが
<Directory>, <Location>, <Files> セクションの動作法</
a></
seealso>
<
directivesynopsis type="section">
<
name>LocationMatch</
name>
<
description>囲んだディレクティブを正規表現にマッチする URL のみに
<
syntax><LocationMatch
<
var>regex</
var>> ... </LocationMatch></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive type="section">LocationMatch</
directive> ディレクティブは、
<
directive type="section" module="core">Location</
directive> と同じ様に
URL により中に書かれたディレクティブの適用範囲を制限します。
但し、引数は普通の文字列ではなく、<
glossary ref="regex">正規表現</
glossary>となります。
<LocationMatch "/(extra|special)/data">
という文字列が含まれている場合にマッチします。</
p>
<
seealso>リクエストを受けた際にこれらの異なるセクションが
<Directory>, <Location>, <Files> セクションの動作法</
a></
seealso>
<
description>ErrorLog の冗長性を制御する</
description>
<
syntax>LogLevel <
var>level</
var></
syntax>
<
default>LogLevel warn</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive>LogLevel</
directive> は、エラーログ (<
directive module="core" >ErrorLog</
directive> ディレクティブを
見てください) へ記録するメッセージの冗長性を調整します。
以下の <
var>level</
var> を指定でき、順に重要度が下がっていきます。</
p>
<
th><
strong>レベル</
strong> </
th>
<
th><
strong>説明</
strong> </
th>
<
th><
strong>例</
strong> </
th>
<
td><
code>emerg</
code> </
td>
<
td>緊急 - システムが利用できない</
td>
<
td>Child cannot open lock file. Exiting
(子プロセスがロックファイルを開けないため終了した)</
td>
<
td><
code>alert</
code> </
td>
<
td>getpwuid: couldn't determine user name from uid
(getpwuid: UID からユーザ名を特定できなかった)</
td>
<
td><
code>crit</
code> </
td>
<
td>socket: Failed to get a socket, exiting child
(socket: ソケットが得られないため、子プロセスを終了させた)</
td>
<
td><
code>error</
code> </
td>
<
td>Premature end of script headers
(スクリプトのヘッダが足りないままで終わった)</
td>
<
td><
code>warn</
code> </
td>
<
td>child process 1234 did not exit, sending another SIGHUP
(子プロセス 1234 が終了しなかった。もう一度 SIGHUP を送る)</
td>
<
td><
code>notice</
code> </
td>
<
td>httpd: caught SIGBUS, attempting to dump core in ...
(httpd: SIGBUS シグナルを受け、... へコアダンプをした)</
td>
<
td><
code>info</
code> </
td>
<
td>"Server seems busy, (you may need to increase
<
td><
code>debug</
code> </
td>
<
td>"Opening config file ..." (設定ファイルを開いている...)</
td>
<
p>特定のレベルが指定された場合、それより高いレベルの全てのメッセージが
<
em>例えば</
em>、<
code>LogLevel info</
code> に指定すると、
<
code>notice</
code> と <
code>warn</
code> も報告されます。</
p>
<
p>なお <
code>crit</
code> 以上のレベルを指定することが推奨されます。</
p>
<
p>ファイルにログを出力する場合、<
code>notice</
code>
レベルのメッセージは抑制されず、すべてログに出力されます。
しかし <
code>syslog</
code> を使用している場合は、
<
name>MaxKeepAliveRequests</
name>
<
description>持続的な接続上で許可されるリクエストの数</
description>
<
syntax>MaxKeepAliveRequests <
var>number</
var></
syntax>
<
default>MaxKeepAliveRequests 100</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive>MaxKeepAliveRequests</
directive> ディレクティブは、
<
directive module="core">KeepAlive</
directive> が有効な場合に、
一回の接続で受け付け可能なリクエストの数を制限します。
<
code>0</
code> に設定していれば、受け付けるリクエストは無制限になります。
この設定は、サーバ性能を向上させるために、大きな数値を指定することを勧めます。
<
name>NameVirtualHost</
name>
<
description>名前ベースのバーチャルホストのための IP アドレスを指定</
description>
<
syntax>NameVirtualHost <
var>addr</
var>[:<
var>port</
var>]</
syntax>
<
contextlist><
context>server config</
context></
contextlist>
<
p><
directive>NameVirtualHost</
directive> ディレクティブは、
<
a href="/vhosts/">名前ベースのバーチャルホスト</
a>の設定を行ないたい場合に
<
p><
var>addr</
var> にはホスト名を指定できますが、
NameVirtualHost 111.22.33.44
<
p><
directive>NameVirtualHost</
directive> ディレクティブは、
利用してリクエストを受け付ける IP アドレスを指定します。
これは、普通は名前ベースのバーチャルホストアドレスです。
ただし、ファイアーウォールや他のプロキシがリクエストを受け付け、
違う IP アドレスのサーバにフォワードするという場合は、
リクエストを提供したいマシン上の物理インターフェースの
複数のアドレスで複数の名前ベースのバーチャルホストを指定する場合は
各アドレスに対してディレクティブを書いてください。</
p>
<
p>「主サーバ」や、どの <
code>_default_</
code> サーバも、
<
directive>NameVirtualHost</
directive> で指定した IP アドレスへのリクエスト
を処理することは<
strong>ありません</
strong> (なぜか
<
directive>NameVirtualHost</
directive> を
指定したけどそのアドレスに <
directive>VirtualHost</
directive> を定義しなかった場合を除く)。</
p>
<
p>名前ベースのバーチャルホストにポート番号を指定することも可能です。
NameVirtualHost 111.22.33.44:8080
<
p>IPV6 のアドレスは次の例のように角括弧で囲む必要があります:</
p>
NameVirtualHost [2001:db8::a00:20ff:fea7:ccea]:8080
<
p>すべてのインタフェースへのリクエストを受け取るようにするためには、
引数として <
code>*</
code> を使います。</
p>
<
note><
title><
directive type="section">VirtualHost</
directive> ディレクティブの引数</
title>
<
p><
directive type="section">VirtualHost</
directive> ディレクティブの引数は <
directive >NameVirtualHost</
directive> ディレクティブの引数に正確に
合っている必要があることに注意してください。</
p>
NameVirtualHost 1.2.3.4<
br />
<VirtualHost 1.2.3.4><
br />
</VirtualHost><
br />
<
seealso><
a href="/vhosts/">バーチャルホスト説明書
<
description>ディレクトリに対して使用可能な機能を設定する</
description>
[+|-]<
var>option</
var> [[+|-]<
var>option</
var>] ...</
syntax>
<
default>Options All</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>Options</
override>
<
p><
directive>Options</
directive> ディレクティブは、特定のディレクトリに対して
<
p><
var>option</
var> を <
code>None</
code>に指定すると、
また、以下の示す 1 個以上のものを指定できます。</
p>
<
dt><
code>All</
code></
dt>
<
dd><
code>MultiViews</
code> を除いた全ての機能が有効となります。
<
dt><
code>ExecCGI</
code></
dt>
<
module>mod_cgi</
module> による CGI スクリプトの実行を許可します。</
dd>
<
dt><
code>FollowSymLinks</
code></
dt>
サーバが、このディレクトリ内でシンボリックリンクをたどれるようにします。
<
note><
p>サーバがシンボリックリンクをたどる場合でも、
<
directive type="section" module="core">Directory</
directive> セクションに
パス名は<
em>変更されません</
em>。</
p>
<
p><
directive type="section" module="core">Location</
directive> 内に
このオプションを指定しても<
strong>無視される</
strong>ことに
<
p>このオプションを省略したからといってセキュリティの強化にはなりません。
なぜなら symlink の検査はレースコンディションを引き起こす可能性があり、
<
dt><
code>Includes</
code></
dt>
<
module>mod_include</
module> が提供する SSI を有効にします。</
dd>
<
dt><
code>IncludesNOEXEC</
code></
dt>
SSI は有効になりますが、<
code>#exec</
code> コマンド と <
code>#exec CGI</
code> は無効になります。
ただし、<
code>#include virtual</
code> により、<
directive module="mod_alias">ScriptAlias</
directive> されたディレクトリで
<
dt><
code>Indexes</
code></
dt>
もし、URL がディレクトリにマップするリクエストであって、
且つ <
directive module="mod_dir">DirectoryIndex</
directive> で指定したファイル (例えば、<
code>
index.html</
code>) が
ディレクトリ内に無ければ、<
module>mod_autoindex</
module> が
ディレクトリ内の一覧を整形して返します。</
dd>
<
dt><
code>MultiViews</
code></
dt>
<
module>mod_negotiation</
module> による
された "MultiViews" を許可します。</
dd>
<
dt><
code>SymLinksIfOwnerMatch</
code></
dt>
シンボリックリンクの所有ユーザ ID と同じ場合にのみシンボリックリンクを
<
note><
title>注</
title> <
p><
directive type="section" module="core" >Location</
directive> 内にこのオプションを
<
p>このオプションはセキュリティの強化にはなりません。
なぜなら symlink の検査はレースコンディションを引き起こす可能性があり、
<
p>通常、ディレクトリに対して複数の <
directive>Options</
directive> が
最も近いもの一つのみが適用され、他のものは無視されます。
複数の指定がマージされるわけではありません。(<
a しかし、すべての <
directive>Options</
directive> ディレクティブが <
code>+</
code> や <
code>-</
code> 付きで
<
code>+</
code> を頭につければ現在の設定に加えられ、
<
code>-</
code> を付ければ現在の設定から削除されます。</
p>
<
note type="warning"><
title>警告</
title>
<
p><
directive>Options</
directive> で <
code>+</
code> や
<
code>-</
code> のついたものを、つけないものと組み合わせて
指定する構文は正しい構文ではありませんので、期待する結果に
<
p>例えば、<
code>+</
code> や <
code>-</
code> を利用しない場合は:</
p>
Options Indexes FollowSymLinks<
br />
<
code>Includes</
code> だけが適用されます。
しかし、2 番目の <
directive>Options</
directive> で <
code>+</
code> や <
code>-</
code> を利用してみると:</
p>
Options Indexes FollowSymLinks<
br />
Options +Includes -Indexes<
br />
<
p><
code>/
web/
docs/
spec</
code> というディレクトリには、 <
code>FollowSymLinks</
code> と
<
code>Includes</
code> が適用されます。</
p>
<
p><
code>-IncludesNOEXEC</
code> もしくは
<
code>-Includes</
code> を指定すると、
前の設定がどのようになっていようとも SSI は無効となります。</
p>
<
p>どのような設定もされていなければ、デフォルトでは <
code>All</
code> に
<
description>Apache の子プロセスから起動されたプロセスの CPU 消費量を
<
syntax>RLimitCPU <
var>seconds</
var>|max [<
var>seconds</
var>|max]</
syntax>
<
default>未設定。オペレーティングシステムのデフォルトを使用</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context></
contextlist>
最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、
2 番目のパラメータは最大のリソースリミットを設定します。
パラメータには数字か、オペレーティングシステムの最大となる
<
code>max</
code> のどちらかを指定することができます。
<
code>root</
code> で実行するか起動されなければいけません。</
p>
<
p>ちなみに、この設定は Apache の子プロセス自体ではなく、
リクエストを受け付けた Apache の子プロセスから fork されたプロセスに
これには CGI や SSI から実行されたコマンドが含まれますが、Apache の
親プロセスから fork されたログのパイププロセスなどには適用されません。</
p>
<
p>CPU リソースのリミットはプロセスあたりの秒数で表わされます。</
p>
<
seealso><
directive module="core">RLimitMEM</
directive></
seealso>
<
seealso><
directive module="core">RLimitNPROC</
directive></
seealso>
<
description>Apache の子プロセスから起動されたプロセスのメモリ消費量を
<
syntax>RLimitMEM <
var>bytes</
var>|max [<
var>bytes</
var>|max]</
syntax>
<
default>未設定。オペレーティングシステムのデフォルトを使用</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context></
contextlist>
最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、
2 番目のパラメータは最大のリソースリミットを設定します。
パラメータには数字か、オペレーティングシステムの最大となる
<
code>max</
code> のどちらかを指定することができます。
<
code>root</
code> で実行するか起動されなければいけません。</
p>
<
p>この設定は Apache の子プロセス自体ではなく、
リクエストを受け付けた Apache の子プロセスから fork されたプロセスに
これには CGI や SSI から実行されたコマンドが含まれますが、Apache の
親プロセスから fork されたログのパイププロセスなどには適用されません。</
p>
<
p>メモリリソースのリミットはプロセスあたりのバイト数で表わされます。</
p>
<
seealso><
directive module="core">RLimitCPU</
directive></
seealso>
<
seealso><
directive module="core">RLimitNPROC</
directive></
seealso>
<
description>Apache の子プロセスから起動されたプロセスが起動するプロセスの
<
syntax>RLimitNPROC <
var>number</
var>|max [<
var>number</
var>|max]</
syntax>
<
default>未設定。オペレーティングシステムのデフォルトを使用</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context></
contextlist>
最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、
2 番目のパラメータは最大のリソースリミットを設定します。
パラメータには数字か、オペレーティングシステムの最大となる
<
code>max</
code> のどちらかを指定することができます。
<
code>root</
code> で実行するか起動されなければいけません。</
p>
<
p>この設定は Apache の子プロセス自体ではなく、
リクエストを受け付けた Apache の子プロセスから fork されたプロセスに
これには CGI や SSI から実行されたコマンドが含まれますが、Apache の
親プロセスから fork されたログのパイププロセスなどには適用されません。</
p>
<
p>プロセスの制限は、ユーザあたりのプロセス数で制御されます。</
p>
<
p> CGI プロセスがウェブサーバのユーザ ID 以外で実行されるので
このディレクティブは、サーバ自身が生成できるプロセスの数を制限することになります。
そのような状況になっているかどうかは、<
code>error_log</
code> 中の
<
strong><
code>cannot fork</
code></
strong> というメッセージにより
<
seealso><
directive module="core">RLimitMEM</
directive></
seealso>
<
seealso><
directive module="core">RLimitCPU</
directive></
seealso>
<
name>ScriptInterpreterSource</
name>
<
description>CGI スクリプトのインタープリタの位置を調べるための手法</
description>
<
syntax>ScriptInterpreterSource Registry|Registry-Strict|Script</
syntax>
<
default>ScriptInterpreterSource Script</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context></
contextlist>
<
override>FileInfo</
override>
オプション <
code>Registry-Strict</
code> は Apache 2.0 以降で使用可能</
compatibility>
<
p>このディレクティブは、Apache で CGI スクリプトを
どのように探し出すかについて制御するために使用します。
デフォルトの設定は <
code>Script</
code> です。これはスクリプトの
shebang 行 (最初の行で <
code>#!</
code> から始まるもの)
に指されているインタープリタを使用します。Win32 ではその行は
<
p>もしくは、<
code>perl</
code> が <
code>PATH</
code> にある場合は単に:</
p>
<
p><
code>ScriptInterpreterSource Registry</
code> を指定すると、
スクリプトファイルの拡張子 (例えば、<
code>.pl</
code>) を
キーとして、Windows のレジストリツリー <
code>HKEY_CLASSES_ROOT</
code>
<
code>Shell\ExecCGI\Command</
code> か、それが存在しない場合は
<
code>Shell\Open\Command</
code> がスクリプトファイルを開くために
使われます。レジストリキーが見つからないときは、Apache は <
code>Script</
code>
オプションが指定されたときの動作に戻ります。</
p>
<
note type="warning"><
title>セキュリティ</
title>
<
p><
code>ScriptInterpreterSource Registry</
code> を <
directive module="mod_alias">ScriptAlias</
directive> されたディレクトリで使うときは
注意してください。Apache はそのディレクトリ中の<
em>すべての</
em>ファイルを
実行しようとします。<
code>Registry</
code> という設定は通常は実行されない
ファイルに対して望ましくないプログラムの実行が発生する可能性があります。
<
code>.htm</
code> ファイルのデフォルトの「開く」コマンドは
Microsoft Internet Explorer を実行しますので、スクリプトに指定された
ディレクトリにある <
code>.htm</
code> ファイルへのリクエストはサーバの
バックグラウンドでブラウザを実行することになります。これは、一分内くらいで
システムをクラッシュさるための良い方法です。</
p>
<
p>Apache 2.0 から導入されたオプション <
code>Registry-Strict</
code> は
<
code>Registry</
code> と同じことを行ないますが、サブキー
<
code>Shell\ExecCGI\Command</
code> のみを使います。
<
code>ExecCGI</
code> キーは普通に使われるキーではありません。Windows
レジストリに手動で設定する必要がありますので、システムでの偶発的なプログラムの
<
description>サーバがクライアントに送るエラーメッセージに含める電子メールの
<
syntax>ServerAdmin <
var>email-address</
var>|<
var>URL</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive>ServerAdmin</
directive> は、クライアントに返すさまざまな
問合せアドレスを設定します。与えられた引数を <
code>httpd</
code> が
URL と認識しない場合は、<
var>email-address</
var> だと解釈して、
ハイパーリンクのターゲットに <
code>mailto:</
code> を付けます。
実際には、ここには電子メールアドレスを使うことが推奨されています。
多くの CGI スクリプトはそうなっていることを仮定しています。
URL を使う場合は、あなたの管理下にある別サーバを指すようにしてください。
そうでないと、エラーが起こったときに連絡をすることができなくなって
<
p>その際、これのために専用のアドレスを設定するのが良いでしょう。
ServerAdmin www-admin@foo.example.com
<
p>といったようにします。ユーザはいつもサーバに関する話であるということを
<
description>リクエストを名前ベースのバーチャルホストにマッチさせているときに
使用されるホストの別名</
description>
<
syntax>ServerAlias <
var>hostname</
var> [<
var>hostname</
var>] ...</
syntax>
<
contextlist><
context>virtual host</
context></
contextlist>
<
p><
directive>ServerAlias</
directive> ディレクティブは、<
a 適切であれば、<
directive>ServerAlias</
directive> ディレクティブでは
<VirtualHost *><
br />
<
seealso><
a href="/vhosts/">Apache バーチャルホスト説明書</
a></
seealso>
<
description>サーバが自分自身を示すときに使うホスト名とポート</
description>
<
syntax>ServerName [<
var>scheme</
var>://]<
var>fully-qualified-domain-name</
var>[:<
var>port</
var>]</
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
compatibility>このディレクティブはバージョン 2.0 ではバージョン 1.3 の
<
directive>Port</
directive> ディレクティブの機能も含みます。</
compatibility>
<
p><
directive>ServerName</
directive> ディレクティブは、
サーバが自分自身を示すスキーム名、ホスト名とポート番号を設定します。
これは、リダイレクトする URL を生成する際に利用されます。
ウェブサーバが後者として認識されて欲しいときは、以下のようにディレクティブを
<
p><
directive>ServerName</
directive> が指定されていないときは、
サーバは IP アドレスから逆引きを行なうことでホスト名を知ろうとします。
<
directive>ServerName</
directive> にポートが指定されていないときは、
ポートを使います。最高の信頼性と確実性をもたらすためには、
<
directive>ServerName</
directive> を使ってホスト名とポートを明示的に
を利用している場合、<
directive type="section" module="core" >VirtualHost</
directive> セクション内の
<
directive>ServerName</
directive> はこのバーチャルホストにマッチするために
何がリクエストの Host: ヘッダに現れる必要があるのかを指定します。</
p>
<
p>SSL を処理するデバイス、例えばリバースプロクシやロードバランサや
SSL 処理軽減アプライアンスの裏側でサーバが稼動する場合もあるでしょう。
そういった場合では、クライアントが接続するときに使う
<
code>https://</
code> スキームとポート番号を <
directive>ServerName</
directive>
ディレクティブで指定して、自己参照 URL が正しく生成できるようにします。</
p>
<
p>自己参照 URL (例えば <
module>mod_dir</
module> モジュールによるものなど)
が指定されたポートを使うか、クライアントのリクエストのポート番号を使うかを
決定する設定は <
directive module="core">UseCanonicalName</
directive>
module="core">UseCanonicalPhysicalPort</
directive>
<
seealso><
a href="/vhosts/">Apache バーチャルホスト説明書</
a></
seealso>
<
seealso><
directive module="core">UseCanonicalName</
directive></
seealso>
<
seealso><
directive module="core">UseCanonicalPhysicalPort</
directive></
seealso>
<
seealso><
directive module="core">NameVirtualHost</
directive></
seealso>
<
seealso><
directive module="core">ServerAlias</
directive></
seealso>
<
description>非互換のブラウザが名前ベースのバーチャルホストにアクセスしたときの
ための互換用 URL パス名</
description>
<
syntax>ServerPath <
var>URL-path</
var></
syntax>
<
contextlist><
context>virtual host</
context></
contextlist>
<
p><
directive>ServerPath</
directive> ディレクティブは、<
a href="/vhosts/">ネームベースのバーチャルホスト</
a>において利用する
<
seealso><
a href="/vhosts/">Apache バーチャルホスト説明書</
a></
seealso>
<
description>インストールされたサーバのベースディレクトリ</
description>
<
syntax>ServerRoot <
var>directory-path</
var></
syntax>
<
contextlist><
context>server config</
context></
contextlist>
<
p><
directive>ServerRoot</
directive> ディレクティブは、
通常、<
code>conf/</
code> や <
code>logs/</
code> といったサブディレクトリが
また、他の設定ディレクティブ (例えば <
directive module="core">Include</
directive> や <
directive module="mod_so">LoadModule</
directive> など) における相対パスは、
このディレクトリからの相対位置となります。</
p>
<
example><
title>例</
title>
<
seealso><
a href="/invoking.html"><
code>httpd</
code> の <
code>-d</
code>
<
seealso><
directive>ServerRoot</
directive> の権限を適切に設定する方法は<
a<
name>ServerSignature</
name>
<
description>サーバが生成するドキュメントのフッタを設定</
description>
<
syntax>ServerSignature On|Off|EMail</
syntax>
<
default>ServerSignature Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
p><
directive>ServerSignature</
directive> ディレクティブは、
(エラーメッセージ、<
module>mod_proxy</
module> における FTP のディレクトリリスト、
<
module>mod_info</
module> の出力、等々)
プロキシが複数連なっている場合に、ユーザはどのサーバが返した
エラーメッセージかを知る手段がほとんど無いというものがあります。</
p>
<
p>デフォルトである <
code>Off</
code> に設定をすると、フッタ行が抑制されます
(そして、Apache-1.2 以前と互換の動作をします)。
<
code>On</
code> に設定した場合は、単にドキュメントの中に、サーバのバージョン、
href="#servername">ServerName</
a> の書かれた行を追加し、
<
code>EMail</
code> にした場合はさらに参照されたドキュメントに対する <
a href="#serveradmin">ServerAdmin</
a> を指す "mailto:" が追加されます。</
p>
<
p>バージョン 2.0.44 以降では、表示されるサーバーのバージョン番号の詳細は<
directive module="core">ServerTokens</
directive>
<
seealso><
directive module="core">ServerTokens</
directive></
seealso>
<
name>ServerTokens</
name>
<
description><
code>Server</
code> HTTP 応答ヘッダを設定する</
description>
<
syntax>ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full</
syntax>
<
default>ServerTokens Full</
default>
<
contextlist><
context>server config</
context></
contextlist>
<
p>このディレクティブは、クライアントに送り返す <
code>Server</
code>
コンパイルされて組み込まれているモジュールの情報を
<
dt><
code>ServerTokens Prod[uctOnly]</
code></
dt>
<
dd>サーバは (例えば): <
code>Server:
Apache</
code> といったように送ります。</
dd>
<
dt><
code>ServerTokens Major</
code></
dt>
<
dd>Server sends (<
em>
e.g.</
em>): <
code>Server:
<
dt><
code>ServerTokens Minor</
code></
dt>
<
dd>Server sends (<
em>
e.g.</
em>): <
code>Server:
<
dt><
code>ServerTokens Min[imal]</
code></
dt>
<
dd>サーバは (例えば): <
code>Server:
<
dt><
code>ServerTokens OS</
code></
dt>
(Unix)</
code> といったように送ります。</
dd>
<
dt><
code>ServerTokens Full</
code> (もしくは未指定)</
dt>
<
p>この設定はサーバ全体に適用され、バーチャルホスト上で有効にしたり
<
p>バージョン 2.0.44 以降ではこのディレクティブは <
directive module="core">ServerSignature</
directive>
ディレクティブにより表示される情報も制御します。</
p>
<
seealso><
directive module="core">ServerSignature</
directive></
seealso>
<
description>マッチするファイルがハンドラで処理されるようにする</
description>
<
syntax>SetHandler <
var>handler-name</
var>|None</
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
<
compatibility>Apache 2.0 で core に移動</
compatibility>
<
p><
code>.htaccess</
code> や <
directive type="section" module="core" セクション、<
directive type="section" module="core">Location</
directive>
>ハンドラ</
a>で扱われることを強制します。例えば、拡張子に関わらず、
ディレクトリ全体がイメージマップファイルとして解析して欲しい場合には、
以下をそのディレクトリの <
code>.htaccess</
code>
が指定されたときにサーバが状態報告をするようにしたいときは、以下を
<Location /status><
br />
SetHandler server-status<
br />
<
p><
code>None</
code> という値を設定することで、
前の方の <
directive>SetHandler</
directive> で定義された設定を無効にすることが
<
p><
strong>注意:</
strong>SetHandler はデフォルトのハンドラをオーバーライド
しますので、通常の挙動、たとえば、スラッシュ (/) で終わる URL が
リクエストされたときにディレクトリやインデックスファイルを返すよう取り扱う挙動は、
<
seealso><
directive module="mod_mime">AddHandler</
directive></
seealso>
<
name>SetInputFilter</
name>
<
description>クライアントのリクエストや POST の入力を処理するフィルタを設定する</
description>
<
syntax>SetInputFilter <
var>filter</
var>[;<
var>filter</
var>...]</
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
<
p><
directive>SetInputFilter</
directive> ディレクティブはクライアントの
リクエストや POST の入力をサーバが受け取ったときに処理するフィルタを
設定します。これは <
directive module="mod_mime">AddInputFilter</
directive>
ディレクティブを含め、他の場所で定義されているフィルタの設定に
<
p>複数のフィルタを指定するときは、データを処理する順番に
<
name>SetOutputFilter</
name>
<
description>サーバの応答を処理するフィルタを設定する</
description>
<
syntax>SetOutputFilter <
var>filter</
var>[;<
var>filter</
var>...]</
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context><
context>.htaccess</
context>
<
override>FileInfo</
override>
<
p><
directive>SetOutputFilter</
directive> ディレクティブは
サーバの応答をクライアントに送り返される前に処理するフィルタを設定します。
これは <
directive module="mod_mime">AddOutputFilter</
directive>
ディレクティブを含め、他の場所で定義されているフィルタの設定に
<
p>例えば、以下の設定は <
code>/
www/
data/</
code> ディレクトリのすべての
SetOutputFilter INCLUDES<
br />
<
p>複数のフィルタを指定するときは、データを処理する順番に
<
description>各イベントについて、リクエストを失敗させるまでにサーバが
<
syntax>TimeOut <
var>seconds</
var></
syntax>
<
default>TimeOut 60</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context></
contextlist>
<
p><
directive>TimeOut</
directive> ディレクティブは、
様々な条件下での I/O 待ち時間を定義します:</
p>
受信バッファが空になっていて、TCP パケットが届くまで
送信バッファがいっぱいで、パケットの受信完了 <
transnote>ACK</
transnote>
<
li><
module>mod_cgi</
module> 内で、CGI スクリプトが出力を
<
li><
module>mod_ext_filter</
module> 内で、フィルタ処理で出力を
<
li><
module>mod_proxy</
module> 内で、
<
directive module="mod_proxy">ProxyTimeout</
directive>
が設定されていない場合のデフォルトの待ち時間</
li>
<
description><
code>TRACE</
code> メソッドのリクエストに対する応答方法を決める
<
syntax>TraceEnable <
var>[on|off|extended]</
var></
syntax>
<
default>TraceEnable on</
default>
<
contextlist><
context>server config</
context></
contextlist>
<
compatibility>Apache 1.3.34, 2.0.55 以降</
compatibility>
<
p>Apache のコア機能<
transnote><
module>core</
module></
transnote>と
<
module>mod_proxy</
module> 両方の <
code>TRACE</
code>
の挙動をオーバーライドします。デフォルトの <
code>TraceEnable on</
code>
は、リクエストボディを受け入れないような、RFC2616 に準拠した
<
code>TRACE</
code> リクエストを受け付けます。
<
code>TraceEnable off</
code> と設定すると、コアサーバと
<
module>mod_proxy</
module> は <
code>405</
code> (メソッド不許可)
<
p>最後に、テストや調査目的などの限定用途として、仕様に準拠しない
<
code>TraceEnable extended</
code> を使って、リクエストボディを
受け付けるように挙動を変更できます。(オリジンサーバとしての)
Apache のコアでは、リクエストボディのサイズは 64k (
<
code>Transfer-Encoding: chunked</
code> が使われている場合は
chunk ヘッダ用に +8k) に制限されます。
Apache のコアは、ヘッダと全ての chunk ヘッダをレスポンスの
proxy サーバとしては、リクエストボディのサイズは 64k に制限されません。</
p>
<
name>UseCanonicalName</
name>
<
description>サーバが自分自身の名前とポートを決定する方法を設定する</
description>
<
syntax>UseCanonicalName On|Off|Dns</
syntax>
<
default>UseCanonicalName Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context></
contextlist>
<
p>多くの状況で Apache は<
em>自己参照</
em> URL、すなわち
同じサーバを指す URL、を作成する必要があります。
<
code>UseCanonicalName On</
code> の場合は、<
directive module="core">ServerName</
directive> ディレクティブで指定されている
ホスト名とポート番号を使って、その正規名 (自己参照の名前) を生成します。
この名前は、すべての自己参照 URL で使われますし、CGI の
<
code>SERVER_NAME</
code> と <
code>SERVER_PORT</
code> でも使われます。</
p>
<
p><
code>UseCanonicalName Off</
code> の場合、
クライアントがホスト名とポートを指定したときには、
それらを元に自己参照 URL を作成します (指定がなかったときは
バーチャルホスト</
a>を実装で使われているのと同じ値で、
CGI 変数 <
code>SERVER_NAME</
code> と <
code>SERVER_PORT</
code>
もクライアントから与えられた値から作成されます。</
p>
<
p>このような挙動が便利な例は、イントラネットのサーバで <
code>www</
code>
のような短い名前でユーザがマシンに接続するときです。
ユーザの入力で短いホスト名が使われていて、URL が<
em>最後のスラッシュ無しの</
em>
ユーザは 2 回認証をしなければならなくなります (<
code>www</
code> に
しかし <
directive>UseCanonicalName</
directive> が <
code>Off</
code> になっていると、
<
p>三つ目のオプション <
code>UseCanonicalName DNS</
code> は、
大規模な IP ベースのバーチャルホスティングで、
<
code>Host:</
code> ヘッダを提供しない古いクライアントを
このオプションでは Apache は、クライアントが接続した IP アドレスに対して
DNS の逆引きを行なって、自己参照 URL を作成します。</
p>
<
note type="warning"><
title>警告</
title>
<
p>CGI が <
code>SERVER_NAME</
code> に関して何らかの前提条件を
仮定しているときには、このオプションの設定によっては動作しなく
なるかもしれません。クライアントは実質的にはホスト名として
何でも望みの値を指定することができます。CGI が
<
code>SERVER_NAME</
code> を使って自己参照 URL を作成することしかしない
場合は、どの設定を行なっても大丈夫なはずです。</
p></
note>
<
seealso><
directive module="core">UseCanonicalPhysicalPort</
directive></
seealso>
<
seealso><
directive module="core">ServerName</
directive></
seealso>
<
seealso><
directive module="mpm_common">Listen</
directive></
seealso>
<
name>UseCanonicalPhysicalPort</
name>
<
description>自分自身の名前とポート番号を解決する方法を設定する
<
syntax>UseCanonicalPhysicalPort On|Off</
syntax>
<
default>UseCanonicalPhysicalPort Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context></
contextlist>
<
p>さまざまな局面で <
em>自己参照</
em> URL -- それ自体のサーバを参照する URL
を作ることになります。<
code>UseCanonicalPhysicalPort On</
code> と設定すると、
<
directive module="core">UseCanonicalName</
directive> に従って別名を
生成する場合に、実際の物理ポート番号を使って構成するようになります。
<
code>UseCanonicalPhysicalPort Off</
code> の場合は、実際の物理ポート番号は
使用せず、設定された情報を元にポート番号を決めます。</
p>
<
p>物理ポートが使われる場合の順番は次のようになっています:<
br /><
br />
<
code>UseCanonicalName On</
code></
p>
<
li><
code>ServerName</
code> で指定されているポート番号</
li>
<
code>UseCanonicalName Off | DNS</
code>
<
li><
code>Host:</
code> ヘッダをパースして取得されるポート番号</
li>
<
li><
code>ServerName</
code> で指定されているポート番号</
li>
<
p><
code>UseCanonicalPhysicalPort Off</
code> で、
物理ポート番号が上記の順序付けから除外されます。</
p>
<
seealso><
directive module="core">UseCanonicalName</
directive></
seealso>
<
seealso><
directive module="core">ServerName</
directive></
seealso>
<
seealso><
directive module="mpm_common">Listen</
directive></
seealso>
<
directivesynopsis type="section">
<
description>特定のホスト名や IP アドレスのみに適用されるディレクティブを
<
var>addr</
var>[:<
var>port</
var>] [<
var>addr</
var>[:<
var>port</
var>]]
...> ... </VirtualHost></
syntax>
<
contextlist><
context>server config</
context></
contextlist>
<
p><
directive type="section">VirtualHost</
directive> 及び
<
code></VirtualHost></
code> は、
特定のバーチャルホストに対してのみ適用されるディレクティブ群を括る
バーチャルホストコンテキストで許可される全てのディレクティブを指定可能です。
サーバが、指定されたバーチャルホストにあるドキュメントへの
<
directive type="section">VirtualHost</
directive> セクションの中にある
<
var>Addr</
var>は、次のものが利用できます:</
p>
<
li>バーチャルホストの IP アドレス</
li>
<
li>バーチャルホストの IP に対応する完全なドメイン名 (非推奨)</
li>
<
li><
code>NameVirtualHost *</
code> と共に使われる、
すべての IP アドレスにマッチする文字 <
code>*</
code></
li>
<
li>IP ベースのバーチャルホストで他のものにマッチしない IP アドレス
のための文字列 <
code>_default_</
code></
li>
<
example><
title>例</
title>
<VirtualHost 10.1.2.3><
br />
ServerAdmin webmaster@host.example.com<
br />
<
p>IPv6 アドレスはオプションのポート番号の指定と区別するために、
角括弧で括って指定する必要があります。次は IPv6 の例です:</
p>
<VirtualHost [2001:db8::a00:20ff:fea7:ccea]><
br />
ServerAdmin webmaster@host.example.com<
br />
<
p>各々のバーチャルホストにはそれぞれ違う IP アドレス、ポート番号
1 番目の場合には複数のアドレスで IP パケットを受信できるように
(もし、マシンが複数のネットワークインターフェースを持たない場合は、
(OSがサポートしていれば) <
code>ifconfig alias</
code> コマンドにより
<
p><
directive type="section">VirtualHost</
directive> は Apache が Listen する
IP アドレスには影響を与え<
strong>ません</
strong>。
<
directive module="mpm_common">Listen</
directive> を
使って Apache が正しいアドレスを listen するように設定する必要があります。</
p>
<
p>IP ベースのバーチャルホストを使っている場合は、特別な名前
<
code>_default_</
code> を指定することができます。その場合は
そのバーチャルホストは他のバーチャルホストで明示的に挙げられていない
すべての IP アドレスにマッチします。<
code>_default_</
code> バーチャルホストが無い
場合に IP がバーチャルホストで指定されたものにマッチしないときは、
VirtualHost セクションの外のすべての定義からなる「主」サーバ設定が
module="core">NameVirtualHost</
directive> ディレクティブにマッチする
すべての IP アドレスは「主」サーバ設定も <
code>_default_</
code> バーチャルホストも
<
p><
code>:port</
code> といった形式で記述することにより、
一番最後に <
code><
a href="#port">Port</
a></
code> で指定されたポートが
<
code>:*</
code> を指定することにより、
アドレス上の全てのポートにマッチします。(<
code>_default_</
code> のときは
<
p><
directive type="section">VirtualHost</
directive> ブロックごとに
<
directive module="core">ServerName</
directive> を指定すべきです。
<
directive module="core">ServerName</
directive>
<
note type="warning"><
title>セキュリティ</
title>
<
p>サーバーを起動した以外のユーザがログファイルが保管されるディレクトリに
書き込み可能なときになぜセキュリティが破られる可能性があるかの詳細は
<
seealso><
a href="/vhosts/">Apache バーチャルホスト説明書</
a></
seealso>
<
seealso><
a href="/bind.html">Apache が使用するアドレスとポートの設定</
a></
seealso>
<
seealso>リクエストを受けた際にこれらの異なるセクションが
<Directory>, <Location>, <Files> セクションの動作法</
a></
seealso>