<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>

<!-- English Revision: 669847:1199485 (outdated) -->

<!--

Licensed to the Apache Software Foundation (ASF) under one or more

contributor license agreements. See the NOTICE file distributed with

this work for additional information regarding copyright ownership.

The ASF licenses this file to You under the Apache License, Version 2.0

(the "License"); you may not use this file except in compliance with

the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software

distributed under the License is distributed on an "AS IS" BASIS,

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and

limitations under the License.

-->

<modulesynopsis metafile="core.xml.meta">

<name>core</name>

<description>常に使用可能な Apache HTTP サーバのコア機能</description>

<status>Core</status>

<directivesynopsis>

<name>AcceptFilter</name>

<description>プロトコルを Listen しているソケットの最適化を設定する</description>

<syntax>AcceptFilter <var>protocol</var> <var>accept_filter</var></syntax>

<contextlist><context>server config</context></contextlist>

<compatibility>2.1.5 以降</compatibility>

<usage>

<p>Listen しているソケットに対して、OS が固有に持っているプロトコルについての最適化を

有効にするディレクティブです。大前提となる条件は、データが受信されるか

HTTP リクエスト全体がバッファされるかするまで、カーネルがサーバプロセスに

ソケットを送らないようになっている、ということです。現在サポートされているのは、

<a href="http://www.freebsd.org/cgi/man.cgi?query=accept_filter&amp;sektion=9">

FreeBSD の Accept Filter</a> と Linux のプリミティブな

<code>TCP_DEFER_ACCEPT</code> のみです。</p>

<p>FreeBSD のデフォルト値は :</p>

<example>

AcceptFilter http httpready <br/>

AcceptFilter https dataready

</example>

<p><code>httpready</code> Accept Filter は HTTP リクエスト全体を、

カーネルレベルでバッファリングします。リクエスト全体を受信し終わると、

その後サーバプロセスにそれを送ります。詳細については <a

href="http://www.freebsd.org/cgi/man.cgi?query=accf_http&amp;sektion=9">accf_http(9)</a>

を参照してください。HTTPS のリクエストは暗号化されているので <a

href="http://www.freebsd.org/cgi/man.cgi?query=accf_data&amp;sektion=9">accf_data(9)</a>

フィルタのみが使用されます。</p>

<p>Linux でのデフォルト値は :</p>

<example>

AcceptFilter http data <br/>

AcceptFilter https data

</example>

<p>Linux の <code>TCP_DEFER_ACCEPT</code> は HTTP リクエストのバッファリングを

サポートしていません。<code>none</code> 以外の値で

<code>TCP_DEFER_ACCEPT</code> が有効になります。詳細については Linux

man ページ <a

href="http://homepages.cwi.nl/~aeb/linux/man2html/man7/tcp.7.html">tcp(7)</a>

を参照してください。</p>

<p>引数に <code>none</code> を指定すると、プロトコルに対する全ての Accept

Filter が無効になります。<code>nntp</code> といった、先にサーバにデータを

送る必要のあるプロトコルに有効です :</p>

<example>AcceptFilter nntp none</example>

</usage>

</directivesynopsis>

<directivesynopsis>

<name>AcceptPathInfo</name>

<description>後に続くパス名情報を受け付けるリソースの指定</description>

<syntax>AcceptPathInfo On|Off|Default</syntax>

<default>AcceptPathInfo Default</default>

<contextlist><context>server config</context>

<context>virtual host</context><context>directory</context>

<context>.htaccess</context></contextlist>

<override>FileInfo</override>

<compatibility>Apache 2.0.30 以降で使用可能</compatibility>

<usage>

<p>このディレクティブは実際のファイル名 (もしくは存在するディレクトリの

存在しないファイル) の後に続くパス名情報があるリクエストを受け付けるか

拒否するかを制御します。続きのパス名情報はスクリプトには <code>PATH_INFO</code>

環境変数として利用可能になります。</p>

<p>例えば、<code>/test/</code> が、<code>here.html</code> というファイル

一つのみがあるディレクトリを指しているとします。そうすると、

<code>/test/here.html/more</code> と <code>/test/nothere.html/more</code>

へのリクエストは両方とも <code>/more</code> を <code>PATH_INFO</code> とします。</p>

<p><directive>AcceptPathInfo</directive> ディレクティブに指定可能な

三つの引数は:</p>

<dl>

<dt><code>Off</code></dt><dd>リクエストは存在するパスにそのまま

マップされる場合にのみ受け付けられます。ですから、上の例の

