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

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

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

d5d794fc2f4cc9ca6d6da17cfa2cdcd8d244bacdnd

d5d794fc2f4cc9ca6d6da17cfa2cdcd8d244bacdnd

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

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd<name>core</name>

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

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd<status>Core</status>

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd

edcb4d94a269c3b1c3fdd6473e3f91e6c20e1702takashi<directivesynopsis>

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd<name>AcceptFilter</name>

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

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

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

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd<compatibility>2.1.5 以降</compatibility>

5c1f950c0d431c4f0cce5f954808ff0019a6b7b3niq

5c1f950c0d431c4f0cce5f954808ff0019a6b7b3niq<usage>

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

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

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

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

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

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

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

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd

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

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd <example>

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd AcceptFilter http httpready <br/>

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd AcceptFilter https dataready

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd </example>

b73a2be324e0b7fda7671ffc1e580a83a2af0d61nd

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

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

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

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

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

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

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

206b5dce9e48924aa9f12ce87f14856a4cd3fb68takashi <example>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive AcceptFilter http data <br/>

7a98571671f92e53441bf24a0222768072172f90coar AcceptFilter https data

7a98571671f92e53441bf24a0222768072172f90coar </example>

7a98571671f92e53441bf24a0222768072172f90coar

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

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive man ページ <a

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

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

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive <example>AcceptFilter nntp none</example>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

20c4dfd964dafeb1227373f224fafac0b01dfc85slive</usage>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive</directivesynopsis>

206b5dce9e48924aa9f12ce87f14856a4cd3fb68takashi

206b5dce9e48924aa9f12ce87f14856a4cd3fb68takashi<directivesynopsis>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive<name>AcceptPathInfo</name>

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive<default>AcceptPathInfo Default</default>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive<contextlist><context>server config</context>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive<context>virtual host</context><context>directory</context>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive<context>.htaccess</context></contextlist>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive<override>FileInfo</override>

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

20c4dfd964dafeb1227373f224fafac0b01dfc85slive<usage>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

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

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

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

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

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

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive 三つの引数は:</p>

55eb45d44f175c6809521998627457789f95e240humbedooh

20c4dfd964dafeb1227373f224fafac0b01dfc85slive <dl>

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

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

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

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

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

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

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

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

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

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

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive </dl>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

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

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

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

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive 基づいてコンテンツを生成しているときに必要になります。

20c4dfd964dafeb1227373f224fafac0b01dfc85slive コアハンドラでは通常拒否されるので、そういったスクリプトを動作させるには

20c4dfd964dafeb1227373f224fafac0b01dfc85slive 次のような設定を使います。</p>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive

20c4dfd964dafeb1227373f224fafac0b01dfc85slive <example>

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

20c4dfd964dafeb1227373f224fafac0b01dfc85slive <indent>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive Options +Includes<br />

20c4dfd964dafeb1227373f224fafac0b01dfc85slive SetOutputFilter INCLUDES<br />

20c4dfd964dafeb1227373f224fafac0b01dfc85slive AcceptPathInfo On<br />

20c4dfd964dafeb1227373f224fafac0b01dfc85slive </indent>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive &lt;/Files&gt;

20c4dfd964dafeb1227373f224fafac0b01dfc85slive </example>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive</usage>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive</directivesynopsis>

55eb45d44f175c6809521998627457789f95e240humbedooh

20c4dfd964dafeb1227373f224fafac0b01dfc85slive<directivesynopsis>

20c4dfd964dafeb1227373f224fafac0b01dfc85slive<name>AccessFileName</name>

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

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

d1745d6933c22c807cf2388332426defd1b19f03covener<default>AccessFileName .htaccess</default>

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

d1745d6933c22c807cf2388332426defd1b19f03covener</contextlist>

d1745d6933c22c807cf2388332426defd1b19f03covener

d1745d6933c22c807cf2388332426defd1b19f03covener<usage>

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

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

d1745d6933c22c807cf2388332426defd1b19f03covener そのドキュメントへの

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

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

860b4efe27e7c1c9a2bf5c872b29c90f76849b51jim

d1745d6933c22c807cf2388332426defd1b19f03covener <example>

d1745d6933c22c807cf2388332426defd1b19f03covener AccessFileName .acl

d1745d6933c22c807cf2388332426defd1b19f03covener </example>

d1745d6933c22c807cf2388332426defd1b19f03covener

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

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

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

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

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

d1745d6933c22c807cf2388332426defd1b19f03covener

d1745d6933c22c807cf2388332426defd1b19f03covener <example>

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

d1745d6933c22c807cf2388332426defd1b19f03covener <indent>