<code>/test/here.html/more</code> のように、本当のファイル名の

後にパス名情報が続くリクエストには 404 NOT FOUND エラーが返ります。</dd>

<dt><code>On</code></dt><dd>前の方のパスが存在するファイルにマップする場合は

リクエストが受け付けられます。上の例の <code>/test/here.html/more</code>

は <code>/test/here.html</code> が有効なファイルにマップすれば

受け付けられます。</dd>

<dt><code>Default</code></dt><dd>続きのパス名情報の扱いはリクエストの

<a href="../handler.html">ハンドラ</a>で決まります。

普通のファイルのためのコアハンドラのデフォルトは <code>PATH_INFO</code> を拒否します。

<a href="mod_cgi.html">cgi-script</a> や <a

href="mod_isapi.html">isapi-handler</a> のようにスクリプトを扱うハンドラは

一般的にデフォルトで <code>PATH_INFO</code> を受け付けます。</dd>

</dl>

<p><code>AcceptPathInfo</code> の主な目的はハンドラの <code>PATH_INFO</code> を

受け付けるか拒否するかの選択を上書きできるようにすることです。

例えば、これは例えば <a href="mod_include.html">INCLUDES</a> のような

<a href="../filter.html">フィルタ</a>を使って <code>PATH_INFO</code> に

基づいてコンテンツを生成しているときに必要になります。</p>

<example>

&lt;Files "mypaths.shtml"&gt;<br />

<indent>

Options +Includes<br />

SetOutputFilter INCLUDES<br />

AcceptPathInfo On<br />

</indent>

&lt;/Files&gt;

</example>

</usage>

</directivesynopsis>

<directivesynopsis>

<name>AccessFileName</name>

<description>分散設定ファイルの名前</description>

<syntax>AccessFileName <var>filename</var> [<var>filename</var>] ...</syntax>

<default>AccessFileName .htaccess</default>

<contextlist><context>server config</context><context>virtual host</context>

</contextlist>

<usage>

<p>リクエストを処理するとき、サーバはディレクトリに

対して分散設定ファイルが<a href="#allowoverride">有効になっていれば</a>、

そのドキュメントへの

パス上にある全てのディレクトリから、ここで指定された名前の一覧の中で

最初に見つかったファイルをそれぞれ設定ファイルとして読み込みます。例えば:</p>

<example>

AccessFileName .acl

</example>

<p>という設定があると、以下のようにして無効にされていない限り、

ドキュメント <code>/usr/local/web/index.html</code>

を返す前に、サーバは <code>/.acl</code>, <code>/usr/.acl</code>,

<code>/usr/local/.acl</code>, <code>/usr/local/web/.acl</code> から

ディレクティブを読み込みます。</p>

<example>

&lt;Directory /&gt;<br />

<indent>

AllowOverride None<br />

</indent>

&lt;/Directory&gt;

</example>

</usage>

<seealso><directive module="core">AllowOverride</directive></seealso>

<seealso><a href="../configuring.html">設定ファイル</a></seealso>

<seealso><a href="../howto/htaccess.html">.htaccess ファイル</a></seealso>

</directivesynopsis>

<directivesynopsis>

<name>AddDefaultCharset</name>

<description>レスポンスのコンテントタイプが <code>text/plain</code> あるいは

<code>text/html</code> の場合に追加するデフォルトの charset パラメータ</description>

<syntax>AddDefaultCharset On|Off|<var>charset</var></syntax>

<default>AddDefaultCharset Off</default>

<contextlist><context>server config</context>

<context>virtual host</context><context>directory</context>

<context>.htaccess</context></contextlist>

<override>FileInfo</override>

<usage>

<p>レスポンスのコンテントタイプが <code>text/plain</code>

あるいは <code>text/html</code>

の場合に限りますが、レスポンスに追加するメディアタイプの文字セットパラメータ

(文字エンコーディングの名前) のデフォルト値を、このディレクティブで指定します。

これはレスポンス <transnote>レスポンスの HTML</transnote> 内で <code>META</code>

要素で指定された、どのような文字セットも無効にしますが、

最終的な挙動はユーザのクライアント側の設定で決まります。

この機能は <code>AddDefaultCharset Off</code> という設定で無効になります。

<code>AddDefaultCharset On</code> にすれば、

Apache 内部のデフォルト文字セット <code>iso-8859-1</code> に設定されます。

その他 <var>charset</var> に指定できる値であれば、どんな値でも使えます。

指定する値は、MIME メディアタイプとして使われる

<a href="http://www.iana.org/assignments/character-sets">IANA

に登録されている文字セット名</a>のうちの一つにすべきです。

例えば:</p>

<example>

AddDefaultCharset utf-8

</example>

<p><directive>AddDefaultCharset</directive> を使うときは、全てのテキストリソースが

指定する文字エンコードになっていると分かっていて、かつ、

リソースの個々に文字セットを指定するのが大変な場合のみです。

例を挙げると、レガシーな CGI スクリプトなどの、動的に生成される

コンテンツを含むリソースに文字セットパラメータを追加する場合で、

ユーザの入力データが出力に入り、クロスサイトスクリプティングが

引き起こされうる場合です。デフォルト文字セットをセットしたとしても、

ブラウザの "文字エンコードの自動選択" 機能が有効になっているユーザを

守ることにはならないので、もちろんより良い解決策は単にスクリプトを修正

(あるいは削除) することです。</p>

</usage>

<seealso><directive module="mod_mime">AddCharset</directive></seealso>

</directivesynopsis>

<directivesynopsis>

<name>AddOutputFilterByType</name>

<description>MIME-type に出力フィルタを割り当てる</description>

<syntax>AddOutputFilterByType <var>filter</var>[;<var>filter</var>...] <var>MIME-type</var>

[<var>MIME-type</var>] ...</syntax>

<contextlist><context>server config</context>

<context>virtual host</context><context>directory</context>

<context>.htaccess</context></contextlist>

<override>FileInfo</override>

<compatibility>Apache 2.0.33 以降で使用可能; Apache 2.1 以降非推奨</compatibility>

<usage>

<p>このディレクティブは応答の <glossary ref="mime-type">MIME タイプ</glossary> に応じて出力<a

href="../filter.html">フィルタ</a>を使用するようにします。

しかし後述する問題のため、このディレクティブは非推奨です。

同等の機能は <module>mod_filter</module> で実現可能です。</p>

<p>次の例は <module>mod_deflate</module> の <code>DEFLATE</code> フィルタを

使っています。<code>text/html</code> と <code>text/plain</code> の

すべての出力 (静的なものも動的なものも) をクライアントに送られる前に

圧縮します。</p>

<example>

AddOutputFilterByType DEFLATE text/html text/plain

</example>

<p>複数のフィルタでコンテンツを処理させたいときは、それぞれの名前をセミコロンで

分ける必要があります。各フィルタに対して

<directive>AddOutputFilterByType</directive> を一つずつ書くこともできます。</p>

<p>次の例は <code>text/html</code> のスクリプトのすべての出力を

まず <code>INCLUDES</code> フィルタで処理し、さらに <code>DEFLATE</code> フィルタにかけます。</p>

<example>

&lt;Location /cgi-bin/&gt;<br />

<indent>

Options Includes<br />

AddOutputFilterByType INCLUDES;DEFLATE text/html<br />

</indent>

&lt;/Location&gt;

</example>

<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 スクリプトでコンテントタイプを設定するというものでも

大丈夫です。</p>

</note>

</usage>

<seealso><directive module="mod_mime">AddOutputFilter</directive></seealso>

<seealso><directive module="core">SetOutputFilter</directive></seealso>

<seealso><a href="../filter.html">フィルタ</a></seealso>

</directivesynopsis>

<directivesynopsis>

<name>AllowEncodedSlashes</name>

<description>URL 中の符号化されたパス分離文字が先に伝えられるのを許可するかどうかを

決定する</description>

<syntax>AllowEncodedSlashes On|Off</syntax>

<default>AllowEncodedSlashes Off</default>

<contextlist><context>server config</context><context>virtual host</context>

</contextlist>

<compatibility>Apache 2.0.46 以降で使用可能</compatibility>

<usage>

<p><directive>AllowEncodedSlashes</directive> ディレクティブは符号化された

パス分離文字 (<code>/</code> は <code>%2F</code>、さらにシステムによっては

<code>\</code> に対応する <code>%5C</code>) が存在する URL の使用を

許可するかどうかを決定します。通常はそのような URL は 404 (Not found) エラー

で拒否されます。</p>

<p><directive>AllowEncodedSlashes</directive> <code>On</code> による

パス分離文字の使用は、<code>PATH_INFO</code> と合わせて

使うときに一番役に立ちます。</p>

<note><title>注</title>

<p>符号化されたスラッシュを許可することは、<em>復号</em>をすることを

意味<em>しません</em>。<code>%2F</code> や (関係するシステムでの)