d1745d6933c22c807cf2388332426defd1b19f03covener AllowOverride None<br />

d1745d6933c22c807cf2388332426defd1b19f03covener </indent>

d1745d6933c22c807cf2388332426defd1b19f03covener &lt;/Directory&gt;

d1745d6933c22c807cf2388332426defd1b19f03covener </example>

d1745d6933c22c807cf2388332426defd1b19f03covener</usage>

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

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

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

d1745d6933c22c807cf2388332426defd1b19f03covener</directivesynopsis>

d1745d6933c22c807cf2388332426defd1b19f03covener

d1745d6933c22c807cf2388332426defd1b19f03covener<directivesynopsis>

d1745d6933c22c807cf2388332426defd1b19f03covener<name>AddDefaultCharset</name>

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

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

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

d1745d6933c22c807cf2388332426defd1b19f03covener<default>AddDefaultCharset Off</default>

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

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

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

d1745d6933c22c807cf2388332426defd1b19f03covener<override>FileInfo</override>

d1745d6933c22c807cf2388332426defd1b19f03covener

d1745d6933c22c807cf2388332426defd1b19f03covener<usage>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

47ff2654d827dd3596ce2e4099d69cec0f1009b9takashi 例えば:</p>

47ff2654d827dd3596ce2e4099d69cec0f1009b9takashi

47ff2654d827dd3596ce2e4099d69cec0f1009b9takashi <example>

47ff2654d827dd3596ce2e4099d69cec0f1009b9takashi AddDefaultCharset utf-8

47ff2654d827dd3596ce2e4099d69cec0f1009b9takashi </example>

47ff2654d827dd3596ce2e4099d69cec0f1009b9takashi

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

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

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

例を挙げると、レガシーな 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">カスタマイズ可能な

エラー応答のドキュメンテーション</a></seealso>

</directivesynopsis>

<directivesynopsis>

<name>ErrorLog</name>

<description>サーバがエラーをログ収集する場所</description>

<syntax> ErrorLog <var>file-path</var>|syslog[:<var>facility</var>]</syntax>

<default>ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)</default>

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

</contextlist>

<usage>

<p><directive>ErrorLog</directive> ディレクティブは、

サーバに生じたさまざまなエラーを

記録する為のファイルの名前を設定します。

<var>file-path</var> が絶対パスでないときは、<directive

module="core">ServerRoot</directive> からの相対パスとみなされます。</p>

<example><title>例</title>

ErrorLog /var/log/httpd/error_log

</example>

<p><var>file-path</var> がパイプ (|) から始まる場合は、

エラーログを処理するために実行されるコマンドが

指定されていると解釈されます。</p>

<example><title>例</title>

ErrorLog "|/usr/local/bin/httpd_errors"

</example>

<p>ファイル名の変わりに <code>syslog</code> と指定することによって、

システムがサポートしていれば syslogd(8) を利用したロギングが有効になります。

デフォルトでは、<code>local7</code> ファシリティとなりますが、

<code>syslog:<var>facility</var></code> といった形で記述することにより、

通常 syslog(1) のドキュメントで説明されているファシリティの一つを使うように

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

<example><title>例</title>

ErrorLog syslog:user

</example>

<p>セキュリティ:

ログファイルを格納するディレクトリが、サーバを起動したユーザ以外の

ユーザによって書き込める場合にセキュリティが破られる可能性があることに

関する詳細は <a

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

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

<note type="warning"><title>注</title>

<p>Unix 以外のプラットフォームでファイルのパスを入力するときは、

プラットフォームがバックスラッシュの使用を許していたとしても、

確実にスラッシュのみが使用されるように注意してください。一般的には、

設定ファイル全般でスラッシュのみを使う方が良いでしょう。</p>

</note>

</usage>

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

<seealso><a href="/logs.html">Apache ログファイル</a></seealso>

</directivesynopsis>

<directivesynopsis>

<name>FileETag</name>

<description>ETag HTTP 応答ヘッダを作成するために使用される

ファイルの属性</description>

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

</contextlist>

<override>FileInfo</override>

<usage>

<p>

<directive>FileETag</directive> ディレクティブは

ドキュメントがファイルに基づいたものであるときに、

<code>ETag</code> (エンティティタグ) 応答ヘッダフィールドを作成するときに使用する

ファイルの属性を設定します。 (<code>ETag</code> の値はネットワークの帯域を節約するための

キャッシュの管理で使われます。) Apache 1.3.22 以前では、<code>ETag</code> の値は

<em>常に</em>ファイルの inode, サイズ、最終修正時刻 (mtime) から作成

されていました。<directive>FileETag</directive> ディレクティブにより、これらのどれを使うかを

選ぶことができます。認識されるキーワードは:

</p>

<dl>

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