<code>%5C</code> は、他の部分が復号された URL の中でもそのままの形式で

残されます。</p>

</note>

</usage>

<seealso><directive module="core">AcceptPathInfo</directive></seealso>

</directivesynopsis>

<directivesynopsis>

<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>

<usage>

<p>サーバが (<directive

module="core">AccessFileName</directive> によって指定された)

<code>.htaccess</code> ファイルを見つけた時、そのファイルの中で

宣言されたどのディレクティブがより前に定義された設定ディレクティブを

上書きできるかを知る必要があります。</p>

<note><title>&lt;Directory&gt; セクションでのみ使用可能</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> セクションでは無効です。

</note>

<p>このディレクティブを <code>None</code> に設定すると、<a href="#accessfilename">.htaccess</a> ファイルは完全に

無視されます。

この場合、サーバはファイルシステムの <code>.htaccess</code> ファイルを読むことを

試みさえしません。</p>

<p>このディレクティブが <code>All</code> に設定されている時には、

<code>.htaccess</code> という <a

href="directive-dict.html#Context">コンテキスト</a> を持つ

全てのディレクティブが利用できます。</p>

<p><var>directive-type</var> には、以下のディレクティブ群の

キーワードのどれかを指定します。</p>

<dl>

<dt>AuthConfig</dt>

<dd>

認証に関するディレクティブの使用を許可する (<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>

<dt>FileInfo</dt>

<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*

ディレクティブ<em>など</em>),

ドキュメントのメタデータ (<directive

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>

ディレクティブ。

</dd>

<dt>Indexes</dt>

<dd>

ディレクトリインデックスを制御するためのディレクティブの使用を許可する

(<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>

<em>など</em>)。</dd>

<dt>Limit</dt>

<dd>

ホストへのアクセス制御を行うためのディレクティブの使用を許可する (<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>

<dd>

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

(<directive module="core">Options</directive> と

<directive module="mod_include">XBitHack</directive>)。

<directive module="core">Options</directive> で設定するオプション

を、(空白を含めない) コンマ区切りのリストにして等号の後に続けることで

設定できます。</dd>

</dl>

<p>例:</p>

<example>

AllowOverride AuthConfig Indexes

</example>

<p>上の例では <code>AuthConfig</code> と <code>Indexes</code> のどちらにも

属さないディレクティブはすべて内部サーバエラーを引き起こします。</p>

</usage>

<seealso><directive module="core">AccessFileName</directive></seealso>

<seealso><a href="../configuring.html">設定ファイル</a></seealso>

<seealso><a href="../howto/htaccess.html">.htaccess ファイル</a></seealso>

</directivesynopsis>

<directivesynopsis>

<name>CGIMapExtension</name>

<description>CGI スクリプトのインタープリタの位置を調べるための手法</description>

<syntax>CGIMapExtension <var>cgi-path</var> <var>.extension</var></syntax>

<contextlist><context>directory</context><context>.htaccess</context>

</contextlist>

<override>FileInfo</override>

<compatibility>NetWare のみ</compatibility>

<usage>

<p>このディレクティブは Apache が CGI スクリプトを実行するための

インタープリタを探す方法を制御します。

例えば、<code>CGIMapExtension sys:\foo.nlm .foo</code> と設定すると

<code>.foo</code> という拡張子のすべての CGI スクリプトは FOO インタープリタに

渡されます。</p>

</usage>

</directivesynopsis>

<directivesynopsis>

<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>

</contextlist>

<override>Options</override>

<status>Experimental</status>

<usage>

<p>このディレクティブは、RFC1864 及び RFC2616 において定義されている

<code>Content-MD5</code> ヘッダーの生成を有効にします。</p>

<p>MD5 は、任意長のデータの「メッセージダイジェスト」(「指紋」

と表現されることもある) を計算するアルゴリズムで、

データの変更があった場合には非常に高い信頼度でメッセージダイジェストに変更が

反映されます。</p>

<p><code>Content-MD5</code> ヘッダは、エンドツーエンドで

エンティティボディーに含まれるメッセージの完全性チェック

(Message Integrity Check - MIC)を提供します。

このヘッダを調べることで、プロキシやクライアントは、

途中経路におけるエンティティボディの予期せぬ変更などを

検出することができます。ヘッダの例:</p>

<example>

Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==

</example>

<p>リクエスト毎にメッセージダイジェストを計算する (値はキャッシュされません)

ことから、

サーバパフォーマンスが低下することについて注意してください。</p>

<p><code>Content-MD5</code >は、<module>core</module> 機能により処理された

ドキュメントを送るときのみ有効であり、

SSI ドキュメントや CGI スクリプトの出力、バイトレンジを指定した

応答の場合にはこのヘッダは付与されません。

</p>

</usage>

</directivesynopsis>

<directivesynopsis>

<name>DefaultType</name>

<description>サーバがコンテントタイプを決定できないときに

送られる MIME コンテントタイプ</description>

<syntax>DefaultType <var>MIME-type|none</var></syntax>

<default>DefaultType text/plain</default>

<contextlist><context>server config</context><context>virtual host</context>

<context>directory</context><context>.htaccess</context>

</contextlist>

<override>FileInfo</override>

<compatibility>引数 <code>none</code> は Apache 2.2.7 以降で利用可能</compatibility>

<usage>

<p>サーバは、<glossary ref="mime-type">MIME タイプ</glossary>

のマップからは決定できないドキュメントの送信を要求されることがあります。</p>

<p>サーバは、ドキュメントのコンテントタイプをクライアントに通知するべきです。

サーバで通常の方法ではこれが判定できない場合は、

<code>DefaultType</code> で指定されたタイプを利用します。

例:</p>

<example>

DefaultType image/gif

</example>

<p>これは <code>.gif</code> という拡張子がファイル名に含まれていない

多くの GIF 画像が含まれているディレクトリに適しているでしょう。</p>

<p>サーバでも管理者でも判定することができない (例えばプロクシの) 場合、

誤った情報を与えるよりは MIME タイプの指定がない状態が望ましいことも

あります。この場合は次のようにします :</p>

<example>

DefaultType None

</example>

<p><code>DefaultType None</code> は httpd-2.2.7

以降でのみ利用できます。</p>

<p><directive module="core">ForceType</directive> ディレクティブと

違って、このディレクティブはデフォルトの MIME タイプを提供するだけで

あることに注意してください。ファイル名の拡張子を含め、

メディアタイプを決定できる他の MIME タイプの定義があれば

このデフォルトは上書きされます。</p>

</usage>

</directivesynopsis>

<directivesynopsis>

<name>Define</name>

<description>変数の存在を宣言する</description>

<syntax>Define <var>parameter-name</var></syntax>

<contextlist><context>server config</context></contextlist>

<usage>

<p><program>httpd</program> の <code>-D</code>

引数と同じものです。</p>

<p>このディレクティブを使うと、スタートアップスクリプトに

記載されている <code>-D</code> 引数を書き換える必要なく、

<directive module="core" type="section">IfDefine</directive>

セクションを切り替えることができます。</p>

</usage>

</directivesynopsis>

<directivesynopsis type="section">

<name>Directory</name>

<description>指定のファイルシステムのディレクトリとサブディレクトリとのみに

適用されるディレクティブを囲む</description>

<syntax>&lt;Directory <var>directory-path</var>&gt;

... &lt;/Directory&gt;</syntax>

<contextlist><context>server config</context><context>virtual host</context>

</contextlist>

<usage>

<p>指定されたディレクトリとそのサブディレクトリにのみ

ディレクティブを適用させるためには、

<directive type="section">Directory</directive> と

<code>&lt;/Directory&gt;</code> を対として、ディレクティブ群を囲います。

その中には、ディレクトリコンテキストで許可された全てのディレクティブを

利用できます。

<var>directive-path</var> は、フルパスもしくは Unix のシェル形式の

ワイルドカードを指定します。

<code>?</code> は任意の 1 文字、<code>*</code> は任意の文字列にマッチします。

シェルにおける指定同様、文字の範囲を <code>[]</code> で指定できます。

ワイルドカードは `/' 文字にはマッチしませんので、

<code>/home/user/public_html</code> には

<code>&lt;Directory /*/public_html&gt;</code> はマッチしませんが、

<code>&lt;Directory /home/*/public_html&gt;</code> はマッチします。

例:</p>

<example>

&lt;Directory /usr/local/httpd/htdocs&gt;<br />

<indent>

Options Indexes FollowSymLinks<br />

</indent>

&lt;/Directory&gt;

</example>

<note>

<p><var>directory-path</var> 引数には注意してください: その引数は

Apache がファイルをアクセスするために使うファイルシステムのパスに

そのままマッチする必要があります。ある <code>&lt;Directory&gt;</code> に

適用されるディレクティブは、別のシンボリックリンクをたどったりして

同じディレクトリを違うパスでアクセスした場合には適用されません。</p>

</note>

<p><code>~</code> という文字を

付加することで<glossary ref="regex">正規表現</glossary>を利用することもできます。

例えば:</p>

<example>

&lt;Directory ~ "^/www/.*/[0-9]{3}"&gt;

</example>

<p>といった指定の場合、<code>/www/</code> 以下にある数字

3 文字のディレクトリにマッチします。</p>

<p>もし複数の (正規表現以外の) <directive type="section"

>Directory</directive>セクションが

ドキュメントを含むディレクトリ (やその上位ディレクトリのどれか) とマッチしたならば、

<a

href="#accessfilename">.htaccess</a> ファイルのディレクティブも読み込みつつ、

短いパスから順に適用されます。

例えば、</p>

<example>

&lt;Directory /&gt;<br />

<indent>

AllowOverride None<br />

</indent>

&lt;/Directory&gt;<br />

<br />

&lt;Directory /home/&gt;<br />

<indent>

AllowOverride FileInfo<br />

</indent>

&lt;/Directory&gt;

</example>

<p>と設定し、ドキュメント <code>/home/web/dir/doc.html</code> への

アクセスがあった場合には以下のように動作します:</p>

<ul>

<li><code>AllowOverride None</code> が適用される。

(<code>.htaccess</code> ファイルは無効になる)</li>

<li><code>AllowOverride FileInfo</code> が適用される

(<code>/home</code> ディレクトリに対して)。</li>

<li><code>/home/.htaccess</code>, <code>/home/web/.htaccess</code>,

<code>/home/web/dir/.htaccess</code> の順にそれらのファイル中の

FileInfo ディレクティブが適用される。</li>

</ul>

<p>正規表現は、通常のセクションがすべて適用されるまで

考慮されません。

その後、全ての正規表現が設定ファイルに現れた順で試されます。

例えば、以下のような場合に</p>

<example>

&lt;Directory ~ abc$&gt;<br />

<indent>

# ... directives here ...<br />

</indent>

&lt;/Directory&gt;

</example>

<p>正規表現のセクションはすべての通常の <directive

type="section">Directory</directive> と

<code>.htaccess</code> の適用が終わるまで考慮されません。

その後で、正規表現は <code>/home/abc/public_html/abc</code> にマッチし、

対応する <directive type="section">Directory</directive> が適用されます。</p>

<p><strong>Apache のデフォルトでは <code>&lt;Directory /&gt;</code> へのアクセスは

<code>Allow from All</code> になっていることに注意してください。

これは、URL からマップされたどのファイルでも Apache は送るということです。

これは以下のようにして変更することが推奨されています。</strong></p>

<example>

&lt;Directory /&gt;<br />

<indent>

Order Deny,Allow<br />

Deny from All<br />

</indent>

&lt;/Directory&gt;

</example>

<p><strong>そしてアクセスを<em>可能にしたい</em>ディレクトリに対して

個別に設定すればよいでしょう。

このあたりについては、<a

href="../misc/security_tips.html">セキュリティに関するコツ</a>を

参照してください。</strong></p>

<p>ディレクトリセクションは <code>httpd.conf</code> ファイルに書きます。

<directive type="section">Directory</directive>

ディレクティブは入れ子にすることができず、

<directive module="core" type="section">Limit</directive> や <directive

module="core" type="section">LimitExcept</directive> セクションの中にも

記述できません。</p>

</usage>

<seealso>リクエストを受けた際にこれらの異なるセクションが

組み合わされる方法については <a href="../sections.html">

&lt;Directory&gt;, &lt;Location&gt;, &lt;Files&gt; セクションの動作法</a></seealso>

</directivesynopsis>

<directivesynopsis type="section">

<name>DirectoryMatch</name>

<description>正規表現にマッチするファイルシステムのディレクトリと

サブディレクトリとのみに適用されるディレクティブを囲む</description>

<syntax>&lt;DirectoryMatch <var>regex</var>&gt;

... &lt;/DirectoryMatch&gt;</syntax>

<contextlist><context>server config</context><context>virtual host</context>

</contextlist>

<usage>

<p><directive module="core" type="section">Directory</directive>

ディレクティブと同様に、<directive type="section">DirectoryMatch</directive>

と <code>&lt;/DirectoryMatch&gt;</code> は指定されたディレクトリと

そのサブディレクトリにのみ適用されるディレクティブ群を囲います。

しかし、このディレクティブは引数として<glossary

ref="regex">正規表現</glossary>をとります。例えば:</p>

<example>

&lt;DirectoryMatch "^/www/(.+/)?[0-9]{3}"&gt;

</example>

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

</usage>

<seealso>通常の <directive type="section">Directory</directive> と正規表現の指定が

適用される順番については <directive type="section"

module="core">Directory</directive></seealso>

<seealso>リクエストを受けた際にこれらの異なるセクションが

組み合わされる方法については <a href="../sections.html">

&lt;Directory&gt;, &lt;Location&gt;, &lt;Files&gt; セクションの動作法</a></seealso>

</directivesynopsis>

<directivesynopsis>

<name>DocumentRoot</name>

<description>ウェブから見えるメインのドキュメントツリーになる

ディレクトリ</description>

<syntax>DocumentRoot <var>directory-path</var></syntax>

<default>DocumentRoot /usr/local/apache/htdocs</default>

<contextlist><context>server config</context><context>virtual host</context>

</contextlist>

<usage>

<p>このディレクティブは、<program>httpd</program>

がファイルを提供するディレクトリを設定します。

<directive module="mod_alias">Alias</directive> のようなディレクティブにマッチしない場合には、

ドキュメントの (訳注:ファイルシステム上の) パスを生成するために、

リクエストされた URL のパス部分をドキュメントルートに付与します。

例:</p>

<example>

DocumentRoot /usr/web

</example>

<p>この場合、

<code>http://www.my.host.com/index.html</code> へのアクセスがあれば

<code>/usr/web/index.html</code> が返されます。

<var>directory-path</var> が絶対パスでない場合は、

<directive module="core">ServerRoot</directive>

からの相対パスとみなされます。</p>

<p><directive>DocumentRoot</directive> は最後のスラッシュ無しで

指定する必要があります。</p>

</usage>

<seealso><a href="../urlmapping.html#documentroot">URL をファイルシステムの位置に

マップする</a></seealso>

</directivesynopsis>

<directivesynopsis>

<name>EnableMMAP</name>

<description>配送中にファイルを読み込むためにメモリマッピングを

使うかどうか</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>

</contextlist>

<override>FileInfo</override>

<usage>

<p>このディレクティブは配送中にファイルの内容を読み込む必要があるときに

<program>httpd</program> がメモリマッピングを使うかどうかを制御します。

デフォルトでは、

例えば、<module>mod_include</module> を使って SSI ファイルを配送

するときのように、ファイルの途中のデータをアクセスする必要があるときには

Apache は OS がサポートしていればファイルをメモリにマップします。</p>

<p>

このメモリマップは性能の向上を持たらすことがあります。

しかし、環境によっては運用上の問題を防ぐためにメモリマッピングを

使用しないようにした方が良い場合もあります:</p>

<ul>

<li>マルチプロセッサシステムの中にはメモリマッピングをすると

<program>httpd</program> の性能が落ちるものがあります。</li>

<li>NFS マウントされた <directive module="core">DocumentRoot</directive>

では、<program>httpd</program> がメモリマップしている間にファイルが削除されたり

短くなったりしたときに起こるセグメンテーションフォールトのために

<program>httpd</program> がクラッシュする可能性があります。</li>

</ul>

<p>これらの問題に当てはまるサーバの設定の場合は、以下のようにして

ファイルの配送時のメモリマッピングを使用不可にしてください:</p>

<example>

EnableMMAP Off

</example>

<p>NFS マウントされたファイルには、問題のあるファイルにのみ明示的に

この機能を使用不可にします:</p>

<example>

&lt;Directory "/path-to-nfs-files"&gt;

<indent>

EnableMMAP Off

</indent>

&lt;/Directory&gt;

</example>

</usage>

</directivesynopsis>

<directivesynopsis>

<name>EnableSendfile</name>

<description>ファイルのクライアントへの配送時にカーネルの sendfile サポートを

使うかどうか</description>

<syntax>EnableSendfile On|Off</syntax>

<default>EnableSendfile On</default>

<contextlist><context>server config</context><context>virtual host</context>

<context>directory</context><context>.htaccess</context>

</contextlist>

<override>FileInfo</override>

<compatibility>バージョン 2.0.44 以降で使用可能</compatibility>

<usage>

<p>このディレクティブはクライアントにファイルの内容を送るときに

<program>httpd</program> がカーネルの

sendfile サポートを使うかどうかを制御します。デフォルトでは、

例えば静的なファイルの配送のように、リクエストの処理にファイルの

途中のデータのアクセスを必要としないときには、Apache は OS が

サポートしていればファイルを読み込むことなく sendfile を使って

ファイルの内容を送ります。</p>

<p>sendfile は read と send を別々に行なうことと、バッファの割り当てを

回避します。しかし、プラットフォームやファイルシステムの中には

運用上の問題を避けるためにこの機能を使用不可にした方が良い場合があります:</p>

<ul>

<li>プラットフォームの中にはビルドシステムが検知できなかった、壊れた

sendfile のサポートが存在するものがあります。これは特に

バイナリが別のマシンでビルドされ、壊れた sendfile のあるマシンに

移動したときに起こります。</li>

<li>Linux では、sendfile を用いると、

IPv6 使用時に存在する特定ネットワークカードの TCP-checksum

オフロードのバグを踏んでしまいます。</li>

<li>Itanium 上の Linux では、sendfile では 2GB 以上の

ファイルを扱うことができません。</li>

<li>ネットワークマウントされた <directive module="core">DocumentRoot</directive>

(例えば NFS や SMB)

では、カーネルは自身のキャッシュを使ってネットワークからのファイルを

送ることができないことがあります。</li>

</ul>

<p>これらの問題に当てはまるサーバの設定の場合は、以下のようにして

この機能を使用不可にしてください:</p>

<example>

EnableSendfile Off

</example>

<p>NFS や SMB マウントされたファイルには、問題のあるファイルにのみ明示的に

この機能を使用不可にします:</p>

<example>

&lt;Directory "/path-to-nfs-files"&gt;

<indent>

EnableSendfile Off

</indent>

&lt;/Directory&gt;

</example>

</usage>

</directivesynopsis>

<directivesynopsis>

<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>

</contextlist>

<override>FileInfo</override>

<usage>

<p>問題やエラーが発生したときの動作として、

Apache には以下の四つのうち一つの動作を設定することができます。</p>

<ol>

<li>Apache 標準の簡単なエラーメッセージを表示</li>

<li>自分で指定したメッセージを表示</li>

<li>問題やエラーの処理をする為に、自サーバ内の

<var>URL-path</var> へリダイレクト</li>

<li>問題やエラーの処理をする為に、外部の <var>URL</var> へリダイレクト</li>

</ol>

<p>最初のものがデフォルトの動作で、2 番目から 4 番目は、

<directive>ErrorDocument</directive>ディレクティブにより、

HTTP のレスポンスコードと、メッセージか URL を指定することで設定します。

Apache が問題もしくはエラーに関する追加情報を提供することがあります。</p>

<p>URL の場合は、スラッシュで始まる (/) ローカルの web-path (

<directive module="core">DocumentRoot</directive> からの相対パス

) か、クライアントが解決できる完全な URL を指定します。

もしくは、ブラウザに表示されるメッセージを指定できます。

例:</p>

<example>

ErrorDocument 500 http://foo.example.com/cgi-bin/tester<br />

ErrorDocument 404 /cgi-bin/bad_urls.pl<br />

ErrorDocument 401 /subscription_info.html<br />

ErrorDocument 403 "Sorry can't allow you access today"

</example>

<p>加えて、特別な値 <code>default</code> を使って Apache に

ハードコードされている簡単なメッセージを指定することができます。

通常は必要ではありませんが、<code>default</code> を使うと

既存の <directive>ErrorDocument</directive> ディレクティブの設定を

継承するところで、Apache のハードコードされた簡単なメッセージに

戻すことができます。</p>

<example>

ErrorDocument 404 /cgi-bin/bad_urls.pl<br /><br />

&lt;Directory /web/docs&gt;<br />

<indent>

ErrorDocument 404 default<br />

</indent>

&lt;/Directory&gt;

</example>

<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

Knowledge Base の記事 <a

href="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q294807">Q294807</a>

にあります。</p>

<p>ほとんどのエラーメッセージを上書きすることができますが、特定の状況下では

<directive module="core">ErrorDocument</directive> の設定にかかわらず

内蔵のメッセージが使われます。

特に、不正な形式のリクエストが検出された場合、通常のリクエスト処理は

即座に中止され、内蔵のエラーメッセージが返されます。

この処置は不正なリクエストによって引き起こされる、セキュリティ問題から

守るために必要な措置です。</p>

<p>2.0 より前のバージョンでは、対になっていない二重引用符を

先頭に付けることによりメッセージであることを指定していました。</p>

</usage>

<seealso><a href="../custom-error.html">カスタマイズ可能な