<dd>使用可能なすべてのフィールドを使います。

これは <example>FileETag INode MTime Size</example> と等価です。</dd>

<dt><strong>None</strong></dt>

<dd>ドキュメントがファイルに基づいたものでも、<code>ETag</code> フィールドを

応答に付加しません</dd>

</dl>

<p><code>INode</code>, <code>MTime</code>, <code>Size</code> キーワードには

<code>+</code> や <code>-</code> を前に付けて

指定することもできます。この場合は、より広い範囲から継承された

デフォルトの設定に変更を加えるようになります。そのような接頭辞の

無いキーワードを指定すると、即座に継承した設定を無効にします。</p>

<p>あるディレクトリの設定に

<code>FileETag&nbsp;INode&nbsp;MTime&nbsp;Size</code> があり、

サブディレクトリの設定に <code>FileETag&nbsp;-INode</code> があるときは、

そのサブディレクトリの設定は (設定が上書きされなければサブディレクトリの

サブディレクトリにも継承されます) <code>FileETag&nbsp;MTime&nbsp;Size</code>

と同じになります。</p>

<note type="warning"><title>警告</title>

WebDAV を使っていて、<module>mod_dav_fs</module> をストレージプロバイダとして

使っているような Directory や Location では、デフォルト値を変更しないでください。

<module>mod_dav_fs</module> では、条件付リクエストでの比較演算に

<code>INode&nbsp;MTime&nbsp;Size</code>

の固定フォーマットを使っています。

<directive>FileETag</directive> で <code>ETag</code> フォーマットを

変更してしまうと、条件付リクエストでうまく動作しなくなります。

</note>

</usage>

</directivesynopsis>

<directivesynopsis type="section">

<name>Files</name>

<description>マッチするファイル名に適用されるディレクティブを囲む</description>

<syntax>&lt;Files <var>filename</var>&gt; ... &lt;/Files&gt;</syntax>

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

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

</contextlist>

<override>All</override>

<usage>

<p><directive type="section">Files</directive> ディレクティブは、

その中にあるディレクティブの適用範囲をファイル名で制限します。

<directive module="core"

type="section">Directory</directive> ディレクティブや <directive

module="core" type="section">Location</directive> ディレクティブと

同じような機能を持ちます。

これは、<code>&lt;/Files&gt;</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>を使うこともできます。

例えば、</p>

<example>

&lt;Files ~ "\.(gif|jpe?g|png)$"&gt;

</example>

<p>とすることにより、一般的なインターネットの画像フォーマットにマッチします。

ただし、

<directive module="core" type="section">FilesMatch</directive> を使う方が

推奨されています。</p>

<p>ちなみに、<directive module="core" type="section"

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

>Location</directive> セクションとは異なり、

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

は <code>.htaccess</code> ファイル内で利用することができます。

これにより、ユーザがファイル毎にアクセスの制御を行なうことができるように

なっています。</p>

</usage>

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

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

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

</directivesynopsis>

<directivesynopsis type="section">

<name>FilesMatch</name>

<description>正規表現にマッチするファイル名に適用される

ディレクティブを囲む</description>

<syntax>&lt;FilesMatch <var>regex</var>&gt; ... &lt;/FilesMatch&gt;</syntax>

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

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

</contextlist>

<override>All</override>

<usage>

<p><directive type="section">FilesMatch</directive> ディレクティブは、

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

ディレクティブ同様にその中にあるディレクティブの適用範囲をファイル名で制限します。ただし、

このディレクティブには<glossary ref="regex">正規表現</glossary>を指定します。

例えば:</p>

<example>

&lt;FilesMatch "\.(gif|jpe?g|png)$"&gt;

</example>

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

</usage>

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

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

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

</directivesynopsis>

<directivesynopsis>

<name>ForceType</name>

<description>すべてのマッチするファイルが指定の MIME コンテントタイプで

送られるようにする</description>

<syntax>ForceType <var>MIME-type</var>|None</syntax>

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

</contextlist>

<override>FileInfo</override>

<compatibility>Apache 2.0 で core に移動</compatibility>

<usage>

<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> セクションに

書かれた場合、このディレクティブはそこにあるすべてのファイルが

<var>MIME-type</var>

で指定されたコンテントタイプとして扱われるようにします。たとえば、

GIF ファイルばかりのディレクトリがあって、すべてのファイルを <code>.gif</code>

で終わらせたくはないときに、以下のものを使用します:</p>

<example>

ForceType image/gif

</example>

<p><directive module="core">DefaultType</directive> と違って

このディレクティブはメディアタイプを決めることができるかもしれない

ファイルの拡張子も含め、すべての MIME タイプの関連付けを

上書きすることに注意してください。</p>

<p><code>None</code> という値を使うことで <directive>ForceType</directive> の

設定を無効にできます:</p>

<example>

# force all files to be image/gif:<br />

&lt;Location /images&gt;<br />

<indent>

ForceType image/gif<br />

</indent>

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

<br />

# but normal mime-type associations here:<br />

&lt;Location /images/mixed&gt;<br />

<indent>

ForceType None<br />

</indent>

&lt;/Location&gt;

</example>

</usage>

</directivesynopsis>

<directivesynopsis>

<name>HostnameLookups</name>

<description>クライアントの IP アドレスの DNS ルックアップを

有効にする</description>

<syntax>HostnameLookups On|Off|Double</syntax>

<default>HostnameLookups Off</default>

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

<context>directory</context></contextlist>

<usage>

<p>このディレクティブは、ホスト名をログ収集できるように

DNS ルックアップを有効にします

(さらに、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>

<p>ディレクティブのデフォルトは

本当に逆引きを必要としているわけではないサイトの

ネットワークトラフィックを低減させるために、<code>Off</code> になっています。

ルックアップによる余計な遅延がなくなるため、

エンドユーザにとっても良いでしょう。

DNS のルックアップには、かなりの時間が必要となる場合が多く、

負荷の高いサイトではこのディレクティブは <code>Off</code> にすべきです。

なお、<var>/support</var> ディレクトリに含まれ、デフォルトでは

インストールディレクトリの <code>bin</code> サブディレクトリに

インストールされる <program>logresolve</program> ユーティリティにより、

Apache の動作とは別に、ログに残されている IP アドレスからホスト名を

ルックアップすることが可能です。</p>

</usage>

</directivesynopsis>

<directivesynopsis type="section">

<name>If</name>

<description>実行時、リクエストが条件を満たした場合にのみ適用される

ディレクティブを包含する</description>

<syntax>&lt;If <var>expression</var>&gt; ... &lt;/If&gt;</syntax>

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

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

</contextlist>

<override>All</override>

<usage>

<p><directive type="section">If</directive> ディレクティブは

実行時に式を評価し、条件式が真になるときにのみ

内包するディレクティブを適用します。

例えば</p>

<example>

&lt;If "$req{Host} = ''"&gt;

</example>

<p>上記例は <var>Host:</var> ヘッダの存在しない HTTP/1.0 のリクエストに

マッチします。</p>

</usage>

<seealso><a href="/sections.html">どのように &lt;Directory&gt;, &lt;Location&gt;,

&lt;Files&gt; セクションが動作するか</a> では、リクエストを受けたときに、

これらの異なるセクションがどのように組み合わさるかについて記載されています。

<directive type="section">If</directive> は

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

と同じ処理順と用法になっています。</seealso>

</directivesynopsis>

<directivesynopsis type="section">

<name>IfDefine</name>

<description>起動時にテストが真であるときのみに処理されるディレクティブを

囲む</description>

<syntax>&lt;IfDefine [!]<var>parameter-name</var>&gt; ...

&lt;/IfDefine&gt;</syntax>

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

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

</contextlist>

<override>All</override>

<usage>

<p><code>&lt;IfDefine <var>test</var>&gt;...&lt;/IfDefine&gt;</code>

セクションは、

ディレクティブを条件付きで指定するために利用します。

<directive type="section">IfDefine</directive> セクションに

含まれるディレクティブは、<var>test</var>が

定義されているときのみ処理されます。

もし <var>test</var> が定義されていなければ、

開始と終了の指定の間のディレクティブは無視されます。</p>

<p><directive type="section">IfDefine</directive> セクションディレクティブに

指定する <var>test</var> は、

次の二つの形式のうちの一つをとります:</p>

<ul>

<li><var>parameter-name</var></li>

<li><code>!</code><var>parameter-name</var></li>

</ul>

<p>前者の場合には、<var>parameter-name</var> と名付けられたパラメータが

定義されていれば開始と終了の間のディレクティブが処理されます。

後者の場合は逆で、<em>parameter-name</em> が指定されて<strong>いない</strong>

場合に処理されます。</p>

<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> セクションは

入れ子にすることができ、複数のパラメータによるテストをするために使用できます。

例:</p>

<example>

httpd -DReverseProxy -DUseCache -DMemCache ...<br />

<br />

# httpd.conf<br />

&lt;IfDefine ReverseProxy&gt;<br />

<indent>

LoadModule proxy_module modules/mod_proxy.so<br />

LoadModule proxy_http_module modules/mod_proxy_http.so<br />

&lt;IfDefine UseCache&gt;<br />

<indent>

LoadModule cache_module modules/mod_cache.so<br />

&lt;IfDefine MemCache&gt;<br />